AIエージェントが使えるツールは増え続けていますが、どこに何があるかを探す仕組みはバラバラのままです。2026年6月17日、GoogleとMicrosoft、GitHubほかがAgentic Resource Discovery（ARD）というオープン仕様を公開し、MCPサーバーやスキル、エージェントの発見と検証を共通化する動きが始まりました。
この記事では、ARDが解決しようとしている課題と仕組み、GitHub CopilotのAgent Finder、GoogleのGemini Enterprise向け対応を整理します。
この記事でわかること
- ARDが標準化する「探索レイヤー」の役割
ai-catalog.jsonとレジストリによる発見の流れ- GitHub Copilot Agent Finderの使い方と制御方法
- 既存の手動接続やMCPとの違い
分散したレジストリが抱える課題
MCP（Model Context Protocol）は、AIが外部ツールやデータに接続するためのプロトコルです。A2A（Agent-to-Agent）は、エージェント同士が連携するための仕様です。どちらも実行の仕組みとしては整いつつありますが、利用可能なリソースを探す段階は別問題です。
Microsoftの技術解説では、コーディングエージェントの例が示されています。GitHub Copilotを新規インストールした状態では、組み込みツールは少数です。慣れた開発者でも接続できるのは数十件程度にとどまります。一方、公開リポジトリや社内に散在するエージェント向けリソースは数十万規模に達し、日々増え続けています。
各AIクライアントは、あらかじめ接続されたリソースしか使えません。名前とURLだけでは、何ができるか、誰が提供しているか、組織のポリシーに合うかを判断できません。その結果、MCPサーバーやスキル、エージェントをワークフローごとに手動で配線し直す作業が発生します。コンテキストウィンドウにも、使わないツールの説明が詰め込まれやすくなります。
ARDが追加する探索レイヤー
ARDは、こうした「発見」の問題に特化した仕様です。実行ランタイムでも、MCPやAPIの代替でもありません。エージェントが接続する前に、どのリソースを使うべきかを探し、信頼できるかを確認するための共通レイヤーです。
仕様はApache 2.0で公開され、現行版はv0.9（Draft）です。Linux Foundation傘下のAI Catalog Working Groupが策定したAI Catalogデータモデルを土台にしています。共同開発には、Microsoft、Google、GitHub、GoDaddy、Hugging Faceに加え、Cisco、Databricks、Nvidia、Salesforce、ServiceNow、Snowflakeが名を連ねています。
Google Developers Blogの説明では、ARDが答える3つの問いが挙げられています。正しい機能はどこにあるか、どれを選ぶべきか、接続して安全かです。これらを組織の境界を越えて解決するのが目的です。
カタログとレジストリの仕組み
ARDの中心は2つの要素です。
カタログは、組織が自社ドメイン上に公開するリソース一覧です。提供者は/.well-known/ai-catalog.jsonにマニフェストを置き、MCPサーバー、A2Aエージェント、OpenAPIツール、スキル、ネストしたカタログなどを記述します。ドメイン名そのものが信頼の起点となり、各エントリにはurn:ai:ドメイン名:...形式のURN（Uniform Resource Name）が付きます。
レジストリは、公開されたカタログをクロールして索引化する検索エンジンです。エージェントは自然言語の意図をPOST /searchで送り、関連度順にマッチしたリソースを受け取ります。既知のパートナードメインからカタログを直接取得する経路もあります。
本番環境では、発見結果に暗号学的な信頼メタデータ（trust manifest）が付きます。クライアントは接続前に発行者の身元を検証できます。認証や実行そのものは、各プロトコル側に委ねられます。
GitHub CopilotのAgent Finder
GitHubはARDの参照実装としてAgent FinderをCopilotに組み込みました。2026年6月17日に全Copilotプランで利用可能になっています。
使い方はシンプルです。タスクを自然言語で書くと、Agent Finderが選択したレジストリ内のAIリソースを検索し、関連度の高い候補を返します。Copilotは必要なときだけ選んだリソースをコンテキストに取り込みます。
レジストリは利用者が選びます。GitHubがキュレーションした公開カタログを使うことも、社内のプライベートレジストリを指すこともできます。検索結果は指定したソースに限定されます。
企業向けには、Copilotの管理設定でエージェントが発見・利用できるリソースを制限できます。Agent Finderは許可されたものだけを表示します。また、ツールの自動インストールや自動接続は行いません。候補を見つけて提示するまでがAgent Finderの役割で、実際に配線するかは利用者が決めます。
同時期に、Copilot BusinessおよびCopilot Enterpriseでは、CLIやVS Codeが権限プロンプトを自動でスキップする動作を管理者が止められる設定も追加されています。.github-privateリポジトリ経由で配布され、Copilotが自動的に適用します。
Google Gemini Enterpriseの対応
Google Cloudは、Gemini Enterprise Agent Platform内のAgent RegistryでARDの思想を製品化しています。エージェント、スキル、MCPサーバーなどを検索・発見・ホストする基盤です。
企業向け機能として、グローバルに一意な名前空間付きURN、エージェントの外向き通信ポリシー（egress policy）、ツールや仕様のピン留めが挙げられます。Agent IdentityがARDのtrust manifestを検証し、エージェントの真正性を確認します。HIPAAなどのコンプライアンス要件にも対応する設計です。
Gemini Enterprise Agent PlatformへのネイティブARDサポートは、今後数か月以内に提供予定とされています。社内レジストリを広い連合ネットワークに安全に接続できるようになります。
手動配線との違い
従来の運用では、開発者やIT管理者がリソースを1件ずつ見つけ、信頼性を判断し、AIクライアントに接続し、更新を追いかける必要がありました。リソースが数百件を超えると、この方式は破綻します。
ARDは、リソース側が軽量なマニフェストを公開し、レジストリが索引化するモデルです。Microsoftの比喩では、初期インターネットの手作りブックマークから検索エンジンへ移行した構図に近いと説明されています。DNSのようにローカル制御とグローバル連合を両立する設計とも位置づけられています。
重要なのは、単一の巨大カタログを作ることではない点です。公開向け、ベンダー向け、企業内向けなど、用途の異なるレジストリが共存します。クライアントがどのレジストリを問い合わせるかで、返る答えが変わるのは仕様の意図どおりです。
開発者が今できること
仕様はすでに公開されています。自社ドメインにai-catalog.jsonを置けば、数分でリソースを発見可能にできます。スキーマ、連合モデル、信頼アーキテクチャ、参照実装はagenticresourcediscovery.orgとGitHubリポジトリで確認できます。
Hugging FaceもARD準拠のDiscover Toolを参照実装として提供しており、Hub上のスキルやMCPサーバーを横断検索できます。ただし仕様はv0.9ドラフトのため、スキーマや運用推奨は今後変わる可能性があります。Google Cloudのネイティブ対応も提供前の段階です。
エージェントにツールを増やし続けるなら、探索の標準化は避けて通れない課題です。ARDは実行プロトコルを置き換えるのではなく、その手前で「何を使うか」を解く共通語彙を定義し始めました。Copilot利用者はAgent Finderから試せます。自社サービスを公開する側は、カタログのホストから着手するのが現実的です。