A2Aプロトコルで異なるAIエージェント基盤は本当に連携できるか

複数のクラウドベンダーが提供するAIエージェント基盤を組み合わせて使いたい、と考えたことがあるエンジニアに向けた内容です。Google、AWS、Microsoftはそれぞれ独自のエージェント開発フレームワークを持っていますが、これらを横断して連携させる際に何を判断材料にすればよいかを整理します。

近年、AIエージェント（自律的にタスクを実行するAIプログラム）を実装するためのフレームワークが各クラウドベンダーから出そろいました。Googleの「ADK」、AWSの「Strands Agents」、Microsoftの「Agent Framework」です。これらが共通して採用し始めているのが「A2A（Agent2Agent）」というオープンプロトコルです。

A2Aは、異なるチームや異なるフレームワークで作られたエージェント同士が呼び出し合うための通信規格です。エージェントは/.well-known/agent-card.jsonというURLに自分の機能を記述したカード（agent card）を公開し、HTTP上でJSON-RPCという形式を使ってやり取りします。プロトコル自体はA2Aの公式サイトが「相互運用性の決定的な共通言語」と説明しているとおり、通信手順としてはすでに標準化が進んでいます。

ただし、通信規格が同じであることと、実際に3つのクラウドのエージェントを組み合わせて安定運用できることは別問題です。ここでは、複数クラウドのエージェント基盤を混在させて使う場面を想定し、判断すべき軸を整理します。

どんな場面でこの判断が必要になるか

典型的なのは、社内で複数クラウドを使っている組織が、既存のAI投資を無駄にせずエージェント連携基盤を構築したいケースです。

たとえば検索・要約を担当するエージェントはGoogleのGemini系モデルで動かし、社内データ処理はAWS Bedrock上のエージェントに任せ、両者をMicrosoft Foundry上の調整役エージェントがオーケストレーション（複数の処理を統括・調整すること）する、といった構成です。A2Aが「共通言語」であるなら理論上は可能ですが、実際に検証する際に見るべきポイントがいくつかあります。

判断軸1: ネイティブツールの有無

エージェントに検索機能などのツールを持たせる際、各フレームワークが標準で用意しているツールの充実度には差があります。

GoogleのADKはすぐ使える検索ツールを同梱していますが、MicrosoftのAgent FrameworkはSupportsWebSearchToolというインターフェースを公開しているだけで、これは「チャットクライアントが宣言できるプロトコル」であり、エージェントにそのまま渡せる完成品のツールではありません。Foundry自体のグラウンディング機能（外部情報に基づいて回答精度を高める仕組み）を使うにはBingリソースとの接続を別途用意する必要があります。AWSのStrandsに至ってはツールを一切同梱していません。

この差を無視して「各社ネイティブの検索機能」で比較すると、Google検索、Bing、検索なしという3種類の異なる検索プロダクトを比べることになり、モデルの性能差なのか検索の質の差なのか切り分けられなくなります。公平な比較検証をしたいなら、3クラウドに同一の検索関数を持たせて条件をそろえる必要があります。自社で導入検証する際も、まず各フレームワークの公式ドキュメントで「標準搭載ツールは何か」「外部ツールをどう束縛するか」を確認するのが最初の一歩です。

判断軸2: ツールの束縛方法（フレームワークの設計思想）

3つのフレームワークは、モデルにツールをどう結びつけるかという設計が異なります。

GoogleのADKはLlmAgentというクラスにツールを渡す構成、AWSのStrandsはAgentクラスにツールを渡す構成、MicrosoftのAgent Frameworkも同様にAgentクラスを使いますが、A2A対応させる際の橋渡し方法が異なります。ADKはto_a2a()という関数でA2A化でき、AWS側はa2a-sdkのリファレンス実装ルートを使い、Microsoft側はA2AExecutorという実行クラスを介します。

この部分は、A2Aという共通プロトコルの「外側」にある各社固有の実装であり、移行や併用を考える際に学習コストとして直接効いてきます。

判断軸3: ホスティング環境と実行モデル

実際に動かす場所も各社バラバラです。

GoogleはCloud Run（us-central1）、AWSはBedrock AgentCore(us-west-2)、MicrosoftはContainer Apps(westus2)という構成が確認されています。いずれもサーバーレスまたはコンテナベースの実行環境ですが、リージョン設計・課金体系・スケーリング挙動はサービスごとに異なります。複数クラウドを跨いだレイテンシやコストを検証したい場合、この環境差が結果に影響することを前提に置く必要があります。

判断軸4: モデルの違いを切り分けられているか

検証で使われたモデルは、Googleがgemini-2.5-flash、AWSがus.amazon.nova-micro-v1:0、MicrosoftがFoundry上のgpt-5-miniです。

モデル自体の性能差と、フレームワーク・プラットフォームの差を混同しないことが重要です。指示文（プロンプト）のバージョン、スコアリング基準、失敗時の分類方法（failure taxonomy）まで含めて条件を揃えないと、「Aクラウドのほうが優れている」という結論が実はモデルの違いにすぎない、という誤読が起こります。自社で比較検証を組む際は、変数を1つずつ切り分ける設計を最初に決めておくことをおすすめします。

選択肢の比較

ケース別の推奨

既存のクラウド資産がGoogle中心で、検索を伴うエージェントをすぐ動かしたいなら、ADKの同梱ツールを使うのが早道です。実装コストが最も低く、A2A化もto_a2a()という1関数で済みます。

AWSのBedrockを既に本番運用しており、他社エージェントを部分的に呼び出したいだけなら、StrandsをA2Aのクライアント役として組み込み、検索などのツールは自前で用意する前提で設計するのが現実的です。

Microsoft 365やAzure ADの認証基盤に依存した社内システムと連携させたいなら、Foundry上のAgent Frameworkを調整役（コーディネーター）に据え、GoogleやAWSのエージェントをA2A経由のサブエージェントとして呼び出す構成が検討に値します。ただしBingリソースとの接続作業が別途発生する点は見積もりに入れておくべきです。

あえて見送るべき条件

一方で、次のような条件では複数クラウドの混在構成を急いで採用する必要はありません。

• 検索ツールなど各社の「ネイティブ機能」の性能差自体を比較検証する目的がある場合(条件を揃えないと結論が歪みます)
• 単一クラウド内で完結できる要件しかなく、他社エージェントを呼ぶ理由が特にない場合
• チームがA2AやJSON-RPCといった基盤技術の学習コストを割けない場合
• 本番環境でのSLA(サービス品質保証)要件が厳しく、3つの異なるホスティング環境の可用性をまたいで保証する体制がまだない場合

導入前に確認すること

A2Aプロトコル自体は各社が足並みを揃えて実装しつつあり、通信レベルの相互運用性は実現されています。

ただし実運用に踏み出す前に、以下を最低限チェックしておくと判断がぶれません。

• 各フレームワークの公式ドキュメントで標準搭載ツールとツール束縛APIの違いを確認する
• 自社で使いたいモデルとフレームワークの組み合わせがどのホスティング環境で提供されているか調べる
• 比較検証をする場合は、プロンプト・スコアリング基準・失敗分類を先に固定し、変えるのはフレームワークだけにする
• A2A化の実装コスト(to_a2a()、a2a-sdk、A2AExecutorのいずれか)を実際に小さなPoC(概念実証)で試してみる

まずは1つの小さなエージェントをA2A化し、agent-card.jsonが正しく公開されるかを確認するところから始めるのが、無理のない第一歩です。