マルチエージェント・トポロジー 6 種と A2A プロトコル

ch2 の 8 パターンは「どんな処理をするか」の語彙だった。本章では、それらを実装するときの**「形」── トポロジー**を扱う。同じパターン（例：Orchestrator-Workers）でも、トポロジーの選び方で運用結果が変わる。

6 つのトポロジー早見表

トポロジー	構造	強み	弱み	常時稼働適性	失敗ケース
Single	1 エージェント	単純、debug 容易、context 管理が一点集中	context window が天井、メモリ汚染が累積	△ 単発・短中期	context rot
Supervisor-Worker	1 lead + N sub	動的分割、並列性能	lead が SPOF、sub の並列度限界	◯ 中期	lead 飽和
Swarm	対等エージェントの相互通信	柔軟性、自己組織化	合意形成の遅延、コスト爆発	×	暗黙決定衝突
Router	入力分類 → 専門エージェント	専門化で精度向上	分類器の精度が天井	◯	silent drift
Hierarchical	多段の Supervisor-Worker	スケーラビリティ、明確な責任分担	階層ごとのレイテンシ累積	◎ 長期	階層間の状態同期
Pipeline	直線的なエージェント鎖	単純、決定論的、各 step 独立にテスト可能	1 step 失敗で後続全滅	△ 短中期	SPOF 連鎖

これらは 排他ではなくネスト可能だ。Pipeline の 1 段に Supervisor-Worker を入れる、Hierarchical の sub に Swarm を入れる、といった組み合わせが実本番では普通。

各トポロジーの詳細

1. Single Agent

最もシンプル。1 つの強力な LLM が tools・memory・retrieval を持って自律的に動く。Cognition Devin が代表例。

設計の主張（Cognition）：

Multi-agent は sub-agent の前提衝突を起こしやすい。コンテキストを 1 つに集中させることで、整合性が保たれる。

強み：

• debug が容易（1 つの実行ストリームを追えばよい）
• context 管理が一点集中
• 失敗ケースが理解しやすい

弱み：

• context window が天井
• 長時間でメモリ汚染が累積（第1部 ch5 参照）

常時稼働の壊れ方：context rot。長セッションで関連度の低い情報が蓄積し、判断品質が落ちる。

実例：Devin、ChatGPT Agent、Claude Code（nO ループ、単一スレッド・マスターループ）。

2. Supervisor-Worker（= Orchestrator-Workers）

1 つの Lead Agent が複数の Sub Agent を動的に呼ぶ。Anthropic Multi-agent Research の標準形。

graph TB
    L[Lead Agent<br/>Opus]
    S1[Sub 1<br/>Sonnet]
    S2[Sub 2<br/>Sonnet]
    S3[Sub 3<br/>Sonnet]
    M[(Shared Memory)]

    L -->|計画分割| S1
    L -->|計画分割| S2
    L -->|計画分割| S3
    S1 -->|要約| L
    S2 -->|要約| L
    S3 -->|要約| L
    L -.write.-> M
    S1 -.read.-> M
    S2 -.read.-> M
    S3 -.read.-> M

強み：

• 動的タスク分割
• 並列性能（リサーチで +90.2%）

弱み：

• Lead が SPOF
• Sub の並列度に上限（経験的に 3〜5）

常時稼働の壊れ方：Lead が context 飽和すると全体が止まる。

実装上の注意：LangChain 公式は 2026 時点で「langgraph-supervisor ライブラリより create_handoff_tool で Supervisor as tool calling を直接書く方が context engineering に都合が良い」と明示している。

実例：Anthropic Multi-agent Research、Magentic-One（Microsoft Research）。

3. Swarm

対等なエージェントが情報共有しながら並列に動く。OpenAI Swarm の元の設計（後に Agents SDK に統合）。

強み：

• 柔軟性
• 自己組織化

弱み：

• 合意形成の遅延（エージェントが永遠に話し続ける）
• コスト爆発

失敗面の数：「fully-connected swarm は失敗面が 4 agents で 6 点、10 agents で 45 点 と quadratic」（Augment Code）。中央 state 不在で circuit-break ができない。

常時稼働の壊れ方：暗黙決定の衝突 + 合意形成ループ。

業務投入での評価：現実の業務では Swarm はまず採用されない。Stack AI / Fast.io / Augment Code の共通見解。

4. Router

入力分類 → 専門エージェントへ振り分け。ch2 の Routing パターンの実装形。

graph TB
    I[Input]
    R[Router LLM<br/>or 分類器]
    A1[Specialist 1<br/>billing]
    A2[Specialist 2<br/>technical]
    A3[Specialist 3<br/>sales]

    I --> R
    R -->|billing query| A1
    R -->|tech query| A2
    R -->|sales query| A3

強み：

• 専門化で精度向上
• 各エージェントの context を最小化

弱み：

• 分類器の精度が全体の天井

常時稼働の壊れ方：入力分布が変化したときの silent drift。Patronus「misclassified input が誤エージェント連鎖で hallucination 増幅」。

実例：サポートチケットのカテゴリ分類、IT ヘルプデスク。

5. Hierarchical（階層構造）

Supervisor-Worker の入れ子。各 Sub Agent が、さらに自分の Sub を持つ。

強み：

• スケーラビリティ
• 明確な責任分担

弱み：

• 階層ごとのレイテンシ累積
• 階層間の状態同期が複雑化

常時稼働の壊れ方：レイテンシの累積。3 階層で各層 5 秒なら 15 秒になる。

実例：

• Replit Agent 3 Stacks：「Agent が他の Agent を生成」する Docker sandbox + Postgres インスタンス・ストレージレイヤーを各ユーザに割当、日に数千スピンアップ
• CrewAI hierarchical process：Manager crew が下位 crew を呼ぶ

6. Pipeline / Sequential

直線的なエージェント鎖。リサーチ → 執筆 → レビュー、のような順序固定処理。ch2 の Prompt Chaining の実装形。

graph LR
    A[Agent 1<br/>research] --> B[Agent 2<br/>writing] --> C[Agent 3<br/>review]

強み：

• 単純、決定論的
• 各 step を独立にテスト可能

弱み：

• 1 step 失敗で後続が全滅
• 8-10 sequential handoffs を超えると prompt tuning では救えない品質劣化（Augment Code: Swarm vs Supervisor, 2026-04）

常時稼働の壊れ方：1 step 失敗の連鎖（SPOF 連鎖）。

回避策：各 step に retry を入れる、durable execution（第1部 ch7）と組み合わせる。

トポロジーのネスト

実際の本番システムは、6 種類が混在する。

graph TB
    subgraph Outer["Pipeline (外側)"]
        P1[Phase 1<br/>Intake]
        P2[Phase 2<br/>Processing]
        P3[Phase 3<br/>Output]
    end

    subgraph SW["Supervisor-Worker (Phase 2 の内側)"]
        L[Lead]
        W1[Worker 1]
        W2[Worker 2]
        W3[Worker 3]
    end

    P1 --> SW
    SW --> P3
    L --> W1
    L --> W2
    L --> W3

実例（Replit Agent 3）：

• 外層：Hierarchical（Stacks）
• 中層：Supervisor-Worker（manager + editor + verifier）
• 内層：Self-healing ループ（Evaluator-Optimizer）

実例（Cursor Composer 2）：

• 外層：Pipeline（explore → plan → execute）
• 各 phase は Single Agent
• HITL gate を phase 境界に配置

A2A プロトコル ── エージェント間通信の標準化

複数エージェントを繋ぐとき、通信プロトコルが必要になる。2025-2026 年で A2A (Agent2Agent) Protocol が事実上の標準として浮上した。

A2A の歴史

2025-04: Google が A2A Protocol を発表
2025-06: Linux Foundation に寄贈
2025-08: IBM の Agent Communication Protocol (ACP) が A2A に統合
2025-12: Linux Foundation AAIF（AI Agent Interoperability Foundation）設立
         MCP / goose / AGENTS.md が中心プロジェクトに

A2A v1.0.0 の primitives

• Agent Card：エージェントの自己記述（capabilities、エンドポイント）
• Task：エージェント間で受け渡される作業単位
• Message：会話単位
• Artifact：成果物（ファイル、データ）

トランスポート：HTTP+JSON / JSON-RPC / gRPC（+ Server-Sent Events）。

MCP との関係

A2A と MCP は補完的だ。

プロトコル	役割
A2A	横軸：agent ⇔ agent
MCP	縦軸：agent ⇔ tool / data source
AGENTS.md	規範：エージェントの行動規約
Skill spec	能力：エージェントが提供する skill の宣言

つまり 2026 のエージェント interop スタックは「A2A + MCP + AGENTS.md + Skill spec の 4 軸」に収束しつつある。

OpenAI Swarm の handoff との関係

OpenAI が 2025-03 に出した Agents SDK の Handoffs は、A2A の前駆的存在。Agents SDK は 2026-04 に native sandbox / harness を追加し、handoffs に加えて A2A 互換の通信パスを持つように拡張されている [要検証 仕様の最新版]。

2026 の新しい動き

• Anthropic Project Deal（2026-04）：agent-on-agent commerce の初の実証実験。69 名 / 186 deals / $4,000+
• M-GRPO（arXiv 2511.13288）：multi-agent をまとめて RL で学習。トポロジーが学習側からも設計される転換点
• MoE 風 multi-model routing が agent 層に降りてきた：vLLM Semantic Router、Bifrost

「Single vs Multi-agent」論争の決着

ch1 で触れた Cognition と Anthropic の論争に、ここで一旦の答えを出す。両者の見解は次の表で和解する。

タスクの性質	推奨トポロジー	根拠
深い前提共有が必要（コーディングなど）	Single	sub の前提衝突を避ける（Cognition）
並列で独立できる（リサーチなど）	Supervisor-Worker	+90.2% / 15× tokens（Anthropic）
入力分類が明確	Router	専門化で精度
順序固定の多段処理	Pipeline	単純さ
多階層 + 大量並列	Hierarchical	スケーラビリティ

つまり「マルチ vs シングル」は二者択一ではなく、「タスクが何を要求するか」によって決まる選択だ。

❌ アンチパターン：Premature multi-agent

症状
─────────
- 1 エージェントで足りる業務に 5 エージェント投入
- トークンコスト 15× で性能向上わずか
- debug が困難になり、振る舞いの予測不能性が増大

根本原因
─────────
- 「マルチエージェントの方がかっこいい」と思っている
- タスクが Single Agent で完結することを認められない
- 「Add tools before adding agents」（Truefoundry / Augment Code）の原則を知らない

脱出法
─────────
1. Single Agent + Augmented LLM に戻す
2. 必要なら Tools と Memory を強化
3. 明確なボトルネックが tool で解決できないと判明したら、Supervisor-Worker に切り替え
4. 2 エージェント以上にするときは「タスクが独立に並列できるか」を必ず問う

業務投入の観点で重要な 3 点

1. トポロジーの選択は「タスクの性質」が決める：マルチエージェントは万能ではない。深い前提共有が必要なタスク（コーディング）は Single 寄り、独立並列できるタスク（リサーチ）は Multi 寄り
2. トポロジーはネスト可能：Pipeline の 1 段に Supervisor-Worker を入れる、Hierarchical の sub に Swarm を入れる、は実本番で普通。外側から内側へ、徐々に動的にする設計が読みやすい
3. A2A + MCP + AGENTS.md + Skill spec の 4 軸が 2026 のエージェント interop の標準スタック：自前プロトコルを作るより、これらの公開仕様に乗る方がエコシステムの恩恵を受けられる

次章への接続

ch4 では、本作の 8 パターンの理論的なルーツとなる古典パターンを扱う。ReAct（推論と行動の交互）、Reflexion（自己反省ループ）、Plan-and-Act（計画と実行の分離）、Tree of Thoughts（探索的推論）、Voyager（スキル蓄積）の 5 つを、本作の 8 パターン語彙にどう対応するかを示す。これらの古典は、現代のフレームワークの設計に深く影響している。

---

この章のまとめ

• 6 つのトポロジー早見表：Single / Supervisor-Worker / Swarm / Router / Hierarchical / Pipeline
• トポロジーは排他ではなくネスト可能：Pipeline の 1 段に Supervisor-Worker、Hierarchical の sub に Swarm
• 「Single vs Multi」はタスクの性質が決める：コーディングは Single 寄り、独立並列リサーチは Multi 寄り
• Swarm は業務投入で採用されにくい：失敗面が quadratic、合意形成ループ
• A2A プロトコル v1.0.0 が 2026 の標準：MCP（縦軸）+ A2A（横軸）+ AGENTS.md + Skill spec
• Premature multi-agent は最頻アンチパターン：「Add tools before adding agents」

＋ － ⟳ ✕