AIエージェントの提案書に「A2A対応」と書いてあったとして、それが何を約束しているのかを、発注側は書面から判断できるだろうか。
2026年8月17日、AIエージェント同士が通信するための標準である Agent2Agent（A2A）が、Agentic AI Foundation（AAIF）のホステッドプロジェクトになったと発表された。同じ8月17日、GoogleはGemini Enterpriseのリリースノートで、A2UIおよびA2Aのエージェント登録機能を一般提供（GA）に切り替えたことを公表している。片方は標準の統治の話、もう片方は製品での実装の話である。
この2つが同じ日に動いたことには、発注側にとっての実務的な意味がある。
この記事を読むべき人
- AIエージェントの導入をこれから検討する会社
- 提案書に「マルチエージェント」「エージェント連携」と書かれていて、意味が判然としない会社
- 特定のAIベンダーに囲い込まれることを避けたい経営者
- 既に複数のAIツールを導入していて、それらが連携していない会社
- 取引先や業務委託先のシステムとAIで連携する構想がある会社
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
まず正確に押さえる：A2Aは今回初めて中立化されたわけではない
誤解しやすい点から先に潰しておく。
AAIFの発表によれば、A2Aは2025年4月にGoogleが立ち上げ、AWS、Cisco、Google、Microsoft、Salesforce、SAP、ServiceNowといった創設組織とともにLinux Foundationへ寄贈されている。つまりA2Aは以前からLinux Foundationのプロジェクトだった。2025年8月にはIBMのAgent Communication ProtocolがA2Aへ統合されたことも記されている。
今回起きたのは、そのA2Aが、同じくLinux Foundationがホストする Agentic AI Foundation の下に集約されたということである。AAIFにはすでに他のプロジェクトが置かれており、そこへエージェント間通信の層が加わった形になる。
「今回初めて中立の団体に移った」という説明を受けたら、それは正確ではない。 提案の前提が事実と合っているかを見る、ひとつの目安になる。
AAIFが示した5つの層
AAIFの発表は、各プロジェクトが担う層を明示している。これは発注側にとって、いま議論している内容がどの層の話なのかを切り分けるための地図になる。
横にスクロールして確認できます
| 層 | プロジェクト | 担う役割 |
|---|---|---|
| 指示とコンテキスト | AGENTS.md | プロジェクトの期待、規約、運用指示をAIエージェントへ伝える形式を標準化する |
| エージェントの実行環境 | goose | エージェントが推論し、計画し、機能を呼び出し、作業を遂行する環境を提供する |
| エージェントとツールの接続 | MCP | エージェントがツール、データソース、アプリケーション、サービスへ接続し相互作用する方法を標準化する |
| 通信の仲介と制御 | agentgateway | エージェントシステムと稼働基盤の境界に位置し、ルーティング、ポリシー、可観測性を管理する |
| エージェント間の相互運用性 | A2A | 独立したエージェントが互いを発見し、通信し、タスクを委任し、システムや組織の境界を越えて結果を交換する方法を標準化する |
この表を提案書と突き合わせると、話が噛み合っていない箇所が見つかることがある。 よくあるのは、ツールへの接続の話をしているのにエージェント間連携の用語で説明されている、あるいはその逆である。
切り分けの軸は「誰が持っているか」ではなく「相手が何か」である。 相手がツール、データソース、アプリケーション、サービスであればMCPの層。相手が独立して判断するエージェントであればA2Aの層。この区別は組織の内外とは無関係で、自社内の独立したエージェント同士のやり取りもA2Aの層に属する。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
A2Aが実際にやっていること
A2Aの仕組み自体は、発表の説明を読むと単純である。エージェントは「エージェントカード（agent card）」を公開する。これは自分が何をできて、どうやって到達できるかを構造化して記述したものである。他のエージェントはそのカードを読んで能力を発見し、人間が仲介しなくてもタスクを委任する。やり取りは構造化されており、観測可能で、フレームワークに依存しない、と説明されている。
発表は、この標準が生まれた理由も率直に書いている。サプライチェーンや金融サービスの現場でマルチエージェントを本番投入したとき、異なるフレームワークで作られたエージェント同士は、その組み合わせ専用の統合コードを書かないと作業を引き渡せなかった。新しい取引先が増えるたびに同じ統合作業が最初から発生する。コストはエージェント本体ではなく、その間の統合にあった、という記述である。
この一文は、日本の中堅企業にとってもそのまま読める。 AIツールを部門ごとに導入した結果、それぞれが独立して動き、間をつなぐのは人間、という状態は珍しくない。つなぐ作業を人間がやっている限り、ツールを増やすほど手間が増える。
安定版の仕様であるA2A v1.0は2026年3月に公開されている。複数プロトコルへの対応とバージョンの折衝、マルチテナンシー、そして暗号的な同一性検証のための署名付きエージェントカードが追加されたとされる。署名付きエージェントカードは、企業間で連携する場合に効いてくる項目である。
「A2A対応」を4段階で確認する
ここからはGXOが提案書を読むときに使っている切り分けである。標準を定めた団体やベンダーが推奨しているものではない。
「A2A対応しています」という説明は、実際には次のどれかを指している。どれなのかを確認しないと、期待と成果物がずれる。
段階1：仕様に準拠したエージェントカードを用意できる。 自社のエージェントの能力と到達方法を、A2Aの形式で記述できる状態。誰に見せるかは別の設定であり、社内限定でも成立する。最も基本的な意味での「対応」である。
段階2：主要プラットフォームにエージェントとして登録できる。 今回GoogleがGemini Enterpriseで一般提供に切り替えたのは、まさにこの部分である。リリースノートには、管理者がA2UI（Agent to UI）を使って独自のインターフェースを構築し、A2AプロトコルでGemini Enterpriseと通信するエージェントを登録・管理できるようになったこと、この機能が公開プレビューから一般提供へ移行したこと、A2UIのv0.8に加えてv0.9に対応し、v0.9では新しいMaterial Designベースのコンポーネントカタログが利用できることが記されている。
段階3：自社の業務でタスクの委任が成立している。 仕様に準拠していることと、実際に業務が流れることは別である。「委任した結果が正しいかを誰が確認するか」が決まっていなければ、本番では使えない。
段階4：他社のエージェントとの連携実績がある。 発表によれば、A2AはGoogle CloudのADK、Agent Engine、Cloud Run、GKEで開発・展開が可能とされ、Microsoft Azure AI FoundryではエージェントがA2Aのエンドポイントを公開し標準的な発見手順で外部エージェントを見つけられるとされ、AWS Bedrock AgentCoreはA2Aサーバーをホストして運用できるとされている。ただし、これは基盤側が対応しているという事実であって、自社の案件で連携が成立した実績とは別である。
提案書に「A2A対応」とだけ書かれている場合、それがどの段階を指すのかは書面からは判別できない。 段階3や段階4を期待したまま発注すると、稼働後に差が出る。どの段階なのかを聞き、回答を書面に残しておきたい。
発注前にベンダーへ投げたい質問
以下はGXOが実際に使っている質問である。
質問1：今回の構成で、A2AとMCPはそれぞれどこに使われますか。 どちらの層に何を割り当てたのかを、図か文章で示してもらう。両方の名前が出てくるのに使い分けを説明できない場合は、構成がまだ具体化していないと考えたほうがよい。
質問2：当社のエージェントカードには何を書き、どの方式で見せますか。 エージェントカードは能力と到達方法を記述したものだが、それを常に一般公開するとは限らない。 A2Aの仕様文書は、発見の方式として、既知のURIに置く方法、選別されたレジストリに登録する方法、そして直接設定によるプライベートな発見の3つを挙げており、エージェントカードを保護する方法についても別に記述している。したがって、何を書くかと、誰に見せるかは、それぞれ自社が決める項目である。ベンダー任せにしてよい部分ではない。
質問3：他社のエージェントへタスクを委任した結果は、誰がどう検証しますか。 委任は便利だが、結果の妥当性を確認する仕組みがなければ、誤りがそのまま業務に流れる。
質問4：将来、別のプラットフォームへ移す場合、どこまでが作り直しになりますか。 標準に沿っていれば移行が容易になる、という説明で終わらせず、具体的にどの部分が残り、どの部分が作り直しかを聞く。
質問5：この提案のうち、今日すでに一般提供されている機能はどれで、プレビュー段階のものはどれですか。 今回のGemini Enterpriseのように、公開プレビューから一般提供へ移る節目がある。提案時点でどちらだったかは、後から効いてくる。
標準が固まることの本当の利点
AAIFの発表は、中立的な統治が必要な理由をこう説明している。基盤となる構成要素が単一のベンダーに所有されている場合、下流のチームはすべてそのベンダーのロードマップとリリース周期の制約を引き受けることになる。開かれた形で統治されていれば、何がいつ作られるかをコミュニティが形づくる。
A2Aの150を超えるパートナー組織には、直接の競合関係にある企業が含まれているとも書かれている。その広がりは、どの参加者も単独では支配できない統治の下でしか維持されない、という説明である。
発注側にとっての読み方はこうである。 標準に沿った作りにしておく価値は2つある。ひとつは、発表が冒頭で述べているとおり、組み合わせごとに専用の統合コードを書く手間と費用を減らせること。もうひとつが、依存先の事業判断に自社の将来が左右されにくくなることである。 前者は開発費の議論、後者は契約とリスクの議論に属する。提案書で語られやすいのは前者だが、経営として効いてくるのは後者である。
よくある質問
Q. 当社はまだAIエージェントを導入していない。今回の話は関係あるか。 A. 導入前のほうが効く。すでに作ったものを後から標準に合わせる場合、設計の見直しと作り替えが発生する余地がある。提案を受け取る前に、上記の質問を用意しておきたい。
Q. A2Aに対応していないAIツールは選ぶべきでないのか。 A. そうとは限らない。単独で完結する業務であれば、連携の標準は必要ない。判断すべきは、そのツールが扱う業務が、将来ほかの仕組みと連携する見込みがあるかどうかである。
Q. 他社のクラウドを使っている場合はどうか。 A. 判断材料になる。AAIFの発表によれば、Microsoft Azure AI FoundryとAWS Bedrock AgentCoreもA2Aに対応している。特定製品の採用可否とは別に、主要な基盤が揃って同じ標準を扱うようになったこと自体が、発注の前提として使える。
Q. エージェントカードを公開すると、社外に情報が漏れないか。 A. 一般公開が唯一の方式ではない。A2Aの仕様文書は、既知のURIに置く方式のほかに、選別されたレジストリを使う方式と、直接設定によるプライベートな発見を挙げている。カード自体は能力と到達方法を記述するもので、業務データを載せる場所ではない。それでも「何ができるか」自体が競争上の情報になり得るため、どの方式を採るかは発注時に決めておきたい。
Q. 技術の当否を判断できる人が社内にいない。 A. 技術的な優劣を判定する必要はない。5つの質問への回答が具体的かどうかは、専門知識がなくても見分けられる。「対応しています」で止まる回答と、層と段階を分けて説明する回答では、情報量がまったく違う。
Q. 標準はまた変わるのではないか。 A. 変わる可能性はある。だからこそ、標準そのものより「切り替えられる作りになっているか」を契約で確認するほうが実益がある。
提案書に「A2A対応」と書いてあったら
論点になるかどうかを決めるのは、導入する数でも社内外の別でもなく、通信の相手が何かである。ツールやデータだけを相手にする構成なら優先度は下がる。だが相手が独立して判断する別のエージェントなら、それが自社内にあっても社外にあっても、1つ目から確認の対象になる。
手元に提案書があるなら、本稿の4段階と5つの質問をそのまま当てて読んでみてほしい。段階1までしか書かれていないのに段階3や段階4を期待していた、という食い違いは、稼働後ではなく契約前に見つけるべきものである。読み合わせに第三者を入れたいときは、提案内容の点検を承っている。
まだ提案を受け取る前の段階であれば、順序が違う。自社側で決めておく事項はAIエージェント導入前チェックリストに並べてある。そもそも自社の業務に適用余地があるかはAI導入前チェックで見る。そのうえで、どの業務にエージェントを置き、どの層をどう組むかをAIエージェントで詰めていく形になる。社内のデータやシステムを参照させる設計が絡むならエンタープライズRAG、権限とログの運用ルールまで含めるなら生成AIガバナンスが該当する。
ロックインを避けるRFPの書き方はMCPとA2Aを含むRFP要件、プラグインの可搬性についてはプラグインの可搬性とベンダーロックインで扱っている。本稿は、標準の統治が集約されたことと、プラットフォーム側の実装が一般提供になったことを、発注判断としてどう読むかに絞っている。
参照した情報
- Agentic AI Foundation「A2A joins AAIF's open agentic stack」（2026年8月17日公開）: https://aaif.io/blog/a2a-joins-aaif
- Google Cloud「Gemini Enterprise release notes」（2026年8月17日の項）: https://docs.cloud.google.com/gemini/enterprise/docs/release-notes
- A2A 仕様およびSDK: https://a2a-protocol.org/latest/
- A2A「Agent Discovery in A2A」: https://a2a-protocol.org/latest/topics/agent-discovery/
A2AがAAIFのホステッドプロジェクトになった旨、150を超える組織に支持されている旨、2025年4月にGoogleが立ち上げLinux Foundationへ寄贈した旨と創設組織名、2025年8月にIBMのAgent Communication ProtocolがA2Aへ統合された旨、A2A v1.0が2026年3月に公開され複数プロトコル対応とバージョン折衝・マルチテナンシー・署名付きエージェントカードが追加された旨、エージェントカードの仕組み、統合コストに関する説明、AAIFの5つの層とそれぞれの役割、Google Cloud・Microsoft Azure AI Foundry・AWS Bedrock AgentCoreにおける対応状況、および中立的な統治に関する説明は、上記AAIFのページを取得して確認した。
エージェントカードの発見方式として、既知のURIに置く方法・選別されたレジストリを使う方法・直接設定によるプライベートな発見の3つが挙げられている旨、およびエージェントカードを保護する方法が別に記述されている旨は、上記のA2A「Agent Discovery in A2A」を取得して確認した。
Gemini EnterpriseでA2UIおよびA2Aエージェントの登録が一般提供になった旨、公開プレビューからの移行である旨、A2UI v0.8に加えてv0.9へ対応した旨、およびv0.9が新しいMaterial Designベースのコンポーネントカタログに対応する旨は、上記リリースノートの2026年8月17日の項を取得して確認した。
「A2A対応」を4段階に分ける見方、層の切り分け、5つの質問——いずれもAAIF、Linux Foundation、Googleが提示した枠組みではない。 AIエージェントの発注支援を通じてGXOが独自に組み立てた読み方である。製品の採用可否を示す記事でもない。発表にはHuawei、Tencent、PayPalの事例が記載されているが、いずれも海外の事例にとどまり、国内の普及状況を測る材料にはならないため、判断には用いていない。
