これはGoogle Cloud NEXT Writing Challengeへの投稿です
誰もが話しているのは違うこと
Google Cloud Next '26は雷雨のように降り注ぎました。インターネットは、Appleとの提携、Gemini Enterprise Agent Platformの洗練されたデモ、そして第8世代TPUをめぐって爆発しました。ほら、これらは確かにわくわくするものです。ですが、基調講演を見て、ドキュメントを読み、実際に数時間かけてリリースされた内容を掘り下げてみた後で確信したのは、「ソフトウェアの作り方を変える」発表が、Hacker Newsのトップページにすら出ていなかったということです：
Agent2Agent（A2A）プロトコルは現在、150以上の組織で本番運用されています。v1.2で、Linux Foundationによって正式にガバナンスされています。
他のサービスと通信するものを何かしら作っている開発者なら、そして正直に言うとそれが私たち全員のはずなら、これは「眠れないほど」気にすべき発表です。
簡単な入門：A2Aとは何か、そしてなぜ気にすべきなのか？
今日、サービス同士がどうやって通信しているかを考えてみてください。私たちはRESTエンドポイントを書きます。GraphQLのスキーマを扱いこなし、チーム間でAPI契約を交渉し、独自のSDKを作り、20〜40%もの開発サイクルを食い潰す脆い統合レイヤーを維持しています。さあ、それをAIエージェントにスケールしたらどうなるでしょうか。
エージェントが当たり前の世界では、「自分のサービスが相手のAPIを呼ぶ」だけではありません。人間があらゆる手順を段取りすることなく、エージェント同士が互いを発見し、能力をすり合わせ、タスクを委譲し、結果を報告する必要があります。
これがA2Aが解決する課題です。そして、仕組みを平易な英語で言うとこうです：
1. エージェントカード：ソフトウェアの名刺
すべてのA2A準拠エージェントは、周知されたURL（/.well-known/agent-card.json）に「Agent Card（エージェントカード）」を公開します。このカードには次が記載されます：
- そのエージェントが誰か — 名前、説明、バージョン
- 何ができるか — 能力とスキル
- どうやって話しかけるか — エンドポイント、認証要件、対応プロトコル
これはOpenAPI仕様とDNSレコードの組み合わせのようなものですが、自律型のAIシステムのために特化して設計されています。ネットワーク上のどのエージェントでも、人間が統合ドキュメントを書くことなく、別のエージェントの能力を発見し評価できます。
2. 親しみある仕組みの上でのコミュニケーション
A2Aは車輪の再発明をしません。HTTP/HTTPS、JSON-RPC 2.0、およびストリーミング用のServer-Sent Events（SSE）を使います。この10年でWebhookハンドラを書いたことがあるなら、転送層の80%はすでに分かっているはずです。
これは意図的で、そして見事な設計選択です。既存のWebインフラに基づいて作ることで、A2Aは何十年分ものツール群を継承します。ロードバランサ、APIゲートウェイ、可観測性スタック、WAF——すべてそのまま使えます。
3. 長時間の作業のためのタスクライフサイクル管理
ここが、A2Aがそれ以前のあらゆるものから分かれているポイントです。明示的な状態を持つ、構造化されたタスクライフサイクルが含まれています：
-
pending→ タスクを受信し、実行のためにキューへ -
in-progress→ エージェントが現在も作業中 -
completed→ 結果の準備ができた -
failed→ 何かが壊れた。理由はこちら
これは単なるステータス追跡ではありません。組織の境界をまたいだ複雑で多段階のワークフローを、エージェントが管理できるようにする契約です。クライアントのエージェントは、タスクを開始して他の作業をこなし、結果に対してポーリングしたりストリーミングしたりできます。うまく設計された非同期ジョブシステムのように。ただし、その標準はエコシステム全体で揃っています。
4. 実際に企業が必要とするセキュリティ
v1.2のアップデート（Cloud Nextと同時に投入されたもの）では、ドメイン検証のための暗号学的に署名されたエージェントカードが追加され、さらにOAuth 2.0とmTLSのサポートも加わりました。これは、本番システムに後付けされた研究プロトコルではありません。初日から本番用として作られています。
Google CloudのModel Armorによるインライン通信サニタイズと組み合わせれば、セキュリティチームが、エージェントの展開のたびに毎回車輪を作り直す必要がないセキュリティの物語が手に入ります。
それがGemini Enterprise Agent Platformよりも重要な理由
誤解しないでください。Gemini Enterprise Agent Platform（かつてVertex AIと呼ばれていたもの）は素晴らしいです。エージェントデザイナーのノーコードキャンバス、長時間稼働するエージェントのワークフローを管理するためのInbox、エージェントレジストリ——どれも本当に役に立つツールです。
ですが、私のホットテイクを言うと：プラットフォームは独自仕様であり、プロトコルは永続する。
Gemini Enterprise Agent PlatformはGoogleの製品です。優れていて、もしGoogle Cloudのエコシステムにいるなら、ぜひ使うべきです。けれどもA2AプロトコルはLinux Foundationのもとにあるオープン標準です。すでに次のものに組み込まれています：
- GoogleのAgent Development Kit（ADK）
- LangGraph（LangChain）
- CrewAI
- LlamaIndex Agents
- Microsoft Semantic Kernel
- AutoGen
これは珍しいケースで、大手クラウドベンダーが、競合するプラットフォーム上の開発者を含め、誰にとっても役立つものをリリースしました。これは慈善ではありません。標準化によってロックインよりも先にパイが広がる、という賭けです。そして歴史的に、その賭けは当たる傾向があります（例：HTTP、TCP/IP、OAuth、OpenTelemetry）。
開発者への影響：今すぐ何が変わるのか
実用的なイメージを描きます。たとえば、カスタマーサポートの仕組みを作っているとしましょう。今日のあなたのアーキテクチャは、おそらくこうなっているはずです：
User → Your App → Custom LLM Integration → Custom CRM API Wrapper
→ Custom Billing API Wrapper
→ Custom Knowledge Base Search
どの統合もオーダーメイドです。接続はすべて保守の負債になります。新しいデータソースごとに、新しいアダプタ、新しい認証対応、新しいエラー回復ロジックが必要です。
A2Aを混ぜると、だいたいこう見えます：
User → Your Orchestrator Agent
→ discovers CRM Agent (via Agent Card)
→ discovers Billing Agent (via Agent Card)
→ discovers Knowledge Agent (via Agent Card)
→ delegates tasks via standard A2A protocol
→ monitors lifecycle states
→ composes results
オーケストレータは、CRMエージェントが内部でどう動いているのかを知る必要はありません。Agent Cardを読み、能力を理解し、標準プロトコルで通信できれば十分です。明日Salesforceが独自のA2A準拠エージェントを出したとしても、あなたのシステムは新しい統合コードを1行も書かずにそれを取り込めます。
これが革命です。 どれか1つのエージェントが賢くなることではありません。すべてのエージェントが、人間がすべての接続を手配線しなくても協働できるようになることです。
A2A vs. MCP：競合ではなく補完関係
A2AがModel Context Protocol（MCP）とどう関係するのかについて、いくつか混乱を見かけましたので、整理させてください：
返却形式: {"translated": "翻訳されたHTML"}| MCP | A2A | |
|---|---|---|
| Purpose | エージェントをツールとデータに接続する | エージェントを他のエージェントに接続する |
| Relationship | Agent ↔ Resource | Agent ↔ Agent |
| Analogy | 周辺機器向けのUSBポート | ネットワーク化されたシステムのためのTCP/IP |
| Use Case | 「私のデータベースを問い合わせて」 | 「ねえCRMエージェント、この顧客を調べて」 |
それらは補完関係にあるレイヤーです。MCPは、あなたのエージェントに「手」と「目」を与えます。A2Aは、その「同僚」を与えます。Agentic Data Cloud と Knowledge Catalog（Next ’26でも発表されたもの） は MCPレイヤーに位置し、エージェントに必要な文脈と土台（グラウンディング）を提供します。A2Aはその上にあり、専門化されたエージェント同士の協働をオーケストレーションします。
エージェント領域で何か非自明なものを作るなら、両方が必要になります。
まだ欠けていると私が思うこと
プロトコルはv1.2の時点ではどれも完璧ではなく、A2Aにはぜひ埋めてほしいいくつかのギャップがあります：
1. 大規模なディスカバリー
よく知られたURLにあるAgent Cardは、どこを探せばいいか分かっているときにはとても上手く機能します。しかし、存在を知らないエージェントを見つけるにはどうするのでしょう？ 現時点では、標準化されたレジストリやマーケットプレイスのプロトコルはまだありません。GoogleのAgent RegistryはGCPのエコシステム内では役立ちますが、オープンなプロトコルには分散型のディスカバリー機構が必要です——例えばエージェント版DNSのようなものです。
2. 経済的プリミティブ
エージェントAがタスクをエージェントBに委任するとき、誰が支払うのでしょう？ A2Aには、メータリング（計量）、請求、コスト交渉といった概念が組み込まれていません。エージェントのマーケットプレイスへと進んでいくにつれ（GoogleはProject Marinerの2026年Q4のロードマップでそのようなものに言及しています）、これは重要になります。
3. 能力のためのセマンティックバージョニング
Agent Cardは能力を説明しますが、それらの能力をバージョン管理するための標準がありません。エージェントがスキルを更新したとき、クライアントは何が変わったのかをどうやって知るのでしょう？ エージェントの能力に対するsemverのような仕組みが必要です。
4. 複数エージェントのワークフローをデバッグする
単一エージェントのトレースですら難しいのに、3つの異なるベンダーの5エージェントにまたがる会話をトレースするとなると？ 観測可能性（オブザーバビリティ）のストーリーには改善の余地があります。A2AのトレースへのOpenTelemetryの統合は、まさにゲームチェンジャーになるでしょう。
より大きな全体像：Googleが賭けるエージェント型エンタープライズ
視点を引いて見ると、Cloud Next ’26の全体像（ナラティブ）がきれいに噛み合って見えてきます：
- Gemini Enterprise Agent Platform = エージェントを作る「工場」
- Agent Designer = エンジニアでない人のための「設計図（ブループリント）作成ツール」
- Knowledge Catalog + Agentic Data Cloud = 「燃料」（エンタープライズデータからの信頼できる文脈）
- Model Armor + Agentic Defense = 「柵（ガードレール）」（セキュリティとガバナンス）
- A2A Protocol = すべてをつなぎ合わせる「道路」
- 8th-Gen TPUs + Virgo Network = その下にある「電力網」
Appleとの提携は？ これは、GoogleのAIインフラが最高水準であることの裏付けです。Appleが次世代の基盤モデルを作るためにGoogle Cloudを選んだことは、VirgoのファブリックとTPUアーキテクチャへの信頼の表れです。しかし、開発者である私たちにとっては、私たちが作るものや作り方を変えるものではありません。
A2Aは違います。知的システム同士の「協働のアーキテクチャ」を変えます。そしてそれは、何年にもわたって積み重なっていく変化です。
今週あなたがやるべきこと
もしこれらの話に少しでも共感できたなら、私の実践的なアドバイスは次のとおりです：
A2Aの仕様を読む。 よく書かれていて、驚くほど短いです。google.github.io/A2A から始めてください。
おもちゃのAgent Cardを作る。 既存のサービスの1つについて、
/.well-known/agent-card.jsonを公開します。たとえ完全なA2Aサーバーを作らなくても、サービスの能力を機械で読める形式で説明する演習は、非常に明確にしてくれます。ADKを試す。 GoogleのAgent Development Kitには、最初からネイティブのA2Aサポートが含まれています。2つのエージェントを立ち上げて、会話する様子を見てください。自律的なシステムが互いに発見し委任していくのを見るのは、どこか魔法のようです。
統合の“税金（integration tax）”について考える。 現在のコードベースを見てみてください。システムAとシステムBをつなぐためだけに存在しているコードはどれくらいありますか？ A2Aが排除するよう設計されたのは、そのコードです。標準化されたプロトコルが独自の“つなぎ込み”コードに取って代われるような統合の継ぎ目（seams）を特定し始めましょう。
開発者向けキーノートの再生を視聴する。 自然言語でマルチエージェントのワークフローを構築するAgent Designerのデモは、本当に見応えがあり、実際にA2Aのライフサイクル全体が動いていることを示しています。
最後に
あらゆる大きなプラットフォームの転換は、プロダクトではなくプロトコルによって引き起こされてきました。WebはNetscapeによって作られたわけではありません——HTTPによって作られました。モバイルはiPhoneによって定義されたわけではなく——LTEによって可能になりました。クラウドコンピューティングはAWSによって生み出されたのではなく——APIとOAuthによって支えられました。
エージェント型の時代も同じでしょう。そしてA2Aは、それを可能にするプロトコルです。
Google Cloud Next ’26は派手なデモや大型の提携で満載でした。ですが、彼らが出荷した中で最も重要なのは、許可なくどのベンダーにも頼らずにAIエージェント同士が連携できる、退屈なくらい堅実で美しいオープンなプロトコルだったのです。
注目すべきは、まさにそれです。まさにそこに基づいて作る価値があります。
あなたの見立てはどうですか？ A2Aは、私が思うほどのゲームチェンジャーなのでしょうか、それとも私は言い過ぎでしょうか？ すでにこのプロトコルで作ってみたことはありますか？ コメントであなたの経験をぜひ聞かせてください。
