A2A（Agent2Agent）とは、Googleが2025年4月のGoogle Cloud Next 2025で発表した、AIエージェント同士が安全に通信・連携するためのオープンプロトコルです。2026年3月にはv1.0が正式リリースされ、150以上の組織が本番環境で運用を開始するなど、エージェント間通信の業界標準として急速に普及が進んでいます。
しかし、A2Aとはそもそもどのようなプロトコルなのか、MCP（Model Context Protocol）とはどう違うのか、自社のマルチエージェント構築にどう活かせるのかといった疑問を持つ方も多いのではないでしょうか。
本記事では、A2Aの定義や設計原則から、仕組み・MCPとの違い・導入メリット・活用事例、そしてエコシステムの最新動向まで、JAPAN AIが網羅的に解説します。
＼ ChatGPTもClaudeもGeminiも使える！ ／
目次
- A2A（Agent2Agent）とは
- A2A（Agent2Agent）の5つの設計原則
- A2A（Agent2Agent）の仕組み
- A2A（Agent2Agent）とMCPの違い
- A2A（Agent2Agent）導入のメリット
- A2A（Agent2Agent）のリスクと注意点
- A2A（Agent2Agent）の活用事例
- A2A（Agent2Agent）の始め方
- A2A（Agent2Agent）のエコシステムと対応状況
- A2A（Agent2Agent）の未来と展望
- A2A（Agent2Agent）に関してよくある質問
- A2A（Agent2Agent）を理解してAIエージェント連携の第一歩を踏み出そう
A2A（Agent2Agent）とは
A2A（Agent2Agent）とは、AIエージェント同士が安全に情報交換し、タスクを協調して実行するためのオープンプロトコルです。正式名称はAgent-to-Agentで、Googleが2025年4月にGoogle Cloud Next 2025で50社以上のテクノロジーパートナーとともに発表しました。
A2Aプロトコルの基盤には、HTTP、JSON-RPC、gRPCといった既存のWeb標準技術が採用されています。非同期通信にはSSE（Server-Sent Events）やWebhookも活用されています。これにより、新たな独自プロトコルを学ぶ必要がなく、既存のITインフラと容易に統合できる設計です。ライセンスはApache License 2.0で公開されており、誰でも無償で利用・改変・再配布が可能です。
なお、A2Aプロトコルは2026年3月にv1.0が正式リリースされ、本番環境での利用に耐える安定版として位置づけられています。2026年5月にはv1.0.1もリリースされ、仕様の安定化が着実に進んでいます。
AIエージェントの基本的な概念や仕組みについては、「AIエージェントとは？生成AIとの違いから特徴や事例を徹底解説」の記事で詳しく解説しています。
出典:Google Developers Blog「Announcing the Agent2Agent Protocol (A2A)」
背景と課題
A2Aプロトコルが求められる背景には、AIエージェントのサイロ化という深刻な課題があります。
企業がAIエージェントを導入する動きは急速に広がっていますが、各ベンダーやフレームワークが独自の通信方式を採用しているため、異なるプラットフォーム上のエージェント同士が直接連携できない状況が生じています。たとえば、Salesforce上の営業エージェントとServiceNow上のIT運用エージェントが協調して顧客対応を行いたくても、共通の通信手段がなければ人手による橋渡しが必要です。
この「エージェントのサイロ化」は、マルチエージェントシステムの構築を阻む最大のボトルネックです。各エージェントが孤立して動作する限り、業務プロセス全体を横断的に自動化することは困難です。A2Aプロトコルは、この課題を解決するために設計された統一的な通信規格といえます。
A2Aの役割
A2Aプロトコルは、異なるフレームワークで構築されたエージェント間の「共通言語」として機能します。
具体的には、エージェントが自身の能力を公開し、相手のエージェントを発見し、認証を経てタスクを依頼・実行するという一連の通信フローを標準化しています。その結果、Google Cloud上のエージェントがAWS上のエージェントと連携するといった、クラウドをまたいだ協調動作が実現可能です。
A2AとMCP（Model Context Protocol）の関係も重要です。MCPはエージェントと外部ツールやデータソースを接続する「縦方向」のプロトコルであるのに対し、A2Aはエージェント同士を接続する「横方向」のプロトコルです。両者は競合関係ではなく、相互に補完し合う設計思想に基づいています。
A2A（Agent2Agent）の5つの設計原則
A2Aプロトコルは、ベンダーやフレームワークに依存しないエージェント連携を実現するために、5つの設計原則に基づいて構築されています。これらの原則は、Googleが50社以上のパートナー企業と共同で策定したもので、実際のプロトコル仕様に一貫して反映されています。
- エージェントの能力を活かす
- 既存技術の活用
- セキュリティ重視
- 長時間タスクへの対応
- モダリティ非依存
エージェントの能力を活かす
A2Aプロトコルの第一の設計原則は、エージェントを単なるツールではなく、自律的に判断・行動する主体として扱うことです。
従来のAPI連携では、呼び出し元が相手のシステムの内部構造を理解し、具体的な操作手順を指定する必要がありました。A2Aプロトコルでは、エージェント同士がメモリやツール、コンテキストを共有していなくても、自然なモダリティで協調できる仕組みを採用しています。
たとえば、クライアントエージェントは「この顧客の与信審査を行ってほしい」という抽象的なタスクをリモートエージェントに依頼するだけで済みます。リモートエージェントは自身の専門知識とツールを活用して、最適な方法でタスクを遂行します。この設計により、真のマルチエージェント連携が実現します。
既存技術の活用
A2Aプロトコルは、HTTP、JSON-RPC 2.0、SSEといった広く普及したWeb標準技術を基盤に構築されています。
新たな独自プロトコルを採用せず、既存のWeb標準に準拠することで、開発者が追加の学習コストをかけずにA2Aを導入できるよう配慮されています。企業のITインフラに組み込まれているロードバランサーやAPIゲートウェイ、監視ツールといった既存のミドルウェアも、そのまま活用可能です。
v1.0ではgRPCバインディングの仕様が厳格に標準化され、JSON-RPCやHTTP/RESTと同等の品質で低レイテンシが求められるユースケースにも対応できるようになりました。既存のWeb開発の知識とツールチェーンがそのまま通用する点は、エンタープライズ環境での導入障壁を大幅に下げます。
セキュリティ重視
A2Aプロトコルは、HTTPS通信を前提とし、認証・認可・スコープ制御をデフォルトで組み込む設計を採用しています。
エージェント間通信では、機密性の高い業務データがやり取りされる可能性があるため、セキュリティは最初から設計に組み込まれています。OpenAPIの認証スキームと同等の水準を目指しており、OAuth 2.0やAPIキーなど、企業で広く使われている認証方式に対応しています。
v1.0で導入されたSigned Agent Card（暗号署名付きエージェントカード）により、エージェントの発行元をJWS（JSON Web Signature）で暗号的に検証できるようになりました。これは、組織をまたいだエージェント連携において、なりすましを防止するための重要な機能です。
長時間タスクへの対応
A2Aプロトコルは、数秒で完了する即時タスクから、数時間から数日にわたる長時間タスクまで柔軟に対応できる設計です。
企業の業務プロセスには、データ分析レポートの作成や複数部門にまたがる承認フローなど、完了までに長い時間を要するタスクが数多く存在します。A2Aプロトコルでは、SSEによるストリーミングとWebhookによるプッシュ通知の2つの非同期通信方式をサポートしています。
クライアントエージェントはタスクの進捗をリアルタイムに把握でき、リモートエージェントからの中間報告や状態更新を受け取りながら、必要に応じて追加の指示を送ることも可能です。この柔軟な非同期処理の仕組みにより、人間の介在が必要な複雑なワークフローにも対応できます。
モダリティ非依存
A2Aプロトコルは、テキストだけでなく、音声・画像・動画・構造化データなど多様な形式に対応する設計です。
メッセージ内の各コンテンツはPart（パーツ）という単位で管理され、それぞれにコンテンツタイプが指定されます。クライアントエージェントとリモートエージェントは、対応可能なフォーマットを事前に交渉（ネゴシエーション）できるため、双方の能力に応じた最適な形式でデータをやり取りできます。
iframeやWebフォーム、動画ストリーミングといったリッチなUIコンポーネントもサポートされており、エージェントの出力をそのままエンドユーザーに提示する場面でも柔軟に活用できます。
出典:Google Developers Blog「Announcing the Agent2Agent Protocol (A2A)」
A2A（Agent2Agent）の仕組み
A2Aプロトコルの通信アーキテクチャは、クライアントエージェントとリモートエージェントの役割分担を軸に構成されています。通信フロー全体は、エージェントカードによる能力発見、認証、タスク送信、レスポンス取得という4つのステップで進行し、5つのコアオブジェクトがその基盤を支えています。
- エージェントカード
- タスク
- メッセージ
- アーティファクト
- v1.0の主な新機能
エージェントカード
エージェントカード（Agent Card）とは、エージェントの能力・スキル・認証情報を記述するJSON形式のメタデータです。
各エージェントは、自身のエージェントカードを`.well-known/agent.json`というURLパスに配置します。クライアントエージェントはこのURLにアクセスすることで、リモートエージェントがどのようなタスクを実行できるか、どの認証方式に対応しているか、どのモダリティをサポートしているかを事前に把握できます。
この仕組みは、Webサイトの`robots.txt`やOAuth 2.0のディスカバリエンドポイントに類似した設計です。エージェントカードには、エージェント名・説明文・対応スキル・エンドポイントURL・認証要件などが構造化されて記述されます。クライアントエージェントはこの情報をもとに、タスクに最適なリモートエージェントを自動的に選定できます。
タスク
タスクオブジェクトは、エージェント間のやり取りの中心となる作業単位です。
クライアントエージェントがリモートエージェントにタスクを送信すると、そのタスクにはライフサイクルが生まれます。タスクの状態は「submitted（送信済み）」「working（処理中）」「input-required（追加入力待ち）」「auth-required（認証待ち）」「completed（完了）」「failed（失敗）」「canceled（取消）」「rejected（拒否）」の8段階で管理され、クライアントエージェントはいつでも最新の状態を問い合わせることが可能です。
即時に完了するタスクの場合は、送信と同時に結果が返されます。一方で、長時間を要するタスクの場合は、SSEストリーミングやWebhookを通じて進捗が逐次報告されます。タスクの最終的な成果物はアーティファクトとして返却されるため、中間的な通信（メッセージ）と最終成果物（アーティファクト）が明確に区別されています。
メッセージ
メッセージとは、クライアントエージェントとリモートエージェントの間で交わされる通信の基本単位です。
各メッセージにはロール（送信者の役割）が付与され、クライアントからの指示なのか、リモートからの応答なのかが明示されます。メッセージの本体はPart（パーツ）で構成されており、テキスト・画像・ファイル・構造化データなど、複数の形式のコンテンツを1つのメッセージに含めることができます。
メッセージはタスクの実行中に複数回やり取りされ、コンテキストの共有、追加指示の送信、中間結果の報告などに使われます。この双方向のメッセージングにより、エージェント同士が対話的に協調しながらタスクを進められます。
アーティファクト
アーティファクトとは、タスク実行の最終的な成果物を指します。
メッセージがタスク実行中の中間的なやり取りであるのに対し、アーティファクトはタスクが完了した際に生成される確定的な出力です。分析レポートの生成タスクで考えた場合に、完成したPDFファイルがアーティファクトに該当します。
アーティファクトもメッセージと同様にPart（パーツ）で構成されており、テキストや画像、ファイルなど複数の形式を含むことが可能です。クライアントエージェントは、タスクの完了後にアーティファクトを取得し、その内容をエンドユーザーに提示したり、別のエージェントへの入力として活用したりできます。
v1.0の主な新機能
2026年3月にリリースされたA2Aプロトコルv1.0は、本番環境での運用に耐える最初の安定版です。
v1.0では、Signed Agent Card（暗号署名付きエージェントカード）が導入されました。JWS（JSON Web Signature）を用いてエージェントカードの発行元を暗号的に検証できるため、組織をまたいだエージェント連携においてなりすましリスクを大幅に低減できます。
gRPCバインディングの仕様が厳格に標準化され、JSON-RPCやHTTP/RESTと同等の品質で通信できるようになりました。マルチテナンシー機能では、単一のエンドポイントで複数のエージェントを安全にホスティングできます。バージョンネゴシエーション機能により、異なるバージョンのA2Aプロトコルを使用するエージェント同士でも互換性を保った通信が可能です。
また、v1.0では従来のTextPart・FilePart・DataPartが単一のPart型に統合され、メッセージとアーティファクトで統一的なデータ構造が使えるようになりました。2026年5月にはv1.0.1もリリースされ、仕様のさらなる安定化が進んでいます。
A2A（Agent2Agent）とMCPの違い
A2AとMCP（Model Context Protocol）は、AIエージェントのエコシステムにおいて異なるレイヤーを担う補完的なプロトコルです。A2Aがエージェント同士の「横方向」の通信を標準化するのに対し、MCPはエージェントと外部ツールやデータソースの「縦方向」の接続を標準化しています。両者は競合関係ではなく、組み合わせて使うことで最大の効果を発揮します。
比較表
| 比較項目 | A2A（Agent2Agent） | MCP（Model Context Protocol） |
|---|---|---|
| 開発元 | Google（オープンソース） | Anthropic（オープンソース） |
| 目的 | エージェント間の通信・協調 | エージェントとツール・データの接続 |
| 接続方向 | 横方向（エージェント↔エージェント） | 縦方向（エージェント↔ツール/データ） |
| 通信プロトコル | JSON-RPC / gRPC / HTTP REST | JSON-RPC（stdio / Streamable HTTP） |
| 対象 | 自律的なAIエージェント | ツール・データソース・API |
| ユースケース | マルチエージェント連携・業務横断の自動化 | 外部データベースやSaaSツールとの接続 |
| 管理団体 | Linux Foundation（Agent2Agent Protocol Project） | Linux Foundation（AAIF） |
MCPの仕組みや活用方法については、「MCP（Model Context Protocol）とは？仕組み・メリット・活用事例をわかりやすく解説」の記事もあわせてご覧ください。
A2AとMCPはどう使い分ける？
A2AとMCPの使い分けは、解決したい課題の性質によって判断できます。
単一のエージェントが外部ツールやデータソースに接続する場合は、MCPだけで十分です。チャットボットがCRMのデータを参照して顧客情報を回答するケースでは、MCPでCRMとの接続を確立するだけで要件を満たせます。
一方、複数のエージェントが協調して業務プロセスを遂行する場合は、A2Aが必要です。たとえば、営業エージェントが見積もりを作成し、与信審査エージェントに審査を依頼し、承認エージェントが最終決裁を行うといった業務横断のワークフローでは、A2Aによるエージェント間通信が不可欠です。
最も効果的な構成は、MCPでエージェントと外部ツールを接続し、A2Aでエージェント同士を連携させるハイブリッド型です。MCPが各エージェントの「手足」を拡張し、A2Aがエージェント間の「対話」を実現するという役割分担により、柔軟かつ拡張性の高いマルチエージェントシステムを構築できます。
A2A（Agent2Agent）導入のメリット
A2Aプロトコルを導入することで、企業はマルチエージェントシステムの構築において、相互運用性・柔軟性・拡張性の3つの優位性を獲得できます。オープンプロトコルとしての特性が、特定ベンダーへの依存を排除し、長期的なシステム運用の自由度を高めます。
- 専門特化エージェントの組み合わせ
- ベンダーロックインの回避
- スケーラビリティ
専門特化エージェントの組み合わせ
A2Aプロトコルにより、各業務に特化したエージェントを自在に組み合わせた高度な業務自動化が可能です。
単一の汎用エージェントですべての業務をカバーしようとすると、精度や対応範囲に限界が生じます。A2Aプロトコルを活用すれば、経理処理に特化したエージェント、法務チェックに特化したエージェント、データ分析に特化したエージェントをそれぞれ独立して開発し、必要に応じて連携させることができます。
各エージェントは自身の専門領域に集中できるため、個々の精度が高まります。さらに、新しい業務要件が発生した際には、既存のエージェントに影響を与えることなく、新たな専門エージェントを追加するだけで対応できます。この「マイクロサービス的」な構成は、組織の業務変化に対する俊敏な適応を可能にします。
ベンダーロックインの回避
A2Aプロトコルはオープンスタンダードであるため、特定のベンダーやクラウドプラットフォームに依存しないシステム構築が可能です。
Apache License 2.0で公開されているA2Aプロトコルに準拠してエージェントを構築すれば、Google Cloud上のエージェントをAWSやAzureに移行する際にも、通信インターフェースを変更する必要がありません。プロトコルレベルでの互換性が保証されているため、ベンダー選定の自由度が大幅に向上します。
エンタープライズ環境では、部門ごとに異なるクラウドプラットフォームやAIフレームワークを採用しているケースが一般的です。A2Aプロトコルは、こうしたマルチクラウド・マルチフレームワーク環境においても、統一的なエージェント間通信を実現します。
スケーラビリティ
A2Aプロトコルの標準化された通信インターフェースにより、エージェントの追加・入れ替え・削除が容易です。
従来の個別連携方式では、新しいエージェントを追加するたびに既存エージェントとの接続を個別に構築する必要がありました。A2Aプロトコルでは、新しいエージェントがエージェントカードを公開するだけで、既存のクライアントエージェントから自動的に発見・利用が可能です。
v1.0で導入されたマルチテナンシー機能により、単一のエンドポイントで複数のエージェントをホスティングできるため、インフラの管理負荷も軽減されます。業務の拡大に応じてエージェントを段階的に増やしていく「スモールスタート」のアプローチが取りやすく、初期投資を抑えながら段階的にシステムを拡張できます。
AIエージェントの業務活用を加速するなら「JAPAN AI AGENT」
A2Aプロトコルのようなオープン標準の普及により、AIエージェント同士の連携は今後ますます加速していきます。こうした時代に、自社の業務プロセスにフィットしたAIエージェントを迅速に構築・運用できる基盤の整備が重要です。JAPAN AI AGENTは、ノーコードでAIエージェントを作成でき、MCP対応による外部ツール連携やマルチLLM対応、上場企業水準のセキュリティを備えた法人向けプラットフォームです。業務に特化した「AI社員」を約1分で自動構築でき、営業・マーケティング・人事・バックオフィスなど幅広い業務の効率化を実現します。
日本企業のための
最も実用的なAIエージェントへ！
AIが企業の様々な職種の
方々が
普段行っている
タスクを自律的に実行
JAPAN AI AGENT
実用性の高いAIエージェンを提供
無料の伴走サポート
高いカスタマイズ性
目標設定をだけで自律的にAIが各タスクを実行
A2A（Agent2Agent）のリスクと注意点
A2Aプロトコルの導入には多くのメリットがある一方で、マルチエージェント環境特有のリスクと注意点も存在します。セキュリティ管理の複雑化と標準化の発展途上という2つの課題を事前に理解し、適切な対策を講じることが重要です。
- セキュリティリスク管理の複雑化
- 標準化・互換性の課題
セキュリティリスク管理の複雑化
マルチエージェント環境では、認証・認可の管理対象がエージェントの数に比例して増加します。
単一のエージェントを運用する場合と異なり、複数のエージェントが相互に通信するマルチエージェント環境では、各エージェント間の信頼関係を個別に管理する必要があります。エージェントAがエージェントBを信頼し、エージェントBがエージェントCを信頼している場合、エージェントAはエージェントCも暗黙的に信頼してよいのかという「信頼の連鎖」の問題が生じます。
v1.0で導入されたSigned Agent Cardは、エージェントの発行元を暗号的に検証する仕組みを提供し、なりすましリスクの軽減に寄与しています。ただし、エージェントに付与するスコープ（権限範囲）の設計や、アクセストークンの有効期限管理など、運用面での設計は導入企業側の責任です。最小権限の原則に基づいた慎重なスコープ設計が求められます。
標準化・互換性の課題
A2Aプロトコルは急速に進化しているため、異なるバージョン間の互換性管理が実務上の課題です。
2025年4月の初期リリースからv1.0、v1.0.1と短期間でバージョンアップが進んでおり、各バージョンで新機能の追加や仕様変更が行われています。複数の組織がそれぞれ異なるバージョンのA2Aプロトコルを実装している場合、通信の互換性が保証されない可能性があります。
この課題に対し、v1.0ではバージョンネゴシエーション機能が導入されました。クライアントエージェントとリモートエージェントが通信開始時に互いのバージョンを確認し、共通のプロトコルバージョンで通信を行う仕組みです。
また、A2Aプロトコルは2025年6月にGoogleからLinux Foundationに寄贈され、中立的なガバナンスのもとで管理されています。さらに、2025年12月に設立されたAAIF（Agentic AI Foundation）がMCPなどの関連プロトコルを管理しており、エージェント関連標準全体の長期的な互換性維持が期待されています。
A2A（Agent2Agent）の活用事例
A2Aプロトコルは、複数のAIエージェントが連携して業務プロセスを遂行する場面で真価を発揮します。金融・ヘルスケア・製造業の3つの分野における具体的なユースケースを通じて、A2Aによるエージェント間連携の実践的な活用方法を解説します。
金融分野：不正検知
金融分野では、取引監視・認証・アラートの3段階で連携する不正検知システムがA2Aの代表的なユースケースです。
取引監視AIエージェントが決済データをリアルタイムに分析し、不審なパターンを検出すると、A2Aプロトコルを通じて認証AIエージェントにタスクを送信します。認証AIエージェントは本人確認や過去の取引履歴との照合を実施し、その結果をアーティファクトとして返却します。不正の疑いが高いと判定された場合、アラートAIエージェントが担当者への通知と該当取引の一時停止を自動的に実行します。
この3段階の連携は、各エージェントが独立して開発・更新できるため、不正検知のアルゴリズムを改良する際にも他のエージェントへの影響を最小限に抑えられます。A2Aプロトコルのタスク状態管理により、各段階の処理状況をリアルタイムに追跡できる点も、金融機関の監査要件に適合しています。
ヘルスケア分野：患者データ管理
ヘルスケア分野では、診断・データ管理・通知の各AIエージェントが連携して患者データを安全に共有するユースケースが想定されています。
診断AIエージェントが検査結果を解析し、異常値を検出した場合、A2Aプロトコルを通じてデータ管理AIエージェントに患者の電子カルテ更新を依頼します。データ管理AIエージェントは該当する医療記録を更新し、通知AIエージェントが担当医師や看護師へのアラートを送信します。
医療データは機密性が極めて高いため、A2Aプロトコルのセキュリティ設計が重要な役割を果たします。Signed Agent Cardによるエージェントの身元確認と、スコープ制御によるアクセス権限の厳格な管理により、患者データの不正アクセスを防止しながら、必要な情報を必要な担当者に迅速に届けることが可能です。
製造業：スマートファクトリー
製造業では、品質検査・工程最適化・在庫管理の各AIエージェントが連携して製造ラインを最適化するユースケースが注目されています。
品質検査AIエージェントが製造ラインの画像データを分析し、不良品の発生率が閾値を超えた場合、A2Aプロトコルを通じて工程最適化AIエージェントにタスクを送信します。工程最適化AIエージェントは製造パラメータの調整案を生成し、在庫管理AIエージェントが原材料の追加発注や出荷スケジュールの調整を自動的に実行します。
A2Aプロトコルの長時間タスク対応機能は、製造ラインの24時間稼働環境において特に有効です。各エージェントが非同期で連携し、リアルタイムに状態を共有しながら、製造プロセス全体の最適化を継続的に実行できます。
マルチエージェントシステムの基礎や活用パターンについては、「AIマルチエージェントとは？基礎概要や活用事例を解説」の記事で詳しく解説しています。
A2A（Agent2Agent）の始め方
A2Aプロトコルを使い始めるには、公式リポジトリの活用とGoogle ADK（Agent Development Kit）との連携が最も効率的なアプローチです。
A2Aプロトコルの仕様書やサンプルコードは、GitHubの公式リポジトリ（a2aproject/A2A）で公開されています。Python、Java、TypeScriptなど複数の言語向けのSDKが提供されており、既存の開発環境に合わせて選択できます。
Google ADK（Agent Development Kit）はA2Aプロトコルのネイティブサポートを備えたオープンソースのエージェント開発フレームワークです。ADKを使えば、数行のコードでA2Aエージェントを構築し、エージェントカードの公開やタスクの受け付けを実装できます。既存のADKエージェントをA2A対応にすることも容易です。
デプロイ環境としては、Google CloudのAgent Runtime（旧Vertex AI Agent Engine）がA2Aエージェントのホスティングに対応しています。Cloud Runを使えば、コンテナベースでA2Aエージェントをスケーラブルにデプロイすることも可能です。まずは公式リポジトリのサンプルコードを動かし、エージェントカードの公開とタスクの送受信を体験することが、A2A導入の第一歩です。
AIエージェントの構築方法全般については、「AIエージェントの作り方完全ガイド！初心者でもノーコードで5ステップ作成」の記事もあわせてご覧ください。
出典:Google Cloud Blog「Announcing a complete developer toolkit for scaling A2A agents on Google Cloud」
A2A（Agent2Agent）のエコシステムと対応状況
A2Aプロトコルのエコシステムは、発表から約1年で150以上の組織が参加する規模に成長しました。Linux Foundationへの寄贈と主要クラウドプラットフォームの対応により、業界標準としての地位が急速に確立されつつあります。
- AAIF（Agentic AI Foundation）
- クラウドプラットフォームの対応状況
- 主要パートナー企業
AAIF（Agentic AI Foundation）
AAIF（Agentic AI Foundation）は、AIエージェント関連のオープンプロトコルを中立的に管理する組織です。
2025年12月にLinux Foundation傘下で設立され、Anthropic・Block・OpenAI・Amazon Web Services・Google・Microsoftなどがプラチナメンバーとして参加しています。AAIFは、AnthropicのMCP（Model Context Protocol）、BlockのGoose、OpenAIのAGENTS.mdを創設プロジェクトとして管理しています。
A2Aプロトコルは、AAIFとは別にLinux Foundation傘下の独立プロジェクト「Agent2Agent Protocol Project」として運営されています。2025年6月にGoogleからLinux Foundationに寄贈され、中立的なガバナンスのもとで発展しています。AAIFとA2Aプロジェクトは同じLinux Foundationのエコシステム内に位置しており、エージェント関連標準全体の相互連携が進んでいます。
出典:Linux Foundation「Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)」
クラウドプラットフォームの対応状況
主要なクラウドプラットフォームは、いずれもA2Aプロトコルへの対応を進めています。
Google Cloudは、Gemini Enterprise Agent Platform（旧Vertex AI）のAgent Runtimeで、A2Aエージェントのデプロイ・スケーリングをネイティブにサポートしています。ADK（Agent Development Kit）のA2Aネイティブ対応により、開発からデプロイまでの一貫したワークフローを提供しています。
AWSは、Amazon Bedrock AgentCore Runtimeを通じてA2Aプロトコルに対応しました。Bedrock上で構築したエージェントがA2Aプロトコルで他のエージェントと通信できるため、AWS環境内でのマルチエージェント構築が容易です。
Microsoftは、Azure AI FoundryおよびCopilot StudioにA2Aを統合しています。Copilot StudioからA2Aエージェントに接続する機能により、Microsoft 365のエコシステムとA2Aエージェントの連携が実現しています。
主要パートナー企業
A2Aプロトコルのパートナー企業は、発表当初の50社超から150以上の組織に拡大しています。
エンタープライズソフトウェア領域では、Salesforce（Agentforce）・SAP・ServiceNow・Atlassianといった主要ベンダーが参加しています。これらの企業は自社のプラットフォーム上でA2Aプロトコルに対応したエージェントの構築・連携機能を提供しており、既存の業務システムとAIエージェントの統合を推進しています。
コンサルティング領域では、Accenture・BCG・Capgemini・Deloitte・KPMG・McKinsey、PwCといったグローバルファームが参加し、クライアント企業へのA2A導入支援を展開しています。サプライチェーンや金融サービス、保険、IT運用など、複数の業界でA2Aプロトコルを活用した本番運用が進んでいます。
A2A（Agent2Agent）の未来と展望
A2Aプロトコルは、エージェント経済（Agent Economy）と呼ばれる新たな産業構造の基盤として、今後さらなる発展が見込まれています。
v1.0のリリースとv1.0.1への迅速なアップデートが示すように、プロトコルの進化は加速しています。Signed Agent CardやgRPCサポート、マルチテナンシーなど、エンタープライズ環境で求められる機能が着実に追加されており、今後もセキュリティとスケーラビリティの両面で機能拡充が続くと見込まれます。
A2AとMCPがともにLinux Foundation傘下で発展していく体制が整ったことも重要です。A2AはLinux Foundation直下のプロジェクトとして、MCPはAAIF傘下のプロジェクトとして、それぞれ独立しつつも連携可能な形で運営されています。両プロトコルの連携がさらに深化すれば、エージェントがツールを活用しながら他のエージェントと協調する、より高度なマルチエージェントシステムの構築が標準化されていきます。
将来的には、企業が自社のAIエージェントをA2Aプロトコル経由で外部に公開し、他社のエージェントとサービスを取引する「エージェント経済」の形成が予測されています。エージェントカードが企業の「デジタル名刺」として機能し、エージェント同士が自律的にパートナーを発見・選定・契約する時代の到来に備え、A2Aプロトコルの理解と実装経験を蓄積しておくことが、企業の競争力を左右する要素です。
A2A（Agent2Agent）に関してよくある質問
A2Aを使うにはGoogleのサービスが必要ですか？
A2Aプロトコルの利用にGoogleのサービスは必要ありません。A2AはApache License 2.0で公開されたオープンプロトコルであり、Google Cloud以外の環境でも自由に利用できます。AWS、Azure、オンプレミス環境のいずれでも実装可能で、利用料金も一切かかりません。GitHubの公式リポジトリからSDKやサンプルコードを取得し、任意の環境で開発・デプロイできます。
A2AとMCPの両方を使う必要がありますか？
ユースケースによって異なります。単一のエージェントが外部ツールやデータソースに接続するだけであれば、MCPのみで十分です。複数のエージェントが協調してタスクを遂行するマルチエージェントシステムでは、A2Aによるエージェント間通信が必要です。最も効果的な構成は、MCPでツール接続を行い、A2Aでエージェント間の連携を実現するハイブリッド型です。
A2Aプロトコルの本番利用は可能ですか？
可能です。2026年3月にv1.0がリリースされ、本番環境での利用に耐える安定版として位置づけられています。2026年5月にはv1.0.1もリリースされ、仕様の安定化が進んでいます。150以上の組織がサプライチェーン、金融サービス、保険、IT運用などの分野で本番運用を行っており、エンタープライズ環境での実績が蓄積されています。
A2A（Agent2Agent）を理解してAIエージェント連携の第一歩を踏み出そう
A2A（Agent2Agent）は、AIエージェント同士が安全に通信・連携するためのオープンプロトコルであり、マルチエージェントシステム構築の業界標準として急速に普及しています。MCPがエージェントとツールの「縦方向」の接続を担うのに対し、A2Aはエージェント間の「横方向」の通信を標準化する補完的な存在です。
2026年3月のv1.0リリースにより、Signed Agent CardやgRPCサポート、マルチテナンシーなどエンタープライズ向け機能が充実し、本番運用に耐える段階に到達しました。150以上の組織によるA2Aプロトコルの採用と、AAIFを中心としたエージェント標準化の進展は、エージェント間通信の標準化が業界全体のインフラとして定着しつつあることを示しています。
A2Aプロトコルの理解と実装経験は、今後のAIエージェント戦略において不可欠な要素です。まずは公式リポジトリ（GitHub: a2aproject/A2A）のサンプルコードを動かし、エージェントカードの公開とタスクの送受信を体験することから始めてみてください。
