7月23日、Redis公式ブログが「Model Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need?」と題した記事を公開した。著者はJeff Mills。AIエージェント設計における2大プロトコルMCPとA2Aの違いと、どちらを選ぶべきかの実践的な判断基準について詳しく解説している。
「A2Aを使うべきでは？」という問いへの答え
複数のエージェントを設計していると、デザインレビューで必ずこの質問が出る。「これ、A2Aを使うべきじゃないか？」
MCPとA2Aはよく一緒に語られるが、実際には異なるレイヤーの異なる問題を解決するプロトコルだ。混同したまま設計を進めるとアーキテクチャに無駄なコストが生じる。
結論から言えば、判断軸は「エージェントの数」ではなく「誰がそのエージェントを所有しているか」だ。
MCPとは何か
MCP（Model Context Protocol）は、LLMアプリと外部ツール・データを接続するためのオープン標準だ。アーキテクチャは3つの役割で構成される。
- Hosts：全体を調整するLLMアプリ
- Clients：Host内部のコネクター
- Servers：ツールやデータを公開するエンドポイント
Serverは3つのプリミティブでCapabilityを公開する。モデルが呼び出せるTools、コンテキストを供給するResources、ワークフローをテンプレート化するPromptsだ。通信にはJSON-RPCを使い、ローカル接続またはHTTP経由でストリーミングも可能。
2025年3月にOpenAIがAgents SDKでMCPを採用し、GoogleもGemini APIとSDKにネイティブ対応した。その後MCPはLinux Foundation傘下のAgentic AI Foundationに移管されている。
MCPの本質的な特徴は2点ある。
- 階層的な通信：エージェントが受動的なサーバーを呼び出す一方向の関係
- ディスカバリーなし：あらかじめ設定されたエンドポイントに直接接続する
A2Aとは何か
A2A（Agent2Agent）は、異なるチーム・ベンダー・企業が所有する独立したエージェント同士の通信を想定して設計されている。3つのコアコンセプトがある。
- Agent Cards：
/.well-known/agent.jsonで公開されるJSONドキュメント。エージェントのID、エンドポイント、認証要件、スキルを宣言する - Tasks：人間の承認待ち（Human-in-the-loop）を含む、ライフサイクルを持つステートフルな作業単位
- Artifacts：リモートエージェントが返す具体的な成果物
A2AはGoogleが開発し、2025年6月にLinux Foundationに寄贈された。AWS、Microsoft、Salesforce、SAPが創立メンバーに名を連ね、現在は150以上の組織が標準をサポートしている。
ただし記事は率直にこう指摘する。A2Aの実採用は現状「ほぼ探索段階」だ。今日「マルチエージェント」と呼ばれるシステムの多くは、1チームのオーケストレーターがツールを順番に呼び出しているだけで、信頼境界をまたぐ独立したエージェント同士の通信ではない。
2つのプロトコルの対比
両者は競合ではなく補完関係にある。自動車修理工場に例えると、顧客のエージェントが修理工場のマネージャーエージェントにA2Aで話しかけ、マネージャーがメカニックエージェントとA2Aで診断の会話をし、メカニックが診断ツールをMCPで呼び出す——という構造になる。
| 次元 | MCP | A2A |
|---|---|---|
| 目的 | エージェント↔ツール連携 | エージェント↔エージェント連携 |
| 通信モデル | クライアント-サーバー（受動的ツールを呼び出す） | ピアツーピア（別エージェントに委任） |
| タスク性質 | リクエスト-レスポンス | ステートフル・長時間・マルチターン |
| ディスカバリー | 明示的な設定が必要 | Agent Cardsで自動検出 |
判断基準は「誰がエージェントを所有しているか」
A2Aは「マルチエージェントプロトコル」として語られるため、エージェントが複数あれば使うべきに見える。だが実際はそうではない。
A2Aを選ぶべき状況：
- 自分たちが制御できない境界をまたいで作業を委任する場合
- タスクが長時間にわたり、承認ゲートを持つステートフルなライフサイクルが必要な場合
- 異なるフレームワーク上のエージェントがカスタムコードなしで連携する必要がある場合
フレームワーク内オーケストレーション（LangGraph、CrewAIなど）で十分な状況：
- 自分たちが所有するコードベース内にすべてのエージェントが収まる場合
- 全エージェントが同一チームの管理下にある場合
A2Aのプロトコルオーバーヘッド（セットアップ、認証、可動部品の増加）が報われるのは、「相手が隠しておきたい内部ロジックがある」ときだけだ。同じチームが両側のエージェントを所有している場合、隠すものがないのでコストだけが増える。
なお、LinkedInはエンタープライズエージェントにMCPとA2Aを併用しつつも、A2Aを「より実験的なもの」として扱っていると記事では言及されている。
両プロトコルが解決しない課題
どちらのプロトコルを選んでも、以下の問題は自前で解決する必要がある。
状態の相関：A2AのcontextIdが関連タスクをグループ化しても、エージェントの内部コンテキスト、MCPサーバーの状態、A2Aタスク識別子を一本のトレース可能なスレッドに結ぶ仕組みはない。
オブザーバビリティと速度：あるエージェントの分析では、モデルの思考が処理時間の**69.4%、ツール実行が30.2%**を占めた。またMCPでは接続するツールの説明がモデルのコンテキストウィンドウを消費するため、ツールを増やすほどエージェントの精度が下がるトレードオフがある。
エージェントメモリの標準がない：エージェントが状態をどう保存・呼び出すかを規定する共通インターフェースは存在せず、各チームが個別に実装している。
プロトコルが解決しない層を担うコンテキストエンジンとして
上記のような課題——状態の相関、メモリ管理、レイテンシ——はMCPもA2Aも直接は扱わない。記事はこうした「プロトコルの外側」の問題に対応するレイヤーとして、Redisが開発するRedis Irisを紹介している。
報告された数値として、ベクター検索で10億ベクター・50並列クエリ・上位100件取得の条件下で90%精度・中央値約200msレイテンシ、セマンティックキャッシュ（Redis LangCache）で高繰り返しワークロードにおけるLLM推論コスト73%削減が挙げられている。
詳細はModel Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need?を参照していただきたい。
