前章では、1体のエージェントにMCPで外部ツールをつなぐ方法を扱いました。ここまでで「頭・道具・記憶・ループ」を備えた自律エージェントが1体、動くようになっています。ところが仕事が大きくなると、1体にすべてを詰め込む設計はどこかで破綻します。この章では、役割を分けて複数のエージェントで解く「マルチエージェント設計」と、その協調の考え方（A2A：Agent-to-Agent）を、フレームワークに依存しない概念レベルで整理します。
ゴールは「いつ・どう分ければ強くなるか」を判断できること
1体で足りなくなるとき
1体のエージェントは、シンプルで見通しがよく、動きも追いやすい――だからこそまずは1体で作るのが正解です。問題は、そこに次々と役割を足していったときに起こります。「調べて、書いて、レビューして、翻訳して、公開もして……」と1つのプロンプトへ責務を詰め込むと、ある地点から急に精度が落ち始めます。
原因は主に3つあります。①指示が長く曖昧になる（あれもこれもと書くほど、モデルはどれを優先すべきか迷う）。②コンテキストが膨れる（無関係な情報まで抱え込み、肝心の指示が薄まる）。③ツールが多すぎる（選択肢が増えるほど、誤ったツールを選びやすくなる）。1体に詰め込みすぎた状態は、いわば「1人に何役も兼任させて混乱している職場」です。
💡 発想の転換。 1体を賢くし続けるのではなく、「1つの役割に集中した小さなエージェントを、複数、協力させる」という発想に切り替える。これがマルチエージェント設計の出発点です。人間の組織で仕事を分業するのと同じ理屈で、各自の責務を狭く明確にするほど、全体は安定します。
ただし――分ければ必ず良くなるわけではありません。分業には調整のコストがつきまといます。だからこの章の本題は「どう分けるか」だけでなく、「そもそも分けるべきか」を見極めることにあります。まずは代表的な3つの形を見てから、その判断基準に進みましょう。
3つの基本パターン
マルチエージェントの構成は無数に描けますが、実務で繰り返し現れる骨格は3つに集約できます。この3つを組み合わせれば、たいていの構成は説明できます。まずは1つずつ、役割と向き・不向きをつかみましょう。
親（オーケストレーター）が全体の計画を立て、タスクを子（ワーカー）へ振り分けて実行させ、結果を集めて統合する。子は互いを知らず、親だけを見る。中央集権的で制御しやすいのが強み。
向く場面: タスクを分割でき、並列で走らせたいとき。
工程を並べ、前のエージェントの出力を、次のエージェントの入力として順に渡す。たとえば「調査 → 執筆 → 校正」。各段が1つの工程だけを担うので、責務が明快で検証もしやすい。
向く場面: 手順が線形で、段階が決まっているとき。
「調査担当」「コード担当」「レビュー担当」のようにそれぞれ得意分野を持つ専門エージェントを用意し、状況に応じて呼び分ける。各自の指示とツールを絞れるので、専門性が上がる。
向く場面: 求められる能力が領域ごとに大きく違うとき。
この3つは排他ではありません。実際のシステムは、たとえば「オーケストレーターが専門家型のワーカーたちを束ね、その中の1つがパイプラインになっている」といった入れ子構造になることがよくあります。まず一番外側の骨格を1つ決め、必要な箇所だけ内側で別のパターンを使う――という積み上げ方が扱いやすいです。
📊 迷ったら①から。 3つのうち最も汎用的なのはオーケストレーター＋ワーカーです。親が中央で計画と統合を握るため制御しやすく、多くのマルチエージェント構成の基本形になります。パターン全体の整理はマルチエージェントとは、システムとしての捉え方はマルチエージェントシステムとはも参考に。
分けるとき／分けないとき
パターンを知ると、つい何でも分けたくなります。しかし分業には常に「調整のコスト」がかかる――エージェント間で情報を渡し、噛み合わせ、待ち合わせる手間です。分けて得られる利益が、この調整コストを上回るときだけ、マルチエージェントは正解になります。まずは両側を並べて見ましょう。
- 並列できる：独立したサブタスクを同時に走らせ、時間を短縮できる
- 専門性が要る：領域ごとに指示・ツールを絞ると精度が上がる
- 探索が広い：複数の視点や候補を手分けして探したい
- コンテキストを分離したい：役割ごとに文脈を切り、混線を防げる
- 本来は単純：1体で足りる処理を、無用に複雑化してしまう
- コストが増える：エージェントが増えるほどLLM呼び出し・トークンが積み上がる
- 調整が重い：受け渡しや待ち合わせの手間が、分業の利益を食いつぶす
- 強い逐次依存：前の結果に強く依存し、並列の余地がほとんどない
⚠️ まず「1体で十分か」を問う。 マルチエージェントは強力ですが、初手で選ぶものではありません。1体 → プロンプトを工夫 → ツールを足す → それでも足りなければ分割、と段階を上げるのが鉄則です。複雑さは「今の1体が本当に限界か」を確かめてから足しましょう。分割は後からでもできます。
実務的な目安として、「その役割を人間の同僚に説明するとき、1人分の職務記述書に自然に収まるか」を想像してみてください。1つの肩書きで書けるなら、まだ1体で足ります。「これは調査の人、これは執筆の人」と別人にしたくなった瞬間が、分割を検討するタイミングです。判断の全体像はマルチエージェントシステムの作り方も合わせてどうぞ。
エージェント間の連携（A2A）
分けると決めたら、次の設計課題は「エージェント同士がどう情報をやり取りするか」です。人間のチームでいえば、引き継ぎ書のフォーマットや報告のルールを決める作業にあたります。ここが曖昧だと、いくら個々が優秀でも全体は噛み合いません。連携で押さえるべき点は大きく2つです。
何を、どんな形式で渡すかを決める。「タスクの指示・必要な入力・期待する出力形式」を明示的な約束にすると、受け手が迷わない。自由文の丸投げより、構造化した受け渡しの方が安定する。
複数の出力を1つにまとめる工程。誰が最終責任を持って統合するかを決めておく。矛盾する結果が返ったときの優先順位や、まとめ方（要約・突き合わせ・多数決）も設計に含める。
この「エージェント同士が役割を分担して協調する」考え方を、より標準化して扱おうという動きがA2A（Agent-to-Agent）です。前章のMCPが「エージェント↔ツール／データ」をつなぐ約束事だったのに対し、A2Aは「エージェント↔エージェント」をつなぐ約束事――相手のエージェントに何ができるかを知り、タスクを依頼し、結果を受け取るための共通の作法だと捉えてください。
💡 MCPとA2Aは対比で覚える。 ざっくり言えばMCP＝エージェントに「手」をつなぐ、A2A＝エージェント同士を「つなぐ」。前者は道具・データ接続、後者は協調の作法です。まずは概念として押さえておけば十分で、具体的なプロトコルは次章以降でも触れます。より詳しくはA2Aプロトコルとはを参照。前章のMCPとツール接続と読み比べると違いが明確になります。
大切なのは、プロトコルの名前を覚えることではなく、「連携には明示的な約束が要る」という設計姿勢です。誰がどのタスクを持ち、どんな入力で始まり、何を返し、失敗したら誰に戻すのか――この約束を先に決めておくことが、規模が増えても崩れないシステムの土台になります。
コンテキストとコストの管理
マルチエージェントの最大の実務的リスクは、コンテキストとコストの膨張です。エージェントが増え、互いに情報を渡し合うほど、各エージェントが抱えるコンテキストは太り、LLMの呼び出し回数もトークン量も積み上がっていきます。放っておくと、遅く・高く・不安定なシステムになりがちです。設計段階で手綱を握りましょう。
子にはそのタスクに必要な分だけ渡す。全履歴をそのまま流さない。無関係な文脈は精度も落とす。
長い結果は要点に要約してから次へ渡す。生ログではなく「結論と根拠」を手渡す発想。
同時に走らせる子の数に上限を設ける。無制限に増やすとコストとレート制限で破綻する。
重い推論の親と、単純作業の子でモデルの規模を使い分ける。全部を最上位モデルにしない。
特に「渡す情報を絞る」は効果が大きい設計判断です。オーケストレーター＋ワーカー型なら、親は全体像を持つが、子には切り出したタスクと最小限の入力だけを渡す。子が抱えるコンテキストを小さく保てるほど、精度は上がり、コストは下がります。これは前章までで触れたコンテキストエンジニアリングの考え方が、複数エージェントに拡張されたものだと捉えてください。
⚠️ コストは「体数 × ステップ数」で効く。 エージェントを1体増やすと、そのぶんの呼び出しがループの回数だけ積み上がります。体数が増えるほど、1体あたりの無駄が全体で何倍にも膨らむ点に注意。並列数の上限と、各エージェントのステップ上限（止めどき）を最初から決めておきましょう。この「どれだけ使っているか」を測る話は、次章の可観測性につながります。
つまずきと設計での防ぎ方
マルチエージェントには、単体では起きなかった固有の失敗があります。いずれも実行時の運任せではなく、設計であらかじめ防ぐのが基本です。代表的な3つと、その対策を押さえておきましょう。
複数のエージェントが同じ仕事を二重にやる、または「どちらの担当か」が曖昧で誰もやらない。
防ぎ方: 各エージェントの責務を重ならず・漏れなく切り分け、境界を1文で言い切れる状態にする。
AがBに、BがAに……と互いに仕事を押し付け合い、いつまでも終わらない・同じやり取りを繰り返す。
防ぎ方: 終了条件と、往復・ステップ数の上限を必ず設ける。中央（親）が最終判断を握る形にすると暴走しにくい。
1体の失敗や誤った出力が、そのまま次へ流れ、全体を止める・誤った成果を作り上げる。
防ぎ方: 受け渡しの前に出力を検証し、失敗時のフォールバック（再試行・代替・人間へエスカレーション）を決めておく。
3つに共通する教訓は、「境界・終了条件・検証」をコードを書く前に決めておくことです。誰が何を担当し（境界）、いつ止まり（終了条件）、渡す前に何を確かめるか（検証）。この3点を設計に織り込んでおけば、マルチエージェント固有のトラブルの大半は未然に防げます。
📊 「見えないと直せない」。 これらの失敗は、どのエージェントが何をしたかを後から追える状態になっていて初めて気づけます。複数エージェントが絡むと、単体以上に「どこで何が起きたか」が見えにくくなる――だからこそ次章の評価と可観測性が、マルチエージェントでは一段と重要になります。
- 1体に詰め込みすぎると精度が落ちる。役割を狭く分けた小さなエージェントの協力で解く。
- 基本パターンは3つ ― オーケストレーター＋ワーカー・パイプライン・役割分担。入れ子にできる。
- 分けるのは並列・専門性・広い探索が要るとき。単純なら1体のまま。まず「1体で十分か」を問う。
- 連携は明示的な約束で行う（A2A＝エージェント同士をつなぐ作法）。コンテキストとコストは絞って管理。
- 固有の落とし穴（重複・投げ合い・連鎖する失敗）は境界・終了条件・検証を設計で先に決めて防ぐ。
複数のエージェントが動き始めると、次に必要になるのは「本当にうまく動いているかを測り、動きを見える化する」ことです。次の第5章「評価と可観測性」で、エージェントの品質を測り、内部の動きを追える状態にする方法へ進みます。