Googleは2026年6月17日にAgentic Resource Discovery（ARD） specificationを発表しました。これは、Web上に散在するツール、スキル、エージェントを、組織のドメインにひもづく形で公開し、見つけ、検証するための共通仕様です。生成AIの導入が進むほど、社内エージェントは自社ツールだけで完結せず、他部門や他社のAI資産に安全につなぐ必要があります。今回の論点は新しいプロトコルが増えたことではなく、発見と信頼確認の層が整理され始めた点にあります。
特に企業実務では、A2Aで仕事を委譲できても、どの相手を信頼して呼び出すか、MCPサーバーやOpenAPIツールを誰がどの条件で配布するかが運用のボトルネックでした。GoogleはARDをGemini Enterprise Agent PlatformのAgent Registryにも接続していく方針を示しており、単なる概念説明ではなく、今後の社内エージェント基盤に直結する話として捉えるべきです。
Agentic Resource Discoveryとは何か
ARDは、AI capabilitiesを公開、検索、検証するためのopen specificationです。Googleの説明では、公開対象にはMCP servers、A2A agents、OpenAPI tools、さらに別のcatalogまで含められます。重要なのは、個別ベンダーの管理画面の中だけで閉じるのではなく、組織自身のドメイン配下にcatalogを置き、その所有権を信頼の起点にすることです。
公式ブログでは、ai-catalog.jsonをwell-known pathで公開し、registryがそれをcrawlしてindexし、agentのdiscovery requestに応じて候補と検証用メタデータを返す流れが示されています。つまりARDは、実行そのものを担う規格ではなく、どこに何があり、誰が出しているかを確かめるための発見レイヤーです。
何が変わるのか: catalog、registry、direct fetchの3層
実務で押さえたい変化は3つあります。1つ目はcatalogです。各組織が自社ドメインで自分たちのAI資産を定義できるため、配布主体が明確になります。2つ目はregistryです。複数組織のcatalogを横断して検索できるので、部門別にばらけたエージェントやツールを一覧性のある形で見つけやすくなります。3つ目はdirect fetchです。すでに信頼済みの取引先や自社グループ会社なら、検索を経由せず直接catalogを取得できます。
この構造は、社内ポータルで人がSaaSを探す体験に近い一方で、相手は人ではなくagentです。従来は『Slack bot一覧』『MCPサーバー一覧』『各部署の非公式ドキュメント』が別々に存在し、更新漏れや権限不整合が起きがちでした。ARDが機能すると、発見の入口を標準化しつつ、接続先ごとに信頼情報を引き渡せるため、運用の属人化を減らせます。
A2A、MCP、OpenAPIとの違い
A2Aはagent同士が仕事をhand offし、対話し、必要なら確認質問まで返すための協調プロトコルです。Googleは2026年6月18日のA2A記事で、black box handoff、context windowの分離、専門エージェント同士の協調を強調しました。一方MCPは、モデルやagentが外部ツールやデータ源を呼び出す接続方式として使われます。OpenAPIはさらにAPI記述寄りで、決まった入出力を呼ぶのに向いています。
ARDはそれらの上位で『何を見つけるか』を扱います。A2Aが会話の方法、MCPやOpenAPIが接続の方法だとすれば、ARDは発見と検証の方法です。だから企業が今考えるべき順番は、1. 何をcatalog化するか、2. どの資産を検索可能にするか、3. 実行時はA2A/MCP/OpenAPIのどれでつなぐか、の順になります。これを混同すると、プロトコル導入だけ進んで棚卸しやガバナンスが追いつきません。
Gemini Enterprise Agent Platformで見る判断基準
GoogleはARDをGemini Enterprise Agent PlatformのAgent Registryへ持ち込む方針を示しています。公式説明では、このRegistryはagents、skills、MCP servers、other toolsをsearch、discover、hostでき、さらにglobally unique namespaced URNsの付与、agentic egress policiesの適用、toolsやspecificationsのpinningを担うとされています。ここは導入判断で見逃せません。検索のしやすさより、誰が何を外へ呼び出せるかを中央で制御できるかが企業価値だからです。
同時に注意点もあります。Googleはnative support for ARD will be available in the coming monthsと述べており、6月21日時点で全面提供済みとは確認できません。したがって、今すぐ大規模移行を決めるより、既存の社内エージェント一覧、利用中のMCPサーバー、外部委託したA2A連携候補を棚卸しし、将来registryへ載せやすい単位で整理する方が現実的です。
社内導入前に確認したい5つのチェックリスト
第1に、catalog化の単位を決めることです。部署ごと、プロダクトごと、共通基盤ごとのどれで公開するか曖昧だと、後から重複登録と責任分界の問題が出ます。第2に、検索対象と非公開対象を分けることです。すべてのagentを社内検索可能にすれば便利ですが、規制業務や個人情報に触れる資産はdirect fetch限定にした方が安全です。
第3に、実行方式を統一しすぎないことです。会話型の委譲はA2A、ツール呼び出しはMCP、既存業務APIはOpenAPIというように、役割で分ける方が管理しやすくなります。第4に、egress policyとpinningの責任者を明確にすることです。外部へ出る先や許可バージョンを決めないままregistry化すると、見つけやすさだけ増えて統制が弱まります。第5に、FAQと例外運用を先に用意することです。新しい発見基盤は『見えるのに使えない』問い合わせが増えやすいため、申請経路と審査基準を最初から書いておくべきです。
HelloCraftAIでは、社内エージェントの棚卸し、MCP/A2A/OpenAPIの役割整理、公開前のガバナンス設計まで支援しています。Agent Registry導入前に『どの資産を見つけられるようにするか』『どこまで検索させるか』を詰めたい場合は、 お問い合わせください 。
FAQ
Q. ARDがあればA2AやMCPは不要ですか。A. 不要にはなりません。ARDは発見と検証の層であり、実行や会話の層ではないためです。Q. いま始めるなら何を準備すべきですか。A. まず社内のagent、skills、MCP servers、API連携を棚卸しし、公開可否、所有者、外部接続条件を表にするのが近道です。Q. Google製品だけの話ですか。A. 公式にはunderlying framework、protocol、providerを問わず共有できる仕様として説明されており、Googleは自社基盤への搭載を進めつつもopen specificationとして公開しています。
