Anthropicは10月9日、クラウド上でAIエージェントを実行するサービス「Claude Managed Agents」に、「動的ワークフロー」をパブリックベータとして追加した。Claudeが作業の分担や進行を管理するプログラムを自ら作成し、複数のエージェントを動かして結果を取りまとめる仕組みだ。公式リリースノートによると、これにより、大量の文書レビューやコード監査をバックグラウンドで進めながら、主担当のエージェントとの会話を続けられるようになる。

1回の実行で起動できるエージェントは累計最大1,000体。ただし、同時稼働できるのは現時点で64スレッドに限られる。1,000体のエージェントが一斉に動くわけではなく、処理速度が単純に1,000倍になるという意味でもない。

今回の機能で重要なのは、作業の分担から結果の再検証までを、プログラムで自動的に進められるようになったことだ。その実用性を評価するには、発見できた問題の数だけでなく、調査できなかった対象がどれだけ残ったのか、どの程度の費用がかかったのかも確認する必要がある。

AD

作業の振り分けから進行管理まで、Claudeがプログラムを作成

動的ワークフローは、開発者向けツールのClaude Codeでは5月28日に発表されている。今回の発表は、この仕組みをClaude Managed Agentsのクラウド実行環境にも導入するものだ。同じ名称の機能でも、実行環境や利用上限などの仕様は異なるため、区別して考える必要がある。

従来のサブエージェントへの作業委任では、主担当のClaudeが次に何を任せるかをその都度判断し、担当エージェントから報告を受けて次の作業へ進む。

一方、動的ワークフローでは、こうした進行管理をプログラムが担う。各エージェントの結果を受け取り、別のエージェントへ引き継ぎ、必要に応じて処理を繰り返す。公式の機能説明によると、その間も主担当のエージェントは、ユーザーへの応答や進捗確認を続けられる。

例えば、大量の契約書を調べる場合、契約書ごとに担当エージェントを割り当てて内容を確認し、その後、別のエージェントにすべての契約書を再確認させる、といった使い方ができる。

最初の調査で問題が見つかった契約書だけを再検証する方式では、最初の担当者が見落とした問題は、そのまま見逃されてしまう。そこでAnthropicが示している指示例では、最初の調査結果にかかわらず、すべての契約書を別の担当エージェントに確認させる。検証に合格しなければ作業をやり直し、再び検証する流れだ。

このように、何をどの順番で調べ、どのような条件で再検証するかを、あらかじめワークフローに組み込める。

ただし、動的ワークフローを使えば、すべての作業が自動的に二重チェックされるわけではない。どのように作業を分担し、何を検証対象とするか、失敗した場合にどう報告するかは、ユーザーの指示やワークフローの設計によって決まる。

利用するには、エージェント定義のmultiagent.typeにmultiagent_20261001を指定し、ワークフローを有効にする。この設定では、ワークフローとサブエージェントへの作業委任が標準で有効になる。

あとはメッセージやシステム指示で実行したい作業を伝えれば、主担当のエージェントがワークフローを開始するかどうか判断する。起動するために別途APIを呼び出す必要はない。

最大1,000体のエージェントを起動可能。ただし同時稼働は64スレッド

ワークフローの実行仕様では、1回の実行で起動できるエージェントの累計数と、同時に稼働できるスレッド数に、それぞれ異なる上限が設けられている。

ここでいうスレッドとは、各エージェントが独自の会話履歴を持って作業する単位を指す。2026年10月10日時点で確認できる主な制限は以下のとおりだ。

制限の対象 現行の上限・設定 注意点
1回の実行で起動できるエージェントの累計 最大1,000体 実行全体を通じた累計数であり、1,000体が同時に動くわけではない
1回の実行で同時稼働できるスレッド 64 空きが出るまで次の担当を起動できない。変更される可能性がある値であり、API上の保証値ではない
1回の実行の有効期間 標準で24時間 エージェント側で短縮できる。待機中に期限が切れる場合もある
1セッションで未終了のまま保持できる実行 標準で10件 予算上限への到達などで一時停止した実行も含まれる

エージェントが失敗した場合、サーバー側が新しいスレッドで処理を再実行することもある。そのため、実行全体で使われたスレッドの累計数が1,000を超える場合もあり、監視画面に表示されるスレッド数とエージェントの起動数が必ずしも一致するとは限らない。

また、組織ごとに設定されるモデル利用のレート制限も別途適用される。エージェントを上限まで起動できたとしても、一定の速度で処理が完了する保証はない。

各エージェントの会話履歴は独立しているが、作業対象のファイルは同じ実行環境で共有される。

主担当のエージェントに大量の調査結果を直接読み込ませずに済む一方、複数の担当者が同じファイルを書き換えた場合の競合まで防げるわけではない。コードの修正などに利用する場合は、担当するファイルや変更範囲を明確に分ける必要がある。

作業を任せるエージェントは、事前に登録しておくことも、実行時に新しく定義することもできる。実行時に定義したエージェントは、主担当と同じモデルを使用する。

一部の作業を別のモデルに任せたい場合は、そのモデルを使うエージェントを事前に登録しておく必要がある。登録済みエージェントには、利用するツールやMCPサーバーを個別に指定できるため、仕事内容に応じてアクセスできる範囲を制限しやすい。

ただし、ワークフロー内で動く担当エージェントに対して、主担当が後から追加のメッセージを送ることはできない。

報告を受けた後も同じ担当と対話を続けられる通常のサブエージェントとは、この点が異なる。修正や再検証を繰り返す必要があるなら、その処理をワークフローのプログラムに組み込んでおく必要がある。

AD

70個のバグのうち66個を発見。単一エージェントとの差は大きい

Anthropicは、11万6,000行のコードに70個のバグを意図的に仕込んだ社内テストの結果を、公式開発者アカウントで公表した。

単一エージェントと動的ワークフローのそれぞれで3回ずつ調査を実行したところ、単一エージェントが発見したバグは14個、15個、27個だった。一方、動的ワークフローは3回とも66個を発見したという。

70個のバグに対する発見率は、単一エージェントが20.0〜38.6％だったのに対し、動的ワークフローは3回とも94.3％に達した。

実行回 単一エージェントの発見数 動的ワークフローの発見数 発見率（単一／ワークフロー）
1回目 14個 66個 20.0％／94.3％
2回目 15個 66個 21.4％／94.3％
3回目 27個 66個 38.6％／94.3％

出典：Anthropicが10月9日に公表した社内テストの結果。発見率は、各回の発見数を仕込んだ70個のバグで割り、100を掛けて小数第1位に丸めたもの。コード内のあらゆる問題に対する正答率や、誤検知率を示すものではない。

この結果は、大規模なコードベースの調査において、複数のエージェントによる分担と検証が見落としの削減につながる可能性を示している。

ただし、動的ワークフローでも毎回4個のバグを見逃している。また、3回とも66個を発見したという数字だけでは、毎回同じ66個を見つけたのかどうかまでは分からない。発見したバグを正しく修正できたことを示す結果でもない。

さらに、公表された発見数だけでは、両方式を同じトークン予算で比較したのか、誤検知がどれだけ発生したのかも判断できない。

費用や処理時間を含めた効率についても、この数字だけでは評価できない。異なる規模や種類のコードベースでも同様の成果が得られるかどうかは、今後の検証が必要だ。

エージェントを増やせば費用も増える。予算制御と完了判定に注意

動的ワークフローそのものに独立した利用料金は設定されておらず、各エージェントが消費したトークンに対して、使用したモデルの単価に応じた料金が発生する。

これに加えて、Managed Agentsにはセッションの稼働時間1時間あたり0.08ドルの料金がかかる。

同じセッション内で複数のエージェントが並行して稼働しても、重複する稼働時間は二重に計上されない。そのため、64体を同時に動かしたからといって、時間単価が64倍になるわけではない。

一方で、各エージェントが資料を読み込み、推論し、結果を検証すれば、その分だけトークン消費量は増える。

Anthropicは1月23日に公開したマルチエージェントシステムの設計に関する解説で、同等の作業を単一エージェントで処理する場合と比べ、3〜10倍のトークンを消費する実装が一般的に見られると説明している。

これは今回の動的ワークフローの消費量を測定した数字ではないが、処理を並列化して完了までの時間を短縮できたとしても、総トークン消費量や料金まで減るとは限らないことを示している。

こうした費用を管理するため、Managed Agentsではセッション作成時に予算の上限を設定できる。

予算はワークフロー内のすべてのエージェントで共有される。上限の判定に使われるのは、契約上の割引などを反映した実際の請求額ではなく、公開単価に基づいて計算した利用額だ。

予算上限に達すると、新しいモデルリクエストの発行は停止される。ただし、すでに処理中のリクエストは完了まで実行されるため、稼働中の各スレッドにつき最大1リクエスト分、設定した予算を超える可能性がある。

また、予算上限に達したからといって、ワークフローが完了したわけではない。

実行は一時停止状態となり、予算上限を引き上げるか解除すれば再開できる。ただし、一時停止している間にも実行の有効期間は経過するため、再開前に期限切れとなる可能性がある。長時間の処理を設計する場合は、予算だけでなく、待機や一時停止にかかる時間も考慮する必要がある。

さらに重要なのは、実行結果にcompletedと表示されても、すべての作業が正常に完了したとは限らないことだ。

公式仕様では、一部のエージェントが作業に失敗したり、必要なエージェントを起動できなかったりしても、ワークフローのプログラム自体は完了する場合があると明記されている。

例えば、大量の契約書をレビューするなら、確認できた契約書の結果だけでなく、読み込めなかった契約書や検証に失敗した契約書も、漏れなく報告させる必要がある。コード監査なら、指摘した問題を再現できるかどうかに加え、調査できなかった範囲も明示させるべきだ。

Anthropicは、作業を分担する際には、それぞれの担当が独立して処理できる単位に分けることを推奨している。

同じ機能の開発を「計画担当」「実装担当」「テスト担当」と工程ごとに分けると、設計意図や作業状況を何度も引き継ぐ必要が生じる。むしろ、独立した文書や、担当範囲が明確なコードの部品ごとに作業を割り当て、必要な検証をワークフローに組み込むほうが、この機能の利点を生かしやすい。

実際に導入する際は、まず対象を絞り、単一エージェントと同じ資料・評価基準で比較することが望ましい。そのうえで、調査できた範囲、発見した問題の正確性、見落としや未処理の件数、費用を記録する必要がある。

必要な対象を漏れなく調査し、問題を再現できる結果が予算内で得られるのであれば、動的ワークフローは、大量の文書レビューやコード監査を効率化する有力な選択肢になる。これまで人間が一つひとつ作業の進行を指示していた工程を、どこまでAIに任せられるかが、今後の実用化における焦点となる。