Googleの「A2Aプロトコル」って実際どうなの？使っている人いる？

Googleの「A2Aプロトコル（Agent-to-Agent）」について気になっています。半年ほど前に調べてみたのですが、当時は使いどころがいまいちピンときませんでした。当時はまだエージェントの概念自体が模索段階でしたし、その後MCPプロトコルが一気に普及したことも影響していたかもしれません。ただ最近思うのは、エージェントがツールやサービス、データ、そして連絡先情報を持ち始めた今、まさにエージェント同士が直接やり取りするフェーズに入っているのでは？ということです。最適なコンテキストを持ち、クエリに対して正確に回答できるエージェント同士を連携させるのは非常に理にかなっています。そこで、皆さんに伺いたいのですが、実際にこのA2Aプロトコルを実務やプロジェクトで使っている方はいますか？ https://github.com/a2aproject/A2A

関連情報。他に何かある？

The Agent2Agent Protocol (A2A) - https://news.ycombinator.com/item?id=43631381 (https://news.ycombinator.com/item?id=43631381) - 2025年4月 (280コメント)

自分の知る限り、それほど大きな効果は出てないね。Laurie Voss（npmの作成者）が数ヶ月前にエージェント同士の相互作用プロトコルについて良いプレゼンをしていたけど、彼はA2Aを含めてそれらがどれほどの価値を付加しているのか懐疑的だったよ。 https://youtu.be/kqB_xML1SfA?si=lxehX1-_z_dBoZtQ (https://youtu.be/kqB_xML1SfA?si=lxehX1-_z_dBoZtQ)

仕事でA2Aを使ってるよ。エージェントのための「マイクロサービスアーキテクチャ」みたいな感じかな……チームが独立してエージェントを開発できて、必要な時に連携させられる。今のところ大きな障害はないね。

オーバーエンジニアリングに思えるな。普通にエージェントの前にAPIを構築して、もう一方のエージェントにマークダウンファイルで仕様を渡せば済む話じゃないか。

AIインフラ/ツール開発者（www.hic-ai.com）です。A2Aプロトコルは慎重に検討しましたが、私から見てA2Aは正しい問題を解決していないと判断しました。（エージェントの観点から見て）エージェントAからエージェントBへの通信と、エージェントAから「未来のエージェントA」への通信に違いはありません。実際、エージェントには固有のアイデンティティという概念が全くないので、「エージェントA」という唯一無二の存在も定義できません。「エージェントA」がメッセージを受け取った、あるいは別のエージェント（または自身の未来の姿）にメッセージを送っているという概念は、そもそもエージェントのアイデンティティが明確に存在しているという前提に囚われすぎています。A2Aは、エージェントカードが発見・デプロイ可能な特定のエージェントを指し示しているという前提で、そのような明確なアイデンティティの存在を仮定しています。また、gRPCによる抽象化のレイヤーが重すぎて実装も面倒だと感じています。MCPなどに比べて普及していない現状を見ると、A2Aは現実世界の課題を解決できていないのだと思います。

VS Codeチームでは、新しいプロトコルであるAHPの上でエージェントインフラを再構築しているよ： https://github.com/microsoft/agent-host-protocol (https://github.com/microsoft/agent-host-protocol) 。

複数のエージェントやハーネスを管理するホストと対話するための共通プロトコルだよ。

A2Aは、独立して開発されたエージェント同士が会話する問題を解決するものだね。でもより大きな課題は「お前のエージェントが本当に機能するかどうやって信頼するのか？」という点で、これは「エージェント評価（Agent Evals）」の信頼できるシステムがあれば解決するはず。それがなければ、エージェントディレクトリや自動ディスパッチなんてほとんど役に立たない。

Googleエコシステムに深く関わっているなら意味があるよ：

• gemini-cliはリモートのA2Aエージェントを接続できる（https://github.com/tanaikech/gemini-cli-gas-a2a-subagents を参照）。試してはいないけど、下のローカルなユースケースはやってみた。

• カスタムのGoogle ADK「エージェント」をワンライナーでA2Aとして公開できて、同じ方法でgemini-cliに接続できる。

こういうプロトコルの類はすべてノイズだよ。重要なのは、エージェントが現在のスコープやACLの範囲内で、ツールの発見やアクセスを含めて相互に会話できるようにすることだ。AnthropicがMCPを良いアイデアだと言ってリリースした時、私は何日も文句を言ったよ。そう、今もまだ言っている。

もちろん発見の仕組みは重要で、今まさにトップページにも投稿がある。でもみんなが見落としているのは、a) トークンを使ってサービスを認証する仕組みはHTTPで十分うまく処理できるということ。面白い事実として、元々のHTTPプロトコル（まだRFCなんて気にする人はいるかな？）はPOSTをサポートしていなかったんだ！だから、ほとんどの呼び出しは、相手が理解できるトークンを添えてGETリクエストを送るだけで事足りる。SSLを重ねてクエリパラメータを隠せばいいし、自宅ネットワークに証明書を紐付けるのも今は簡単だしね。

発見の仕組みは色々あるけど、エージェントが動いている場所の性質上、接続するのは困難だ（穴開けとかが頭に浮かぶ）。もちろんクラウドで実行すればいい。でも、主権を気にするなら、サービスや単一のエージェント/モデルに「ロックイン」されるのは避けたいはずだ。

100%欠けているのは支払いだ。402（PAYMENT REQUIRED）に注目すべき。Cloudflareは何かやっているみたいだが、少し前にLightning LabのroasbeefのApertureプロジェクトから盗んだものだね。あれはLightningネットワークで決済を実装している。

ビットコインアドレスにまとめて支払いをして、Lightningインボイスに詰め込んで送れば、相手が受け取ってサーバーを更新してアクセスを許可してくれる。もし騙されたと思えば、インボイスを閉じて返金を受ければいい。

ビットコインに懐疑的な人が多いのは知っているけど、エージェント間の通信にはマイクロペイメントが本当に役立つと思っている。だから2年ほど前にメモを残しておいたんだ： https://ahp.nuts.services/

その通り！まあ、自分でもオープンソースのA2Aパッケージをいくつか作っている（https://github.com/a2anet ）ので、少し偏った意見かもしれないけどね。客観的な視点として、A2A SDKの月間ダウンロード数を確認しているんだ（https://pypistats.org/packages/a2a-sdk ）。現時点で約1,090万件に対して、MCPは2億5,700万件だから、MCPのほうが24倍ほどダウンロードされているね。

A2Aはスタートアップよりエンタープライズで人気があるんだ。Gemini Enterprise、AgentForce、watsonx Orchestrate、SAP Jouleなどのクラウドプロバイダーやオーケストレーションプラットフォームが対応しているからね。エンタープライズの人は、これらのプラットフォームでエージェントを共有したり他チームと連携したりするために、A2A互換にすることが多いよ。

A2Aを使っているスタートアップは、たいてい以下の理由の少なくとも1つがあるね：

1. APIエンドポイントの標準化。A2Aはテキスト、データ、ファイルの送受信方法を規定しているから、クライアントコードを一度書けば異なるエージェントフレームワークで再利用できる。
2. エージェントカタログの標準化。A2Aは名前、説明、スキル、受け入れ可能な入力などを保持する「エージェントカード」という概念を導入している。
3. 長時間稼働タスクのため。A2Aはポーリング、ストリーミング、ウェブフックをサポートし、長時間稼働のタスク向けに設計されている。

紛らわしいことに、これらは必ずしもエージェント同士の通信とは限らない。結局のところ、通信・発見・認証を標準化するためには、エージェントの仕組み自体を標準化する必要があるということだよ。

A2Aプロトコルはエージェント間通信のための良質な（完璧ではないが）ソリューションであり、これからも成長するだろう。どこまで成長するかはエージェントの進化次第だね。現時点ではコーディングエージェントやチャットボットのためにMCPサーバーが構築されているけど、エージェントそのもののためのものはまだ少ない。最終的には、顧客体験を制御・向上させるためのエージェントが構築されるようになると思う。そうなれば、インターネットを介したエージェントの発見・接続・通信の問題を解決するA2Aが自然な選択肢になるはずだよ。