Managed Agents でも dynamic workflows が使えるようになりました

2026 年 10 月 9 日、Claude Platform のリリースノートで、Claude Managed Agents の dynamic workflows が公開ベータになりました。エージェントが、多数のエージェントを段階的に動かして結果を統合するプログラム (workflow) を自分で書き、サーバーが実行する機能です。数百件の文書の審査のように、1 つの会話に収まらない作業を想定しています。

ここで混同しやすいのが、Claude Code の dynamic workflows との関係です。名前は同じですが、動かす場所と追い方が違います。Claude Code 側の使い方は Opus 4.8 を使いこなす要点 にまとめました。本記事は、API で Managed Agents を使う開発者向けに、設定・イベント・上限・費用を整理します。

内容は、Anthropic の リリースノート、Multiagent orchestration、Workflow runs、Reference、料金ページ を 2026 年 10 月 10 日に確認したものです。一次情報に無い数字は書いていません。ベータのため、仕様は変わる可能性があります。

有効にする設定

有効にするのは、エージェントの作成時に指定する multiagent フィールドです。ベータヘッダーは managed-agents-2026-04-01 で、SDK を使えば自動で付きます。

{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": {
      "type": "enabled"
    }
  }
}

公式ドキュメントの例では、このほかに name、model、system、tools を指定しています。この type では、subagents への委任も既定で有効です。dynamic workflows だけにしたい場合は、"subagents": {"type": "disabled"} を足します。すでにあるエージェントの multiagent.type を変えるときは、公式ドキュメントの移行の案内を先に読んでください。

使い始めてから気づきやすい点を、先に挙げます。

  • run を始める専用の API はありません。依頼を user.message で伝えると、エージェントが始めるかどうかを判断します
  • 判断を寄せたいときは、system に使いどころを書きます。公式の例は「数件を超える契約書を審査するときは run で並列に読み、統合する。1〜2 件なら run を使わずに自分で読む」です
  • 権限ポリシーが効くのは run のエージェントが呼ぶツールで、run を始める操作には効きません
  • run のエージェントは、ワークフローが定義する inline agent が既定です。別のモデルを使いたいときは、エージェントを作って workflows.predefined_agents に並べます (最大 20)。inline agent は、セッションのエージェントと同じモデルで動きます
FIXITFIXIT

run を始めるボタンみたいな API はないの？

TsumikiTsumiki

ないんです。公式は、始めるかどうかをエージェントが判断すると書いています。

FIXITFIXIT

じゃあ、使ってほしいときはどうするの？

TsumikiTsumiki

system prompt に使いどころを書きます。公式の例も、件数で分けています。

1 回の run の中身

workflow は、エージェントが書くプログラムです。ほかのエージェントを動かし、それぞれの結果を集めて、統合します。サーバーがバックグラウンドで実行する単位が workflow run です。run は次の層でできています。

層中身
workflow run1 つの workflow の実行。1 つのセッションで複数の run が同時に開けます
phase「契約書を読む」のような、run の段階。進み具合は phase のイベントで追います
agent threadphase の中で動く各エージェント。サーバーが session thread を作ります

プログラムにできることは、公式ドキュメントでは次のように説明されています。

  • 多数のエージェントを同時に動かす (fan out)
  • あるエージェントの結果を、別のエージェントに渡す
  • 結果から次の手を、エージェントではなくプログラムが決める
  • 草稿を、レビューが通るか規定の回数に達するまで繰り返す
  • エージェントが失敗したとき、プログラムが処理するか、run を終わらせる

run の全エージェントは、セッションのサンドボックスの同じファイルを使います。会話の履歴はスレッドごとに別です。run が終わると、セッションのエージェントに、結果を読む番が回ります。

workflow のコードは画面に出ません。見たいときは、run が終わってセッションが idle になってから、次のように頼む方法が公式に紹介されています。

Print the workflow that you started the run with, word for word, in one code block. Do not start another run.

進捗は workflow_run のイベントで追う

run の状況は、セッションのイベントストリームに workflow_run.* として届きます。リファレンスでは次の 7 種類です。

イベント届くとき
workflow_run.createdrun が作られた。名前・説明・宣言された phase の一覧を含む
workflow_run.status_running実行が始まった。予算での一時停止から再開したときにも届く
workflow_run.status_idle予算などで一時停止した
workflow_run.phase_startedphase に入った
workflow_run.phase_endedphase を出た
workflow_run.status_endedrun が終わった。result を含み、その run の最後の workflow_run.* になる
workflow_run.errorrun のエラー、またはサーバーが断った開始。status_ended の前に届く

status_ended の result は、次のいずれかです。

result意味
completedworkflow が最後まで動いた。作業が成功したという意味ではない
stoppedエージェントが止めたか、セッションが archive された
error の timeout_error寿命に達した
error の program_errorworkflow のコードや規則違反、または run のスレッドの失敗がそのまま run を止めた
error の thread_limit_error始められるエージェントの上限を超えた
error の unknown_errorサーバーが続けられなかった、または他の上限を超えた

特に注意したいのは、completed が成功ではない点です。公式ドキュメントは、スレッドの作業が失敗していても、run は completed で終わりうると書いています。失敗した作業を探すには、run の各スレッドのイベントを読みます。スレッドは、session.thread_created の workflow_run_id で見分けます。

また、run のイベントは webhook を起動しません。ストリームを開いて追う前提です。ストリームは過去の分を再送しないため、再接続したときは、イベントの一覧を types で絞って取り直し、run の状態を組み立て直します。

「終わった」は 2 つの条件で判定する

run を使うセッションでは、session.status_idle が来ても、作業が終わったとは限りません。公式ドキュメントは、次の 2 つがそろったときを完了としています。

  1. 作成を見たすべての run に、workflow_run.status_ended が届いている
  2. そのあとに、stop_reason が end_turn の session.status_idle が届く。自分の interrupt が原因の idle は数えない

落とし穴は、ほかにもあります。

  • 一時停止した run は、セッションを running に保ちません。予算に達すると、セッションは budget_reached で idle になりますが、run はまだ開いています
  • エージェントは、結果を読んだあとに新しい run を始めることがあります。完了の判定は、そのたびにやり直します
  • run のスレッドが、あなたのクライアントの応答を待つことがあります。カスタムツールの呼び出しは、届いた時点で答えます。idle を待たないでください
  • retries_exhausted で idle になっても、サーバーが自分で新しいターンを始めることがあります

注意

interrupt (user.interrupt) はエージェントのターンを止めますが、run は終わらせません。run を止めたいときは、user.message でエージェントに run を止めるよう頼みます。止まった run は stopped で終わります。

公式ドキュメントには、イベントを追って run の名前と phase を出力し、完了で止まるサンプルが Python・TypeScript などで載っています。自作する前に、そのまま動かして挙動を確かめると早いです。

上限と費用

上限は、公式ドキュメントでは次のとおりです。

上限値超えたとき
1 つの run で同時に動くスレッド641 つ終わるまで新しく作らない。数字は保証されず、変わりうる
run の全期間にワークフローが始めるエージェント1,000超えると thread_limit_error で終わる
run の寿命既定 24 時間 (エージェントが短縮できる)timeout_error で終わる。一時停止中も寿命は進む
1 つのセッションで同時に開く run既定 10開始が断られ、max_workflow_runs_error が届く。idle の run も数える

費用の考え方は、次の 3 点です。

  • run に専用の料金はありません。 run のエージェントが使ったトークンが、各モデルの料金で、セッションの他のトークンと同じように課金されます
  • Managed Agents は、トークンと稼働時間の 2 軸で課金されます。料金ページには、稼働時間は 1 時間あたり 0.08 ドルで、セッションが running の間だけ数えるとあります。Batch API の割引は適用されません
  • run のモデル呼び出しは、セッションの予算に数えます。予算に達すると、開いている run がすべて一時停止します。予算を上げるか外すと、一時停止した run が再開します。ただし、各スレッドは始めたリクエストを終えるため、予算を少し超えることがあります

1 つの run の使用量は、セッションのスレッド一覧から、その workflow_run_id を持つスレッドの usage を足して出します。金額は変わりうるため、実際の見積もりは最新の料金ページを使ってください。

レート制限は、新しく用意されるものではありません。Managed Agents のエンドポイントは、組織ごとに作成系が 1 分あたり 300 リクエスト、読み取り系が 1,200 リクエストです。run のモデル呼び出しは、Messages API のレート制限に、他のトラフィックと一緒に数えられます。進捗はポーリングせずに、イベントストリームで追ってください。

Claude Code の dynamic workflows との違い

観点Managed AgentsClaude Code
動く場所Anthropic のサーバー側のセッション (サンドボックスはクラウドか自前)Claude Code のセッション
起動セッションのエージェントが判断して始める/workflows から始める
追い方API のイベントストリーム (workflow_run.*)Claude Code の画面
上限の数字本記事の表のとおり別 (本記事では扱わない)

Managed Agents 側の欄は公式ドキュメントで確認した内容です。Claude Code 側は 自社の既存記事 の範囲にとどめ、上限などの数字は書いていません。両者の上限を比べたいときは、Claude Code 側の公式ドキュメントを別に確認してください。

FIXITFIXIT

Claude Code の dynamic workflows と、結局どっちを使えばいいの？

TsumikiTsumiki

手元の作業なら Claude Code です。自分のアプリから API で動かすなら Managed Agents になります。

試す前に確認したい制約

導入を決める前に、次の点を確認してください。

  • データの扱い。 Managed Agents は、ステートフルな作りのため、Zero Data Retention と HIPAA の BAA の対象外です。セッションの履歴・サンドボックスの状態・成果物はサーバーに保存されます。セッションと、アップロードしたファイルは、API でいつでも削除できます
  • ツールの冪等性。 run は、同じ作業のために複数のスレッドを作ることがあります。失敗したエージェントを、新しいスレッドでやり直すためです。ツールは、2 回呼ばれても困らない作りにします
  • run が開いている間の操作。 セッションの agent の更新は、開いている run が 1 つでもあれば 400 になります。セッションの archive や delete も、400 になることがあります。先にエージェントに run を止めるよう頼んでください
  • 試すための費用。 Max と Team の毎月の API クレジットは Managed Agents にも使えます。受け取り方は Claude Max / Team の毎月 API クレジット にまとめています

最初の検証は、件数の多い単純な作業で小さく始めるのが現実的です。たとえば、数十件の文書から条項を抜き出す作業を 1 回だけ run で流し、イベントの届き方と、予算で止まる動きを確かめます。そのうえで、自社のデータを扱えるかを判断します。

FIXIT の運用 — 大量処理のエージェントをどう設計するか

FIXIT は AI 駆動開発のクリエイティブスタジオとして、エージェントを使うプロダクト開発では、成果の確認を人の側に残す設計を基本にしています。dynamic workflows のような並列処理でも、completed を成功とは読まず、失敗した作業を拾う検査を別に置くのが安全だと考えています。

並列に動かす仕組みは、速さと引き換えに、費用と責任の所在が見えにくくなります。予算・寿命・上限を先に決め、イベントを記録しておくことを、導入の最初の設計項目にします。

まとめ

Managed Agents の dynamic workflows は、エージェントが書いたプログラムで多数のエージェントを動かす機能です。multiagent に multiagent_20261001 と workflows を指定して有効にし、workflow_run.* のイベントで追います。完了は、全 run の status_ended と、その後の end_turn の idle がそろった時点です。completed は成功を意味しません。

上限は、同時 64 スレッド・累計 1,000 エージェント・寿命 24 時間・同時 10 run が目安で、run に専用の料金はありません。データの保持に制約があるため、機密を扱う前に社内の規程と照らしてください。

エージェントを使った大量処理を業務に組み込む設計は、AI エージェント開発 で相談できます。社内の AI 開発ツールの導入から整えたい場合は、AI 開発ツール定着支援 があります。状況を相談したい場合は、お問い合わせ からご連絡ください。