Claude 動的ワークフロー：主担当 Agent がプログラムを書き、複数の Agent が段階的に大規模タスクを完遂する

動的ワークフロー（Dynamic Workflows）とは、Claude がタスクに応じた進行を管理するプログラムを書き出し、そのプログラムが複数の Agent を指揮して段階的に作業を完了させる仕組みです。 主担当 Agent は目標の理解、プログラム作成、最終回答の提示を担当し、プログラム側がタスクの割り振り、中間結果の受け渡し、後続フェーズの進行を受け持ちます。資料の読み込み、分析、突合は、各フェーズで実行を担当する Agent が行います。

この機能は、Anthropic が開発者向けに提供するマネージド Agent サービス「Claude Managed Agents」の一部です。実行環境、セッション、認証情報はプラットフォーム側で管理され、開発者は自身のアプリケーションに組み込むことができます。動的ワークフローは現在、パブリックベータとして公開されています。

主に以下の5つの機能を提供します：

• タスクに応じたフロー生成：主担当 Agent が現在のタスクに合わせたプログラムを作成します。先行フェーズの結果に応じて後続の処理を決定したり、再確認や再試行を組み込んだりできます。
• フェーズ別の並行処理：多数の資料を複数の Agent に同時に読み込ませ、完了後に集約フェーズや突合フェーズへと進めることができます。
• 個別閲覧とファイル共有：各 Agent は独立した対話履歴を持つ一方で、セッション内の共有ファイルにアクセスできるため、同一の資料群を引き継いで処理しやすくなっています。
• バックグラウンド実行：プログラムはサーバー側で動作するため、主担当 Agent はユーザーへの対応を継続するか、現在のターンを終了して結果を待つことができます。
• 進捗確認とコスト制御：開発者はフェーズや実行スレッドのイベントを確認でき、セッション予算（Budget）によってワークフローを含むモデル全体の支出を制限できます。

300 件の契約書：分割読み込みから1つの回答へまとめる流れ

たとえば、300 件の契約書の中から「経営権変更（チェンジ・オブ・コントロール）条項」が含まれるものを抽出するケースを考えてみます。この種の条項は会社の経営権が移転した後の権利や義務に関わるため、精査には契約書の具体的な文面を確認する必要があります。

1 件ごとの読み込みは手分けして進められますが、最終的には誰かが結果を取りまとめる必要があります。どの契約書が該当したのか、その根拠はどこにあるのか、どの結果を再確認すべきか——動的ワークフローは、こうした調整作業をプログラムに委ねます。

主担当 Agent は目標を受け取ると、「契約書の読み込み」と「集約・突合」の2つのフェーズからなるワークフローを書き出します。第1フェーズでは、プログラムが各契約書を読み込み担当 Agent に振り分けます。各 Agent は独立した対話の中で資料を処理し、結果をプログラムに返します。

各読み込み担当 Agent の対話履歴は独立しており、他の Agent のコンテキストに自動で取り込まれることはありません。次フェーズに必要な情報は、プログラム経由で明示的に渡されます。一方で、各 Agent は同一サンドボックス内のファイルにアクセスし、セッションの認証情報も共有します。独立しているのは読み込みやツール呼び出しの対話履歴であり、ファイルワークスペース自体は共有されています。

たとえば、読み込み担当 Agent に契約書番号、条項の原文、一次判定を返させ、プログラムがそれらの結果をレビュー担当 Agent に引き渡すよう構成できます。これにより、レビューフェーズでは確認に必要な整理された情報だけを受け取ればよく、すべての読み込み対話ログを再読み込みする必要がなくなります。

続いて、プログラムは一次判定の結果を第2フェーズの Agent に渡し、発見事項の突合と統合を行わせます。さらに、この契約書タスクに対して手戻り（リトライ）ルールを設計することも可能です：レビューに合格すれば結果を集約し、不合格で再試行が許容される場合は関連資料を再読み込みして再びレビュー担当 Agent に引き渡します。設定した上限回数に達しても不一致が解消しない場合は、未解決の問題としてレポートを出力して終了します。プログラムは返された判定に応じて次のステップを選択し、その具体的なルールは今回のタスク向けに生成されたワークフローによって決定されます。

このように、主担当 Agent はメインの対話内で1件ずつ報告を受け取り、次のタスクを振り直す必要がありません。通常、ワークフローが終了すると、主担当 Agent は集約結果を読み取るためのターンを1回受け取り、ユーザーに最終回答を提示します。下記の契約書デモは、読み込み、突合、回答までの基本的な流れを示しています。

「動的」と呼ばれる理由は、プロセスがタスクに合わせて生成され、後続の手順も直前の結果に応じて変化できる点にあります。ユーザーがあらかじめ契約書ごとに固定の Agent を構成しておく必要はありませんが、目標、突合ルール、失敗時の処理方針、終了条件は明確に指示しておく必要があります。

バグ検出の向上は何を意味しているのか

Anthropic は、11.6 万行のコードベースに 70 個のバグを埋め込み、単一 Agent と動的ワークフローのそれぞれで 3 回ずつ実行しました。

単一 Agent が 3 回で検出したのは 14 個、15 個、27 個でした。一方、動的ワークフローは 3 回とも 66 個を検出しました。埋め込まれた 70 個のバグを分母とすると、前者の検出割合は 20.0%、21.4%、38.6% であり、後者はいずれも 94.3% で、毎回 4 個の未検出が残りました。

この実験結果が支持する判断は、「今回のコード調査タスクにおいて、ワークフローはより多くのバグを発見でき、3 回の検出数もより安定していた」ということです。複雑な調査タスクの編成手法として試す価値があると言えます。

ただし、3 回とも検出数が同じだからといって、毎回まったく同じバグ群を発見したとは限りません。自身のコードレビュータスクを評価する際は、見つかった数だけでなく、見落としや誤検知が許容範囲内かも確認する必要があります。

また、94.3% は今回埋め込まれたバグに対する検出割合です。すべてのコードレビューに通用する汎用的な正解率ではなく、誤検知の発生状況も含まれていません。元の報告では、同一予算下での比較、総トークン消費量、所要時間は開示されていません。費用対効果が優れているかを判断するには、実際の業務タスクにおいて結果、所要時間、費用のバランスを検証する必要があります。

どのようなタスクが動的ワークフローに適しているか

まずタスクを分割処理できるかを見極め、次に結果を統合できるかを確認します。数百件の契約書精査、複数モジュールにわたるコード調査、大量資料のクロスチェックなどは、いずれも独立した処理単位が存在し、最後に集約を必要とします。対象が1〜2件の契約書にとどまる場合や、各ステップがユーザーとの前回のやり取りに依存する場合は、通常どおり主担当 Agent が直接処理するほうが適しています。

同じマルチ Agent 協調でも、違いは「誰が次のステップを決めるか」にあります。動的ワークフローはプログラムが進行を担います。通常のサブ Agent では主担当 Agent がタスクを委託し、報告を読んで追加質問を行います。Advisor は主担当 Agent に助言を提供するのみで、実際の作業は主担当 Agent が行います。

たとえば、契約書の一括読み込みはワークフローに任せ、特定の難解な契約書について専門家と議論を深めたいときは、通常のサブ Agent による継続的な追問が適しています。計画段階や最終確認で顧問モデルの判断を借りたいだけなら、Advisor を利用します。これら3つの方式は併用可能です。

通常のサブ Agent のスレッドは保持してメッセージを送り続けることができますが、委任は1階層のみサポートされ、1つのセッションで同時に保持できる子スレッドは最大 25 個（アイドル状態のスレッドも含む）です。ワークフロー内のスレッドはこの 25 個にはカウントされませんが、追加の質問を送ることはできません。サーバー側は遅くとも実行完了時にこれらのスレッドをアーカイブし、その後も記録の照会が可能です。

役割分担のあと、資料が実際に処理されたかをどう確認するか

自動調整は「次のステップを誰が進めるか」を解決するものであり、ユーザーにとって何が合格基準かを定義してくれるわけではありません。契約書精査の場合、最終的にヒットした契約書リストを受け取るだけでは不十分です。各結論について原文の該当箇所へ遡れること、ヒットしなかった契約書も再確認されていること、読み込みに失敗したファイルが個別にリストアップされていることが求められます。

特に注意すべきは、「条項が見つからなかった」ことと「契約書が読み込めなかった」ことの区別です。前者は読んだ上での判定ですが、後者はタスク自体が未処理であることを意味します。読み込み失敗を「該当なし」のリストに混ぜてしまうと、一見完全に見えるレポートの中に重大な見落としが潜むことになります。

タスクを指示する際は、次のような突合要件を含めると有効です。以下は契約書精査シナリオを想定した指示の例です：

動的ワークフローを使用して contracts/ 内の全契約書を精査し、経営権変更（チェンジ・オブ・コントロール）条項を探してください。
一次判定は契約書ごとに分担し、条項を発見した場合は原文を抜粋して該当条項またはページ番号を明記し、未発見の場合はその旨を明確に記録してください。
第2ラウンドでは、一次判定で該当しなかった契約書を含め、全契約書を独立して再確認してください。2つのラウンドで結果が食い違った場合は、再度突き合わせて判定を下してください。
読み込み失敗やタイムアウトが発生したファイルは、未該当として処理せず、未処理リストに個別に記載してください。
最終出力には、精査完了件数、該当契約書と根拠、再確認でも条項が見つからなかった契約書、未処理のファイルとその理由を列挙してください。
今回の実行時間上限を 1 時間 に設定してください。

これらの要件は、生成されるワークフローに明確な突合基準を与えます。最終的には、ワークフローがこれらを確実に履行したか、とりわけカバー件数と失敗リストを検証する必要があります。

UI 上に completed と表示されても、ワークフロープログラムが正常終了したことしか意味しません。プログラムがあるファイルの読み込みエラーに遭遇した際にスキップを選択した場合でも、実行ステータスは completed と表示されることがあります。タスクが真に完了したかを判断するには、成果物と各実行スレッドのエラーログを確認する必要があり、フェーズ完了やプログラム全体の完了イベントだけを信じてはいけません。

トラブルシューティングの際、フェーズイベントはフローがどこまで進んだかを把握するのに役立ち、実行スレッドのメッセージやツール呼び出し履歴はどの資料の読み込みが失敗したかを特定するのに役立ちます。メインイベントストリームには実行、フェーズ、スレッドのステータスが集約されますが、詳細な読み込みやツール呼び出しログは各スレッド固有のイベントストリームに含まれます。両方のログを突き合わせて確認する必要があります。API には各スレッドがどのフェーズに対応するかを直接示すフィールドは用意されていません。

クライアント側からは、デフォルトではワークフローのコード、起動や管理に関わる内部呼び出し、各 Agent がプログラムに返した中間値は見えません。実際の分担やリトライルールを確認したい場合は、ワークフローが終了し主セッションがアイドル状態になった後、主担当 Agent に対し、起動時に使用したプログラムを逐語的に出力させ、新たなワークフローを起動しないよう明示して指示するとよいでしょう。

バックグラウンド実行時における規模と費用の制御

実行に参加する各 Agent はそれぞれトークンを消費します。分担数やレビューラウンドを増やすと消費量も増加するため、導入初期は範囲が明確なタスクを選んで成果と消費量を観察し、段階的に複雑度を上げていくのが賢明です。

「1回の実行で最大 1,000 Agent」という制限は、実行期間全体を通じて累積で起動できる数の上限であり、1,000 個が同時に並行稼働できるわけではありません。現在、1 つのワークフローで同時に実行できるワーカースレッドは最大 64 個であり、溢れたタスクはキューに入って待機します（64 という数値は現在のサーバー側設定であり、今後調整される可能性があります）。累積申請数が 1,000 Agent を超えると実行は終了します。なお、失敗したタスクに対するサーバー側の自動再試行によって新しいスレッドが生成される場合があるため、最終的なスレッド総数は 1,000 を超えることもあります。

同一セッション内では、デフォルトで未終了のワークフローを最大 10 個まで同時に保持できます（一時停止中のものも枠を消費します）。各実行の有効期間（lifetime）はデフォルトで最大 24 時間であり、より短い上限を設定することも可能です。予算枯渇による一時停止や、クライアント側でのツール要求処理待ちの経過時間も、この 24 時間のカウントに含まれ、タイマーが止まることはありません。

予算による一時停止でも、費用が厳密な数値で止まるわけではない

セッション予算（Budget）はモデルの公表価格に基づいて支出を算出し、主担当 Agent およびワークフロー全体のモデルリクエストを対象とします。上限に達するとワークフローは一時停止しますが、すでに送信済みのモデルリクエストは最後まで処理されるため、最終的な消費額が予算を超過する可能性があります。

予算はセッション作成時に設定する必要があり、作成後に新規追加することはできません。すでに設定されている予算の引き上げや解除は可能です。予算を引き上げるか解除すると、予算枯渇で停止していたワークフローの実行を再開（resume）できる場合があります。ただし、ユーザーによる中断（interrupt）など他の理由で同時に停止していた場合は、自動復帰するとは限りません。

メインの対話を中断しても、バックグラウンド処理の停止とは限らない

クライアント側から送られる user.interrupt は主担当 Agent の現在のターンを中断しますが、ワークフロー自体は終了しません。バックグラウンドタスクはそのまま継続するか、あるいは一時停止状態になります。確実に停止させたい場合は、主担当 Agent にワークフローの停止を指示し、実行終了イベントの結果が stopped になったことを確認してからセッションをアーカイブする必要があります。未終了のワークフローが残っている場合、アーカイブ要求は拒否されることがあります。

主担当 Agent が終了結果を読み取るタイミングにも注意が必要です。予算枯渇時や、メインスレッドがクライアントの応答待ちになっている間は、この結果取得ターンが遅延します。また、ユーザー中断のあとは結果が自動的に読み込まれない場合があり、結果を読み取って処理を続行するよう追加のメッセージを送信する必要があります。

予算が枯渇したセッションは新しいユーザーメッセージを直接受け付けられません。停止指示を送る前に、まず予算を引き上げるか解除する必要があります。しかし、この操作自体がバックグラウンド実行を再開させる可能性もあるため、「予算の追加」と「タスクの停止」は別個の操作として意識する必要があります。

タスクがファイルを変更したり外部ツールを呼び出したりする場合は、再試行への配慮も欠かせません。同一のサブタスクが再実行される可能性があるため、ツール側は重複リクエストを識別し、同一操作の繰り返しによる意図しない追加の変更を防げるようにしておく必要があります。

開発者向け導入手順：まずワークフローを許可し、次いでタスクを指示する

Agent の定義において、multiagent.type を multiagent_20261001 に設定することで、この協調機能を有効化できます。このタイプでは動的ワークフロー、通常のサブ Agent、インライン Agent がデフォルトで有効になり、Advisor はデフォルトで無効になっています。開発者がユーザーメッセージやシステムプロンプト内でどのような場面でワークフローを使用すべきかを指示し、主担当 Agent が起動の要否を判断します。ワークフローを起動するための特別な API を個別実行する必要はありません。

セッションは作成時点でその時の Agent 設定を複製（クローン）して保持するため、後から Agent 定義を変更しても、既存のセッションには反映されません。設定を変更した場合は、更新後の設定を適用するために新しいセッションを作成してください。

ワークフローを有効化してからタスクを指示

設定例

実行役となる Agent の指定には2つの方法があります。事前に作成した Agent を使用し、それぞれのモデル、プロンプト、ツールを指定しておく方法と、主担当 Agent またはワークフローがインライン Agent をその場で一時定義し、現在のサブタスクに応じたプロンプトを記述させる方法です。インライン Agent は主担当 Agent のモデルを継承し、ツール、MCP、Skills は主担当 Agent が持つ能力のサブセットとして割り当てられます。事前定義 Agent の2つの設定リストには、それぞれ最大 20 個の異なるロールを登録でき、バージョンは設定の作成時または更新時に固定（ピン留め）されます。

Advisor を使用する場合は、メインモデルと顧問モデルのペアリング要件を満たす必要があります。Advisor は一時的なスレッドを通じて助言を提供するものであり、通常のサブ Agent のように継続的な追問を行うことはできません。

Claude Code セッションでは、公式のオンボーディングコマンドを使用して bug-hunter テンプレートの構成を開始できます：

/claude-api managed-agents-onboard bug-hunter

また、コンソールのクイックスタートテンプレートにアクセスして開始することも可能です。まずは対象範囲を絞ったタスクで役割分担、結果の確認、支出状況を確認し、その後に資料全体へと規模を拡大していくことを推奨します。

進捗表示を組み込む際、イベントストリームの再接続時には新規イベントのみが配信される点に注意してください。欠落したログを補完するには、過去イベントのページネーション取得が必要です。現行の API には、すべてのワークフロー実行を一覧取得する専用エンドポイントは用意されていません。また、実行スレッドからカスタムツール呼び出しや権限確認の要求が届いた場合、他のスレッドが並行稼働している可能性があるため、クライアントは速やかに応答する必要があります。セッションが requires_action 状態で停止している場合は、保留中のツール要求を処理してからでなければ、新しいユーザーメッセージを正常に送信できません。