マルチAgent協調アーキテクチャ実践：
設計パターンから本番投入まで

なぜ単一 Agent では足りないのか

「モノリシック Agent」——1 つの LLM が検索・コーディング・レビューをすべて担当——はプロトタイプは容易ですが、本番スケールで構造的に破綻します：

1. 01

   コンテキストウィンドウの限界：複雑タスクの中間結果がコンテキストを埋め尽くし、後続推論の品質が急落。

2. 02

   専門性の希薄化：1 Agent が検索もコードも監査もこなすと、どれも中途半端に。

3. 03

   直列実行の非効率：総時間 = 各ステップの合計。並列化不可。

4. 04

   単一障害点：1 Agent の障害で全体停止。サブ Agent を独立アップグレード可能にすれば回避。

MLflow 2026 レポートと AdaptOrch 論文によれば、問題はモデルではなくオーケストレーション——トポロジを正しく選べば、より強いモデルに乗り換えるより安定した改善が得られます。

6 大オーケストレーション設計パターン詳解

以下 6 パターンで本番のマルチ Agent シナリオ 95% 以上をカバーします。

パターン 1：順次パイプライン（Sequential Pipeline）

Agent A の出力 → Agent B の入力、厳密な線形。適用：記事作成、コードレビュー、コンプライアンスフロー。総時間 = 各ステップの合計；1 ステップ失敗で全体ブロック。

builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_node("writer", writer_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", "writer")
builder.add_edge("writer", END)
pipeline = builder.compile()

パターン 2：並列ファンアウト／ファンイン（Fan-out / Fan-in）

複数 Agent が独立サブタスクを並列処理し、集約ノードでマージ。総時間 ≈ max(T1…Tn)。LangGraph の Send API + Annotated[list, operator.add] Reducer で並列結果を自動集約。

パターン 3：階層スーパーバイザー・ワーカー（Supervisor-Worker）

スーパーバイザーが意図識別とルーティング、Worker が専門タスクを実行。二層ルーティング推奨：キーワード高速経路（<1ms、LLM 不要）+ LLM 精密ルーティングで曖昧意図を処理。典型：Replit コードアシスタント、カスタマーサポート。

パターン 4：スワーム協調（Swarm）

P2P 受け渡し、中央協調なし。ラウンド数／合意／タイムアウトで終了。コードレビュー議論に適するが、本番では慎重に——非決定論が高い。階層型の代替を推奨。AutoGen GroupChat には max_round の厳格な上限必須。

パターン 5：ブラックボードアーキテクチャ（Blackboard）

共有構造化ワークスペース。前提条件が満たされた Agent が能動的に読み書き。適用：時間単位／日単位の非同期タスク、異種チーム協調、事前ルーティング困難な複雑ワークフロー。

パターン 6：ハイブリッド（Hybrid）

典型構成：Intent ルーティング → 単純クエリは直接回答／複雑レポートは Supervisor → 並列リサーチファンアウト + 品質保証パイプライン（レビュー → 人手 → 公開）。

通信プロトコル二層アーキテクチャ：MCP + A2A

2026 年、両者は Linux Foundation Agentic AI Foundation に採択されています：

• MCP（垂直）：Agent ↔ ツール／DB／API——「一度書けばどこでも使える」。
• A2A（水平）：Agent ↔ Agent——タスク委譲、能力発見（Agent Card @ /.well-known/agent.json）、JSON-RPC 2.0。

A2A は Google が 2025 年 4 月に OSS 化、2026 年初頭 v1.0。Atlassian、Salesforce、SAP など 50+ パートナーが参加。Orchestrator フロー：Agent Card 取得 → スキル検証 → message/send でタスク委譲。

関連記事：MCP が AI 時代の HTTP になる理由、ゼロから MCP Server 開発。

可観測性：ブラックボックスを透明に

MAST 研究チームが 1,642 件の実行トレースを分析した故障分布；さらに懸念すべきは、57% の組織が Agent を本番稼働中、LLM 可観測性を実装済みはわずか 8%——エラーが HTTP 200 で返り、ダッシュボードは緑なのに出力は誤り、という状態です。

核心指標：エンドツーエンド成功率 >85%、P95 レイテンシ <30s、各 Agent エラー率 <5%；品質面は LLM-as-Judge で completeness/accuracy/relevance/hallucination を評価。各 Agent 呼び出しに correlation_id を付与し、OpenTelemetry で完全な呼び出しチェーンを形成。

選定決定木

1. Q1

   タスクに明確な線形依存がある？はい → サブタスク並列可能？いいえ→順次パイプライン；はい→並列ファンアウト+パイプライン混合。

2. Q2

   いいえ → 意思決定権を持つ Agent がある？はい → サブチーム規模が必要？いいえ→Supervisor-Worker；はい→階層型。

3. Q3

   いいえ → 長時間非同期？はい→ブラックボード；いいえ→Agent ≤5 かつ終了明確？はい→Swarm（厳格な上限）；いいえ→階層型へ再構成。