AIエージェント同士をつなぐRelay基盤 — 会話とtransportを分離するアーキテクチャ

AIエージェントが単独で動く時代から、複数のエージェントが協調して動く時代へ移行しつつある。エージェント間の通信を設計するとき、「会話（何を話すか）」と「transport（どう届けるか）」を分離する考え方が重要になっている。本記事では、2026年に整備が進むエージェント間通信プロトコルの全体像と、Relay基盤のアーキテクチャを整理する。

なぜ「会話」と「transport」を分離するのか

AIエージェント同士が会話する際、2つの関心事が混在しがちだ:

会話層: タスクの依頼、進捗報告、結果の返却といった「意味のあるやりとり」
transport層: HTTP、gRPC、WebSocket、SSE といった「届ける仕組み」

これらを密結合にすると、transport を変更するたびに会話ロジックを書き直す必要が生じる。たとえば、開発時は HTTP で通信していたエージェントを、本番では gRPC に切り替えたいケースや、ローカルの関数呼び出しからリモートの API 呼び出しに切り替えたいケースがある。

分離することで、エージェントのビジネスロジック（会話）は transport に依存せず、transport の差し替えが容易になる。

2026年のエージェント間通信プロトコル

現在、エージェント通信の標準化が急速に進んでいる。主要なプロトコルは以下の通り。

MCP（Model Context Protocol）

Anthropic が策定したプロトコルで、エージェントと外部ツール/リソースの接続を標準化する。API、ファイルシステム、データベースへのアクセスを統一的なインターフェースで提供する。

役割: ツール・コンテキスト層
transport: RESTful サーバー経由の構造化データ交換

エージェント → MCP サーバー → 外部ツール（DB, API, ファイル）

A2A（Agent-to-Agent Protocol）

Google が主導し、50社以上のパートナーが参加するオープン標準。エージェント同士のピアツーピア通信とタスク委譲を実現する。

役割: エージェント間通信層
transport: HTTPS 上の JSON-RPC 2.0 + SSE（ストリーミング）
通信モデル: クライアントエージェント → リモートエージェント

クライアントエージェント ──JSON-RPC──→ リモートエージェント
                        ←──SSE────

A2A の特徴は、エージェントの内部メモリ、ツール、ロジックを共有せずに協調できる点。発見（Discovery）→ 認可（Authorization）→ 通信（Communication）の3段階で動作する。

ACP（Agent Communication Platform）

REST ベースの通信とエージェントレジストリを組み合わせたプラットフォーム。

役割: レジストリ駆動の通信基盤
transport: REST インターフェース
特徴: ステートフルなメッセージルーティングでコンテキストを保持

ANP（Agent Network Protocol）

インターネット規模のエージェント協調を想定したプロトコル。

役割: 広域ネットワーク層
transport: HTTPS + DNS、JSON-LD 形式
認証: DID（分散識別子）による暗号署名

Relay基盤のアーキテクチャ

エージェント間通信でRelay（中継）サーバーを置くアーキテクチャは、以下の利点がある:

直接通信の課題

エージェントA ←→ エージェントB
エージェントA ←→ エージェントC
エージェントB ←→ エージェントC

N個のエージェントで N×(N-1)/2 の接続が必要になり、スケールしない。

Relay を挟む構成

エージェントA ──→ Relay ──→ エージェントB
エージェントC ──→ Relay ──→ エージェントD

Relay が中継することで:

接続数の削減: 各エージェントは Relay への1本の接続だけ管理すればよい
transport の抽象化: エージェント側は Relay との通信方法だけ知っていれば、相手のtransportを意識しない
認証・認可の一元管理: Relay がゲートウェイとして認証を担当
メッセージの永続化: Relay がメッセージをバッファリングし、非同期処理に対応
監視・ログの集約: 通信のオブザーバビリティが向上

AGP（Agent Gateway Protocol）の例

AGP は Relay 型アーキテクチャの実装例で、gRPC と HTTP/2 上に構築されている。以下の通信パターンをサポートする:

パターン	用途
リクエスト・レスポンス	同期的なタスク依頼
Pub/Sub	イベント駆動の通知
Fire-and-Forget	ログ送信など非同期処理
ストリーミング	長時間タスクの進捗通知

AGP はデータプレーン（メッセージのルーティングと配信）とコントロールプレーン（管理、認証、アクセス制御）を明確に分離している。

プロトコルスタックの全体像

2026年時点で、以下の3層構造がコンセンサスとして形成されつつある:

┌─────────────────────────────┐
│   AG-UI（エージェント↔人間）    │  ユーザーインターフェース層
├─────────────────────────────┤
│   A2A / ACP / ANP           │  エージェント間通信層
│   （エージェント↔エージェント）  │
├─────────────────────────────┤
│   MCP                       │  ツール・コンテキスト層
│   （エージェント↔ツール）      │
└─────────────────────────────┘

各層が独立しているため、transport の実装を変更しても上位の会話ロジックに影響しない。これが「会話と transport の分離」の本質だ。

実装上の考慮点

transport の選択基準

transport	向いているケース
HTTP/REST	シンプルな同期通信、既存インフラとの親和性
gRPC	高スループット、型安全、双方向ストリーミング
SSE	サーバー→クライアントのストリーミング（A2A標準）
WebSocket	双方向リアルタイム通信

Relay 導入の判断

2〜3エージェントの小規模構成: 直接通信で十分
異なるフレームワークのエージェント混在: Relay が有効
認証・監査の要件がある: Relay をゲートウェイとして必須
非同期・長時間タスク: Relay のバッファリングが必要

まとめ

AIエージェントのマルチエージェント化が進む中、「会話」と「transport」の分離はアーキテクチャの基本原則となりつつある。A2A、MCP、ACP、ANP といったプロトコルが層ごとに責務を分担し、Relay基盤がエージェント間の接続を効率化する。2026年2月時点で100社以上が A2A に参加しており、エージェント間通信の標準化は実用段階に入っている。