マルチエージェントの設計と運用：4つの連携パターン、承認、コスト管理

マルチエージェントをうまく連携させるには、AIエージェントを増やす前に、次の工程の責任者を決めることが大切です。依頼の受付から調査、下書き、承認まで、設計の軸になるのは4つのパターンです。リードエージェントがワーカーを束ねる方式、専門エージェント間のハンドオフ、チェックポイント付きのグラフ、そしてエージェント全体を包む永続的なワークフローです。送信、支出、レコード変更の許可は、モデルの裁量に委ねないでください。

本記事のドキュメントと以下のインフラ料金は、2026年10月13日に確認しています。 業務例は設計案であり、実際の導入事例や性能ベンチマークではありません。

マルチエージェントのオーケストレーションとは？

オーケストレーションとは、次に動くエージェント、渡す情報、そして結果を実際のアクションに移すための条件を決めることです。 エージェントは、モデルに指示とツールを組み合わせたものです。オーケストレーターは、その周囲に責任分担、共有状態、許可する遷移、停止条件といった連携の仕組みを用意します。

受付エージェントだけでも、まとまりのない依頼を使いやすい概要に整理できているかもしれません。そこに調査担当と執筆担当を加えると、別の課題が生まれます。矛盾する根拠を誰が整理するのか。承認者が見たのはどの下書きなのか。メールサービスがタイムアウトした場合、メールは送信されたのか。これらは業務プロセスとして設計すべき問題です。

どこで責任や処理を区切る必要があるかを基準に、パターンを選びます。

これらのパターンは入れ子にできます。案件を管理する永続的なワークフローからグラフを呼び出し、そのノード、つまりグラフ内の工程からリードエージェントに調査の委任を依頼する構成も可能です。ただし、各層には別々の役割を持たせてください。責任範囲が曖昧なまま層を増やすと、デバッグすべき箇所だけが増えます。

単独エージェントの構成から変わるのは、責任の所在です。 業務責任者には、担当者と次のアクションが分かる案件キューが必要です。開発責任者には、状態の保存と、障害から復旧できる実行基盤が必要です。導入を判断する側は、選んだサービスがどの責任を担い、どこからが自社の責任になるのかを把握する必要があります。

リードエージェントとワーカー：全体の責任者を置く

専門分野ごとの作業を生かしつつ、最終的には一貫した回答にまとめたい場合は、リードがワーカーを束ねる方式が適しています。 提案書の責任者が同僚に根拠の収集を頼み、その結果を提案書にまとめる場面を考えてください。同僚は作業に協力しますが、それぞれの判断で顧客に約束するわけではありません。

営業オペレーションの依頼なら、リードは顧客企業の調査と社内での製品適合性の確認を委任し、両方の結果を執筆用のブリーフにまとめられます。

1. 1

   リードに成果物と権限の範囲を示す

   目指す成果物は、根拠に裏付けられた提案書の下書きです。許可する作業は調査と執筆に限定します。提案書の送信、値引きの約束、顧客レコードの更新は、別のアクションとして扱います。

2. 2

   範囲を限定した調査タスクを割り当てる

   各ワーカーに、必要な資料、使用できるツール、期待する出力、停止条件を渡します。独立した調査は並行して進め、他のタスクの結果が必要な場合には、その完了を待ちます。

3. 3

   根拠を回収してから結果をまとめる

   出典、調査結果、未解決の論点を返すよう求めます。リードは矛盾を整理して下書きを作成します。出典がない情報は、要約したからといって断定できる情報にはなりません。

4. 4

   成果物を承認に回す

   顧客担当者が、送信予定の文面、宛先、約束する内容を確認します。送信工程はアプリケーション側で制御し、承認された成果物だけを実行対象にします。

Anthropicのプログラムから操作できるエージェント実行基盤、Claude Agent SDKは、このパターンをサブエージェントで実装します。サブエージェントは、それぞれ固有の指示、コンテキスト、ツールへのアクセス権を持つ独立したエージェントインスタンスです。agentsオプションで定義し、メインエージェントがAgentツールを通じて呼び出します。通常の非フォーク型サブエージェントには親の会話履歴が渡らないため、必要な文脈はタスクのプロンプトに含める必要があります。親が受け取るのは最終報告です。Claudeのサブエージェントのドキュメント。

ここでは、根拠の受け渡しルールを明確にすると役立ちます。調査担当には、推奨案と、それを裏付ける出典の該当箇所を返してもらえます。注意点： コンテキストが分離されていると、顧客に関する重要な制約が抜け落ちる可能性もあります。制約は明示的に渡し、裏付けとなる成果物もレビューできる状態で残してください。

役割別のエージェントとタスクを扱うフレームワーク、**CrewAI**では、manager_llmまたはmanager_agentを使う階層型プロセスを選べます。マネージャーが計画、委任、タスクの出力のレビューを担います。一方、逐次型プロセスは、先行タスクの結果をコンテキストとして使いながら、タスク一覧の順に処理します。CrewAIのプロセスに関するドキュメント。

作業の割り振りに判断が必要なら、階層型を選びます。必ず調査の後に執筆するのであれば、明示的な順序を定めたほうが処理を確認しやすくなります。注意点： マネージャーによるレビューも、自動化された判断であることに変わりはありません。CrewAIのタスクオプションhuman_inputは、最終回答に対する人のレビューを求めます。重要な書き込みが済んだ後にレビューが来ることのないよう、調査タスクと執筆タスクには読み取り専用の権限を与えてください。CrewAIのタスクに関するドキュメント。

ハンドオフ：次の判断を専門担当に引き継ぐ

次の回答や、その後に分岐する作業を別の専門担当に任せたい場合は、ハンドオフを使います。 サポート案件を、その記録とともに請求担当へ移管するイメージです。自分が案件の責任者であり続け、請求担当には質問だけをする方式とは異なります。

エージェントアプリケーション向けライブラリのOpenAI Agents SDKは、この責任の違いを明確にしています。ハンドオフでは制御を専門エージェントに移し、エージェントをツールとして公開する方式ではマネージャーが回答の責任を持ち続けます。JavaScriptのagent.asTool()が対応するのは後者です。ハンドオフには、構造化したメタデータや、必要な部分に絞った履歴を含められます。OpenAIのオーケストレーションに関するドキュメント。

顧客対応の受信窓口なら、次のように進めます。

1. 受付エージェントが請求に関する異議申し立てだと判別し、該当するアカウントと請求書の参照情報を集めます。
2. 顧客の要望、確認済みの事実、未解決の論点、次に許可されるアクションを添えて、請求担当の専門エージェントに案件を渡します。
3. 請求担当が調査し、解決案を作成します。受付に調査メモを返すのではなく、次の回答を担います。
4. 返金やアカウント変更の提案は、対応するツールが実行される前に人が承認します。

注意点： ハンドオフで移るのは制御であって、業務上の実行権限ではありません。受付から案件が回ってきたというだけで、受け取ったエージェントに返金の権限まで与えてはいけません。返金ツールを実行する箇所で、アクションの許可ルールを強制してください。

専門担当が案件を差し戻せるかどうかも決めます。理由を明記したエスカレーションを認めつつ、引き継ぎの繰り返しには上限を設けます。そうしなければ、曖昧な依頼が専門担当の間を行き来し、進捗がないままモデル呼び出しを消費しかねません。

このSDKの承認処理は、アプリケーション側でレビューするための中断情報と、再開可能な状態を返します。判断が後になる場合は状態を永続化し、同じ実行を再開してください。入力ガードレールは最初のエージェントに、出力ガードレールは最終出力を返すエージェントに適用されます。この外側の検査が内部のすべてのアクションを確認すると思い込まず、慎重な扱いが必要なツールの周囲にもチェックを設けてください。OpenAIの人によるレビューに関するドキュメント。

チェックポイント付きグラフ：次の工程を明確にする

エージェントがその場で計画を立てることよりも、許可された経路を守ることが重要なら、グラフを使います。 グラフは、ルールでつながれた工程の集合です。チェックポイントは進捗を保存した記録で、処理を一時停止し、後から続けられるようにします。

状態を持つエージェントワークフロー向けフレームワークの**LangGraph**は、分岐や並列処理を含むワークフローの経路を明示的に定義できます。チェックポインターがスレッドのグラフ状態を保存し、interrupt()で外部からの入力を待つために一時停止します。中断したスレッドはCommand(resume=...)で再開します。LangGraphのワークフローパターン、中断処理のドキュメント。

調達チームが取引先の推奨案を準備する場合は、次のように設計します。

1. 1

   案件を構造化した状態として保存する

   依頼内容、根拠の参照先、不足情報、下書きの保存先、レビュー状況を、それぞれ名前の付いたフィールドに格納します。会話ログを添えても構いませんが、現在の状況が会話ログにしか残っていない状態にはしないでください。

2. 2

   許可する経路を定義する

   必須項目がそろったら、受付から調査へ進みます。情報が足りなければ依頼者に差し戻します。調査結果を執筆につなげ、根拠のチェックで不足が見つかれば、必要な点に絞って再調査に戻せるようにします。

3. 3

   チェックポイントを保存し、レビューで一時停止する

   推奨案を保存し、承認が必要な処理に入る前に中断します。調達責任者は、実際の成果物、裏付けとなる根拠、求められているアクションを確認します。

4. 4

   判断に応じて許可された分岐から再開する

   承認されたら提出に進めます。修正を求められた場合は執筆に戻し、以前の承認を無効にします。却下された場合は理由を記録して案件を終了します。

注意点： LangGraphで中断後に再開すると、中断を含むノードの先頭から処理が始まります。中断より前のコードも再実行されます。影響の大きい書き込みは別途制御する工程に切り出し、繰り返される処理は冪等にしてください。同じ論理的な要求を繰り返しても、追加の作用が生じない設計が必要です。LangGraphの中断に関するルール。

たとえば、取引先レコードを登録してから承認を求めるノードでは、承認前に実行してはいけない処理がすでに済んでいます。再開時に再び登録してしまう可能性もあります。まず変更案を用意し、承認を得てから、変わらないアクション識別子を使って承認済みの変更を実行してください。

本番環境では、チェックポイントを永続化できる保存先を選びます。LangGraphのインメモリ型の保存機構では、プロセスが再起動するとチェックポイントが失われます。永続的なスレッド識別子と、データベースに保存する状態も、復旧設計の一部です。LangGraphの永続化に関するドキュメント。

永続的なワークフロー：エージェントの実行をまたいで案件を管理する

エージェント呼び出しの終了、ワーカーの再起動、外部からの応答の遅れがあっても業務を継続させる必要があるなら、永続的なワークフローを使います。 開始、待機、再試行、再開、完了、エスカレーションという案件のライフサイクルを、このワークフローが管理します。エージェントはその中で作業を担う存在です。

複数の工程を永続的に実行するサービス、**Cloudflare Workflows**は、工程の永続化と再試行の設定に対応しています。処理にはstep.do、外部での判断を待つにはstep.waitForEvent、待機中のインスタンスにその判断を渡すにはinstance.sendEventを使います。Cloudflare Workflows、イベントのドキュメント。

業務チームが個別対応のサービス依頼を扱う場合は、次の流れになります。

1. 依頼を受けた時点で案件レコードを作り、変わらないワークフロー識別子を割り当てます。
2. 調査エージェントを呼び出し、根拠をまとめた成果物を永続化してから、その成果物を渡して執筆エージェントを呼び出します。
3. 返信案を保存し、業務責任者からの承認イベントを待ちます。承認画面では、案件と成果物のバージョンの両方を特定できるようにします。
4. 判断の有効性を検証し、別の工程で承認済みの送信やレコード更新を実行します。
5. 外部サービスの受付結果を記録して案件を完了します。完了したかどうか不明な場合は、再び書き込む前に外部システムと照合します。

注意点： 実行を永続化しても、外部サービスのアクションを安全に繰り返せるとは限りません。Cloudflareは、冪等なAPI呼び出し、細かく分割した工程、決定論的な工程名を明示的に推奨し、step.doの外で副作用を起こさないよう注意を促しています。サービス側では送信を受け付けたのに応答だけが失われた場合、重複排除なしで再試行すると再送信してしまう可能性があります。Workflowsのルール。

再試行は、要求内容を変えずに解消する可能性がある一時的な障害に対して設定します。認証エラー、承認の却下、無効な業務指示には、通常は介入が必要です。Cloudflareでは再試行を設定できるほか、再試行を打ち切るべき障害にNonRetryableErrorを使えます。再試行のドキュメント。

チェックポイントを永続化したLangGraphアプリケーションには、すでに復旧機能があります。追加のワークフローエンジンが必要になるのは、サービス、コールバック、エージェント実行基盤をまたぐ、より広いライフサイクルを管理するときです。同じ有料処理や副作用のある処理を、両方の層が独立して再試行しないようにしてください。この責任の分け方については、マネージドエージェントの成果、Webhook、Cloudflareのワークフローで詳しく説明しています。

人の承認はアクションの実行直前に置く

影響を伴うアクションは、その正確な内容を人が承認してから実行する必要があります。 読みやすい下書きをレビューしても、その後に別のエージェントが宛先、金額、添付ファイルを変更できるなら不十分です。

提案書なら、レビュー画面に宛先、最終的な文面、添付書類、取引上の約束、不確かな主張の根拠を表示します。承認記録では、レビュー担当者の本人情報を、その成果物のバージョンとアクションの引数にひも付けてください。

実行側は、アクションの直前にその記録を確認する設計にします。承認後に下書きや送信先が変わっていれば、レビューに戻します。権限を持つ人による明示的な承認判断を使い、コメントや修正提案とは区別してください。

CrewAI Flowsでは、@persistで状態を永続化し、@human_feedbackでフィードバックを待つために一時停止できます。影響を伴うアクションでは、特に押さえておきたい点があります。emitで結果の選択肢を設定すると、フィードバック機構は自由記述の内容を言語モデルで解釈し、いずれかの結果に分類します。解釈されたコメントだけを実行許可の根拠にせず、権限の確認には別途検証した承認フィールドを使ってください。CrewAI Flowsのドキュメント。

新たな購入が発生しうる箇所には、別の権限チェックを設けます。接続失敗の再試行と、完成した結果をエージェントが気に入らないために別の出力を購入することは、異なる判断です。後者には、定義済みの支出枠か、新たな承認が必要です。この問題に絞った解説は、AIエージェントの再試行に対する人の承認を参照してください。

何を記録し、何に上限を設けるか

案件の経緯を再現できるだけのログを残し、追加の作業を始める前に上限を適用してください。 最終回答がよくできていても、なぜ誤った成果物を送ったのか、なぜ予算を超えたのかは分かりません。

案件レコードと実行イベントには、次の項目群を用意します。

• 識別情報と実行の親子関係： 案件ID、ワークフロー／実行ID、親と子の実行ID、エージェントの役割、現在の工程、試行回数です。ワーカーの障害を、元の業務依頼に結び付けます。
• 入力と設定： 入力成果物の参照先とバージョン、モデル識別子、プロンプト／設定のバージョン、許可されたツール群です。実行間で何が変わったかを特定できます。
• 判断と根拠： 振り分けの判断、選んだ送信先や移管先、出典、検証結果、不足情報です。観測できる判断と簡潔な理由を記録し、モデル内部の非公開の推論には依存しないでください。
• 承認： レビュー担当者、判断、タイムスタンプ、成果物のダイジェスト、アクションの引数、有効期限です。ダイジェストは、レビューした内容を識別する指紋に当たります。
• アクションと復旧： ツール名、機密部分を伏せた引数、アクションキー／冪等性キー、外部リクエストID、受付結果、障害の分類、再試行の予定です。結果が分からないときは、不明であることを明示した状態を残します。
• 使用量と成果： モデルのトークンの区分、推定支出額と照合済みの支出額、有料ツールの使用量、経過時間、レビュー待ち時間、最終状態、人が結果を受け入れたかどうかです。

これらのログを閲覧できる人を制限してください。秘密情報は含めず、顧客データは最小限に抑えます。内容を丸ごと複製すると不要な露出が増える場合は、アクセス制御された成果物への参照を使います。

OpenAI Agents SDKのトレーシングは、モデル呼び出し、ツール呼び出し、ハンドオフ、ガードレールを記録します。技術的なトレースを案件レコードに結び付けてください。ただし、顧客に関わるアクションが承認されたかどうかを判断する業務上の根拠を、トレースだけにしてはいけません。OpenAIのトレーシングに関するドキュメント。

マルチエージェントの連携ツールには、強制できる上限が必要です

案件全体の支出、エージェントのターン数、ツール呼び出し数、同時実行するワーカー数、委任の深さ、ハンドオフ回数、再試行回数、開始からの経過時間に上限を設けます。実行処理の期限と、人のレビューの期限は分けてください。上限値は、事業として許容できるコストと遅延から決めます。どこでも安全に使える共通の初期値はありません。

並行処理を開始する前に予算を確保し、各呼び出しが終わった時点で使用額を照合します。そうしないと、すべてのワーカーが同じ残予算を見て、それぞれ独立に使ってしまう可能性があります。再開した実行の費用も、同じ案件の予算に計上してください。

Claude Agent SDKには、TypeScriptのmaxBudgetUsd、Pythonのmax_budget_usdなどのクエリ単位の支出制御に加え、サブエージェントの深さと同時実行数の制御があります。サブエージェントのドキュメントで、インストール済みのバージョンが要件を満たすか確認してください。

どこまでが集計対象かにも注意が必要です。usageフィールドにはサブエージェントの活動が含まれませんが、modelUsageまたはmodel_usageには含まれます。total_cost_usdにもサブエージェントは含まれますが、これはクライアント側の推定値です。クエリの支出上限が対象にするのは、その呼び出し自体の支出であり、再開したセッションから復元された過去の支出ではありません。案件単位の台帳を持ち、推定値を確定的な使用量の記録と照合してください。Claudeのコスト追跡に関するドキュメント。

SDKの予算設定は、最終請求額がその金額を厳密に超えないという保証でもありません。ドキュメントにある上限付き実行の結果は、しきい値と同額か、それを超えた状態で終了することがあります。実行中の作業に必要な余裕を残し、業務上の支出枠を使い切る前に新たな作業の割り当てを止めてください。

オーケストレーションの費用は案件全体で捉える

失敗した作業やレビューも含め、業務上の成果が完成するまでの費用を予算化してください。 エージェントを増やすと独立した調査の時間を短縮できる一方、コンテキストの重複、結果を統合するための追加呼び出し、修正の繰り返しも増えます。追加コストに見合うほど、受け入れ可能な成果が改善するかどうかが、事業上の判断基準です。

月次の費用は、次の式で考えます。

プロセスの費用 = モデル使用料 + 有料ツール + ワークフローのインフラ + 状態とログの保存 + 人によるレビュー + 運用。

これを、エージェントの実行回数ではなく、承認された成果の数で割ります。失敗した案件や採用されなかった下書きの費用も、分子に含めます。同じ受け入れ基準と人件費の前提を使って、現在のプロセスと比較してください。この情報がなければ、信頼できる削減率は算出できません。

インフラ費用の具体的な目安として、Cloudflareは次の料金を公表しています。

出典：Workersの料金、Workflowsの料金。アカウントの最低料金はインフラの費用であり、エージェントの総額ではありません。リクエスト、CPU時間（プロセッサによる処理）、モデル呼び出し、その他のサービスも別途計上する必要があります。課金に関する告知では、ステップとストレージへの課金開始は2026年8月10日以降とされています。ただし、公表されている記述だけでは、個々のアカウントで課金が有効になっているかまでは確認できません。

本記事での計算： 公表料金の$0.80を100,000で割ると、他の料金を含めない追加ステップあたりの単価は$0.000008です。これは表示料金の単位換算であり、ワークロードの費用見積もりでも、実測した請求額でもありません。公表されているステップ単価。

待機中にモデルを繰り返し動かす必要はありません。Cloudflareは、APIの応答待ち、スリープ、アイドル時間にはCPU時間の課金が発生しないとしています。状態の保存とステップの計上は別です。承認者が返答したかどうかを何度もエージェントに尋ねるのではなく、案件を永続化してイベントを待ってください。Workflowsの料金。

マルチエージェントシステムのフレームワークは業務プロセスに合わせて選ぶ

フレームワークを選ぶ前に、連携の責任範囲を決めてください。 結果の統合が必要なら全体の責任者を置き、次の専門担当が独立して動くべきなら責任を引き継ぎます。許可された遷移を守ることが重要ならグラフを使い、呼び出しが終わった後も業務を続ける必要があるなら、ライフサイクルを永続的に管理する仕組みを加えます。

フレームワークごとの選び方は、AIエージェントのフレームワーク比較で解説しています。明示的なグラフ状態と、役割別のエージェントチームのどちらにするかまで絞れている場合は、LangGraphとCrewAIの比較を参照してください。

開発責任者は、永続化、実行権限、復旧の責任者を明確にする必要があります。業務責任者は、受け入れ基準、承認者、エスカレーション、許容する支出を定めます。導入を判断する側は、誰がこれらの制御を運用し、記録はどこに保存され、障害後に一時停止中の案件をどう復旧するのかを確認してください。

プラットフォームにインフラの運用を任せることはできます。しかし、自社で何を承認済みの返金とみなすか、提案書の主張に十分な根拠があるか、追加購入を認めるかは、プラットフォームには決められません。

期待しすぎてはいけないこと

エージェントを増やすだけで、結果がよくなるとは限りません。 エージェントを分けるなら、それぞれに異なる情報源、ツール、責任を持たせてください。役割に違いのないエージェント同士に何度も批評させても、根拠が増えないまま予算を消費することがあります。

グラフが描かれていることも、障害に耐えられる証拠にはなりません。障害後に何が残るかを決めるのは、保存された状態、永続化のバックエンド、再実行時の挙動です。同様に、プロンプトに「送信前に確認する」と書くだけでは、送信ルールを強制できません。実行側で許可を確認する必要があります。

モデルが決める計画は、範囲を限定したタスクの内側にとどめてください。次にどの関連資料を調べるかは、調査担当に選ばせて構いません。非公開データの開示、経費の承認、顧客へのメッセージ送信の判断は、アプリケーションのアクセス規則と承認規則に従わせます。

まず取り組むべきこと

対象の業務プロセスを絞り、そこに必要な最小限の責任分担や制御を加えるところから始めてください。 すでに機能しているエージェントは生かします。その入力、出力する成果物、ツール、責任者、成功条件、停止条件を書き出し、不足している調査や執筆の役割を追加します。

顧客向けの送信や更新を有効にする前に、機密情報を含まない代表的な入力で障害ケースを試します。下書きの保存後に実行を中断する、承認を重複して届ける、提案を却下する、承認済みの成果物を変更する、予算を使い切る、外部への書き込みの応答が失われる状況を再現する、といった確認です。どの場合も、案件が記録された状態に落ち着き、次に取るべきアクションが明確になることを確かめてください。

専門担当の責任範囲をまたぐ業務、承認待ちがある業務、確実な復旧が必要な業務なら、今取り組む価値があります。現在の問題が情報源の質や曖昧な受け入れ基準にあるなら、エージェントの追加は待ってください。単独エージェントで安定して動き、そうした区切りも必要ないプロセスは、そのままで構いません。

業務責任者が押さえておきたい疑問

単独のエージェントで動いていても、連携を管理するプラットフォームは必要ですか？

現在のアプリケーションに足りない連携機能や運用機能が必要な場合に限ります。まず、専門担当への責任の移管、進捗の保存、後から行う承認、復旧など、不足している役割を明確にしてください。その要件によって、ライブラリ、ワークフローサービス、少量のアプリケーションコードのどれを追加すべきかが決まります。

同じプロセスの中で、これらのパターンを組み合わせられますか？

はい。永続的なワークフローが案件を管理し、グラフがレビューの経路を制御し、リードエージェントが調査を委任する構成にできます。各層の責任を明確にし、同じ処理に対する再試行の方針が重複しないようにしてください。

下書きを承認すると、追加料金のかかる再試行も承認したことになりますか？

その支出範囲が承認に明示的に含まれている場合だけです。成果物を使うことへの承認と、追加の試行を購入する許可は、別々に記録する必要があります。下書きが変わった場合も、それに伴う影響の大きいアクションを進める前にレビューが必要です。

承認者からいつまでも返答がない場合は、どうすればよいですか？

定めた方針に従って保留中の判断を期限切れにし、担当責任者へ通知して、案件を保留するか終了します。後からレビューできるよう、必要な文脈は保存してください。返答がないことを、自動承認に変えてはいけません。

AIを使った業務ワークフローの構築と運用に役立つ実践ガイドは、ニュースレターに登録してお読みください。