マルチエージェントの破綻点 ― 「分ければ速い」を成立させる境界設計

「1体ではコンテキストが足りない。なら、何体かに分ければ速いはず」。マルチエージェント化を考える入口としては自然です。ただ、分けた瞬間に増える仕事があります。誰に何を渡すか、返ってきた内容をどう確かめるか、食い違った成果物を誰が直すか。その設計が抜けると、待ち時間だけでなく、やり直しまで並列になります。

僕は以前、コマンド集を作るために7つのAIエージェントを配置した実例を書きました。そこで実際に落ち着いたのは、当初の7役をそのまま回し続ける形ではなく、サブエージェントへの委任、バッチQA、内容補強という段階的な流れでした。今回はその記録と、このマシンにあるHermesの委任実装を材料に、複数エージェント間の契約と検証を掘り下げます。

※2026年10月時点の公開情報と、2026年10月4日に確認したローカル実装に基づきます。委任文と制御設定の例は本稿用の設計例です。単一構成との費用比較は未実測で、後述の数値は試算として区別します。

単一エージェントの、どの壁を分けるのか

ここでいうマルチエージェントは、仕事を分解して統合する司令塔（orchestrator）と、範囲を絞って作業するワーカー（worker）を組み合わせる構成です。複数モデルに同じ質問をして多数決する話とは分けて考えます。

最初に見るのは、「入力の長さ」「ツールを呼んだ回数」「待機時間」「再作業」の記録です。外部APIの応答を待っているなら、同じ処理を並列にする余地があります。一方、1つのファイルの仕様を何度も判断し直しているなら、担当を増やすより、仕様を固定する方が先でしょう。これは本稿の設計上の判断基準であり、エージェント数だけで速さを約束するものではありません。

Anthropicの研究システムの報告でも、独立した方向を並列に調べる仕事に適性がある一方、依存が多く全員が同じ文脈を必要とする仕事には制約があるとしています。研究での成果を、そのままコード修正や業務処理の速度向上に読み替えない方がよいです。出典：Anthropicのマルチエージェント研究システム

破綻点①：委任仕様に、完成条件がない

親が直前まで読んでいた仕様を、子も当然知っていると思う。ここでズレが始まります。ただし、「サブエージェントは必ず会話履歴を知らない」とまで断定するのも不正確です。履歴を引き継ぐ方式、必要な情報だけを渡す方式など、実装によって違います。確認すべきなのは、今使っている委任機能が何を入力にしているかです。

このマシンのHermesのdelegate_task実装では、子のプロンプトをgoalとcontextから組み立て、子の生成にskip_context_files=Trueとskip_memory=Trueを指定しています。親に適用されたプロジェクト指示や記憶を、そのまま子も読み込む前提にはできません。確認対象はローカルのtools/delegate_tool.py、コミットc82abc309aです。これは確認した版の挙動で、他の版や他の製品まで同じとは言えません。

「調べて」から、返却条件のある委任へ

次のBefore／Afterは、実際の事故ログではなく説明用の例です。曖昧な委任では、ワーカーが製品紹介を書いてきても、親は仕様比較を期待していたかもしれません。

Before:
マルチエージェントの制御機能を調べて、いい感じにまとめて。

After:
目的: この構成で再帰委任を止められるか確認する。
前提: 親が最終回答と統合を担当。調査対象は指定した版の公式資料。
制約: 読み取りのみ。コード変更・投稿・追加委任はしない。
      不明な仕様は推測で埋めず「確認できない」と返す。
出力: 制御項目、適用範囲、根拠URL、確認日、未確認点。
      各結論には対応する根拠を付け、要約は800文字以内。

目的・前提・制約・出力形の4つを、委任のたびに揃えます。実装作業なら前提に基準コミット、制約に編集可能なファイル、出力に差分と実行した検証を足す。「プロジェクトのルールに従って」だけでは、子がルールファイルへアクセスできるか、読んだかが分かりません。ファイルの場所と、今回守る条件を具体的に渡します。

親へ戻す情報も絞ります。結論だけでは検証できず、全文では親の履歴が膨らむ。短い結論に、URLやファイルの位置、未確認点を添えて返すのが、ここでいうコンテキスト分業です。

破綻点②：「成功しました」を検証せずに通す

ワーカーの完了報告は、検査を始める合図です。成果物が正しい証明にはなりません。「公開しました」と返ってきたら、URLを開いて内容を見る。「テストが通りました」なら、どの差分で、何を実行し、どんな終了結果だったかを見る。この手順がないと、子の取り違えを親が確定情報として広めてしまいます。

生成と検証を別のエージェントに分けるQAゲートは、観点を変える手段になります。ただ、同じモデルや同じ根拠の誤りを共有することもあるので、2体が賛成しただけで正解とは扱いません。JSONの構文、必須項目、リンク先の応答など機械で判定できる部分は、まず決まった検査に渡す。文章の主張と出典の対応や要件の漏れは、その後でレビューします。

CrewAIには、次のタスクに進む前に出力を検証するguardrailと、検証失敗時の再試行回数を制限するguardrail_max_retriesがあります。機能があることと、何を合格条件にするかは別の話です。再試行を上限まで繰り返しても不合格なら、成功に置き換えず、未完了として親へ戻します。出典：CrewAI Tasks

破綻点③：再帰委任を、お願いだけで止める

子が「この仕事は難しい」と考えて孫を呼び、孫も別の専門家を呼ぶ。個々の判断が自然でも、全体の呼び出し数は膨らみます。例えば、各エージェントが3体ずつ委任し、親から3階層下まで作る完全な木なら、子孫は3 + 9 + 27 = 39体。これは構造の計算例で、実測ではありません。深さだけでなく、総数と同時実行数も必要になります。

「追加委任しない」とプロンプトに書くのは意思の伝達です。強制するなら、末端のワーカー（leaf）へ委任ツールを公開しない、あるいは呼び出し受付側で拒否する。司令塔と末端の違いを、名称だけでなく権限にします。

確認したHermesの実装では、子の役割はモデルが指定する名前だけで決まらず、現在の深さとmax_spawn_depth、orchestrator_enabledから決まります。該当部分は次の通りです。ローカル実装からの抜粋で、記事作成のためにこのコードを変更・実行したものではありません。

child_depth = getattr(parent_agent, "_delegate_depth", 0) + 1
max_spawn = _get_max_spawn_depth()
effective_role = "orchestrator" if _get_orchestrator_enabled() and child_depth < max_spawn else "leaf"

同じ版のdelegate_tool_config.pyでは、既定の深度は1、子のタイムアウトは未設定です。そこで「深度を制限しているから長時間走らない」とは言えません。深度制限は委任の階層を、タイムアウトは実行時間を抑える別の制御です。

期限に達した親は、新規委任を止め、実行中の子へ中断を伝え、未回収の成果物を未完了として扱います。親が待機をやめただけでは、子が外部APIや別プロセスで動き続けることがあります。子が起動した処理も停止対象に含め、終了を確認するまで担当領域を他のワーカーへ再配分しない。すでに外部へ送った操作が取り消せるとは限らない点も、回収手順に残します。

AutoGenにはメッセージ数、トークン使用量、時間による終了条件があります。ただしトークン条件は使用量の報告が前提です。上限の設定に加え、実際に使用量が届くかまで確認が必要です。出典：AutoGen Termination

破綻点④：並列の結論を、そのまま足し合わせる

ワーカーAは「既存仕様を維持」と判断し、Bは「新仕様へ置換」と判断した。両方が担当範囲では合理的でも、そのまま統合はできません。調査でも同じで、料金や機能の記述が違ったら、日付・版・適用条件を揃えて見直す必要があります。

最初の構成は、ワーカー同士が自由に書き換える共有状態を減らし、親が成果物を受け取る形にすると追いやすいです。読み取り専用の資料は共有して構いません。書き込み先をタスク別に分け、共通ファイルや最終公開物の更新を親へ集めます。コード変更では別ブランチや分離した作業ディレクトリを使い、統合する差分の基準を揃えます。

独立したファイルの修正なら、差分をまずマージして統合後の検査を回す方法があります。反対に、共通の仕様や同じデータについて結論が衝突する場合は、該当箇所を再検証してから採用します。Gitが衝突しなかったことは、意味の整合性まで保証しません。

LangGraphは共有状態の更新を合成するreducerを定義できます。リストを追加して集約する方法はありますが、互いに矛盾する結論まで自動で正しく選ぶ仕組みにはなりません。状態の合成規則と、結論を採用する判断基準の両方を設計します。出典：LangGraph Graph API

実例：7役から、委任・検査・補強の流れへ

4月のコマンド集制作の記事では、ライター・デザイナー・HTML担当と、それぞれのレビュー担当、全体検査担当という7役を定義していました。一方、実際の完成までの流れとして記録したのは、骨組みを委任で作る、全ページをバッチQAで検査する、コマンド情報を使って内容を補強するという3段階です。役割を細かく作ることと、その数のエージェントを常時動かすことは一致しません。出典：過去記事のパイプラインの変遷

ここから本稿で取り出すのは、生成と検査の境界です。「7体に分けたから何倍速くなった」という比較データは、その記事にも今回の確認資料にもありません。過去記事の成果物の記録を、単一構成との性能比較に使うことは避けます。

役割記述を、委任と検品へつなぐ

次は、上の実例から整理したAGENTS.mdの記述例です。実運用ファイルを丸ごと公開したものではなく、必要な契約を短く表すための設計例です。

## 司令塔
- 目的、対象の版、完成条件を確定する。
- 基準コミットと編集可能範囲を付けて委任する。
- 子の成果物を検証し、矛盾の解決と統合を担当する。
- 公開権限を持ち、結果を確認して報告する。

## ワーカー
- 指定した担当範囲だけを扱う。追加委任はしない。
- 根拠、変更内容、実行した検証、未確認点を返す。
- 完成条件を満たせない場合は、未完了として理由を返す。

## 検証担当
- 対象の成果物と完成条件を照合する。
- 合否と、問題の位置・理由を返す。公開操作はしない。

この記述を読ませるだけでは権限制御になりません。ワーカーから委任・公開ツールを外し、実行基盤側で担当パスと予算を制限する。そのうえで「委任→成果物回収→形式検査→根拠検査→統合後の検査→公開確認」を1サイクルにします。QAが不合格なら理由を添えて担当へ返し、修正回数の上限を超えたものは最終報告に残します。

OpenAI Agents SDKも、専門家へ会話の主導権を渡すhandoffと、親が最終回答を持ったまま専門家を呼ぶagents as toolsを区別しています。本稿のように統合責任を親へ置くなら、後者の構成が対応します。名前の付け方より、誰が最後の回答を持つかを先に決めるという読み方です。出典：OpenAI Orchestration and handoffs

コスト予算は、子に配る前に親へ残す

コンテキストを分けても、請求や制限枠が自動で分かれるわけではありません。タスク全体で使える量を決め、親の計画・統合と、検証・再作業の分を先に確保します。余りを各ワーカーへ配る。全量を子へ渡してから「統合する予算がない」となるのを避けるためです。

下表は、入力と出力を合わせた延べトークン数の仮定による試算です。キャッシュやモデル単価は含めず、実測・金額比較には使いません。

この仮定では分業側が多く使いますが、実際の優劣は同じ完成条件で測らないと決まりません。金額を比較するときは、モデル別の入力・出力・キャッシュ対象の単価と、ツール利用料を分けて集計します。成功したタスクだけでなく、失敗・再試行に使った分も含めた「合格成果物1件あたりの費用」を見る。速くてもやり直しが増えるなら、その費用を隠さないことです。

Anthropicが2025年6月に公開した事例では、チャットを基準として単一エージェントが約4倍、マルチエージェントが約15倍のトークンを使うと報告しています。「単一エージェントの15倍」でも「どんな仕事でも15倍の料金」でもありません。特定の研究システムでの報告として読む必要があります。出典：Anthropic、2025年6月13日公開

予算の強制は、エージェントの申告だけに頼らず、APIや実行基盤の使用量をタスクIDへ集計して行います。同時に走る子がそれぞれ「残り予算を使える」と判断すると二重に割り当てるため、呼び出し前に予算を予約し、終了後に実績との差を戻します。使用量が遅れて届く場合は余裕を残す。この会計と、同時実行数によるレート制御を別々に置きます。

まず1つ、検収できる仕事を分ける

最初の分業は、担当範囲が明確で、親が合否を確認できるものがよいです。例えば、別々の公式資料を調べて根拠付きで返す作業なら、全員が同じファイルを書き換える必要はありません。親1体と範囲を絞ったワーカーで、完了時間、合格率、再作業、費用を記録し、単一構成と比べます。

増やす前に、次の4項目を埋めてみてください。

• 子に渡る情報と渡らない情報を、実装で確認したか。
• 返ってきた成果物を、親がどの証拠で検収するか決めたか。
• 追加委任・実行時間・全体予算を、基盤側で止められるか。
• 矛盾が出たときに、誰が再検証して統合するか決めたか。

「分ければ速い」は、独立して進められる作業があり、検収と統合の費用を上回る効果がある場合に成り立つ話です。分業の単位を決められない段階では、人数を足すより、仕事の完成条件を一つ具体化する方が次へ進めます。

実行権限そのものの制御はAIエージェントのガードレール設計、費用の集計はエージェントのコスト設計でも扱っています。本稿の契約と検収を、その土台の上に置いてください。

参照資料と確認範囲

• Anthropic：How we built our multi-agent research system（2025年6月13日公開）
• OpenAI：Orchestration and handoffs
• CrewAI：Tasks
• AutoGen：Termination
• LangGraph：Graph API overview
• 当ブログ：7つのAIエージェントを並列稼働させた話（2026年4月16日）

外部資料は2026年10月4日確認。Hermesは本マシンのコミットc82abc309aにある委任処理と制御定義を読み取り確認しました。SDK横断の動作検証、単一・マルチ構成の時間と費用の比較実測は行っていません。委任文・役割記述・予算配分は、製品共通の実行可能コードではなく設計例です。