Claude Opus 4.8には、Claude Codeの目玉機能としてDynamic Workflowsが搭載されました。1つのセッションで、オーケストレーションエージェントが何百もの並列サブエージェントを起動し、数十のファイルにわたるリファクタリング、広範なテストマトリックスの実行、複数のソリューションパスの同時探索といった大規模で分岐の多いタスクに対処できます。ターミナル上では魔法のように見えますが、その裏側では2つの具体的な要素が連携して機能しています。
このガイドでは、Dynamic Workflowsが実際にどのように機能するのか、いつ利用すべきか、そして生のAPIを通じて同じオーケストレーションパターンを構築する方法を詳しく解説します。モデル自体については、「Claude Opus 4.8とは」をご覧ください。エージェントアーキテクチャの背景については、「Claude Codeエージェントハーネスの詳細」も併せてお読みください。
Dynamic Workflowsの正体
Claude Codeでは、Dynamic Workflowsは「努力レベル」メニューの「ultracode」というモードとして現れます。ここで理解すべき点は、ultracodeは新しいAPIの努力レベルではないということです。それは、Opus 4.8に既に存在する2つの要素の組み合わせです。
- `xhigh`努力レベル
- 会話中のシステムメッセージ

これらを組み合わせることで、オーケストレーターエージェントは、大規模なジョブを計画するための推論の深さと、ジョブの進行に応じてワーカーエージェントを起動するための常時許可の両方を得られます。これがその秘密の全てです。その他はすべてClaude Codeの内部配線に過ぎません。
要素1:xhigh努力レベル
`effort`パラメータは、ツール呼び出しを含め、Opus 4.8が応答全体に費やすトークンの量を制御します。`xhigh`は、Anthropicが長期間にわたるコーディングやエージェント的な作業に推奨するレベルです。数百万単位のトークン予算で30分を超える実行に調整されています。
Dynamic Workflowでは、オーケストレーターがタスクを独立した単位に分解し、生成するワーカーの数を決定し、それらの結果をマージするといった実際の計画を行う必要があるため、その深さが重要になります。努力レベルが低いと、作業範囲が狭まり、ツール呼び出しの回数も少なくなるため、オーケストレーターが必要とすることとは逆の状況になります。`xhigh`を実行する際には、モデルが十分に思考し、調整できるスペースを確保するために、大きな`max_tokens`(64Kが妥当な開始点です)を設定してください。
要素2:会話中のシステムメッセージ
これが、この仕組み全体を可能にする新しいMessages APIの機能です。Opus 4.8より前は、システムプロンプトは会話の開始時に配置され、固定されていました。現在では、`messages`配列の途中にシステムエントリを配置し、タスクの途中で新しい指示や許可を挿入することができます。
これにより、オーケストレーターは会話が開始された後に、事前に交渉することなく、マルチエージェントワークフローを起動するための常時許可を得ることができます。Anthropicは、このメカニズムを「会話中のシステムメッセージ」で文書化しています。これは小さなAPI変更ですが、大きな結果をもたらします。エージェントは、実行中に発見した内容に基づいて、途中で機能を獲得できるようになります。
Claude Codeで有効にする
Claude Codeでは、Dynamic Workflowsは努力レベルメニューの「ultracode」オプションの裏に存在します。これを選択すると、`xhigh`努力レベルが設定され、会話中のシステムメッセージを通じて並列サブエージェントを生成するセッション許可が与えられます。その後、大規模なタスクを記述し、オーケストレーターにそれを展開させます。

いくつかのことが自動的に起こります。
- Claudeがタスクを計画し、どのように分割するかを決定します。
- 各ワーカーがジョブの一部を担当するように、並列にワーカーを起動します。
- 結果がストリーミングで返送され、メインセッションにマージされます。
Claude Codeをプランでセットアップしている場合、関連する設定については「Claudeプランセットアップガイド付きClaudeエージェントSDK」で説明しています。
Dynamic Workflowsを使用すべき時とそうでない時
Dynamic Workflowsは、広範で並列化可能な作業において真価を発揮します。
- 複数のファイルにわたるパターンの同時リファクタリング
- 大規模なテストマトリックスの生成と実行
- 複数の実装アプローチを並行して探索し、比較する
- 各ワーカーが1つのモジュールを担当する大規模なコードベース分析
これらは、狭い範囲の順次的なタスクには不適切なツールです。1つのファイルの変更のために何百ものサブエージェントを生成することは、何の利益もなくトークンを消費し、各ステップが前のステップに依存している場合、並列ワーカーは役に立ちません。コストは現実的です。何百もの`xhigh`サブエージェントは、数百万のトークンを意味します。作業の形に合わせてパターンを選択してください。
APIを通じて同じものを構築する
オーケストレーションを構築するのにClaude Codeは必要ありません。同じ2つの要素は生のMessages APIで利用可能であり、Anthropicは「オーケストレーションモードを構築する」で実例を提供しています。その形式は次のとおりです。
- `xhigh`努力レベルでタスクを計画するオーケストレーター呼び出しを実行します。
- 会話中のシステムメッセージを使用して、オーケストレーターにワーカーをディスパッチする許可を与えます。
- 各々が1つの作業単位にスコープされたワーカー呼び出しを並列に展開します。
- 結果を収集し、マージのためにオーケストレーターにフィードバックします。
import anthropic
client = anthropic.Anthropic()
orchestrator = client.messages.create(
model="claude-opus-4-8",
max_tokens=64000,
output_config={"effort": "xhigh"},
thinking={"type": "adaptive"},
messages=[
{"role": "user", "content": "Plan a refactor of the auth module across all 14 services."},
],
)
各ワーカーは、そのジョブが狭いため、多くの場合より低い努力レベルで並行して実行できる独立したMessages呼び出しです。これをAnthropicのホスト型エージェントインフラストラクチャと比較検討している場合は、「マネージドエージェント vs エージェントSDK」ガイドがトレードオフを説明しています。
コストと制御
並列サブエージェントは、トークン消費を急速に増加させます。200のワーカーを起動し、それぞれが`xhigh`で数万トークンを消費するDynamic Workflowは、実際のコストがかかります。健全に保つための3つの習慣:
- ワーカーの範囲を厳密に設定し、サブタスクが許す限り`medium`または`low`の努力レベルで実行します。
- 暴走したエージェントが予算を使い果たさないように、ワーカーごとの`max_tokens`を制限します。
- 繰り返されるシステムプロンプトがすべてのワーカーで全額請求されないように、共有コンテキストをキャッシュします。
Opus 4.8の料金内訳には、努力レベルとキャッシングに関する計算が記載されています。要するに、オーケストレーションは強力ですが、請求額はエージェントの数に比例して増加するため、並列処理は意図的な選択として扱う必要があります。
Apidogでオーケストレーションをテストする
APIを通じてオーケストレーションを構築する際、デバッグが難しいのはファンアウトの部分です。ワーカーは正しいスコープのコンテキストを取得しているか、応答はマージステップが期待する形式か、そして会話中のシステムメッセージは正しく届いているか、といった点です。200回のライブワーカー呼び出しの後にバグを発見したくはないでしょう。
Apidogを使用すると、各要素を個別にテストできます。
- 何かをディスパッチする前に、オーケストレーターのリクエストを保存し、計画されたタスクの内訳を検査します。
- ワーカーエンドポイントをモックすることで、何百もの実際の呼び出しにトークンを費やすことなく、ファンアウトとマージのロジックをテストできます。
- ワーカーの応答形式にアサーションを追加し、ペイロードのずれがあれば明確に失敗するようにします。
- 異なる`effort`レベルで単一のワーカー呼び出しをリプレイし、ワーカーあたりのコストを調整します。
Apidogをダウンロードし、`https://api.anthropic.com/v1/messages`に対してオーケストレーターおよびワーカーのリクエストを構築し、まずモック上でループを検証します。「Opus 4.8 APIガイド」には、開始するための基本リクエストが記載されています。モックでロジックが堅固になったら、ライブエンドポイントに切り替えます。
よくある質問
Claude CodeにおけるDynamic Workflowsとは何ですか? 1つのセッションで何百もの並列サブエージェントを起動し、大規模で分岐の多いタスクを処理できる機能です。Opus 4.8の`xhigh`努力レベルと会話中のシステムメッセージによって実現されます。
ultracodeは独立した努力レベルですか? いいえ。ultracodeは、`xhigh`努力レベルとマルチエージェントワークフローを起動するための常時許可を組み合わせたClaude Codeの名称です。APIの努力レベルは引き続き`low`、`medium`、`high`、`xhigh`、`max`です。
会話中のシステムメッセージとは何ですか? Opus 4.8におけるMessages APIの変更で、会話の途中にシステムエントリを配置し、タスクの途中で新しい指示や許可を挿入できるものです。これにより、オーケストレーターは実行開始後にワーカーを生成できます。
Claude CodeなしでDynamic Workflowsを構築できますか? はい。生のMessages APIで`xhigh`努力レベルと会話中のシステムメッセージを使用してください。Anthropicは、ドキュメントにオーケストレーションの実例を公開しています。
Dynamic Workflowsは高価ですか? そうなる可能性があります。何百もの`xhigh`サブエージェントは、数百万のトークンを消費します。ワーカーの範囲を厳密に設定し、可能な限り努力レベルを下げ、共有コンテキストをキャッシュして支出を管理してください。
Dynamic Workflowsを避けるべき時はいつですか? 狭い範囲のタスクや厳密に順次的なタスクの場合です。各ステップが前のステップに依存している場合、並列ワーカーは価値を追加せず、小さなジョブではトークンを無駄にします。
