Agent-to-Agent設計 ①全体像 — なぜマルチエージェントか、MCPとA2Aの地図

date: 2026-06-26 A2A マルチエージェント考察

エージェント同士を連携させる「Agent-to-Agent（A2A）」の設計を3回連載で整理する。第1回は全体像。なぜ単一エージェントでは足りないのか、逆に単一で十分（むしろ望ましい）のはどこかを押さえ、設計を4層の地図に落とす。混同されがちなMCP（縦）とA2A（横）の役割分担も明確にする。

「Agent-to-Agent設計」連載（全3回）

① 全体像（この記事）／② 設計パターンカタログ／③ 実装編
①で「なぜ・どの層・どの形」を俯瞰し、②でオーケストレーション・トポロジを棚卸しし、③で実装と失敗対策に落とす。

1. なぜ単一エージェントでは足りないのか

1つの巨大エージェント——1つのループ、1つのコンテキスト窓、全ツールを抱える——には構造的な限界がある。

コンテキスト窓の有限性: context window は「最も希少な共有資源」だ。全タスク・全ツール定義・全履歴・全取得文書を1窓に積むと、トークン増に伴って想起精度が落ちる context rot（コンテキスト腐敗） が起きる。
関心の分離ができない: 探索・計画・実装・検証を1つの履歴で混在させると、無関係な情報が判断をブレさせる。
並列性の欠如: 独立に分割できる探索を逐次でしか回せず、レイテンシが線形に積み上がる。
専門性の希薄化: 1つのシステムプロンプトに全ドメインの規約・ツール作法を詰めると、どれも中途半端になる。

マルチエージェント設計は、これらにコンテキスト分離・並列化・役割特化・組織/ベンダー越境連携で応える。実証として、Anthropic のマルチエージェント・リサーチシステムは、リードエージェント＋並列サブエージェント構成で単一エージェント比+90.2%の性能改善を報告している（ただしトークンは通常チャットの約15倍）。

そして「Agent-to-Agent（A2A）」が本当に要るのはさらにその先——組織・ベンダー・フレームワークの境界を越えてエージェント同士を連携させたいときだ。各社の内部実装（プロンプト・モデル・ツール）を晒さず、「不透明（opaque）なエージェント」のまま疎結合に発見・委譲する標準が要る。

2. でも、単一で十分な領域がある — 濫用の戒め

ここを先に釘を刺しておきたい。マルチエージェント化はコスト・複雑度・失敗面を確実に増やす。次の場合は単一エージェント（または単一スレッドの線形設計）が正解になりやすい。

書き込み中心・相互依存が強い: 逐次コーディングのように「前の判断を全部見て次を決める」作業。Cognition（Devin）の「Don't Build Multi-Agents」は、並列サブエージェントが互いの暗黙の設計判断を共有せず成果物が噛み合わないと指摘する（一方がマリオ風背景、他方が無関係な鳥を作る Flappy Bird の例）。
副作用を伴う: 並列の書き込みは競合を生む。
短命・単発・低stakes: 長期メモリも複雑な協調も不要。
数行の修正・質問応答: オーケストレーションのオーバーヘッドが純損になる。

判断軸はこれ一本

読み取り中心で独立に並列分解できるか（→マルチ向き）／書き込み・相互依存で単一の一貫した意思決定線が要るか（→単一向き）。実際 Cognition 自身も後に「Devin can Manage Devins」（各 Devin を隔離 VM で走らせコーディネータが統合）へ歩み寄っており、現実的な落としどころは「隔離＋明示的な統合」にある。

3. 設計を俯瞰する4層の地図

A2A/マルチエージェント設計は、混同されがちな4つの層に分けると一気に見通しが良くなる。「プロトコル」「オーケストレーション」「通信・状態」「信頼性・セキュリティ」だ。

図1: A2A設計の4層。上位ほど「どう編成するか（抽象）」、下位ほど「どの線で会話するか（具体）」。信頼性・セキュリティはどの層にも効く横断的関心として全層を貫く。

4. MCP と A2A の役割分担 — 縦と横

ここが最初の関門。MCPとA2Aはよく混同されるが、層が直交し、補完関係にある。

MCP（Model Context Protocol, Anthropic）= 縦方向: 1つのエージェント/アプリ（ホスト）が、外部のツール・データ・プロンプトへ「下方接続」する標準。host↔tool の 1:1。プリミティブは Tool（実行）/ Resource（読み取り）/ Prompt（テンプレート）。
A2A（Agent2Agent, Google→Linux Foundation）= 横方向: 対等なエージェント同士のタスク委譲・長時間協調を担う。client agent ↔ remote agent。能力は Agent Card で公開し、仕事は Task として進む。

図2: 定石は「A2Aで横の協調を、MCPで縦のツールアクセスを」。A2Aのエージェントが内部でMCPツールを叩く構成にすると、「Nアプリ × Mツール」「複数ベンダーのエージェント」の断片化を解消できる。

A2AとMCPが事実上の二大基盤だが、用途特化の相互運用標準も増えている。住み分けはこうだ。

プロトコル	主提唱	立ち位置
A2A	Google→Linux Foundation	エージェント間相互運用の中核。Agent Cardで能力公開、Taskライフサイクルで長時間協調
MCP	Anthropic	エージェント→ツール/データの縦接続
ACP	IBM / BeeAI	純REST・非同期ファースト。ライブラリレス（cURL可）、多モーダル
ANP	コミュニティ（W3C CG）	W3C DIDベースの分散・自己主権ID。中央レジストリ非依存の「エージェントのHTTP」
AGNTCY / SLIM	Cisco Outshift	発見/接続/伝送を層分離。SLIMはpub/sub・暗号伝送（A2A/MCPの下回りに敷ける）
AP2	Google + 60組織	A2A/MCP上のエージェント決済拡張。Mandate（署名済みクレデンシャル）で承認証跡

第1回のまとめ

① マルチ化はコンテキスト分離・並列・専門特化・越境連携のため。ただし15倍のトークンを覚悟する。
② 書き込み・相互依存なら単一が正解。濫用は失敗面を増やすだけ。落としどころは「隔離＋明示統合」。
③ 設計はプロトコル／オーケストレーション／通信・状態／信頼性・セキュリティの4層に割れる。
④ MCP＝縦（ツール接続）、A2A＝横（エージェント協調）。直交する補完関係。

次回

地図が描けたので、次は中身。第2回「設計パターンカタログ」では、オーケストレーション・トポロジ（Orchestrator-Worker／階層／Swarm／Pipeline／Blackboard／Contract-Net／Debate …）を図鑑と比較表で棚卸しし、通信・状態の受け渡しとコンテキスト分離の勘所まで掘り下げる。

連載

① 全体像（この記事）／② 設計パターンカタログ／③ 実装編

sue@blog ~ $ _