動的ワークフローの統制設計——Managed Agents

数百件の契約書レビューを1つの会話で回すと、コンテキストが破綻します。2026年10月9日にベータ公開された Managed Agents の動的ワークフロー（dynamic workflows）は、エージェント自身が「複数のエージェントを段階的に走らせるプログラム」を書き、サーバー側のバックグラウンドで実行させる機能です。

その代わり、実行前の承認ステップはありません。プラットフォームチームが先に決めておくべきは、並列度の上限ではなく「どこで止め、何をもって完了とみなすか」です。本記事はエージェントガバナンスの観点で、Managed Agents の動的ワークフローを統制する設計論点を整理します。サブエージェント方式との比較はサブエージェント・オーケストレーション設計も参照してください。

動的ワークフローとは何か

動的ワークフローは、エージェントが書いたプログラムが複数エージェントを並列・段階実行し、結果を統合する仕組みです。

ワークフローは次の3層で構成されます。

• ワークフロー実行（run）: サーバーがバックグラウンドで走らせる実行単位。1セッションに複数同時に開けます
• フェーズ（phase）: 「契約書を読む」「結果を突合する」のような名前付きの段階
• エージェントスレッド: フェーズ内で各エージェントが個別のセッションスレッドとして動く単位

プログラムは並列実行（fan-out）、結果の受け渡し、レビューが通るまでの反復、失敗エージェントの扱いを制御できます。各スレッドは同じセッションのサンドボックスとファイルを共有しますが、会話履歴は別々です。

有効化はエージェント定義で multiagent.type を multiagent_20261001 にし、workflows を有効にします。この型ではサブエージェント委譲も既定で有効のため、ワークフローだけにしたい場合は subagents を無効化します。利用には managed-agents-2026-04-01 のベータヘッダが必要です。

承認ステップが無い前提で、何を上限として設計するか

実行前の承認が無いため、上限は事前に設定した予算・ライフタイム・開始条件の3点で担保します。

ドキュメントが明記している制約値は次のとおりです。

1,000 を超える要求は thread_limit_error で run が終了します。失敗したエージェントはサーバーが新しいスレッドで再実行することがあるため、スレッド総数が1,000を超える場合もあります。

統制の要点は3つです。

1. 予算をセッション作成時に設定する: run のモデルリクエストはセッションの予算に計上され、到達すると開いている全 run が一時停止します。各スレッドは開始済みのリクエストを完了するため、稼働スレッド数ぶんだけ予算を超過し得ます。予算には余白を見てください
2. ライフタイムを短く指示する: 「run に1時間の制限を付ける」とシステムプロンプトで指示できます。一時停止中もライフタイムは進み、timeout_error で終了し得ます
3. 開始条件をシステムプロンプトに書く: 「数件超のときだけ run を使い、1〜2件は自分で処理する」のように規模で使い分けを指示します。各エージェントがトークンを消費するため、run は必要なタスクに限定します

「開始前に計画を説明して承認を待て」と指示することもできますが、承認を強制する機構は無く、プロンプト上の依頼にとどまります。

run が completed でも成功とは限らないのはなぜか

completed はワークフローの実行完了を示すだけで、成果物の合否は保証しません。失敗はスレッド単位で確認します。

workflow_run.status_ended の結果が completed でも、スレッドの作業が失敗していたり、スレッドが作成できなかったりしている場合があります。プログラムが失敗を握りつぶして続行すれば、run は正常終了として扱われます。

終了結果ごとの意味は次のとおりです。

• completed: ワークフローが最後まで走った。合否は含まない
• stopped: エージェントが停止した、またはセッションがアーカイブされた
• timeout_error: ライフタイム到達
• program_error: コードの失敗、ルール違反、または失敗スレッドがそのまま run を終わらせた
• thread_limit_error: 起動エージェント数の上限超過

対策はプロンプトでの明示です。「1エージェントの失敗で run を失敗させない。読めなかった契約は『未カバー』として列挙し、終了時に報告する」と指示すれば、未処理分を成果物に残せます。完了判定の自動化では、次の条件をすべて満たしたときだけ作業完了とみなします。

1. 観測した全 run に workflow_run.status_ended が届いている
2. その後に session.status_idle が end_turn で届く
3. 各 run のスレッドイベントで失敗が無い

予算到達による一時停止中は、run が開いたままセッションだけが idle になります。idle の検知だけで完了と判断しないでください。

イベント監視と中断はどう実装すべきか

実行は workflow_run.* イベントをストリームで追跡し、中断は user.interrupt ではなくエージェントへの停止依頼で行います。

run の進行は、セッションのイベントストリームで workflow_run.created、phase_started、phase_ended、status_ended、error を追います。ストリームは過去分を再送しないため、再接続時はイベントを type フィルタ付きで一覧取得して状態を再構築します。ポーリングは読み取りレート制限を消費するため避けてください。なお run のイベントは webhook を発火しません。

中断には注意が要ります。user.interrupt はエージェントのターンを止めますが、run は終了させません。run を止めるには、user.message で「実行中の run を停止して」と依頼します。待機中のツール呼び出しには、拒否またはエラー結果で個別に応答する必要があります。run 中のスレッドは個別 ID では停止できず、セッションの更新もブロックされます。

運用上の追加ポイントは次のとおりです。

• 同じ作業に対してスレッドが複数作られ得るため、エージェントが呼ぶツールは冪等にする（冪等性設計参照）
• コストは、セッションのスレッド一覧で workflow_run_id が一致するスレッドの usage を合算して run 単位で把握する
• 課金はトークンに加え、running 状態の間だけ session-hour あたり $0.08 のセッションランタイムが発生する（2026年10月時点の公式料金ページ記載）

規模別の留意点（SMB / エンタープライズ）

数十件規模のバッチなら、上限・予算・失敗時の扱いの3点をシステムプロンプトに書くだけでも実用になります。マルチチームで共有する基盤では、組織全体のレート制限を run が食い合う点が課題です。Messages API のレート制限を run 用に確保し、予算を部門単位で割り当てる設計が必要になります。大規模導入の統制設計は RDE でも支援しています。

参考

• Workflow runs - Claude Platform Docs
• Multiagent orchestration - Claude Platform Docs
• Pricing - Claude Platform Docs

まとめ

動的ワークフローは、1会話に収まらない作業を並列化できる一方、承認ステップが無く、completed が成功を意味しない機能です。予算とライフタイムの事前設定、規模に応じた開始条件、失敗の明示報告、イベントに基づく完了判定の4点を、運用開始前に固めてください。

Kuu株式会社は、Managed Agents を含むエージェント基盤の統制設計を支援しています。大規模組織での導入は RDE からご相談ください。