Claude Managed Agents に dynamic workflows がベータ提供 — エージェント自身がワークフローを書き、最大1,000エージェントをフェーズ実行する

要約

Claude Managed Agents で dynamic workflows がベータ提供されました。ベータヘッダは既存の managed-agents-2026-04-01 で、専用ヘッダは追加されていません。

ワークフローとは、エージェント自身が書くプログラムです。 多数のエージェントをフェーズに分けて走らせ、それぞれの戻り値を束ねます。その1回の実行が workflow run にあたり、サーバーがバックグラウンドで走らせます。

何が解けるようになるかというと、1つの会話に収まらない規模の作業です。 公式が例に挙げているのは「300件の契約書のうち、どれに change-of-control 条項があるか」。これを1会話でやろうとすると文脈に入りません。従来はクライアント側で分割・並列実行・結果集約を自分で書く必要がありました。それをエージェントに任せられるようになったということです。

有効化は設定1か所です。 エージェントの multiagent フィールドを {"type": "multiagent_20261001", "workflows": {"type": "enabled"}} にします。この type では dynamic workflows と subagents がどちらも既定で有効になります。workflows.predefined_agents に最大20件のエージェントを登録でき、そこに無いものはワークフロー側が inline agent として定義します。

進行の追跡はイベントストリームです。 workflow_run.created でフェーズ一覧が届き、phase_started / phase_ended で進行し、status_ended で result が返ります。status_idle は budget 到達などで止まった状態です。

ここから先が、実装する人にとって重要な部分です。

1つ目。result が completed でも、作業が成功したとは限りません。 公式はこう書いています——「結果は作業が通ったかどうかを示さない。run のスレッド上の作業が失敗していても、あるいはスレッドが作成できなくても、run は completed で終わりうる」。失敗した作業を見つけるには、run の各スレッドのイベントを読む必要があります。

2つ目。ワークフローのコードは見えません。 公式の Visibility 節に明記されています。run を開始・管理するためにエージェントが呼んだツールコールも、各スレッドがワークフローへ返した結果も見えません。エージェントに尋ねれば教えてくれるという形です。

3つ目。run 固有の料金はありませんが、だからこそ budget が必要です。 run のモデルリクエストはセッションの budget に計上され、各モデルの通常レートで課金されます。公式のマルチエージェントのドキュメントは「run の中のすべてのエージェントがトークンを使うので、セッション budget を設定して支出に上限をかけること」と書いています。

まとめると、「規模の壁を越える代わりに、見える範囲が狭くなる」機能です。 オーケストレーションを書かなくてよくなった分、何が起きたかを後から再構成する作業が残ります。

何が変わったか

• dynamic workflows がベータ提供（2026-10-09、ベータヘッダは既存の managed-agents-2026-04-01）
• 有効化: エージェントの multiagent を {"type": "multiagent_20261001", "workflows": {"type": "enabled"}} に設定
  • この type では dynamic workflows と subagents が既定で有効
  • workflows.predefined_agents に最大20件登録可。未登録分はワークフローが inline agent として定義
• run を開始できるのは primary thread のエージェントだけ。 run 内のエージェントは自分の run を開始できず、run は入れ子にならない
• イベント: workflow_run.created / status_running / status_idle / phase_started / phase_ended / status_ended / error
  • すべての workflow_run.* は workflow_run_id を含む（run が作られなかった error のときだけ null）
  • run イベントは webhook を発火しない
• result の種類: completed、error（program_error / thread_limit_error / timeout_error / unknown_error）
  • completed は作業の成否を示さない。 スレッド側の失敗を見るには各スレッドのイベントを読む
• 上限
  • 1つの run で同時に動くスレッド: 64（API 上の保証はなく変わりうる）
  • 1つの run が生涯で起動できるエージェント: 1,000（超過で thread_limit_error）
  • run の寿命: 既定24時間（エージェントがより短く設定可。超過で timeout_error）
  • セッションで同時に open できる run: 既定10（超過で max_workflow_runs_error。idle な run も数に入る）
  • run / フェーズの name は64文字、description は256文字に短縮される
• 課金: run 固有の料金は無い。 トークンはセッションの budget に計上され、各モデルの通常レート
  • budget 到達ですべての open な run が pause。budget を上げる / 外すと再開
  • 各スレッドは開始済みのモデルリクエストを完了させるため、稼働スレッド数ぶん budget を超えうる
• run のスレッドはセッションの sandbox を共有（同じファイルを見る）。child-thread 上限の対象外
• ワークフローのコードは見えない。 run を管理するツールコールと各スレッドの戻り値も見えない

業務インパクト（一般企業向け）

最初にやることは、セッション budget を切ることです。機能を有効にする前です。

理由は、止める仕組みが budget しかないからです。 run の寿命は既定24時間、同時 open は既定10、1つの run が起動できるエージェントは1,000。これらを全部掛けると、意図せず大量のトークンを使いうる組み合わせになります。 公式も「run の中のすべてのエージェントがトークンを使う」と明示しています。budget は後から付ける安全弁ではなく、有効化の前提条件として扱ってください。

budget の挙動には1つ注意があります。 budget に達したとき、各スレッドはすでに開始したモデルリクエストを完了させます。 つまり稼働中のスレッド数ぶん、budget を超えて課金されうるということです。同時実行が64まで行く構成なら、超過分も64リクエスト分までありえます。ぎりぎりの budget を設定すると、超過分が無視できない大きさになります。

次にやることは、「run が completed で終わった」を成功判定に使わない設計です。

これは実装の前提として最も重要です。 result: {"type": "completed"} は「ワークフローのコードが走り終わった」という意味しかありません。300件の契約書のうち50件でスレッドが落ちていても、completed で終わりえます。 成否を知るには、run の各スレッドのイベントを読んで失敗を探す必要があります。スレッドは workflow_run_id でグループ化できます。

この確認を自動化しておかないと、「レビュー済み」として扱った中に未処理が混ざります。 契約書レビュー、請求書の突き合わせ、ログの異常検出——件数が合っているかを別の手段で検証できる処理にまず適用するのが安全です。「300件投げて300件の結果が返ったか」をワークフローの外側で数えてください。

使用量の集計方法も、公式が具体的に指定しています。 1つの run の使用量を出すには、セッションのスレッドを列挙して、その run の workflow_run_id を持つスレッドの usage のトークン数を合計します。終了済みスレッド（status が terminated）も含まれるので、終わった run も数えられます。ページングは next_page を page に渡して null になるまで回します。usage が null のスレッドは飛ばします。

なお公式は「list_cost を合計するな」と事実上言っています。 スレッドの list_cost を足すとセッションのランタイムが抜け落ち、各数値が別々に丸められるためです。トークン数を合計するのが正しい方法です。社内の原価計算に使うなら、この違いは効きます。

監視の設計で、webhook が使えない点を押さえてください。 run イベントは webhook を発火しません。 イベントストリームを購読するか、セッションのイベント一覧を取得する必要があります。公式はレートリミットの節で「ポーリングせずイベントストリームで追え」と明示しています。既存の webhook ベースの監視に run を乗せる設計は成立しません。

レートリミットは既存の枠を食います。 run のスレッドからのモデルリクエストは、組織の Messages API のレートリミットに、他のトラフィックと合算で乗ります。64スレッドが同時に動くと、そのぶん通常の API 利用を圧迫します。 本番の API トラフィックと同じ組織で run を回すなら、余裕を見るか上限引き上げを申請する必要があります。

冪等性の要件が明記されています。 公式は「run は同じ作業に対して複数のスレッドを作りうるので、エージェントが呼ぶツールは2回呼ばれても安全にすること」と書いています。外部システムへ書き込むツールを run に使わせるなら、冪等性は必須です。発注、送信、課金のような処理を run の中から呼ぶ設計は、ここを満たしてからにしてください。

副業・個人活用視点

この機能は「オーケストレーションを書く仕事」の位置を変えます。

これまで、大量データに対する LLM 処理の受託は、分割・並列化・リトライ・集約のコードを書く仕事でした。 それ自体に価値があり、工数も取れました。dynamic workflows はその層をサーバー側へ持っていきます。

ではどこに仕事が残るかというと、検証と可観測性です。 completed が成否を示さない、コードが見えない、webhook が来ない——この3つを前提に「ちゃんと終わったか」を確認する仕組みを作るのは、依然として人の仕事です。むしろ難しくなっています。 中が見えない分、外側から検証する設計力が要ります。

具体的な提案の形にしやすいです。 「run の各スレッドを workflow_run_id で集計し、失敗スレッドを検出して再実行キューへ入れる仕組みを作ります。あわせて使用量を usage のトークン合計で集計し、原価が見えるようにします」——これは公式ドキュメントに手順が書かれているぶん、見積もりが立てやすい仕事です。

個人開発で試すなら、budget を小さく切ってから有効化してください。 これは節約の話ではなく、仕組みを理解するための手順です。budget に当たると status_idle が来て budget_reached で止まります。この挙動を小さい金額で一度見ておくと、本番で何が起きるか分かります。 上限が既定24時間・同時10 run という構成を、挙動を知らずに本番で回すのは避けてください。

コードが見えないという制約は、受託では説明責任の問題になります。 「どういう処理をしたのか」を聞かれたとき、ワークフローのコードは提示できません。 エージェントに尋ねれば教えてくれますが、それは実行時のコードと一致する保証がありません。 監査が必要な処理——金融、医療、法務——では、この制約を先に顧客へ伝えるべきです。「速くて安い」だけで提案すると、後で説明できなくなります。

記事にするなら、「completed が成否を示さない」を軸にすると価値があります。 リリースノートは「エージェントがワークフローを書けるようになった」という話として読まれます。ドキュメントの奥にある「run のスレッド上の作業が失敗していても completed で終わりうる」という一文が、実装者にとっては最も重要です。 ここを読み落とした実装がどう壊れるかを書けば、同じ機能を使う人に確実に届きます。

inline agent の制約も、書く価値のある細部です。 ワークフローが定義する inline agent は、セッションのエージェントのモデルを使い、ツール・MCP サーバー・スキルはその部分集合になります。公式は「全部もらうが、API はそれを保証しない」と書いています。つまり部分集合しか渡らない前提で設計すべきということです。この種の「保証しない」という書き方を読み取れるかどうかが、実装の堅さを分けます。

関連リンク

• Claude Platform API release notes（2026-10-09 の節）
• Workflow runs（Claude Platform Docs）
• Multiagent orchestration（Claude Platform Docs）
• Budgets（Claude Platform Docs）