MCP vs A2A vs Open Responses — AIエージェント通信プロトコル3つ巴、実戦で何を使うべきか

MCP vs A2A vs Open Responses — AIエージェント通信プロトコル3つ巴、実戦で何を使うべきか

MCP、A2A、Open Responsesの設計目的と生態系を比較します。2026年の実際のエージェントプロジェクトで各プロトコルをいつ・どう組み合わせるか、OpenAI・Google・Anthropicが繰り広げるエージェント通信標準競争の核心を整理しました。

2025年後半から、AIエージェント関連の標準が一気に出揃い始めた。AnthropicがMCPをLinux Foundationに寄贈し、GoogleがA2Aを発表し、OpenAIはOpen Responsesの仕様を公開した。開発者にとっては良いニュースだが、問題がある。三つがそれぞれ何をするのか、競合関係なのか、それとも一緒に使うべきなのかが不明確なのだ。

「またスタンダード戦争か」と最初は思った。しかしMCPサーバーを自分でいくつか実装し、A2Aの仕様書を読み込んでから考えが変わった。この三つは競合ではなく、異なるレイヤーを担当している。混乱の原因は、名前だけ見るとどれも「エージェント通信標準」に聞こえるからだ。

このエントリでは三つのプロトコルをそれぞれ解剖し、実戦でいつ何を使うべきかを整理する。

MCP: エージェントに「手」を与える標準

MCP(Model Context Protocol)は、Anthropicが2024年末に公開し、2025年12月にLinux FoundationのAgentic AI Initiative(AAIF)に寄贈したプロトコルだ。核心的な目的は一つ: AIモデルが外部ツールやデータにアクセスする方法を標準化すること。

「AI版USB-C」という比喩がよく合う。USB-C以前はノートPCごとに充電端子が違った。MCP以前はClaude用ツール接続とGPT用ツール接続が別々だった。MCPが共通コネクターを作った。

MCPが標準化するのは三つだ:

  • Tools: エージェントが実行できる関数やアクション (例: ファイル読み込み、API呼び出し、コード実行)
  • Resources: エージェントが読み取れるデータ (例: ドキュメント、DBレコード、ファイルシステム)
  • Prompts: サーバーが提供する再利用可能なプロンプトテンプレート

2026年4月時点でMCPサーバーは5,000個を超えた。GitHub Actions、Notion、PostgreSQL、Brave Search、ブラウザ自動化まで、主要なツールのほぼすべてにMCPサーバーが存在する。

自分のブログ自動化システムにMCPを最初に組み込んだとき、最も驚いたのはフレームワーク非依存性だ。Claude Codeで使っていたMCPサーバーを、他のMCP互換クライアントでもそのまま使える。実際にはクライアントごとにサポートする機能範囲が異なるため100%互換ではないが、方向性は正しい。

MCPの2026ロードマップの核心的変化

2026年のMCPロードマップで注目すべき変化は、水平スケーリング問題の解決だ。現在のStreamable HTTPトランスポートはステートフルなセッションを維持するが、これがロードバランサーと衝突する。リクエストごとに異なるサーバーインスタンスにルーティングされるとセッションが切れる。ロードマップはこの問題を解決し、MCPサーバーを真のステートレスサービスとして運用できるようにすることを目指している。

もう一つは.well-knownエンドポイントによるディスカバリーの標準化だ。今はMCPサーバーに実際に接続しないと何を提供しているか分からないが、今後は接続なしにメタデータだけでサーバー機能を把握できるようになる。

WebMCPを通じてMCPサーバーの実装詳細を確認した記事も参考になる。

A2A: エージェント同士が話し始めた

A2A(Agent2Agent)は、Googleが2025年4月に発表し、2025年6月にLinux Foundationに寄贈したプロトコルだ。目的がMCPと異なる: エージェント間の通信と協調を標準化すること。

MCPが「エージェント ↔ ツール」の関係なら、A2Aは「エージェント ↔ エージェント」の関係だ。

A2Aが解決しようとする問題はこうだ。旅行予約エージェントがいて、ホテル検索専門エージェント、航空券検索専門エージェントが別にいるとしよう。旅行予約エージェントがこの二つの専門エージェントにタスクを委任するにはどうすればいいか? MCPはこの問題を扱わない。それがA2Aの領域だ。

A2A v1.0の核心概念

2026年初にリリースされたA2A v1.0の核心構成:

Agent Card: エージェントが自分の能力をJSON形式で広告するドキュメント。他のエージェントが「この仕事を任せられるエージェントは誰だ?」を把握する際にAgent Cardを読む。

タスクベース通信: エージェント間の通信はTask単位で行われる。タスクがすぐに完了する場合もあれば、長時間実行される場合は進捗状態を同期するメカニズムがある。

Signed Agent Cards (v1.0の核心): 暗号化署名でAgent Cardの真正性を検証できる。「このエージェントは本当にこのドメインが発行したものだ」という信頼基盤を作る。分散エージェント生態系での偽エージェント排除メカニズムだ。

2026年4月時点で150以上の組織がA2Aを採用しており、Microsoft、AWS、Salesforce、SAP、ServiceNowでプロダクション展開が進んでいる。

正直に言うと、A2A仕様書を初めて読んだとき「これはどれだけ実用的なのか」と懐疑的だった。エージェントが互いに直接通信するという概念自体は面白いが、これを安全に運用するには信頼モデルが複雑になる。v1.0のSigned Agent Cardsがその方向を固めつつあるが、プロダクションで完全に信頼するにはまだ初期段階だと見ている。

A2AとMCPをプロダクション環境で組み合わせるアーキテクチャパターンを別途まとめたが、レイヤーをどう分けるかが核心だ。

Open Responses: API互換性を標準化しようとするOpenAIの試み

Open Responsesは2026年2月にOpenAIが公開したオープン仕様だ。性質がMCPやA2Aと異なる。それらはエージェントがどう通信するかを扱うが、Open ResponsesはエージェントワークフローをどうAPIとして公開するかを扱う。

OpenAIのResponses APIをベースに作られた仕様で、基本的な考え方はこうだ: Chat Completions APIからResponses APIへの移行で生まれた標準をオープンにして、他のモデルプロバイダーも同じインターフェースでエージェンティックワークフローを提供できるようにしよう、というもの。

サポート生態系: Hugging Face、Vercel、OpenRouterが採用しており、Ollama、vLLM、LM Studioのようなローカル推論ツールでも対応している。つまり、OpenAI APIで書いたエージェンティックコードがローカルモデルでも動くというのが核心的な価値提案だ。

まだ仕様とコンフォーマンステストツールがopenresponses.orgにあり、大規模プロダクション検証事例は多くない。Hugging FaceとVercelのサポートは意味があるが、「他のベンダーがOpenAIのAPI設計を標準として受け入れる」という前提がどれだけ現実化するかは様子を見る必要がある。

率直な評価: Open ResponsesはMCPやA2Aと異なるレイヤーにあるため「競合」というよりも補完関係だ。しかし今すぐ実戦でこの仕様を追いかける理由はそれほど大きくない。MCPとA2Aの方がより汎用的で生態系が成熟している。

三つのプロトコルを並べると

以下の表が核心だ:

MCPA2AOpen Responses
設計目的エージェント ↔ ツール接続エージェント ↔ エージェント協調APIエージェンティックループ標準化
比喩USB-C (共通コネクター)HTTP (エージェント間通信)REST API設計標準
主導Anthropic → AAIFGoogle → Linux FoundationOpenAI
現行バージョン2025-11-25v1.0 (2026年初)Beta
生態系成熟度高 (5,000+サーバー)高 (150+組織)低 (初期)
トランスポートStreamable HTTP, stdioJSON-RPC, gRPCWebSocket, HTTP
セキュリティモデルOAuth, サーバー別認証Signed Agent Cards仕様策定中
いつ使うかツールアクセスが必要な常時マルチエージェント委任時OpenAI互換ワークフロー

一点強調したいことがある: MCPとA2AはOR関係ではなくAND関係だ。 2026年の実プロダクションマルチエージェントシステムは、ほとんどこの二つを一緒に使う。各エージェントは自分のツールをMCPで接続し、エージェント間の協調はA2Aで行う。

実戦の階層構造: どう組み合わせるか

実際のプロダクションアーキテクチャでこの三つのプロトコルがどう位置するかを例にとると:

シナリオ: 自動化リサーチシステム

オーケストレーターエージェント
├── (A2A) → ウェブリサーチ専門エージェント
│   └── (MCP) → Brave Search MCPサーバー
│   └── (MCP) → ウェブスクレイピングMCPサーバー
├── (A2A) → ドキュメント分析専門エージェント
│   └── (MCP) → ファイルシステムMCPサーバー
│   └── (MCP) → PDF処理MCPサーバー
└── (MCP) → 結果ストレージMCPサーバー

オーケストレーターがA2Aで専門エージェントに委任し、各専門エージェントはMCPで自分のツールにアクセスする。

Claude Codeのエージェンティックワークフローパターン5種で、この階層構造の実装例をより詳しく扱っている。

今すぐ何を学ぶべきか

各プロトコルの優先順位を率直にまとめると:

即座に学ぶべき: MCP

今エージェント開発をしているなら、MCPから始めるべきだ。理由:

  • 5,000個を超えるサーバー生態系がすでに存在
  • Claude Code、OpenAI Agents SDK、LangGraphなど主要フレームワークがすべてサポート
  • Streamable HTTPが標準となり、仕様が十分安定
  • Anthropic Agent Skillsの標準と組み合わさって、より強力なパターンが生まれている

中期的に: A2A

マルチエージェントシステムをプロダクションに展開する計画があるなら、A2Aを学ぶべきだ。150組織採用、Linux Foundationガバナンス、v1.0の安定性。準備は整っている。ただし、Signed Agent Cardsベースの信頼モデルが実務でどれだけ検証されているかは、まだ見守っている段階だ。

様子見: Open Responses

現在の構成でOpenAI互換性が必要でなければ、急ぐ理由はない。仕様は興味深いが、大規模プロダクション事例がない。

もう一点: MCPとA2AはどちらもLinux Foundation傘下にある。標準戦争ではなく、同じ財団の下で異なる問題を解決する方向に整理されている。これが2024年との最大の違いだ。

私の結論

MCPは今すぐ使うべきツールだ。エージェントに外部世界へのアクセス方法を与えるレイヤーであり、生態系が十分に成熟している。A2Aはマルチエージェントシステムを真剣に考えているなら、v1.0から学ぶべきだ。Open Responsesはポートフォリオとして知っておくが、すぐにアーキテクチャ決定に反映するには早い。

三つを「プロトコル標準戦争」として見ると疲弊する。それぞれ異なる問題を解いており、三つすべてが必要なシステムも十分にある。私の実用的な結論: MCPから始め、A2Aは必要なときに、Open Responsesはアップデートを購読するレベルでフォロー。

そしてAIエージェントフレームワーク選定も、このプロトコル選択と絡み合う問題だ。どのフレームワークを使うかによってMCPとA2Aのサポートレベルが異なるためだ。

他の言語で読む

この記事は役に立ちましたか？

より良いコンテンツを作成するための力になります。コーヒー一杯で応援してください。

著者について

jw

Kim Jangwook

AI/LLM専門フルスタック開発者

10年以上のWeb開発経験を活かし、AIエージェントシステム、LLMアプリケーション、自動化ソリューションを構築しています。Claude Code、MCP、RAGシステムの実践的な知見を共有します。

GitHub LinkedIn X (Twitter) プロフィールを見る

関連記事

ブログリストへ