
こんにちは。Legalscape ソリューションバリューチームの中山と申します。以下では、Agent2Agent (A2A) というAIエージェント同士が通信するためのプロトコルの現状についての雑感を3分ほどで簡単にご紹介したいと思います。
A2A とは
A2A プロトコルは、エージェント同士が動的にスキルを(なんならエージェント自体も)発見し、タスクを投げ、必要ならストリーミングで進捗を受け取るための共通プロトコルを目指している。フレームワークやベンダーに関して中立であり、多様なエージェントがシームレスに通信できるよう標準化がなされている。
2026年2月現在、A2Aは黎明期にあると思う。コンセプトは面白く、非常に興味深いトピックではあるものの、スムーズな本番導入にはエコシステムの足並みが揃うのを待つ必要があるかもしれない。
ちなみに、 Thoughtworks 社が年2回発表している Technology Radar という技術トレンドレポートでは、A2A は2025年11月号で登場し、Assess カテゴリー(詳細に検討すべきだが、必ずしも今すぐ試験的に導入する必要はない)に分類されている。
最新のバージョン
最新の仕様ドキュメントは Release Candidate v1.0 が公開されているものの、latest released version は v0.3.0 である。GitHub のリリースも v0.3.0 (2025-07-30) が latest となっている。
1.0 が RC になりしばらく経ってからも stable なバージョンは動いていないように見えるが、これは2025年6月23日発表の Linux Foundation への寄贈により中立的なガバナンスが整備されたことの現れとも言えるのではないか。なお同年8月29日には ACP という IBM のプロジェクトも A2A に合流している。
SDK とバージョン
オフィシャルの SDK は Python, JavaScript などいくつかの言語向けのものがあるが、いずれも v0.3.0 を実装とある。つまり公式 SDK を使う限り、基本的には 0.3 に従うことになる。
1.0 と 0.3 の違いは色々あるが、目立つところで言えば JSON-RPC のメソッド名が異なる。1.0では message/send が SendMessage に、message/stream が SendStreamingMessage になり、0.3 における gRPC での命名規則に沿った形になった。なお当然ながら 0.3 系 SDK では対応されていない。
とはいえ、クライアントもサーバも同じSDKを使っていればバージョン間の非互換性は今のところ問題にはならない。開発中に curl で手作りの温もりあるリクエストを送ったりしていると Method not found になって首を傾げることもあるが、そもそもそんなことはすべきでなく、 a2aproject/a2a-inspector や a2aproject/a2a-samples の samples/python/hosts/cli を使うなどして、なるべく SDK に面倒を見てもらうべきだろう。
プロキシ
A2A の前段にプロキシを挟むなら、現時点では自作するか、もしくは agentgateway のようなソリューションを採用することもできる。
agentgateway は何もしなくても Agent Card に記載されたエージェントの URL を動的に書き換えたり、CEL式による構成で認証・レート制限・可観測性をケアしたりできる。構成・playground 用 UI もついてくる。
まだ生まれたてではあり、A2A に関する実装は非常にシンプルになっている。例えばバックエンドエージェントの URL にドメインとポート以外のパスが入っていると動的なURL書き換えは働かない。 Well-known URI の RFC に照らすと妥当ではあるのだが、柔軟性が欲しいこともある。
また agentgateway には A2A プロキシ以外にも実に様々な機能があるので、要件とどれだけ重なるかの見極めは必要だと思う。
Agent Engine での開発
Google Cloud には Agent Engine という、AIエージェントをお手軽にデプロイしてセキュアに使おう的なサービスがある。SPIFFE に対応しているので、サービスアカウントによる管理よりも厳格な認証や、相互運用性の高さといった恩恵に与れる可能性がある。この Agent Engine でも A2A をしゃべるエージェントは作れるのだが、まだ Pre-GA ではあり、統合の完成に向けて開発が行われている最中であると想像される。
たとえば、Agent Engine ネイティブのストリーミングは存在するが、Agent Engine 単体での A2A ストリーミングは2026年2月現在まだできない。Agent Engine を使いつつ A2A ストリーミングに対応したい場合、Agent Engine には後述の ADK でネイティブのストリーミングエージェントを置いて、その手前に A2A ストリーミングに対応したプロキシエージェントを Cloud Run に置くといったアプローチがある。
ストリーミングでなければ Agent Engine で A2A エージェントを開発することは難しくない。A2A をしゃべるには、A2A SDK の AgentExecutor を満たすものを実装すれば良い。そのため Agent Engine に A2A エージェントをデプロイするにも、 AgentExecutor (と AgentCard)から Agent Engine の A2aAgent インスタンスを作成するだけとなる。
ADK での開発
Agent Development Kit (ADK) という、これまた Google が出しているAIエージェントフレームワークがある。
ADK は A2A 対応していて、既存のADKエージェントを to_a2a() で A2A にでき、Agent Card もエージェント定義から自動生成できる。呼び出し側は RemoteA2aAgent を使ってローカルのサブエージェントに近い感覚でリモート A2A エージェントを組み込める。
ADK で作成したエージェントは Agent Engine, Cloud Run, GKE その他のコンテナがサポートされる環境にデプロイできる。特に Agent Engine はデプロイ周りがまだややこしく、ADK とその CLI を使うことでかなり楽ができる点が優れている。
今後
個人的には、A2A はエージェント間の開けた相互運用を担うプロトコルとして注目しています。プラットフォームやSDK、ゲートウェイといった環境は少しずつ充実してきており、ビジネスにも活かせるようになりつつある、という状況ではないでしょうか。
A2A はエンタープライズでも耐えうる堅牢なプロトコルを標榜しているので、AI エージェントの盛り上がりに伴ってさらに使いやすくなるかもしれません。今後もウォッチしていきたいと思います。