この記事のポイント
- A2AはAIエージェント同士が対等に発見・通信・協働するためのオープン標準で、発表から1年で参画組織が50社から150社超へ拡大した。
- MCPが「AI↔ツール」の垂直層を担うのに対し、A2Aは「エージェント↔エージェント」の水平層を担う補完関係にある。
- v1.0でSigned Agent Cardが入り、AP2が公式拡張として乗ったことで、A2Aはエージェンティックコマースの水平バスとして使える段階に入った。
1年で50社から150社超へ — A2Aが水平バスになった瞬間
2026年4月9日、PR NewswireでA2Aプロトコルの1周年が報じられました。参画組織は150を超え、GitHubリポジトリは22,000スター超、そしてAzure AI FoundryやAmazon Bedrock AgentCoreなど主要クラウドプラットフォームでの本番利用が確認されている——PR Newswireのリリースが並べた数字は、1年前のCloud Nextで50社パートナーとして始まったものとは別次元です。
本記事では、Googleが2025年4月に発表しLinux Foundationへ寄贈したA2A（Agent-to-Agent）プロトコルを、設計思想・アーキテクチャ・2026年v1.0の変更点・MCPとの関係・そしてAP2拡張による決済連携まで、2026年4月時点の最新情報で整理します。MCPについては既にMCPとは何かとMCPサーバー構築ガイドで詳しく扱っているので、本稿はA2Aに軸足を置いて書きます。
A2Aプロトコルとは何か
A2Aは、AIエージェント同士がフレームワークやベンダーの壁を越えて、対等な相手として発見し、コミュニケーションし、協働するためのオープンプロトコルです。Googleの公式アナウンスは、2025年4月9日のGoogle Cloud Nextで公開されました。立ち上げ時の賛同企業は50社を超え、Accenture、Atlassian、Box、Cohere、Deloitte、Elastic、LangChain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、UiPathといった名前が並んでいます。
公開から2ヶ月後の2025年6月23日、GoogleはA2AをLinux Foundationへ寄贈し、Agent2Agent Protocol Projectとして中立ガバナンスに移管しました。初期の運営メンバーはAWS、Cisco、Google、Microsoft、Salesforce、SAP、ServiceNowの7社。オーナーシップを手放すというこの判断は、後述するMCPのAAIF移管と並んで、「AIエージェントの配線規格はもはや特定ベンダーのものではない」という業界合意の象徴になりました。
A2Aが解こうとしている問題は、結論から言えば水平方向の相互運用性です。各社が独自に作ったAIエージェントは、これまで他社のエージェントと直接話す手段を持っていませんでした。同じSaaSプラットフォーム上のエージェント同士ですら、REST APIを別途定義しない限り連携できません。A2Aはこの「エージェント間の言語」を共通化します。
Agent Card・Task・Message・Artifact — A2Aの4つのコア要素
A2Aの仕様を支えているのは、わずか4つのコア概念です。
1つ目はAgent Card。各エージェントは自分の名前・能力・認証方式・エンドポイント・提供スキルを記述したJSONを、https://{ドメイン}/.well-known/agent-card.jsonに配置します。RFC 8615のwell-known URI規約に従うので、相手エージェントはドメインを知っていれば誰でも能力情報を取りに行けます。これが分散型ディスカバリの土台です。
2つ目はTask。A2Aのすべての対話はTaskという単位で管理されます。Taskは明示的なライフサイクル（submitted → working → input-required / auth-required → completed / failed / canceled / rejected）を持ち、長時間実行される非同期処理を1級市民として扱える設計になっています。MCPが基本的に同期的な要求応答モデルなのに対し、A2Aは長寿命のタスクを前提にしている点が大きな違いです。
3つ目はMessageで、これはTaskの中でやり取りされる発話単位です。role: "user"または"agent"を持ち、本体はPartsという複数パートの配列で表現されます。Partsはテキスト・バイナリ・ファイル・構造化データを混在できる設計で、マルチモーダル前提の現代的な仕様になっています。
4つ目はArtifactで、Taskの成果物を表します。PDFの請求書、JSONの分析結果、画像——どれもArtifactとしてクライアントに返されます。
プロトコル層ではJSON-RPC 2.0をベースに、HTTP・Server-Sent Events・gRPCバインディングをサポートします。認証はAPIキー、HTTP認証、OAuth 2.0 / OpenID Connect、相互TLSまで揃っており、OpenAPIのセキュリティスキーマとパリティがある点が実務的にありがたい設計判断です。公式仕様には11のJSON-RPCメソッド（SendMessage、SendStreamingMessage、GetTask、SubscribeToTask、CreateTaskPushNotificationConfigなど）が定義されており、ストリーミングとWebhookによるプッシュ通知の両方が最初から組み込まれています。
v1.0で加わった決定的なもの — Signed Agent Cardとマルチテナンシー
2026年初頭に公開されたA2A v1.0は、仕様の成熟を示すリリースでした。Version 1.0のリリースノートが強調するのは4つの変更点です。
最も重要なのはSigned Agent Cardの導入でしょう。Agent Cardに暗号学的な署名を載せることで、受け手のエージェントは「このカードを発行したのは本当にそのドメインの所有者か」を検証できるようになりました。これがないと、攻撃者が偽のAgent Cardを立てて相手のエージェントを誘導するカード偽装攻撃が成立してしまいます。Signed Agent Cardは、分散型ディスカバリを前提にするA2Aにとって、実質的な信頼モデルの根幹です。
2つ目がマルチテナンシー対応です。1つのエンドポイントで複数のエージェントをホストできるようになり、SaaSプロバイダがテナントごとに別々のエージェントを運用しやすくなりました。3つ目はマルチプロトコル・バインディングで、同じ論理エージェントをJSON-RPCとgRPCの両方で公開できます。4つ目がバージョンネゴシエーションで、v0.3からv1.0への後方互換マイグレーションが仕様レベルで保証されています。
これらを並べて眺めると、v1.0が目指したのは「v0系は機能的には動いたが本番品質ではなかった」という状態の解消であることが分かります。Signed Agent Cardがなければ本番の企業間連携には耐えられず、マルチテナンシーがなければSaaS提供者は使い物にならない——つまりv1.0はエンタープライズで実際に回すための最後のピースを埋めたリリースです。
A2AとMCPの違い — 競合ではなく層が違う
A2AとMCPは、しばしば混同されますが、担当するレイヤーが完全に異なります。Googleの公式ドキュメントはA2A and MCPという専用のページを用意してこの区別を強調しています。
| 観点 | A2A | MCP |
|---|---|---|
| 主軸 | 水平（エージェント ↔ エージェント） | 垂直（エージェント ↔ ツール・データ） |
| 創出者 | Google（2025年4月） | Anthropic（2024年11月） |
| ガバナンス | Linux Foundation（2025年6月寄贈） | Linux Foundation AAIF（2025年12月寄贈） |
| 対話モデル | ピアツーピア、不透明なエージェント同士がタスクを折衝 | クライアント・サーバー、モデルがツールを呼ぶ |
| ディスカバリ | Agent Card（.well-known/agent-card.json） | 接続時のcapability handshake |
| 状態モデル | Taskによる明示的な状態機械 | 主にステートレスなツール呼び出し |
| 長寿命処理 | 1級市民（input-required、ストリーミング、Push通知） | 限定的、アドホック |
| 主な用途 | 調達エージェント ↔ サプライヤーエージェント、マルチエージェント協調 | エージェント ↔ GitHub、エージェント ↔ Postgres |
Googleの比喩は分かりやすいので紹介します。自動車修理店の例です。外から見た顧客は1つの「修理エージェント」と話しているように見えますが、内部ではその修理エージェントが他の専門エージェント（診断、見積、部品調達）とA2Aで対話し、それぞれの専門エージェントは必要に応じてMCP経由で自社の在庫システムや部品カタログにアクセスします。A2Aが水平バス、MCPが垂直バスというこの構図を頭に入れると、以降の議論がすべて整理できます。
プロトコル全体の整理はエージェンティックAIプロトコル一覧でも扱っているので、A2AとMCPを含む全体の俯瞰はそちらも参考になります。
AP2はA2Aの公式拡張として動く — 決済層との接続
2025年9月、Google CloudとCoinbaseがAP2（Agent Payments Protocol）を発表しました。これが重要なのは、AP2が単なる別プロトコルではなく、A2Aの公式拡張として設計されている点です。AP2のA2A拡張仕様は、AP2をA2AのAgentCard extensionとして登録し、URI識別子https://github.com/google-agentic-commerce/ap2/tree/v0.1で参照できるようにしています。
つまり、A2Aで「あなたは決済対応エージェントですか」を確認するとき、クライアントはAgent Cardのextensionフィールドを見るだけでAP2のサポート有無と対応バージョンを判別できます。追加のプロトコルを発明するのではなく、既存のA2Aディスカバリ機構をそのまま決済層に流用したこの設計は、プロトコルの層構造を崩さずに商取引機能を足す好例です。
AP2自体の詳細はAP2（Agent Payments Protocol）の解説で扱っていますが、A2Aを学ぶ上で押さえておくべきなのは、「A2Aは決済を扱わない。決済はAP2という拡張が担当する」という役割分担です。A2Aは純粋にエージェント同士の対話と協働の言語に徹していて、その上に必要に応じて特化拡張が乗るというモジュラー設計を取っています。
エージェンティックコマースにおけるA2Aの意味
コマース事業者の視点から見ると、A2Aが本当に効いてくるのはこれからの18ヶ月です。
現状のエージェンティックコマースの大部分は「1つのAIエージェントが顧客の代理として1つのECサイトで買う」というシングルエージェント構造です。しかし、実際の調達・B2B取引・比較購買・複雑な契約交渉では、複数のエージェントが協働する必要があります。調達エージェントが複数のサプライヤーエージェントと同時に会話し、見積もりを集め、条件を交渉し、最終的にAP2で決済する——この一連のフローをどの企業も独自仕様で作ってしまうと、1社との連携ごとに別のコネクタが必要になります。
A2Aが提供するのは、この水平方向の共通言語です。Agent Cardがディスカバリを担い、Taskが長寿命の交渉を扱い、AP2拡張が決済を処理します。この3層が揃えば、エージェント同士の商取引が技術的に回せる段階に入ります。この実務的な意味合いはAgent-to-Agent時代のeコマース準備でも踏み込んで扱っています。より広い文脈を押さえたい方はエージェンティックコマースとは何かもあわせてご覧ください。
もう1つ重要なのは、2025年8月にIBMのACP（Agent Communication Protocol）がLinux Foundation AI & Dataの下でA2Aに統合された点です。A2Aの最大の競合だったACPが自ら合流したことで、エージェント間通信の標準化は事実上A2Aに一本化されました。今からエージェント間連携を設計する事業者にとって、A2A以外の選択肢はほぼないのが2026年4月時点の現実です。
まとめ — A2Aは「配線規格」から「商取引のバス」へ
1年前のA2Aは、Googleが50社と一緒に発表した新しい仕様でした。1年後のA2Aは、150を超える組織が参画し、Linux Foundationが所有し、v1.0でSigned Agent Cardが入り、AP2が公式拡張として乗り、Microsoft・AWS・Salesforce・SAP・ServiceNowが本番投入している業界横断の水平バスです。
押さえておくべきは3点に要約できます。A2AとMCPは競合ではなく別レイヤーであること。v1.0がエンタープライズ本番運用の前提を満たしたこと。そしてAP2拡張によって、A2Aはエージェンティックコマースの「水平バス兼商取引層」の中核になったこと。
MCPが「配管」なら、A2Aは「配電盤」です。個々のエージェントがツールに繋がる配管を持っていても、それらが互いに電気をやり取りできなければ、多エージェント社会は成立しません。あなたが設計する次のエージェンティックシステムが1つのエージェントで閉じるのか、それとも他社のエージェントと協働するのか——その問いに答えるとき、A2Aを無視する選択肢はもう残っていません。
