Claudeが複数文書の仕事を分担する。Managed Agents動的ワークフローの使いどころ

Claude Managed Agentsに、こうした仕事を複数のエージェントへ分ける「dynamic workflows（動的ワークフロー）」のbetaが追加されました。Claudeが仕事に合わせたプログラムを書き、複数の担当を動かして結果を集めます。公式リリースノートの日付は2026年10月9日です。発表時刻は記載されていません。公式リリースノート

この記事では公開仕様を整理し、架空の進捗報告4文書で「採用してよい数字」と「確認が必要な数字」を分ける教材を紹介します。Managed AgentsのAPIは実行しておらず、モデルの精度や処理時間を測定したものではありません。

対象は、開発者が業務アプリへ組み込むClaude Managed Agentsです。エージェントのモデル・指示・ツール、実行環境を設定してセッションを開始し、イベントで依頼と結果をやり取りします。実行の仕組みや状態の保持をAnthropic側に任せられる点が特徴です。Managed Agentsの概要

Claude Codeは、ターミナルやIDE、デスクトップ、ブラウザーで使う開発支援ツールです。Projectsにも、資料や会話をまとめる既存版と、クラウドの並列スレッドを使う新betaがあります。新Projectsは一部のPro・Max利用者から段階提供中です。今回のManaged Agents APIの設定を、これらの画面へそのまま貼り付ける機能ではありません。Claude Codeの概要／Projectsの公式説明

「Claudeで複数担当を動かす」という考え方自体は以前からあります。今回の新しさは、Managed Agents上で、Claudeが書いたワークフローをサーバーがバックグラウンド実行する機能がbetaとして案内されたことです。

通常のサブエージェントへの委任では、主担当のClaudeが仕事を渡し、報告を読んで次を決めます。動的ワークフローでは、その進行をClaudeが作ったプログラムに持たせます。プログラムが各担当の結果を受け取り、次の担当へ渡したり、条件に応じてやり直したりできます。マルチエージェントの公式説明

たとえば進捗報告なら、次の分担が考えられます。これは本記事の設計例です。

重要なのは、担当を増やすことより、受け渡す情報を決めることです。「Bチームは6件だった」という要約だけでは、どの文書の数字か分かりません。文書ID、日付、承認状態、原文まで残せば、別の担当や人が確認できます。

同じ実行内の担当は、セッションのサンドボックスにあるファイルを共有します。一方、会話履歴は担当ごとに分かれます。読取結果は文書IDごとの別ファイルへ保存し、最後に統合する設計なら、全担当が同じ集計ファイルを上書きする事態を避けやすくなります。実行とスレッドの仕様

公式資料では、Managed Agentsは全APIアカウントで標準有効です。利用にはClaude APIキーが必要で、beta用ヘッダーはmanaged-agents-2026-04-01です。日本はAPIの対応国に含まれています。実際の接続や支払設定は本記事では確認していません。利用条件／対応国一覧

次はエージェント定義に入れる設定部分です。単独では実行できません。モデルやツール、実行環境、セッションの作成は、公式の手順に沿って別途設定します。

この例は動的ワークフローを有効にし、主担当による通常のサブエージェントへの委任を無効にします。multiagent_20261001では両方が標準有効なので、必要な動作を明示します。設定しただけで毎回ワークフローを作るとは限らず、使う条件をシステム指示に書く必要があります。有効化の公式手順

業務データを渡す際は保存先も確認してください。Managed Agentsは会話履歴、サンドボックスの状態、出力をサーバー側に保持します。現状はZero Data Retentionの対象外です。まずは架空文書や公開資料から、必要な権限だけで試すのが扱いやすいでしょう。

ワークフロー実行そのものに独立した料金はありません。ただし各担当が使ったトークンは、モデルごとの料金で課金されます。さらに、セッションがrunningである時間に1時間あたり0.08ドルがかかります。待機中のidleなどは実行時間課金に入りません。公式料金

1セッションが30分間runningなら、時間分は0.04ドルです。これは架空の計算例で、トークン代やWeb検索代を含む総額ではありません。担当が増えれば各担当への入力と出力も増えるため、「一人で読むより必ず安い」とは言えません。Managed AgentsにはBatch APIの割引も適用されません。

セッションの予算機能は、モデルのトークン、Web検索、実行時間を公開定価で合算して判定します。max_list_cost.amountはドルではなく、セント単位の整数を文字列で指定します。たとえば"100"は1ドルです。予算はセッション作成時に付けます。予算の公式仕様

上限に達すると、新しいモデルリクエストを止めて一時停止します。ただし、すでに始まったリクエストは終了まで進むため、動作中の各スレッドの1リクエスト分、上限を超える場合があります。多数の担当を動かすほど、この余裕も見込む必要があります。

進捗集計の教材ZIPをダウンロードできます。すべて編集部が作った架空データです。Pythonの標準ライブラリだけで検査でき、APIキーやネット接続は不要です。

依頼は「10月9日時点で、各チームの最新の承認済み報告を集計する」です。期待結果はAが8件、Bが6件、Cは確認が必要。確認済み分の小計は14件ですが、全チームの確定合計ではありません。Cを0件にしたり、下書きの7件を足して21件にしたりすると、報告の意味が変わります。

教材のrequest.mdには、文書ごとの抽出、別担当による引用照合、統合の順で作業する依頼文を入れました。documents.jsonが入力、expected.jsonとexamples/は人の採点用です。将来モデルを試す場合、採点用ファイルは入力に混ぜないでください。

展開先で次を実行します。

最初はpassed: true、後の2つはpassed: falseになるのが期待です。後の2つは、旧版採用と未承認文書の合算を意図的に入れた編集部の誤り例で、モデルの出力ではありません。

検査器は、文書ID、日付、承認状態、件数、引用の原文を照合します。実在する引用でも、古い文書から持ってきた数字は採用できません。逆に正しい件数を書いていても、根拠として挙げた文章がその件数を含まなければ検査を通しません。

この固定形式の教材について、正しい例と8種類の誤りを含む9テストを確認しました。任意の文章の意味を判定できる評価器ではありません。実業務では、人が確認すべき例外や、報告書の形式変更に合わせて検収ルールを作り直します。

公式仕様では、ワークフローがcompletedで終了しても、内部の担当が失敗している場合があります。プログラムが最後まで動いたことと、全資料を正しく確認できたことは別です。終了状態の仕様

実装では、作られたすべてのrunにworkflow_run.status_endedが届き、その後に主担当がsession.status_idle、end_turnになったことを追います。自分で割り込んだ結果の待機状態を、仕事の完了と数えない点にも注意が必要です。実行の終了はイベントで、報告書の合否は入力件数・出典・未確認事項で検査します。

標準の有効期間は24時間ですが、一時停止や外部ツールの応答待ちの時間も含みます。「明朝まで放っておけば必ず終わる」という保証ではありません。小さな文書セットで採用条件を固め、失敗した文書と確認済みの文書を分けて返せるようにしてから、対象を増やすのが現実的です。