この記事について
2026年5月28日、Anthropicが Claude Opus 4.8 を公開しました。同時に Claude Code には Dynamic Workflows（リサーチプレビュー）という新しい仕組みが入りました。
この記事は「新機能の一覧」を並べるだけの紹介記事にはしないつもりです。Opus 4.8 で変わったのは個々のスペックよりも、Anthropicがどこに賭けているかという設計の重心だと考えているからです。ベンチマークの数字、effortパラメータ、Messages APIの地味な変更、そしてDynamic Workflows。これらを別々の発表として見ると断片的ですが、一本の線で繋ぐと「対話するモデル」から「任せきれるエージェント」へという同じ方向を向いています。
その線を追いながら、それぞれの機能がなぜ存在するのか、どんなトレードオフの上に成り立っているのかまで掘り下げていきます。
本記事のベンチマーク数値は、公式発表ページおよびシステムカード、各種公開情報をもとにしています。公式ページにも比較表の概要はありますが、個別スコアの詳細は Claude Opus 4.8 System Card に委ねられています。数値の一部は二次情報を含み、公式が後から脚注でスコアを更新する場合もあるため、厳密な検証用途では一次情報をご確認ください。
まず結論――何が変わったのか
細かい話に入る前に、全体像を一段高い視点から押さえておきます。Opus 4.8 の変更は、おおむね次の4つに整理できます。
| 領域 | 変わったこと | 背後にある狙い |
|---|---|---|
| モデルの性格 | コードの欠陥を見逃す確率が前世代の約1/4に | 長時間タスクで信頼できること |
| 制御の粒度 | effortパラメータ（high/xhigh/max） | 品質と速度・コストを利用者が選ぶ |
| API設計 | messages配列内にsystemエントリを置ける | 実行中の指示更新をキャッシュを壊さず行う |
| 実行の構造 | Dynamic Workflows | 数百のサブエージェントを並列でオーケストレーション |
価格は入力 $5 / 出力 $25（100万トークンあたり、Opus 4.7から据え置き）。Fast modeは $10 / $50 で、これは従来のFast modeの約3分の1の価格になりました。APIの識別子は claude-opus-4-8 です。
この表の右列、「狙い」をすべて足し合わせると、ひとつの文になります。「人間が張り付かなくても、長く走り、自分で間違いに気づき、コストを調整しながら、大規模に並列で動けるか」。Opus 4.8 はこの問いに対する回答だと読めます。
ベンチマークが描く「いびつな」上達曲線
最初にベンチマークを見ます。ただし数字の高低そのものより、どこが伸びてどこが伸びなかったかというパターンに注目したいと思います。そこに開発元の優先順位が表れるからです。
公開されている主要なスコアを、Opus 4.7との対比で並べてみます。
| ベンチマーク | Opus 4.8 | Opus 4.7 | 差分 |
|---|---|---|---|
| SWE-bench Verified | 88.6% | 87.6% | +1.0 |
| SWE-bench Pro | 69.2% | 64.3% | +4.9 |
| BrowseComp（単一エージェント） | 84.3% | 79.3% | +5.0 |
| MCP-Atlas（ツール利用） | 82.2% | 77.3% | +4.9 |
| HLE（ツールあり） | 57.9% | 54.7% | +3.2 |
| GPQA Diamond | 93.6% | 94.2% | −0.6 |
PC操作系の OSWorld-Verified も 83.4% という高い水準にあります（前世代比は公式が脚注でスコアを更新しており差分の解釈が割れるため、ここでは絶対値のみ示します）。
このテーブルには、わかりやすい物語があります。エージェント系・ツール利用系（SWE-bench Pro、BrowseComp、MCP-Atlas）が軒並み +5前後の大きな伸びを見せている一方で、純粋な学術的知識を問う GPQA Diamond はわずかに下がっています。
この「いびつさ」をどう読むか。私には、これがトレードオフというより優先順位の表れに見えます。あくまで一つの解釈ですが、GPQA Diamond はすでに93〜94%という天井近くに張り付いていて、ここを0.6%押し上げる労力よりも「ツールを使って実環境で長く働く能力」のほうに伸びしろと価値があった、という事情は想像できます。一問一答の博識さが飽和しつつある一方で、いま現場で効くのは「PCを操作し、ブラウザを渡り歩き、外部ツールを正しく呼べる」能力だ、という温度感は数字の並びとも整合します。ただしこれはAnthropicが配分を明言したわけではなく、あくまで結果から逆算した推測である点はお断りしておきます。
もちろん、この読み方が唯一の正解とは限りません。GPQAの微減は誤差の範囲とも言えますし、学習データやRLHFの副作用かもしれません。ただ、伸びている項目の顔ぶれがここまで一貫していると、偶然と片付けるよりは「意図」を読み取るほうが自然に思えます。
公式の証言として、Online-Mind2Webで84%、Legal Agent Benchmarkで「all-pass基準で初めて10%を超えた最初のモデル」という言及もありました。後者は一見地味な数字ですが、「全工程をミスなく通す」基準で測るとまだ10%台という事実そのものが、長時間エージェントの難しさを物語っています。
「正直さ」をスペックとして扱うということ
Opus 4.8 で個人的にもっとも重要だと感じたのは、ベンチマークの数字ではなく次の一文です。
Opus 4.8 は、自身が書いたコードの欠陥を指摘なく通してしまう確率が、前世代の約4分の1になった。
これは「コードが上手くなった」とは別の軸の話です。上手さは「正解を出せる確率」ですが、ここで語られているのは「自分の間違いに気づいて立ち止まれる確率」です。後者は、エージェントとして長時間任せる場面で効いてきます。
なぜか。単純化した具体例で考えてみます。10ステップの作業をエージェントに任せたとして、各ステップで5%の確率で誤りを「正しい」と思い込んで先に進むモデルがあったとします（話を分かりやすくするため、各ステップの失敗は独立だと仮定します。実際のエージェントの失敗は前の誤りを引きずるので独立ではありませんが、感覚を掴むには十分です）。10ステップ通すと、一度もごまかさずに完走できる確率はおよそ 0.95^10 ≒ 60% まで落ちます。この「見逃し率」が4分の1（5%→1.25%程度）になれば、完走率は 0.9875^10 ≒ 88% まで跳ね上がります。長い鎖ほど、一箇所の信頼性の差が効いてくるわけです。
これがDynamic Workflowsの前提条件になっている、というのが私の見立てです。数百のサブエージェントを並列で走らせ、結果を統合する仕組みは、個々のエージェントが「自分の出力を疑える」ことを土台にしています。途中で誰かが平気で嘘の成功報告を上げる集団に、750,000行のコード移植を任せることはできません。
公式でも、スタッフエンジニアの証言として「計画が筋の通らないものなら押し返してくる」「自分のミスを自分で捕まえる」という性質が強調されています。賢さの自慢ではなく、信頼性の話に紙幅が割かれている点に、このリリースの性格が出ています。
Anthropicは併せてアラインメント評価にも触れ、向社会的（prosocial）な特性で過去最高を記録し、ミスアラインな振る舞いの発生率が前世代より大幅に低下したとしています。「正直さ」と「安全性」を別々の話ではなく、同じ信頼性という軸で扱っている点が一貫しています。
effortパラメータ――「賢さ」を蛇口にする
Opus 4.8 では、応答の品質と速度・レート消費のバランスを利用者が選べる effort という制御が前面に出てきました。設定は high（デフォルト）、xhigh、max の3段階です。
ここで面白いのは、デフォルト値の移動です。Opus 4.7 のデフォルトは xhigh 相当でしたが、4.8 のデフォルトは high に下がっています。にもかかわらず、公式は「コーディングタスクにおいて、4.8のhighは4.7のデフォルトとほぼ同じトークン数を使いながら、性能は上回る」と説明しています。
これは何を意味するか。同じ予算（トークン数）で、より良い結果を返せるようになったということです。言い換えると、効率が上がった分を「デフォルトを軽くする」方向に使い、重い処理が必要なときだけ利用者が xhigh / max に引き上げる、という設計に切り替えたわけです。
なぜこの設計なのか、を考えると示唆があります。LLMの推論コストは、突き詰めれば「どれだけ考える時間（トークン）を使うか」に比例します。従来はモデルが一律に「全力で考える」か、開発元が決めた固定値で動いていました。effortは、その思考量を利用者側の蛇口にしたものです。
実務での使い分けは、おおまかにこう整理できます。
- high（デフォルト）: 日常的なコーディング、レビュー、調べもの。速度とコストのバランスが良い
- xhigh: 難しい設計判断、長時間走るワークフロー、一発で精度を出したいとき
- max: トークンを惜しまず最良を取りに行く局面。難問の最後の詰め
ここで注意したいのは、effortは「常に高ければ良い」ものではない点です。簡単なタスクにmaxを使えば、得られる品質差はわずかなのにコストとレート消費だけが膨らみます。蛇口である以上、出しっぱなしは無駄になります。タスクの難易度に対して必要十分なeffortを選ぶ、という運用判断そのものが、これからのコスト管理の一部になっていくのだろうと感じています。
APIから移行する場合は、思考まわりの仕様変更にも目を向けてください。公式ドキュメントによれば、Opus 4.8 は思考量をモデルが適応的に決める方式が前提になっており、従来のような明示的な thinking budget の指定や、temperature / top_p / top_k を既定値以外にする指定が受け付けられないケースがあるとされています。前世代向けに作り込んだリクエストをそのまま投げると弾かれることがあるため、移行時はパラメータの取り扱いを公式仕様で確認しておくと安全です。コンテキストは入力1Mトークン・最大出力128Kトークンと長尺で、長時間エージェントの実行を支える土台になっています。
Messages APIの地味だが効く変更
派手さはありませんが、エージェント開発者にとって効いてくるのが Messages API の変更です。Opus 4.8 では、systemエントリを messages 配列の中に置けるようになりました。
公式の説明はこうです。
開発者は、プロンプトキャッシュを壊さず、ユーザーターンを経由させることもなく、タスクの途中でClaudeへの指示を更新できる。ハーネス内で、エージェントの実行中に権限・トークン予算・環境コンテキストを更新する用途に使える。
なぜこれが重要か。プロンプトキャッシュの仕組みを思い出すと腑に落ちます。LLMのAPIは、同じ前置き（プレフィックス）を再利用するときにキャッシュを効かせて、コストとレイテンシを下げています。ところが従来は、system命令はリクエストの先頭に固定されていました。途中で指示を差し替えようとすると、先頭が変わる＝キャッシュが丸ごと無効になる、という問題が起きていました。
長時間走るエージェントでは、これが地味に痛い制約でした。「ここから先は書き込み権限を外す」「残りトークン予算はこれだけ」「環境が変わったのでこの前提で」といった更新を、実行中に挟みたい場面は頻繁にあります。それを毎回キャッシュを捨てて行うのは、コスト的にも遅延的にも割に合いません。
messages配列の中にsystemエントリを置けるということは、会話の途中に「ここから指示が変わります」という標識を、キャッシュを温存したまま差し込めるということです。一見ニッチな変更ですが、これは後述のDynamic Workflowsのように「実行中に状況が動的に変わる」前提の仕組みを、現実的なコストで回すための土台になっています。機能単体ではなく、エコシステム全体を支える配管だと捉えると位置づけが見えてきます。
ただし、どこにでも自由に置けるわけではありません。配置にはルール（たとえばユーザーターンの直後に置く、といった制約）があるため、実装する際は公式ドキュメントで許される位置を確認してから組み込むことをおすすめします。仕様を誤ると、期待したキャッシュ温存が効かなかったり、リクエストが弾かれたりします。
Dynamic Workflows――対話からオーケストレーションへ
ここが今回の目玉です。Dynamic Workflowsは、Claudeが複雑で多段階のタスクを、複数の並列サブエージェントをオーケストレーションすることで一気通貫でこなす仕組みです。Claude Code（CLI・Desktop・VS Code拡張）とClaude APIで、リサーチプレビューとして提供されています。
業務導入を検討する場合、提供範囲には注意が必要です。利用はMax・Team・Enterpriseといった上位プランが前提とされ、Enterpriseでは管理者が有効化するまでオフになっているなど、組織側の設定が絡みます。APIについても、Anthropic直のほか Amazon Bedrock・Google Vertex AI・Microsoft Foundry 経由での利用が想定されています。プレビュー段階のため提供条件は変わり得るので、導入前に最新の公式情報で対象プランと有効化手順を確認してください。
どう動くのか
公式の説明を分解すると、おおむね次の流れになります。
- Claudeがプロンプトを分析し、実行計画を動的に組み立てる
- 作業を複数のサブタスクに分解し、並列のサブエージェントに振り分ける
- 各エージェントが独立した角度から問題に取り組む
- ある結果に対し、別のエージェントが反証を試みる（adversarialな検証）
- 答えが収束するまで反復する
- 統合する前に、結果を検証にかける
注目すべきは4番目の「反証を試みる」です。これは単なる並列化（同じことを手分けする）ではなく、わざと否定しにかかる役割を別エージェントに持たせる設計です。1つのエージェントが「バグを見つけた」と報告したら、別のエージェントが「それは本当にバグか、再現するか」を疑う。多数決や敵対的レビューを経て、もっともらしいだけの誤りが最終成果に紛れ込むのを防ぎます。
前述の「正直さ」の改善が、ここで効いてきます。検証役が安易に迎合せず、自分の不確実性を率直に示せるからこそ、この相互チェックが意味を持ちます。仲間の出力に流されて全員で同じ間違いに頷くようでは、何重に検証しても意味がありません。
なぜ「動的」なのか
従来の並列処理やマルチエージェントは、処理の形をあらかじめ人間が決めておくのが普通でした。「この3つを並列で実行」と固定的に書く方式です。Dynamic Workflowsの「動的」は、その形（何を並列にし、何を直列にし、いくつ生やすか）をClaude自身がタスクを見てから決める点を指しています。
この違いは大きいです。事前に作業の形が分からないタスク――たとえば「このリポジトリのバグを洗い出す」のように、いくつ見つかるか走ってみないと分からない仕事――では、固定的な計画では取りこぼします。動的に「見つかった数だけ検証エージェントを生やす」ことができて初めて、規模に応じた網羅が可能になります。
中断しても再開できる
実運用で効くのが、途中経過の保存です。公式は「実行の進行に応じて状態が保存されるので、中断されたジョブは最初からやり直すのではなく、止まったところから再開する」としています。
数百のエージェントが数時間〜数日走るような処理では、途中で接続が切れたりエラーで止まったりするのは避けられません。そのたびにゼロからやり直していては、大規模タスクは現実的に回りません。チェックポイントと再開は、長時間オーケストレーションを「実用」に乗せるための必須要件であり、それがプレビュー段階から組み込まれている点に本気度を感じます。
実例――Bunの言語移植
説得力のある実例として、BunのメンテナであるJarred Sumner氏が、BunをZigからRustへ移植するのにDynamic Workflowsを使った事例が紹介されています。結果は、既存テストスイートの99.8%がパスする状態で、約750,000行のRustコードを11日間で、というものです。
この数字の意味を噛みしめてみます。75万行規模の言語移植は、通常なら相当な期間と人手を要する仕事です。それが11日。公式が「四半期で計画していた作業が、数日で終わる」と表現しているのは、この種の事例を指しています。
ただし、これを「誰でも11日でできる」と読むのは早計だと思います。Bunのような明確なテストスイートが存在し、移植元と移植先の対応が比較的構造的に取れる、という条件が揃っていたからこその数字でもあります。「99.8%パス」の裏には、残り0.2%を詰める人間の判断や、テストそのものの質という前提があります。事例の凄みは正しく受け止めつつ、自分のタスクがどれだけこの条件に近いかは冷静に見る必要がありそうです。
コストという無視できない代償
最後に、見落とせない注意点です。公式は明確に警告しています。
Dynamic Workflowsは、通常のClaude Codeセッションよりも大幅に多くのトークンを消費する可能性がある。
これは当然で、数百のサブエージェントがそれぞれ思考し、さらに検証役が反証のために追加で考えるわけですから、トークン消費は対話1回とは桁が違います。effortパラメータと同じく、「強力だからいつも使う」のではなく、「規模と難易度が見合うときに使う」道具です。
ここで先ほどのeffortやFast modeの話と繋がります。注意したいのは、Fast modeは「安い」わけではない点です。入力 $10 / 出力 $50 と、標準料金（$5 / $25）の倍の単価で、あくまで従来のFast modeより3分の1に下がったというだけです。速度を金で買うオプションが現実的な価格帯まで降りてきた、と捉えるのが正確です。効率化（同じ予算で高品質）、速度オプションの低廉化（Fast mode値下げ）、消費制御（effort）――これらは別々の施策に見えて、「大量に並列で走らせる時代」を金銭的に成立させるための布石として一列に並んでいます。
全体を貫く一本の線
ここまで個別に見てきた機能を、最初の問いに戻して束ね直します。
- 正直さの向上: 長い鎖でも信頼を保てるエージェントの土台
- effortパラメータ: 思考量＝コストを利用者が制御する蛇口
- Messages APIのsystemエントリ: 実行中の指示更新をキャッシュを壊さず行う配管
- Dynamic Workflows: それらの上で数百エージェントを動的にオーケストレーション
- Fast mode値下げ: 大量消費を前提とした使い方の経済的な後押し
これらは別々の発表ではなく、「人間が張り付かずに、長く・大規模に・自分で間違いを正しながら走るエージェント」という同じ目的地に向かう部品のように見えます。素の能力向上そのものは、公式自身が「ささやかだが確かな改善（modest but tangible）」と表現する程度で、世代を一気に飛び越えるジャンプではありません。それでも、添えられた機能群を合わせて眺めると、評価の重心が「どれだけ賢いか」から「どれだけ任せられるか」へ少しずつ寄ってきている――その流れを感じ取れるリリースだと、私は受け取りました。もちろんこれは一つの読み方で、単なる順当なマイナーアップデートと捉える見方も十分あり得ると思います。
実務でどう向き合うか
最後に、現場での付き合い方を整理しておきます。あくまで一つの目安として読んでいただければと思います。
- 日常のコーディングやレビュー: デフォルトのhighで十分なことが多いです。まずはここから始めて、物足りなければ上げる運用が無駄が少ないと感じます
- 難しい設計判断や長時間タスク: xhighを検討します。一発の精度が後工程のやり直しコストを上回る場面で効きます
- Dynamic Workflows: 大規模移植、リポジトリ全体の監査、網羅的な検証など「規模そのものが課題」のタスク向けです。トークン消費が桁違いになる点を踏まえ、小さく試してから広げるのが安全です
- コスト感覚: effortもWorkflowsも「強力＝常用すべき」ではありません。タスクの規模と難易度に効果が見合うかを、その都度判断する姿勢が結局いちばん効率的だと思います
新しいモデルが出るたびにベンチマークの数字を追いがちですが、Opus 4.8 については「数字の裏でどんな使い方を想定しているか」を読むほうが、実際の価値に近づける気がしています。