Agent2Agent プロトコル（略称 A2A）は、エージェント同士がどのように通信するかを定める標準である。これは、エージェント型 AI のためのモデル AI ガバナンス・フレームワーク がエージェントの中核的な構成要素の一つに挙げるプロトコル — エージェントがツールや他のエージェントと通信するための標準化された方法 — の一つであり、同フレームワークでは、エージェントがツールと通信するために開発された Model Context Protocol に対して、エージェント間を担う対応物として位置づけられている。同フレームワークは、この領域が急速に発展しており、特にエージェント型コマースにおいて、エージェント間のやり取りを標準化するためのプロトコルがさらに開発されつつあると指摘している。
用法
同フレームワークでは、プロトコルは構成要素であると同時にリスクの源としても扱われている。プロトコルは不適切に展開されたり侵害されたりしうるもので、その例として、ユーザーのデータを外部に持ち出すコードを含む信頼できない MCP サーバーが挙げられている。マルチエージェント間のやり取りについて同フレームワークが推奨する統制は、A2A を名指ししてはいないものの、あらゆるエージェント間チャネルに関わるものである — エージェント間で意図しない指示が受け渡されるのを減らすために、自由形式のテキストではなく型付きの関数呼び出しのような構造化スキーマを通じてエージェントに通信させること、そしてエージェント間の共有メモリへのアクセスを制限することである。
報告されたある導入事例は、実際に使うとどのようなコストがかかるかを示している。エージェント型エンジニアリング：AI エージェントの群れはソフトウェアエンジニアリングをどう再定義しているか は、すべてのワーカーエージェントが A2A で通信する一方、A2A をサポートしないエージェントには Model Context Protocol のラッパーを介して到達するマルチエージェントのエンジニアリングシステムを説明している。その著者たちは、統合したかった AI コーディングエージェントがネイティブの A2A 機能を持たないことに気づき、そのコーディングエージェントからのリクエストをワーカーエージェントへ中継する MCP アダプターツールを構築した — この構成によってシステムは IDE に依存しないものになったと彼らは述べている。
三つ目の情報源は、このプロトコルが現在どこまで進んでいるかを報告し、何と組み合わせられつつあるかを挙げている。Jimmy Song のオンラインハンドブック『智能体构建指南』のある章は、A2A を Google 主導のものとし、2026 年のアップデートでエージェントディレクトリが導入されたと述べ、これによって組織をまたぎ、フレームワークをまたいだエージェントの発見と呼び出しが可能になったと紹介している。また、主流の Python エージェントフレームワークの一つが最初にネイティブの A2A サポートを得たとも報告している。同章はこの二つの出来事についてリリース日とバージョン番号に言及しているが、それらの根拠となる発表は本ページの情報源に含まれていないため、ここでは再掲しない。
同章がこの結果に与えている枠組みは、業界が落ち着きつつあるという二つのプロトコルからなるスタックである。すなわち MCP はツールをつなぎ、A2A はエージェントをつなぐ — 前者はエージェントが外部の機能にどう到達するかに答え、後者はエージェント同士がどう相互運用するかに答え、両者が合わさって LLM ベースのマルチエージェントシステム のプロトコル基盤を形成する。2026 年のまとめの表では、MCP は事実上の標準になったもの、A2A は Google 主導のものとして挙げられ、エージェントディレクトリがその特徴的な追加要素とされている。これらはエコシステムの現状についての評価として述べられており、測定された知見としてではない。
四つ目の情報源は、エコシステムにおける位置づけではなく、プロトコルの構成要素を説明している。jimmysong.io で公開されている『AI 原生应用架构白皮书』（AI ネイティブアプリケーションアーキテクチャ白書）の第 3 章は、A2A を異種のエージェント間の効率的な通信と協働のためのオープン標準と呼び、三つの中核的な役割 — ユーザー、A2A クライアント、A2A サーバー — と五つの主要な要素を挙げている。すなわち、エージェントの能力とサービスエンドポイントを記述する JSON 形式のメタデータである Agent Card、マルチターンのやり取りをサポートするステートフルな単位である Task、一回のやり取りの基本単位である Message、タスク完了時に生成される具体的な成果物である Artifact、そしてメッセージや成果物の中の最小のコンテンツ単位である Part である。同章は三つのやり取りのメカニズム — ポーリング、ストリーミング、プッシュ通知 — と、三段階の流れを挙げている。すなわち、A2A サーバーの Agent Card を発見し、認可と認証を行い、そのうえで同期またはストリーミングのいずれかで A2A リクエストを送信する。
同じ章は、発見を分散デプロイがもたらす問題として扱っている。同章は Agent Card をリモートエージェントのデジタル名刺と呼び、A2A クライアントはこれを解析してそのエージェントを発見するとし、Agent Card を入手する方法として三つ — 直接設定、固定 URI、レジストリ — を挙げている。最後のものについては、Nacos が A2A レジストリとして機能し、エージェントの登録・発見・取得を一か所で管理し、エージェントのバージョン管理とグレーリリースをサポートすることを説明しており、これによって分散エージェントシステムの保守性と拡張性が高まると紹介している。
五つ目の情報源は、発見の仕組みが実際に使われる様子を示している。Google の AI エージェントプロトコルのための開発者ガイド は、A2A を、リモートエージェントの側にある専門性 — 異なるチームが、異なるフレームワークで構築し、異なるサーバーで動かしている可能性がある — への答えとして紹介し、一部のデータは API を通じてはまったく公開されないかもしれないが、エージェント的なインターフェースを通じてなら公開されうると指摘している。同ガイドの説明では、各 A2A エージェントは well-known パス /.well-known/agent-card.json に、自身の名前・能力・エンドポイントを記述した Agent Card を公開する。呼び出し側のエージェントはこれらのカードを取得して各リモートエージェントが何をするかを把握し、実行時にクエリを適切なエージェントへ振り分けるため、新しいリモートエージェントを追加するにはその URL を追加するだけでよく、コードの変更も再デプロイも必要ない。同ガイドの実例は Agent Development Kit（ADK） を使っており、その RemoteA2aAgent は 1 ターンにつき一つのリモートエージェントに振り分ける。クエリが同時に複数のリモートエージェントにまたがる場合、同ガイドは a2a-sdk を直接使っている。同じガイドは A2A を六つのプロトコルからなるスタックの中に位置づけ、そこでの役割を一行でまとめている。すなわち、MCP はエージェントをツールやデータにつなぎ、A2A はエージェントを他のエージェントにつなぐ。また、Universal Commerce Protocol（UCP） が A2A の well-known URL による発見パターンを再利用しており、A2A をトランスポートとしてその上で動作しうることにも触れている。
新たに登場しつつある四つのエージェント通信プロトコルのサーベイである エージェント相互運用性プロトコルのサーベイ：Model Context Protocol（MCP）、Agent Communication Protocol（ACP）、Agent-to-Agent Protocol（A2A）、Agent Network Protocol（ANP） は、A2A を、能力ベースの Agent Card を用いたピアツーピアのタスク委任を可能にし、企業のエージェントワークフロー全体にわたる安全でスケーラブルな協働をサポートするものとまとめている。同サーベイは A2A を Model Context Protocol、Agent Communication Protocol（ACP）、Agent Network Protocol（ANP） と比較しており、同サーベイが提案する段階的な導入ロードマップでは、A2A は MCP（ツールアクセス用）と ACP（メッセージング用）に続いて協調的なタスク実行のために導入され、その後、分散型のエージェントマーケットプレイスのために ANP へと導入が広がる。
関連用語
Model Context Protocol, AI エージェント, Universal Commerce Protocol（UCP）, Agent Communication Protocol（ACP）, Agent Network Protocol（ANP）