6月19日、Search Engine Journalが「Google, Microsoft Back Draft AI Agent Discovery Spec」と題した記事を公開した。GoogleやMicrosoft、GitHubら11社が共同でAIエージェント向けのツール発見仕様「ARD（Agentic Resource Discovery）」のドラフトを6月17日に公開したことを報じている。注目すべきは、仕様の公開と同日に複数の参加企業が動作する実装をリリースした点だ。AIエージェントが外部ツールを「発見できない」という構造的な課題を、業界横断の標準化によって解決しようとする試みであり、MicrosoftとGoogleがそれぞれ異なる角度からこの仕様を下支えしている。
AIエージェントの「ツール発見問題」を標準化で解決へ
現在のAIエージェントは、利用するツールやAPIをあらかじめハードコードして接続する必要がある。企業が独自のツールやMCPサーバー（Model Context Protocol）を次々と公開していく中、この「事前配線」モデルはスケールしなくなりつつある。MCPとは、AIモデルが外部ツールやデータソースと標準的なインターフェースを通じてやり取りするためのプロトコルであり、近年エージェント基盤として急速に普及している。
この問題に対処するため、Google・Microsoft・GitHub・Hugging Faceを含む11社が、Agentic Resource Discovery（ARD）と呼ばれるオープン仕様のドラフトを6月17日に公開した。ライセンスはApache 2.0で、Linux Foundation傘下のワーキンググループが管理するAI Catalogデータモデルをベースにしている。
参加企業にはCisco、Databricks、GoDaddy、NVIDIA、Salesforce、ServiceNow、Snowflakeも名を連ねる。
ARDの仕組み：カタログとレジストリの2層構造
ARDはカタログ（catalog）とレジストリ（registry）の2つのコンポーネントで構成される。
- カタログ：各組織が自ドメイン上の決まったパスに
ai-catalog.jsonファイルを配置し、提供するツール・MCPサーバー・エージェント・APIの一覧を記述する。 - レジストリ：カタログをクロールしてインデックス化し、エージェントからの発見リクエストに自然言語で応答する。
カタログが各パブリッシャーの自ドメイン上に置かれるため、ドメイン所有権が発行元の検証手段となる。本番環境向けには信頼メタデータを付与し、エージェントやレジストリが接続前に発行元の暗号学的な同一性を確認できる仕組みも用意されている。ケイパビリティが選択された後は、ARDはハンドオフし、エージェントはそのツール固有のプロトコルで直接接続する。
仕様公開と同日に複数の実装が登場
注目すべきは、仕様の公開当日に複数の参加企業が動作する実装をリリースしたことだ。
- **GitHub**：GitHub Copilot向けに「Agent Finder」を導入。選択したレジストリからMCPサーバー・スキル・ツール・エージェントを発見でき、接続するものはユーザーが制御する。
- **Hugging Face**：ARDサービス全体にわたってスキルとMCPサーバーを検索できる「Discover Tool」を公開。
- Cisco：ARDをLinux Foundation傘下のオープンソースプロジェクト「AGNTCY Agent Directory」に紐付けた。
また、Googleはこの2日前に、AIシステム間で組織知識を共有するための仕様「Open Knowledge Format」を公開している。これらの一連の動きに共通するパターンは、「自ドメイン上に構造化ファイルを置き、AIシステムが手動の配線なしに利用できるようにする」というものだ。
GoogleとMicrosoftそれぞれの立ち位置
Googleの役割はGemini Enterprise Agent Platformの一部である「Agent Registry」を中心とする。同社はAgent Registryがエンタープライズガバナンスを担いながらエージェンティックリソースをホストおよび検索すると説明している。ただし、ARDのネイティブサポートは数ヶ月後に予定されており、現時点では未稼働だ。ARDはGoogle Searchの機能ではなく、あくまでも仕様である点も強調されている。
Microsoftの役割は、エージェント開発基盤であるAzure AI Foundryを通じた支援に重点が置かれる。MicrosoftはARDを、Azure AI Foundryエコシステム上でエージェントやツールが相互に発見・接続できる仕組みの標準として位置づけており、同社のエンタープライズ向けAIエージェント戦略との整合を図っている。GitHubを傘下に持つMicrosoftが、GitHub Copilotの「Agent Finder」という形でARDの初期実装を即日公開した点も、同社の本仕様への積極的な関与を示すものだ。両社がそれぞれ異なるプロダクト基盤からARDを支持することで、仕様の業界標準としての重みが増している。
「今すぐ対応すべきか」という問いへの答え
ARDが対象とするのは、ツールやMCPサーバー、エージェントを外部に公開している企業だ。そうした企業にとっては、エージェントに発見・信頼される明確な方法が手に入る。一般的なコンテンツサイトにとっては、現時点で取るべき具体的なアクションは存在しない。
GoogleのJohn Muellerは以前、llms.txt のようなファイルについて「LLMシステムがサイトを区別するために使えるわけではない」と指摘し、将来のエージェント向け戦略より現在のニーズにフォーカスすべきと述べている。ARDもコンテンツではなくツールとエージェントを対象にしており、「まだ存在しないかもしれないトラフィックのために今から構築すべきか」という疑問は残る。
現状と今後
ARDは現在v0.9のドラフトであり、プロジェクトのGitHubリポジトリを通じてフィードバックを受け付けている。仕様の有効性は、カタログを大規模にクロール・インデックス化できるレジストリのエコシステムにかかっており、その整備はまだ初期段階にある。実利を得るのは主に、他社が必要とするツールやエージェントを提供している企業になる見通しだ。
詳細はGoogle, Microsoft Back Draft AI Agent Discovery Specを参照していただきたい。
