AIエージェントの「共通言語」が誕生した
AIエージェントが企業システムに本格導入される2026年、課題として浮上しているのが「異なるベンダーのエージェント同士がどうやって協調するか」という問題です。
LangChainで構築したエージェント、Google ADKで作ったエージェント、ServiceNowのエージェント——それぞれが独自のAPIを持ち、互いに直接通信できない状況は、まるで共通言語のない国際会議のようです。
この課題を解決するために、Googleが2025年4月に提唱し、2026年4月にv1.0として正式リリースされたのが Agent2Agent (A2A) プロトコル です。Linux Foundation の傘下でオープンソース（Apache License 2.0）として公開されており、150を超える組織がすでに採用しています。
A2Aプロトコルとは何か
A2Aは、異なるフレームワーク・ベンダー・環境で動作するAIエージェントが相互通信するためのオープンプロトコルです。
従来、AIエージェントが外部ツールやデータソースにアクセスするにはAnthropicの MCP（Model Context Protocol） が使われてきましたが、A2Aはそれとは異なる層を担います。
- MCP：AIエージェントが「ツール・データ」と通信するためのプロトコル（エージェント ↔ ツール）
- A2A：AIエージェントが「別のAIエージェント」と通信するためのプロトコル（エージェント ↔ エージェント）
Googleはこの2つを「競合」ではなく「補完関係」と位置づけており、実際の本番システムでは両方を組み合わせて使うケースが多くなっています。
技術仕様：A2Aはどのように動くか
基本アーキテクチャ
A2Aは既存のWeb標準を最大限に活用した設計になっています。
| 技術要素 | 採用標準 |
|---|---|
| トランスポート | HTTP(S) |
| メッセージフォーマット | JSON-RPC 2.0 |
| ストリーミング | Server-Sent Events (SSE) |
| 高スループット通信 | gRPC（v0.3以降） |
| エージェント署名 | JWS + JSON Canonicalization |
新しい独自プロトコルを発明せず、エンジニアが既に習熟している技術の上に構築されているため、学習コストが低いのが特徴です。
エージェントカード（Agent Card）
A2Aの中核となる仕組みが Agent Card です。各エージェントは自身のエンドポイントの /.well-known/agent.json にJSONメタデータを公開します。このファイルには以下が記述されています。
- エージェントの名称・説明
- 提供するスキル（できること）
- 認証方式
- 通信エンドポイントURL
クライアントエージェントはこのAgent Cardを読み取ることで、「誰に何を頼めるか」を動的に発見できます。ちょうどWebブラウザが robots.txt を参照するのと同様の仕組みです。
タスクライフサイクル
A2Aにおける作業単位は Task（タスク） です。タスクはユニークなIDを持ち、以下の状態遷移を経ます。
submitted → working → input-required → completed
→ failed
→ canceled
非同期実行が前提で、クライアントはタスク送信後すぐにレスポンスを受け取り（TaskオブジェクトまたはMessageオブジェクト）、処理はバックグラウンドで続行されます。ストリーミングモードではSSEで進捗がリアルタイムに送信されます。
マルチターン対話のサポート
タスク処理中に追加情報が必要になった場合、エージェントは input-required ステータスを返します。クライアントは同一タスクIDで追加メッセージを送信でき、人間の介在（Human-in-the-loop）を含む対話型ワークフローを自然に実現できます。
v1.0の主な新機能
2026年4月にリリースされたv1.0は、v0.3からの進化版で、エンタープライズ対応を大きく強化しています。
1. Signed Agent Cards（署名付きエージェントカード）
最大の変更点が署名付きAgent Cardです。JWSとJSON Canonicalizationを使った暗号署名により、受信側は「このAgent Cardが本当にそのドメインのオーナーから発行されたもの」であることを検証できます。
組織をまたぐエージェント連携では、なりすましや改ざんのリスクがあります。v1.0以前は署名機能がなく、クロスオーガニゼーション統合はセキュリティ上の課題を抱えていました。Signed Agent Cardsはこれを解決し、エンタープライズ展開を現実的にする重要な機能です。
2. マルチテナンシー
単一エンドポイントで複数のエージェントをホストできるようになりました。SaaSプロバイダーが顧客ごとに異なるエージェントを提供するシナリオ（テナントスコープ）をネイティブにサポートします。gRPCリクエストにもテナントスコープが組み込まれています。
3. マルチプロトコルバインディング
同一の論理エージェントを JSON-RPC over HTTP と gRPC の両方で公開できるようになりました。既存のHTTP環境との後方互換性を保ちながら、高スループットが求められる用途にはgRPCを選択できます。
4. バージョンネゴシエーション
v0.3からv1.0への移行を後方互換性を保ちながら実施できます。段階的なアップグレードパスが確保されているため、既存実装を壊さずに新機能を導入できます。
主な使用用途
A2Aが解決するのは主に以下のシナリオです。
マルチエージェントオーケストレーション 複数の専門エージェント（データ分析エージェント、レポート作成エージェント、承認処理エージェント）を協調させる。各エージェントが得意分野を担い、オーケストレーターエージェントがA2Aで指示を出します。
クロスベンダー統合 LangChain製のエージェントとGoogle ADK製のエージェントが、フレームワークの違いを意識せずに通信できます。
エンタープライズシステム間連携 SalesforceのエージェントとServiceNowのエージェントが、組織の壁を越えてリアルタイムにデータや処理を共有します。
人間参加型ワークフロー
エージェントの処理の途中で人間の確認や追加入力が必要になるケースを、input-required ステータスで自然に表現できます。
具体的なユースケース
ユースケース1：食品サプライチェーン（Tyson Foods × Gordon Food Service）
食品大手のTyson FoodsとGordon Food Serviceは、A2Aを使ったクロスオーガニゼーションのエージェント連携を実用化しています。Tyson Foods側のエージェントが商品データや在庫情報を持ち、Gordon Food Serviceのエージェントが調達・発注処理を担当。A2Aを通じてリアルタイムにデータと商談リードを共有することで、サプライチェーンの摩擦を大幅に削減しています。
ユースケース2：ITサービス管理（ServiceNow AI Agent Fabric）
ServiceNowはA2Aの創設パートナーとして、独自の AI Agent Fabric をA2A上に構築しています。ServiceNow製エージェント、顧客が独自に構築したエージェント、パートナー製エージェントがシームレスに通信できる環境を提供しており、インシデント対応・変更管理・承認ワークフローの自動化に活用されています。
ユースケース3：通信・カスタマーサポート（Twilio）
TwilioはA2Aの拡張機能として Latency Aware Agent Selection（遅延を考慮したエージェント選択） を実装しています。顧客からの問い合わせを受けた際、応答速度・専門性・可用性を考慮して最適なエージェントにルーティングする仕組みです。
ユースケース4：購買コンシェルジュ（Google Codelabs参照実装）
Googleが公式に公開しているCodelabsのデモでは、購買担当エージェント（Purchasing Concierge）と販売担当エージェント（Remote Seller Agent）がA2Aで連携する例が示されています。ユーザーの購買要件をコンシェルジュエージェントが受け取り、複数の販売エージェントに商品情報を問い合わせ、最適な提案をまとめて返すワークフローです。
MCPとの違い・比較
エンジニアが最も混乱しがちなのが、A2AとMCPの位置づけの違いです。
| 観点 | A2A | MCP |
|---|---|---|
| 策定元 | Google（Linux Foundation傘下） | Anthropic |
| 対象 | エージェント ↔ エージェント | エージェント ↔ ツール/データ |
| 主な用途 | マルチエージェント協調 | ツール呼び出し・コンテキスト付与 |
| 通信パターン | 非同期タスク・ストリーミング | 同期的ツール実行 |
| エージェントの自律性 | 高（相互にブラックボックス） | 低（ホストが制御） |
| ライセンス | Apache 2.0 | MIT |
MCPはエージェントが「スパナ」や「データベース」といったツールを使うための接続標準です。一方、A2Aはエージェントが「別のエージェント（専門家）」に仕事を委託するための通信標準と理解すると整理しやすいでしょう。
Googleは公式に「A2AはMCPを補完するプロトコル」と述べており、実際のエンタープライズアーキテクチャでは次のような構成が典型的です。
オーケストレーターエージェント
↓ A2A（エージェント間通信）
専門エージェント（例：データ分析エージェント）
↓ MCP（ツール接続）
データベース / 外部API / ファイルシステム
今後の展望
エコシステムのさらなる拡大
v1.0リリース時点で150以上の組織が採用しており、Adobe、S&P Global Market Intelligence、ServiceNow、Twilioなど各業界のリーダー企業が本番環境での利用を開始しています。Linux Foundation傘下のオープン標準として、特定ベンダーへのロックインを避けたい企業からの採用が加速すると見られます。
クラウドプラットフォームへのネイティブ統合
Google Cloud（Agent Engine / Cloud Run / GKE）での A2A ネイティブサポートに加え、Amazon BedrockもA2Aプロトコルコントラクトを公式ドキュメントに掲載するなど、主要クラウドでの対応が進んでいます。マルチクラウド環境でのエージェント連携が現実的な選択肢になっていくでしょう。
セキュリティ・ガバナンスの成熟
Signed Agent Cardsの導入により組織間の信頼検証が可能になりましたが、エージェント認証・認可・監査ログの標準化はまだ発展途上です。エンタープライズ採用が進むにつれ、セキュリティ仕様のさらなる強化が進むと考えられます。
ANP（Agent Network Protocol）との競合・共存
Alibabaが提唱するANP（Agent Network Protocol）など、別のエージェント間通信標準も登場しています。複数の標準が乱立する時期を経て、市場が収れんしていく過程は、かつてのHTTP標準化の歴史と重なるものがあります。A2Aはすでに業界最大規模のエコシステムを持ちますが、標準化競争の行方には引き続き注目が必要です。
まとめ
Agent2Agent (A2A) プロトコルv1.0は、マルチエージェントシステムが企業の本番環境に本格展開される2026年において、最も重要なインフラ標準の一つになりつつあります。
エンジニアとして押さえておくべきポイントは3つです。
- A2AとMCPは競合ではなく補完関係。エージェント間通信にはA2A、ツール接続にはMCPという役割分担を理解する
- v1.0の最大の意義はエンタープライズ対応。Signed Agent Cards とマルチテナンシーにより、組織をまたぐ本番利用が現実的になった
- オープン標準であることの強み。Linux Foundation傘下のApache 2.0ライセンスで、特定ベンダーに縛られない設計
マルチエージェントアーキテクチャを設計・実装するエンジニアは、A2Aの仕様を早期に習得しておくことで、将来の本番システム設計に大きなアドバンテージを持てるでしょう。