契約書300件のうち、支配権の変更（チェンジ・オブ・コントロール）条項があるものを洗い出したい。問い合わせの記録を数百件読んで、分類と要約をまとめたい。1つの会話に収まらない量の作業を AI エージェントに任せようとすると、件数で分けて呼び出し、結果を集めて突き合わせる仕組みを、これまでは自分で作る必要がありました。
2026年10月9日、Claude Platform のリリースノートで、Claude Managed Agents の 動的ワークフロー（dynamic workflows） がベータとして公開されました。エージェントが作業に合わせて「ワークフロー」というプログラムを書き、多数のエージェントを段階（フェーズ）ごとに並列で動かして、結果をまとめます。サーバーがこれを「ワークフローラン」としてバックグラウンドで実行します。
便利な一方で、エージェントが自分の判断で数百のエージェントを動かせることになります。本記事では、公式ドキュメント（Multiagent orchestration、Workflow runs）の記述から、有効にする前に決めておくことを整理します。
仕組み：エージェントがプログラムを書いて並列に動かす
ドキュメントの説明をまとめると、次のとおりです。
- 依頼は通常どおり
user.messageで送る。ランを始めるかどうかはエージェントが判断し、そのための API の呼び出しはない - ワークフローは作業をフェーズ（例：「契約書を読む」「結果を突き合わせる」）に分け、フェーズの中で複数のエージェントを同時に動かせる
- 各エージェントは自分のセッションスレッドで動き、結果はプログラムに返る。プログラムが次に動かすエージェントと指示を決める
- 失敗したエージェントは、通常は新しいスレッドで1回だけ再実行される
有効にするには、エージェントの定義で multiagent.type を "multiagent_20261001" にします。このタイプでは、動的ワークフローとサブエージェントへの委任が既定で有効です。ベータの間はリクエストに managed-agents-2026-04-01 のベータヘッダーが要ります。
"multiagent": {
"type": "multiagent_20261001",
"workflows": { "type": "enabled" }
}注意したいのは、既存のエージェントを multiagent_20261001 に移すと、workflows を明示しなくても動的ワークフローが有効になる点です。ドキュメントには、null を送ると既定（有効）に戻るとも書かれています。止めたい場合は {"type": "disabled"} を明示します。
決めること1：費用の上限をセッション作成時に付ける
ランそのものに料金はなく、ランの中のエージェントが使ったトークンが、それぞれのモデルの単価で通常どおり課金されます。並列に動く数が多いほど、短時間で費用が積み上がります。
ドキュメントが案内している歯止めは、セッションの予算（budget）です。
- 予算はセッションを作るときにしか設定できない（既存のセッションには追加できない）
- 予算に達すると、開いているランはすべて一時停止する
- ただし、各スレッドは始めたモデルのリクエストを最後まで終えるため、動いているスレッドの数だけ予算を超えうる
- 予算を上げるか外すと、止まっていたランが再開する
編集部としては、動的ワークフローを有効にしたエージェントでは、予算を付けずにセッションを作らない運用を提案します。超過の幅は「動いているスレッドの数×1リクエスト分」なので、同時に動く数が多いほど、上限は余裕を持って見積もる必要があります。
決めること2：エージェントに「いつ使うか」を書く
ランを始める前に、利用者が承認する手順はありません。ドキュメントは「There’s no approval step before a run starts」と明記しています。どんな依頼でランを使うかは、エージェントのシステムプロンプトで指示します。ドキュメントの例は次のような書き方です。
数件より多い契約書の確認を頼まれたら、並列に読んで結果をまとめるランを始める。1〜2件なら、ランを使わずに自分で確認する。
ほかにも、ドキュメントは次のような指示を例として挙げています。
- 分け方：1件につき1エージェント。さらに別のエージェントに全件を見直させる
- 失敗の扱い：1件の失敗でラン全体を止めない。読めなかった件を最後に一覧にする
- 時間の上限：ランの上限を1時間にする
- 計画の確認：ランを始める前にフェーズと人数を説明し、了承を待つ
ただし最後の「了承を待つ」は、ドキュメント自身が「nothing enforces this」（強制する仕組みはない）と書いています。プロンプトの指示は守られない可能性がある前提で、予算と組み合わせます。
決めること3：「completed」を成功とみなさない
ランの終わりは workflow_run.status_ended イベントの result で分かります。ところが、{"type": "completed"} は「ワークフローが最後まで動いた」という意味で、作業が成功したかどうかは示しません。スレッドの作業が失敗していても、ワークフローがその失敗を処理していれば completed で終わります。
ほかの終わり方は、エージェントが止めたかセッションがアーカイブされた stopped、寿命を超えた timeout_error、プログラムの失敗の program_error、エージェント数の上限を超えた thread_limit_error などです。
編集部の提案として、ランの結果を業務に使う前に次の2つを確認する流れを組み込みます。
- ランのスレッド（
workflow_run_idが一致するもの）のイベントを読み、失敗したものがないか - エージェントの最終回答に「処理できなかった件」が書かれているか（上の失敗の扱いの指示とセットで）
また、ランのイベントはWebhook では通知されません。終わったことを知るには、セッションのイベントストリームを読むか、一覧を取得します。
決めること4：2回呼ばれても困らないツールにする
ドキュメントは「A run can create more than one thread for the same piece of work, so make the tools your agents call safe to call twice.」としています。失敗したエージェントの再実行などで、同じ作業が2つのスレッドで行われることがあるためです。
読み取りだけのツールなら問題になりにくいですが、チケットの起票、メールの送信、データベースへの書き込みのようなツールをエージェントに渡している場合は、同じ依頼が2回届いても1回分しか処理しない仕組み（処理IDによる重複の排除など）が必要です。ランのスレッドはすべて同じサンドボックスのファイルを使う点も、書き込みの設計で考慮します。
上限とレート制限
ドキュメントに記載されている上限は次のとおりです。
| 項目 | 値 |
|---|---|
| 1ランで同時に動くスレッド | 64（保証値ではない） |
| 1ランで始められるエージェント | 1,000（超えると thread_limit_error） |
| ランの寿命 | 既定24時間（エージェントが設定できる） |
| 1セッションで同時に開けるラン | 既定10 |
ランのスレッドのモデルのリクエストは、組織の Messages API のレート制限に、ほかの利用と合わせて数えられます。社内の別のシステムと同じ組織で Claude を使っている場合、大きなランが動いている間はそちらが制限に当たりやすくなります。ドキュメントは、ランの分の余裕を残すか、上限の引き上げを申請するよう案内しています。本番のシステムと実験的なエージェントで組織やワークスペースを分けるかも、ここで決めておきます。
有効にする前の確認リスト
編集部の整理として、動的ワークフローを有効にする前に確かめる点をまとめます。
multiagent_20261001に移すエージェントで、動的ワークフローを本当に使うか（使わないならdisabledを明示）- セッションを作る処理で、必ず予算を付けているか
- システムプロンプトに、ランを使う条件・失敗の扱い・時間の上限を書いたか
completedのあとに、失敗したスレッドを確認する処理があるか- 書き込みをするツールは、2回呼ばれても重複しないか
- レート制限を、ほかのシステムと分け合っていないか
Managed Agents の全体像はClaude Managed Agents の解説、エージェントの基盤を自前で作るか使うかの判断はAIエージェント基盤を「作る」前に、PoC から本番に載せるまでに決めることはAIエージェントのPoCが本番に載らないで扱っています。
確認した範囲
2026年10月16日に、Claude Platform のリリースノート（October 9, 2026）と、Managed Agents のドキュメント（Multiagent orchestration の Dynamic workflows、Workflow runs、Define your agent）を直接取得して確認しました（資料調査）。動的ワークフローを実際に動かしてはいません。ランの費用・所要時間・失敗の頻度、予算を超える幅の実測は未確認です。冒頭の契約書や問い合わせの例は、ドキュメントの例をもとにした想定の場面で、自社や顧客の事例ではありません。
大量の書類を扱う業務へのAIエージェントの組み込み、費用の上限と失敗時の扱いの設計は、開発・AI・自動化のご相談からお問い合わせください。
