AIエージェント

MCPとA2Aの違いと使い分け：ツール呼び出しかエージェント間の仕事か

2026/9/21 （更新: 2026/10/14）

🤖 AIを使用して執筆

MCPとA2Aは別々の開発元から出て、同じ財団に入った

MCPの開発元はAnthropicで、2024年11月25日に公開した。仕様のリポジトリは同年9月24日に作られ、プロジェクトのサイトはMCPを「AIアプリケーションを外部のシステムへつなぐためのオープンソースの標準」と位置づける⁶。2025年12月9日、AnthropicはMCPをLinux Foundation傘下のAgentic AI Foundationへ提供した。この発表はプラチナ会員としてAmazon Web Services・Anthropic・Block・Bloomberg・Cloudflare・Google・Microsoft・OpenAIを挙げ、「公開されているMCPサーバーは10,000を超える」と書く。GitHubのスター数（関心の指標）は、2026年9月13日時点で仕様のリポジトリが9,193、python-sdkが24,274である³。

A2Aの開発元はGoogleで、2025年4月9日に公開した。リポジトリは同年3月25日に作られ、Googleは同年6月23日にLinux Foundationへ寄贈した⁷。2026年8月27日にはAgentic AI Foundationが成長段階（Growth Stage）のプロジェクトとして受け入れた⁴。A2Aの公式サイトは、A2Aを「独立した、しばしば内部の見えないAIエージェントどうしが、対等な相手として通信し協働する方法を標準化する」ものと位置づける²。2026年4月9日のLinux Foundationの発表は「150を超える組織がこの標準を支持している」とし、2025年4月からの一年で支持組織が50を超える数から150を超える数へ増えたと書く。本体のリポジトリは25,743個、a2a-pythonは2,139個のスターを2026年9月13日時点で集めている⁷。

こうした取り決めはこの二つの外にもある。規約を組み合わせたときの安全を調べた形式的な分析は、MCP、A2A、Agent Network Protocol（ANP）、Agent Communication Protocol（ACP）、Agent Client Protocol（ACP-Client）の五つを対象にしている⁵。このうちACPは、2025年8月にLinux FoundationのもとでA2Aへ合流すると告知している⁸。

MCPはセッションを外してステートレスと定め、A2Aは状態を持つ協働を強みと書いた

二つの規約は、同じ問いに別々の答えを出しているのではなく、別の問いに答えている。MCPが向き合うのは、一つのエージェントがツールや資源をどう呼び出すかという境界である。A2Aが向き合うのは、複数のエージェントどうしがどう仕事を渡し合うかという境界である。A2A自身はこの分担を「MCPは垂直である。一つのエージェントを深める」と書き、一つのアプリケーションの中に一つ以上のエージェントを置く形もMCPの側に入れる。「A2Aは水平である」とし、つなぐ相手のエージェントは「別のチーム、別の部署、あるいは提携先の組織」に属しうると書く²。MCP自身は自分の立ち位置を「AIアプリケーションのためのUSB-Cポート」にたとえる⁶。ポートも、垂直と水平という向きも比喩であって仕様そのものではない。MCPの紹介頁は自分の役割を書くだけで、A2Aとの分担には触れていない。

分担は、規約の文面で固まった。MCPの仕様は、2026年7月28日版でプロトコルの層からセッションを取り除き、「MCPはステートレスなプロトコルである。すべての要求は自己完結し、自分のプロトコル版と能力を運ぶ」と定めた¹。この版より前の仕様は接続ごとのセッションを持っていたので、状態を持たないという性格は最初からではなく、この版で言い切られたものである¹。呼び出しを跨ぐ状態が要るサーバーは、仕様の定めにより「明示的な、サーバーが発行するハンドルを通常のツール引数として渡す」形で自分たちで運ぶ。中核の規約は状態の入れ物を用意せず、運び方の形だけを定める¹。同じ版の中核は、処理の途中で追加の入力が要るとき、サーバーが「入力待ち」の結果を返し、呼ぶ側が答えを添えて同じ要求を送り直す型も定めた¹。一方で、長く走る処理のためのtasksは、中核から公式の拡張へ移された。この拡張では、サーバーは処理が終わるまで待たせる代わりにハンドルを返し、呼ぶ側は「進行中」や「入力待ち」といった状態をポーリングで受け取る¹。A2Aは逆の側に立ち、「A2Aの主な強みは、典型的なツール呼び出しを超えた、柔軟で状態を持つ協働的なやり取りを支えることにある」と自分で書く²。

A2Aは区別を相手の種類で説明し、本稿はそれを状態を保ち続ける相手かどうかとして読む

分かれた理由を、A2Aの側は「A2AとMCPの区別は、エージェントが何とやり取りするかで決まる」と説明する²。MCPは「AIモデルやエージェントが、ツールやAPI、その他の外部の資源へつながり、やり取りする方法を標準化する」もので、そこで動くのは「典型的には、入力と出力がよく定義され構造化された原始的な操作」であり、それが「特定の、しばしば状態を持たない機能を果たす」²。これに対してA2Aが相手にするのは「より自律したシステム」であり、そこではエージェントが「推論し、計画し、複数のツールを使い」ながら「長いやり取りにわたって状態を保つ」²。Linux Foundationの一年報告も「A2Aは組織の境界を越えてエージェントどうしが通信し協調する方法を定め、MCPはエージェントが内部のツールとデータソースへつながる方法を定める」と自分の言葉で線を引く⁷。A2Aの側と財団が文書に引く線は、相手がツールかエージェントかという区別である。本稿はこの特徴の差を、呼び出しを跨いで状態を持たない相手と、何ターンにもわたって自分で計画を立て、状態を保ち続ける相手との境界として読む。

分かれ方には、単純さの差が伴う。MCPの側では、呼ぶ側が相手の中身を知らなくてよく、入力と出力の形さえ決めておけば、ツールの中身がどう変わっても呼び出しは壊れない。プロトコルの層は状態を持たないので、呼ぶ側も答える側も、前の呼び出しを覚えている前提に頼らずに済む¹。Agentic AI Foundationの発表も、MCPが広く採用された理由として、開発者と企業が「単純な統合の方法、セキュリティの制御、より速い展開」に引き寄せられていることを挙げる³。A2Aの側では、対等な相手として扱うエージェントはA2A自身の言葉で「しばしば内部が見えない」ので²、中身を知らずに信頼する相手を増やすぶん、呼ぶ側が学ぶことも増える。ある開発者による観察は、A2Aが、単純なツールの統合を作りたい個人の開発者にまで「エージェントの発見、能力の交渉、セキュリティカード」の理解を求めた一方、「MCPは単純さと即座に使える実利を選んだ」と書き、「MCPは初日から既存のAIアシスタントで動いた。A2Aは新しいインフラを作ることを求めた」と続ける⁹。これは測定ではなく実務者による観察であり、本稿もその位置づけで引く⁹。この観察に対応する数もある。仕様そのものを収めたリポジトリのスターは、MCPが9,193、A2Aが25,743で、A2Aのほうが多い。一方、Python向けのSDKのスターは、MCPのpython-sdkが24,274、A2Aのa2a-pythonが2,139で、順は逆になる³⁷。同じ粒度で並べたこの二組の数は、どちらの規約が優れているかを示すのではなく、開発者の関心が今どこに向いているかを示している。

ただし、先の開発者の記事そのものの結論は、本稿と逆の向きにある。2025年9月の時点で、AIエージェントのエコシステムの大半は「MCPの周りにまとまった」とし、相互に通信し合うエージェントというA2Aの構想も「MCPの上に築かれつつある」と書く⁹。その後の2026年8月、A2AはAgentic AI Foundationの成長段階のプロジェクトとして受け入れられた⁴。本稿はこの開発者の結論を、2025年9月時点の一つの読みとして扱う。

二つの境界の間に架かる橋は、どの規約の保証にも入っていない

二つの境界は、規約が言うほど固くない。A2A自身が「A2Aサーバー（遠隔のエージェント）は、いくつかのスキルをMCP互換の資源として公開できる」と認めている²。対等な相手として振る舞うはずのA2Aサーバーが、ツールとして呼ばれる側にも回れるということである。ただし原典は続けて、これが「最もうまく働くのは、スキルがよく定義され、ツールのように状態を持たない形で呼べるとき」だと添える²。どの継ぎ目をどちらの境界として扱うかは、規約の名前ではなく、まず相手がツールか自律したエージェントかで分かれる²。そこを通る仕事が呼び出しを跨ぐ状態を持つ場合も、MCPの側はハンドルやtasksの拡張でそれを運べるので¹、その状態をどちらの側に置くかは、システムを組む側が見極める。

組む側が境界の線を引いた先、MCPのツールとA2Aの仕事が接する場所で何が起きるかを、形式的な分析が調べている。五つの規約を仕様から実装まで横断して分析する枠組みは、MCPとA2Aをそれぞれ単独で試した振る舞い上の所見のうち「10件のうち9件が、仕様の水準と実装の水準の両方で再現する」と報告する⁵。この分析が対象にしたMCPは、セッションを持っていた2025年11月25日版である⁵。二つをつないだ橋については、モデル検査が一本の流れを反例として見つけた。MCPとA2Aの組は実装の試験に含まれておらず、論文は実際の橋を持たない組の結果をモデルだけのものとしている⁵。その流れは、汚染から権限の昇格へと進む。「無害化されていないMCPの出力が橋を汚染し、その橋がA2Aの権限を受け手のもとの許可を超えて広げる。そしてこの昇格には完全な監査の記録が無い。橋が両方の局所的な監査の範囲の外にあるからである」⁵。MCP側のツールが返した値が、そのままA2A側の仕事の権限として運ばれてしまう経路として読める。

責任の所在についての結論も、同じ論文が明確に書いている。「連鎖したMCPサーバー、A2Aのconductor、ACP-Clientエージェント内のMCPのツールのいずれについても、橋の安全に責任を持つ規約はない」。図5を説明する本文は、この状態を「合成は、例外なく持ち主を欠く」とまとめる⁵。MCPはツールを呼び出す境界の中に、A2Aは仕事を渡す境界の中に自分の保証を置いている。論文は、二つの規約をつなぐ橋や中継、実行環境が、たいていどちらの規約が定める安全の範囲の外にあると書く⁵。分担が固まるほどその傾きが強まるというのは、本稿の推論である。橋を自分の範囲に入れると書いた規約は、本稿が読んだ文書の中には無い。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。