Anthropic、Claude Codeの「Dynamic Workflows」を一般提供開始――Proプランでも最大1000個の並列エージェントが利用可能に

Anthropicは、Claude Codeの「Dynamic Workflows（ダイナミック・ワークフロー）」機能を研究プレビューから一般提供（GA）へと移行し、Proプランのサブスクリプション登録者向けにも初めて開放した。この機能は、Claude自身がオーケストレーション（協調制御）スクリプトを記述し、1回の実行で最大1,000個の並列サブエージェントを協調させることができる。これにより、これまで月額100ドルのプランでしか利用できなかった強力な機能が、より幅広いユーザー層に提供されることになる。

■コンテキストウィンドウの限界を突破する新アーキテクチャ

Dynamic Workflowsの背後にあるアーキテクチャの進化は、エージェント数という派手な数字以上に本質的である。従来のClaude Codeのパターンでは、モデルは会話のコンテキストウィンドウ内にオーケストレーション計画を保持していた。つまり、すべての中間結果、行き止まりの試行、再試行の履歴がウィンドウ内に蓄積され、最終的にウィンドウが満杯になってしまっていた。50万行規模のコードベースを扱う場合、タスクが完了するはるか前にこの上限に達していたのである。

Dynamic Workflowsはこの計画を外部化する。ClaudeがJavaScriptのオーケストレーションスクリプトを書き出し、それをバックグラウンドで別のランタイムが実行する。そして、モデルのコンテキストには最終的に統合された回答のみが返される。この違いは、単に処理が高速化されるかどうかだけでなく、複数日にわたる自律的な実行がアーキテクチャとしてそもそも可能かどうかを決定づける重要な要素である。

■かつて「手動で構築すべき」とされたパターンを自動化

2024年12月、Anthropicは広く引用されているエンジニアリングガイドを公開し、「プロンプトチェーン」「ルーティング」「並列化」「オーケストレーター・ワーカー」「エバリュエーター・オプティマイザー（評価者・最適化者）」という5つのオーケストレーションパターンを提示した。当時は、これらを開発者が手動でシステムに実装するよう明記していた。それから17か月が経過し、Dynamic Workflowsはまさにこれらのパターンをオンデマンドで自動化するようになった。

開発者は、かつて手動で構築する必要があった「オーケストレーター・ワーカー」のループを自然言語で指示するだけで、その特定のタスクに合わせてカスタマイズされたJavaScriptスクリプトを受け取ることができる。

特に「エバリュエーター・オプティマイザー」パターンにおいて、Dynamic Workflowsは単純な並列分散アプローチと一線を画している。Claudeがタスクを並列のサブタスクに分割してワーカーエージェントを派遣すると、別の「敵対的エージェント（adversarial agents）」のレイヤーが、ユーザーに結果を届ける前にその成果物を検証・追及する。例えば、移行エージェントが「99%完了した」と報告してもそのまま受け入れられず、反論エージェントが「見落としがないか」を徹底的に探索する。この敵対的検証のもとで結果が収束するまで実行が繰り返される。これは、LLMベースのエージェントが「自身の成果を検証させると過剰に成功を報告してしまう」という、よく知られた失敗パターンに対する構造的な解決策である。

■コンテキストウィンドウからの脱却がもたらす変化

過去3年間、自律型AIコーディングへのアプローチは常にコンテキストウィンドウの制約に縛られてきた。大規模なコードベースを処理する単一のLLMエージェントは、作業メモリ内にすべての中間結果を蓄積していく。そのため、ステップ25や50に達する頃には、ステップ5で定義した関数のシグネチャ（仕様）を忘れてしまい、以前に確立したインターフェースと整合しないコードを生成し続け、しかもその矛盾に気づかないという問題があった。

Dynamic WorkflowsのJavaScriptランタイムは、この問題をインフラレベルで解決する。各サブエージェントは、割り当てられた特定のタスク（1つのファイル、1つのエンドポイント、1つのセキュリティチェックなど）のみを含む、クリーンで焦点の絞られたコンテキストウィンドウを受け取る。オーケストレーションのロジック、分岐の決定、中間結果、および検証ループはすべて、単一モデルのメモリ内ではなく、ランタイムが実行するスクリプト上に存在する。

Anthropicのドキュメントによると、1つのワークフローで最大16個のエージェントを同時に実行でき、1回の実行あたりの総エージェント数は最大1,000個に制限されている。進捗は継続的に保存されるため、数時間に及ぶ移行作業が途中で中断されても、最初からやり直すことなく最後のチェックポイントから再開できる。

■BunのRust移植：6日間で96万行を処理した実績の背景

Dynamic Workflowsの実力を示す最も有名な事例が、JavaScriptランタイム「Bun」をZigからRustへと移植したプロジェクトである。ただし、発表時の報道であまり触れられていない事実として、Bunの創設者であるJarred Sumner氏は、Anthropicが2025年12月にBunを買収して以来、同社の従業員であるという点がある。つまり、このBunの移植はAnthropicの社内チームが自社のコードベースに対して自社のツールを実証したものであり、極めて優れたエンジニアリングの成果であるものの、独立した第三者による検証ではないという文脈を理解しておく必要がある。

この移植プロジェクトは、エージェントの実行期間として6日間（最初のコミットからブランチのマージまでは実質約11日間）にわたり、4つのフェーズで実施された。まず、あるワークフローがZigのソースコード内にあるすべての構造体フィールドに対して、正しいRustのメモリ生存期間（ライフタイム）をマッピングした。次に、数百の並列エージェントを派遣して、すべての「.zig」ファイルに対して動作が同一となる「.rs」ファイルを生成し、それぞれの出力に対して2つの敵対的レビューエージェントを割り当てた。その後、ビルドとテストスイートが正常にパスするまで修正ループを回し、最終フェーズで不要なデータコピーを特定してプルリクエストを作成した。

結果として、約96万行のZigの入力から約75万行のRustコードが出力され、Linux x64環境において既存のテストスイートの99.8%がパスした。ただし、このRustブランチに対する第三者の技術分析では、重大な制限も指摘されている。移植されたコードには約13,000〜14,000個の「unsafe」ブロックが含まれている。Rustにおいてunsafeブロックは、コンパイラのメモリ安全性の保証が適用されない領域を明示的に示すものであり、エラーではないものの例外的な処理である。この数の多さは、Zigの明示的なアロケータモデルから、コンパイル時に厳格な借用規則を強制するRustへの機械的な行単位の翻訳という現実を反映している。Sumner氏はこの成果について、洗練された書き直しというよりは「構造的に粗い直訳」と表現しており、今後はRustのコンパイラツールを活用して長期的に安全性を担保していく方針を示している。なお、MacおよびWindowsのテストスイートの完全な結果は現時点でも保留中である。

■数日間に及ぶエージェント実行の「実際のコスト」

Dynamic Workflowsを導入する前に、チームはトークン消費の計算が非線形であることを理解しておく必要がある。並列エージェントはトークンを共有しない。各エージェントが独立してトークンを消費するため、10個のエージェントを並列実行すると、同じ実時間で単一エージェントを実行した場合の約10倍のトークンコストが発生する。

Claude Opus 4.8の価格（入力トークン100万個あたり5ドル、出力トークン100万個あたり25ドル）を適用すると、24時間のフル並列実行で400ドルから600ドル（約6万4,400円〜9万6,600円、1ドル=161円換算）のコストがかかる可能性がある。Anthropicは、Dynamic Workflowsが「通常のClaude Codeセッションよりも大幅に多くのトークンを消費する」と警告しており、コードベース全体に適用する前に、まずは範囲を絞ったタスクから開始することを推奨している。

The Futurum Groupでソフトウェアライフサイクルエンジニアリングのプラクティスリードを務めるMitch Ashley副社長は、検証作業が組織にとってより困難な課題になると指摘する。「1つのセッションが移行や監査の過程で数百のサブエージェントに分散すると、変更のペースが人間の手によるレビューの限界を超えてしまう。これを導入する組織は、生成のペースに合わせてスケールする検証、ガバナンス、エビデンスの記録体制を整える必要がある。これを後回しにすれば、ツールによる恩恵よりも早く『検証負債』が蓄積することになるだろう」

■利用プランと開始方法

今回の一般提供開始に伴い、Dynamic Workflowsはすべての有料Claude Codeプランで利用可能となった。

・Proプラン（月額20ドル、約3,220円）：利用可能だが、デフォルトではオフ。Claude Codeインターフェースで「/config」を実行して有効化する（セッション中維持される一回限りの設定）。
・MaxおよびTeamプラン：デフォルトでオン。
・Enterpriseプラン：デフォルトでオフ。組織の管理者が管理設定またはClaude Codeの管理者設定ページから有効化する必要がある。

この機能は、Claude CodeのCLI、デスクトップアプリケーション、VS Code拡張機能のほか、Claude API、および3大クラウドプラットフォーム（Amazon Bedrock、Vertex AI、Microsoft Foundry）経由で動作する。

ワークフローを開始するには、プロンプトに「ultracode」というワードを含めるか、Claudeに直接「ワークフローを作成して（create a workflow）」と指示する。ワークフローが初めて起動すると、Claude Codeは計画されたフェーズを表示し、実行前に確認を求めてくる。セッションレベルの自動化として、エフォート（effort）メニューで「ultracode」設定を有効にすると、与えられたタスクにマルチエージェント処理が必要かどうかをClaudeが自律的に判断するようになる。ただしAnthropicは、日常的な作業ではこの設定をオフにし、タスクの大部分が大規模、曖昧、または重要度の高いセッションに限定して使用することを推奨している。

■OpenAI Codexの並列アプローチとの違い

競合するエージェント型コーディングツールであるOpenAIのCodexは、隔離されたクラウドコンテナを通じて並列タスクの実行をサポートしている。各タスクは、実行開始後にネットワークアクセスが遮断されたサンドボックス環境で実行される。

Dynamic Workflowsとのアーキテクチャ上の違いは、協調制御（コーディネーション）がどこで行われるかにある。Codexは並列タスクをキューに投入して独立して実行するが、Dynamic Workflowsは開発者に結果を返す前に、出力に対して検証および敵対的レビューのレイヤーを実行する。実務において、Claude Codeのアプローチは、エージェント間で知見を共有し、収束した回答に向けて反復処理を行う必要があるタスク（一方のエージェントの発見が他方の作業範囲に影響を与えるような移行や監査など）に適している。一方、Codexのクラウド委譲モデルは、明確に定義されたタスクを丸投げし、ローカルセッションを維持することなくプルリクエストを受け取りたいチームに好まれる傾向がある。

■注目ポイントQ&A

●Dynamic Workflowsと、従来のClaude Codeのサブエージェントアプローチとのアーキテクチャ上の違いは何ですか？

従来のマルチエージェントパターンでは、すべての協調決定と中間結果がモデルの会話コンテキストウィンドウ内に保持されていました。ウィンドウサイズは固定されているため、大規模な移行作業ではタスク完了前にウィンドウが満杯になっていました。Dynamic Workflowsでは、オーケストレーション計画をJavaScriptスクリプトに移行し、バックグラウンドの別ランタイムで実行します。コンテキストウィンドウは最終的な回答のみを受け取るため、ウィンドウを使い果たすことなく、数時間にわたる実行で数百のエージェントを協調させることができます。また、スクリプトは再現可能な成果物として残ります。

●AIによるコード移行において、Dynamic WorkflowsはOpenAI Codexとどのように異なりますか？

どちらもマルチエージェントの並列実行をサポートしていますが、協調制御の方法が異なります。Claude CodeのDynamic Workflowsには「敵対的検証レイヤー」があり、並列エージェントの作業完了後、別のエージェントがその成果を検証・追及して結果を収束させます。一方、OpenAI Codexは隔離されたコンテナでタスクを実行してプルリクエストを返しますが、同様の明示的な敵対的レビューレイヤーは備えていません。セキュリティ監査や、テストスイートの合格を基準とする大規模移行など、成果物全体の正確性を検証する必要があるタスクにおいて、Dynamic Workflowsの検証アーキテクチャが強みとなります。

●Dynamic Workflowsの実行には実際にどのくらいのコストがかかりますか？また、コストを抑える方法はありますか？

トークンコストはエージェント数に応じて線形に増加します。Claude Opus 4.8の価格設定では、24時間の本格的な並列実行で400ドルから600ドル（約6万4,400円〜9万6,600円）かかる可能性があります。ProおよびMaxプランの契約者の場合、この機能は個別課金ではなくプランの利用制限から消費されます。コストを管理するため、Anthropicはリポジトリ全体ではなく単一のディレクトリの監査など、範囲を絞ったタスクから開始してコスト感を把握することを推奨しています。また、プロンプトでトークン予算を設定することや、「/workflows」ビューでエージェントごとの消費量を監視することが主な管理手段となります。

●「ultracode」設定とは何ですか？どのような時に使用すべきですか？

ultracodeは、Claudeの推論レベルを最大（xhigh）に設定し、タスクにDynamic Workflowを適用すべきかどうかをClaudeに自動判断させるセッションレベルの設定です。セッション内の以降のすべてのタスクに適用されるため、各リクエストの処理時間が長くなり、消費トークンも増加します。そのため、Anthropicはタスクの大部分が大規模、複雑、または重要度の高いセッションでのみ有効にすることを推奨しています。日常的な作業では、「/effort high」に下げておくことで、単一のエージェントでより迅速かつ安価に処理できるタスクに高額なワークフローが実行されるのを防ぐことができます。

元記事: Claude Code Dynamic Workflows Go GA: Pro Users Can Now Spawn 1,000 Parallel Agents