Claude Opus 4.8 Dynamic Workflows 実践分析

5月中旬にAnthropicがClaude Opus 4.8をリリースした。SWE-bench Pro 69.2%、100万トークンのコンテキストウィンドウ、そして2つの新機能であるDynamic WorkflowsとFast Mode。私はリリース当日からドキュメントを読みながらコードを動かしてみたが、期待していた部分と失望した部分がかなりはっきり分かれた。

この記事はその判断の根拠をまとめたものだ。機能の宣伝ではなく、「これは実際に動くのか、どこに使えてどこには使うべきでないか」に絞って書く。

核心評価: 何が本当に変わったのか

一言でまとめると: コンテキストウィンドウの外にオーケストレーションロジックを出した。

なぜこれが重要か。従来のマルチエージェントアプローチでは、オーケストレーターのClaudeが「今このサブエージェントに指示して、結果が来たら次のサブエージェントに指示して」という処理をコンテキストの中で追跡していた。サブエージェントが10個を超えると全ての結果をコンテキストに入れなければならずトークンコストが爆発し、途中で何か失敗すると最初からやり直しになっていた。

Dynamic WorkflowsはこのオーケストレーションロジックをJavaScriptスクリプトに切り出す。Claudeがスクリプトを書いて、ランタイムがバックグラウンドで実行する。中間結果はスクリプトの変数に格納される — Claudeのコンテキストウィンドウに積み上がるのではなく。そのおかげで最終回答だけがコンテキストに返ってくる。

この構造の変化が実質的なスケールの差を生む。公式ドキュメント基準で最大16個の同時エージェント、1回の実行で最大1,000エージェントの総量。従来の方式で1,000エージェントの結果をコンテキストに格納しようとするとどれだけかかるか計算してみれば、すぐ理解できる。

Dynamic Workflowsの構造と動作方式

公式ドキュメントの定義はこうだ: 「Dynamic Workflowは、サブエージェントを大規模にオーケストレーションするJavaScriptスクリプトだ。Claudeがあなたの説明した作業に合ったスクリプトを書き、ランタイムがセッションを応答可能な状態に保ちながらバックグラウンドで実行する。」

有効化する方法は3つある。

1つ目、プロンプトに「workflow」キーワードを含める。 Claude Codeがこの単語を検知すると、自動的にスクリプト記述モードに入る。意図していない場合は alt+w で抑制できる。

2つ目、/effort ultracode コマンド。 xhigh推論努力とワークフロー自動実行権限を同時に付与する。このモードではClaudeが各タスクごとに「これはワークフローが必要な作業か」を自ら判断して実行する。1つのリクエストが連続した複数のワークフローをトリガーすることもある。

3つ目、バンドルされている /deep-research コマンド。 Web検索をファンアウトし、ソースをクロス検証し、結果を投票方式で集計して引用付きレポートを返す組み込みワークフローだ。

セッションのライフサイクルで重要な制約が1つある。再開(resume)機能は同じClaude Codeセッション内でのみ動作する。エディターを閉じて再度開くと最初からやり直しになる。すでに完了したエージェントの結果はキャッシュされ再利用されるが、セッション間で状態は引き継がれない。長時間実行される大規模ワークフローを扱うなら、この点を事前に考慮しておく必要がある。

サンドボックスの制約も注目に値する。ワークフロースクリプト自体はファイルシステムやシェルに直接アクセスできない。ファイルの読み書きやコマンド実行はエージェントの役割で、スクリプトはエージェントを調整する役割だけを担う。この境界が想定よりも厳格で、ワークフロースクリプトから直接ファイル操作を試みて弾かれるケースがある。

Mid-Conversation System Message: 見落とされがちなAPI変更

私はこの変更がDynamic Workflowsと同じくらい重要だと思っている。

Opus 4.8以前はシステムプロンプトが会話の開始時点に固定されていた。会話が始まった後でオーケストレーターに「ここからサブエージェントを並列実行する権限を与える」という指示を追加しようとすると、新しい会話を始めるか、最上位のシステムプロンプトに事前に入れておく必要があった。

Opus 4.8のMessages APIは、messages 配列の途中に system タイプのエントリを入れられる。会話が始まった後で新しい指示や権限をmid-taskで注入できるということだ。

messages_with_injection = [
    {"role": "user", "content": "14個のサービスの認証モジュールのリファクタリング計画を立てて。"},
    {"role": "assistant", "content": orchestrator.content[0].text},
    {"role": "system", "content": "今から並列ワーカーエージェントをスポーンする権限があります。最大16個の同時サブエージェントを実行し、各ワーカーを単一のサービスディレクトリにスコープを限定してください。"},
    {"role": "user", "content": "計画に従ってワーカーにファンアウトして実行して。"},
]

この方式の実用的なメリットはプロンプトキャッシュを壊さないことだ。最上位のシステムプロンプトを変更するとキャッシュが無効化されてコストが跳ね上がるが、mid-conversation injectionはその問題を回避する。長時間のエージェント実行においてキャッシュヒットがコストの相当部分を左右することを考えると、小さくない差だ。

Claude Agent SDK サブエージェント オーケストレーション 実践ガイドで扱った既存の並列処理パターンと比較すると、この変更がいかに自然にそのパターンを拡張しているかが分かる。

Fast Mode: 数字で見る現実

Fast Modeは、出力トークン毎秒(OTPS)を標準比で最大2.5倍に高めるオプションだ。公式ドキュメントが強調しているのは、この速度向上がOTPSに適用されるものであり、TTFT(最初のトークンを受け取るまでの時間)ではないということだ。レスポンスが始まるまでの時間は速くならない。すでにストリーミング中のレスポンスがより速く流れてくるということだ。

価格を見ると:

	入力 (per MTok)	出力 (per MTok)
Opus 4.8 標準	$5	$25
Opus 4.8 Fast Mode	$10	$50
Opus 4.7 Fast Mode	$30	$150

Opus 4.7からOpus 4.8に上がることでFast Modeの価格が3分の1になった。標準の2倍という水準は変わらないが、前世代のFast Modeと比較するとこの数字は確かに意味がある。Opus 4.7とManaged Agentsのコスト分析で検討したper-taskコスト構造と合わせて見ると、実際のパイプラインのどこにFast Modeを組み込むか判断しやすい。

使い方はシンプルだ:

import anthropic
client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    speed="fast",
    betas=["fast-mode-2026-02-01"],
    messages=[
        {"role": "user", "content": "このモジュールを依存性注入方式でリファクタリングして"}
    ],
)

レスポンスオブジェクトの response.usage.speed で実際に適用された速度モードを確認できる。

利用可能な環境に制約がある。 Fast ModeはClaude API(Managed Agentsを含む)でのみ動作する。Amazon Bedrock、Google Vertex AI、Microsoft Foundryでは使用できない。アカウントマネージャーへの連絡やclaude.com/fast-modeの待機登録が必要で、Batch APIやPriority Tierでも使用不可だ。エンタープライズのインフラ選択肢が狭まる制約と言える。

実用性の判断: どこに使い、どこには使うべきでないか

ドキュメントと公開事例を基準に見ると、Dynamic Workflowsが本当の効果を発揮するシナリオはかなり具体的だ。

使えるケース:

コードベース全体のセキュリティ監査が典型例だ。「src/routes/ 配下の全APIエンドポイントで認証漏れがないか監査して」というリクエストに対して、並列エージェントが各ファイルを独立して検査し、敵対的エージェントが結果をクロス検証するパターンは、単一エージェントより信頼度の高い結果を出せる。

大規模マイグレーションも同様だ。BunのファウンダーJarred Sumnerが、Dynamic Workflowsを使ってBunランタイムをZigからRustにポーティングした事例が公開されている — 11日間で約75万行のRustコード、既存テストスイートの99.8%通過。数百のエージェントがファイルごとに並列作業し、レビュアーエージェントが各ファイルを2名ずつ検証し、ビルド/テスト通過ループを自動で回したとのことだ。

エージェントワークフローパターン5種類でまとめた分類で見ると、Dynamic Workflowsは「並列パターン」と「自律パターン」の組み合わせをコード化したものだ。

使うべきでないケース:

単一エージェントで解決できる作業にDynamic Workflowsを使うのはオーバーエンジニアリングだ。タスクを分解できても並列化による恩恵がなければトークンを無駄にするだけだ。厳密に順次的な作業 — 各ステップが前のステップの結果に依存する — も同様で、並列エージェントが追加の価値を生まない。

コストに敏感な環境では特に注意が必要だ。1,000エージェントが標準Opus 4.8料金($5/$25 per MTok)で実行されると、各エージェントが平均どれだけ消費するかによって1回の実行コストがかなりの額になりうる。ワークフローを実行する前に /model コマンドで現在の設定を確認し、サブエージェントをタイトにスコープし、強力なモデルが不要なステップは小さいモデルを使うことが重要だ。

惜しい点と既知の問題

正直なところ、リリースドキュメントで不安な項目がいくつか目についた。

プロンプトインジェクション耐性の退行。 Opus 4.7はGray Swan攻撃成功率6.0%だったのに対し、Opus 4.8は9.6%だ。エージェント環境で外部入力を処理するとき、この数字が意味することは小さくない。特にDynamic Workflowsでエージェントが外部コンテンツを処理する場合、追加のサンドボックスが必要になる。

既知のバグが2件。 ワークフローの途中で早期終了するイシュー、エージェンティックコンテキストでファイルを過剰削除するイシューが公式ドキュメントに明記されている。「既知の問題」として認めているということはチームが認識しているということだが、プロダクションパイプラインに投入する前にこの2点が解消されたか確認が必要だ。

Fast Modeのアクセス制限。 Bedrock/Vertex/Foundry非対応は既存のエンタープライズインフラ投資と衝突する。Fast Modeが必要なユースケースをAPI直接呼び出しにルーティングしなければならない場合、アーキテクチャが複雑になる。

xhigh のデフォルト値の引き下げ。 Opus 4.8はOpus 4.7よりデフォルトの努力レベルが1段階低い。high がデフォルトで xhigh は明示的に設定する必要がある。「コーディングにおいてdefault HIGHが4.7比で同等のトークン数でより良いパフォーマンスを出す」というAnthropicの説明はあるが、4.7を使っていたパイプラインが4.8にマイグレーションする際に動作の変化を検証する必要がある。

多言語タスク。 Gemini 3.1 ProとGPT-5.5が優っていると公式ドキュメントに明記されている。日本語・韓国語などの非英語コンテキスト作業が中心のパイプラインならこの点を考慮しておく必要がある。

コスト構造と実際への影響

AIエージェントのコスト現実で扱ったフレームワークをここに当てはめると、Dynamic Workflowsのコスト構造は「トークン量 × エージェント数」が支配する。

ワークフローランタイム自体に追加料金はない。サブエージェントが消費するトークンが標準Opus 4.8料金で請求されるだけだ。問題は1,000エージェントの上限に近い実行で各エージェントのコンテキストサイズがどうなるかということだ。

公式ガイドが示すコスト管理の原則は4つだ:

• サブエージェントのスコープをタイトに保つ
• シンプルなサブタスクは medium や low 努力レベルを使う
• ワーカーごとに max_tokens に上限を設ける
• 強力なモデルが不要なステップは小さいモデルに置き換える

これらの原則が自然に徹底されなければ、1回のワークフロー実行が予算を超えることが起きる。特にultracodeモードでClaudeが自律的に複数のワークフローを連続トリガーする場合は特にそうだ。

AWOフレームワークでエージェントワークフローを最適化する方法と組み合わせると — 反復的なツール呼び出しをメタツールにコンパイルしてLLM呼び出しを削減するアプローチ — Dynamic Workflowsのコストを構造的に下げる余地がある。

誰に本当に向いているか

現時点でDynamic Workflowsをすぐ実戦投入できるチームとそうでないチームを分けて考えると:

すぐに活用できるケース:

• コードベース全体を対象とした1回限りの大規模監査(セキュリティ、パフォーマンス、パターン検査)
• 数百ファイル以上のマイグレーション作業で並列処理による時間短縮が必要な場合
• 研究や分析作業で独立したソースのクロス検証が信頼度に直結する場合
• Claude Code v2.1.154以上がインストールされており、Pro/Max/Team/Enterpriseプランを使っている場合

もう少し様子を見たほうがよいケース:

• エンタープライズインフラがBedrock/Vertex/Foundry基盤でFast Modeが重要な場合
• 多言語処理がコア機能のパイプライン
• プロンプトインジェクションのリスクがある外部コンテンツ処理システム(既知の退行 + 早期終了バグの解消待ち)
• コスト予測が厳密に必要なプロダクション環境(ワークフロー規模によるコスト変動が大きい)

最終判断

私はDynamic Workflowsが実際に動くと思っている。ただし、適している問題の種類がある。BunのZig-to-Rustポーティング事例は、「並列化可能で、独立した検証が信頼度を高め、規模が単一エージェントを超える作業」においてこの機能がなぜ意味を持つかを最も鮮明に示している。

mid-conversation system message injectionは技術的には静かな変更だが、大規模なエージェンティックパイプライン設計において実質的な影響がある。この部分を十分に理解して使うチームとそうでないチームの実装複雑度の差は、時間が経つにつれて広がっていくだろう。

Fast Modeの値下げは歓迎できる変化だ。前世代比で3分の1の価格になり、適切なユースケース — ストリーミング速度が実際のUXに影響するシナリオ — では標準比2倍のコストを正当化できる。

実際に試してみると、既知のバグ(早期終了、過剰なファイル削除)は今すぐプロダクションに投入するのを慎重にすべき理由だ。ワークフローが途中で止まり、なぜ止まったのかログから把握するのに時間がかかった。この部分が解消されれば評価は変わりうる。

LangGraph、CrewAI、Daprのようなサードパーティフレームワークとの比較で見ると、Dynamic Workflowsのポジションは「Claudeエコシステムの中で、Claude Codeと共に、一度きりではなく繰り返し実行可能な大規模オーケストレーション」だ。汎用フレームワークを置き換えるというよりも、特定の作業種別でClaude nativeアプローチが持つ効率性を示す機能として捉えるのが正確だと思う。