Claude Opus 4.8 を初日に触る — effort control と Dynamic Workflows を運用者の実務で読む

結論 — Opus 4.8 で運用者が今日から変えられるのは「つまみ」と「料金」と「自己点検」

2026 年 5 月 29 日、Anthropic が Claude Opus 4.8 (model ID claude-opus-4-8) を公開しました。私が auto-publish を回す側として真っ先に効くと感じたのは 3 つです。応答の計算量を選べる effort control、fast mode の値下げ、そして「自分が書いたコードの欠陥を見逃しにくくなった」という信頼性の改善。ベンチマークの細かい数字より、この 3 つの方が日々のコストと品質に直結します。

この記事は AI が下書きを書き、私が公式アナウンスに当たって確認・編集してから公開しています。正直に書くと、その下書きを起こしたのが当の Opus 4.8 でした。新しい自分を自分で紹介する妙な構図ですが、だからこそ数字は人間の私が一次情報で裏取りしています。

何が変わったか — 料金は据え置き、信頼性が一段上がった

最初に押さえるべきは「値段が同じで中身が良くなった」という事実です。Opus 4.8 の API 料金は前世代の Opus 4.7 から据え置きで、入力は 100 万トークンあたり 5 ドル、出力は 100 万トークンあたり 25 ドル。月末の請求が変わらないままモデルだけ上がるアップデートは、個人で運用している身には一番ありがたい形です。

信頼性で目を引いたのは、Anthropic が「自分が書いたコードの欠陥を、前世代より約 4 倍見逃しにくくなった (around four times less likely to allow flaws in its own code to pass unremarked)」と表現していた点でした。生成したコードを自分で素通しせず、引っかかる場所で立ち止まる確率が上がった、という主張です。エージェント的なタスクで「曖昧なら質問を返し、間違いに気付く」判断力も上がったとされています。

公式のClaude Opus 4.8 アナウンスにはコーディング・エージェント・推論の比較表とシステムカードへのリンクがあります。ベンチマークの個別スコアは表側に当たるのが正確なので、ここでは「料金据え置き + 自己点検の改善」という運用に効く 2 点に絞って読みます。

fast mode の値下げ — 速さに払う割増が 3 分の 1 に

速度を優先したいときの fast mode (応答を高速化する課金モード) が安くなりました。入力 100 万トークン 10 ドル、出力 100 万トークン 50 ドルで、Anthropic は「以前のモデルの fast mode より 3 倍安い」と書いています。通常モードの倍の単価で 3 倍速い、という割り切りなら、対話的に詰める作業では十分に元が取れます。

私の使い分けはこうです。記事の下書きを一気に書かせる長いバッチは通常モード、Admin で本文を直しながら相談する対話は fast mode。auto-publish のように夜間に無人でバッチを回す処理は、速さより単価が効くので通常モードのままにしています。トークン単価とどう向き合うかは コンテキストエンジニアリングで Claude Code のトークン消費を半分にした実務観点 でも書きましたが、モデルが安くなるたびに「どこを速さに振るか」の線は引き直しています。

effort control — 品質とコストのつまみを記事ごとに回す

effort control は、応答にどれだけ計算量をかけるかを呼び出し側で選べる機能です。深く考えさせれば品質は上がるがコストと待ち時間も増える。浅くすれば速くて安いが詰めが甘くなる。そのつまみが、ようやく明示的に手元に来ました。

auto-publish には品質 4 指標 (見出し階層・本文長・出典数・既存記事との重複) のスクリーニングがあり、通らなければ最大 5 回まで書き直させています。ここで effort を低めから始めて、リトライのたびに上げていく、という回し方が素直に効きそうだと考えています。1 回目で通れば安く済み、グレーな題材で粘るときだけ計算量を足す。全部を最大 effort で回すのは、毎回タクシーで通勤するようなもので、財布が静かに痛みます。

Dynamic Workflows と並列サブエージェント — 「脳みそ 1 個問題」の続き

Dynamic Workflows (research preview) は、大規模な作業に数百の並列サブエージェントを投入する仕組みです。コードベースの一括移行のような、横に広い作業を一斉に分担させる用途が想定されています。

ここで私が立ち止まるのは、生成側が並列化しても、最後にレビューする人間は 1 人だ、という単純な事実です。同じ悩みを 並列 AI エージェントと人間の脳みそ 1 個問題 で書きました。数百のサブエージェントが速く正確に動くほど、人間のレビュー帯域がボトルネックになる。Dynamic Workflows は魅力的ですが、私の運用ではまず「人間が一度に確認できる単位」に出力を畳む設計を先に決めないと、速さがそのまま見落としに化けます。

Messages API の system entries — タスク途中で指示を差し込める

Messages API に、messages 配列の途中へ system エントリ (モデルへの指示) を置ける拡張が入りました。会話の頭で全部指示し切らず、タスクの途中で方針を差し込めるようになる、という変更です。

長い自律タスクでは「やっぱりここは出典を 1 件増やして」のような微調整を、会話を作り直さずに途中で渡せると助かります。SDK 側の細かい挙動拡張は Anthropic SDK の thinking-token-count beta のときも実務での効き方を確かめてから採り入れました。今回も auto-publish の各段に組み込むかは、まず手元で 1 本書かせて挙動を見てから決めます。

まとめ — 派手な数字より、料金据え置きと自己点検

Opus 4.8 で私が重く見たのは、ベンチマークの順位より「料金が据え置きのまま、自分のコードの欠陥を 4 倍見逃しにくくなった」という地味な 2 点です。生成側が自分の出力を疑う精度が上がるほど、私が最後に握る人間レビューの工程は楽になります。けれど楽になることと、手放すことは違う。

AI に正誤を委ね切れない理由は 5 つのフロンティア LLM は事実判定の 67% で割れる で数字付きで書いた通りで、賢くなったモデルでも最終判断は人間が握る形を続けます。AI が起稿し私が確認して公開する 二段階のパイプライン は、モデルが上がっても変えません。effort のつまみは新しくなりましたが、最後に責任を持つ人間という一番外側のつまみは、これからも私の手元に置いておきます。