AWS、Agentic Resource Discovery をエージェントレジストリ向けフェデレーション層として支援

Amazon Web Services は Agentic Resource Discovery 仕様を後押しし、2026年8月24日に、同オープン標準が AWS Agent Registry（今年初めにプレビューが開始された、AI エージェント、ツール、スキルの管理カタログ）とどのように連携して機能するかを詳細に発表しました。

このAWS の投稿は、ARD を AWS 自社製品が残す課題への解決策として位置付けています。AWS Agent Registry は Amazon Bedrock AgentCore を通じて提供され、組織にエージェント、MCP サーバー、ツール、エージェントスキル、カスタムリソースの集中型で検索可能なカタログを提供しますが、AWS 環境内に限定されます。多くの企業は複数のクラウド、オンプレミスインフラ、SaaS プラットフォームにわたってエージェントを運用しており、各々が独自のレジストリとメタデータ形式を持っています。そのため、これらの環境を橋渡しするには、レジストリ間のすべてのペアに対してカスタムコネクタを構築する必要があります。

ARD は共有フォーマットの代替案を提案しています: すべてのレジストリがリソースを同一の方法で記述し、共通プロトコルでディスカバリーを提供すれば、発行者はリソースを一度記述するだけで、利用者はあらゆる場所でそれを発見できるようになります。

Inside the AWS Agent Registry Model

現在 Amazon Bedrock AgentCore を通じてプレビュー中のレジストリは、2 つの概念: レジストリ（管理者が独自の認可および承認設定で作成するカタログ）と、各リソースを記述するメタデータエントリであるレコードに基づいて構築されています。出版ワークフローは管理者 → 発行者 → キュレーター → 利用者 の順に進み、レコードがディスカバリー可能になる前に承認ゲートが設けられます。アクセスは AWS Identity and Access Management の認証情報または企業の ID プロバイダーからの JSON Web Token によって制御され、レジストリ自体はリモート MCP エンドポイントとして公開されるため、MCP 対応クライアントは直接検索できます。

このガバナンス層は、AWS が慎重に保持しようとしている部分です。投稿では、AWS は ARD を執行ポイントの外側に位置する相互運用性レイヤーとして説明しています: カタログを公開する組織が内容、閲覧権限、アクセス取り消しのタイミングを管理し、Agent Registry の既存の承認およびアクセス制御はポリシーが実際に適用される場所に残ります。表現は意図的です: ARD はものを見つけることを扱い、プロダクションへの信頼は扱いません。

What the ARD Specification Actually Standardizes

ARD は AWS のプロジェクトではありません。この仕様は 2026年6月17日に、Google、Microsoft、Hugging Face、GoDaddy を含む作業部会によって発表され、Cisco、Databricks、GitHub、NVIDIA、Salesforce、ServiceNow、Snowflake などが共同で参加しています。Apache 2.0 ライセンスで公開されており、agenticresourcediscovery.org に掲載されています。実装例は GitHub にあります。AWS は仕様の作成ではなく、開発中にフィードバックを提供しました。

Google の発表によると、アーキテクチャは 2 つの基本要素に基づいています。カタログは組織が自ドメイン下に公開するファイル（既知のパスにある ai-catalog.json）で、利用可能なエージェント、MCP サーバー、A2A エージェント、OpenAPI ツール、またはネストされたカタログを記述し、ドメイン所有権が発行者の身元を証明する暗号的根拠となります。レジストリはこれらのカタログに対する検索エンジンとして機能し、クロール、インデックス作成、自然言語のディスカバリー要求に応答し、接続前に発行者の身元を確認するために必要な検証可能な信頼メタデータと共に一致結果を返します。

ARD が設定する境界はディスカバリーであり、実行ではありません。ARD を通じてリソースを見つけたクライアントは、そのリソースがネイティブに対応する仕組み（MCP、API、エージェントフレームワークなど）で呼び出します。仕様のサイトでは、ARD はランタイムでもなく、MCP や A2A プロトコルの代替でもなく、中央カタログでもないことが明示されています。設計は多数のディスカバリーサービスが存在し、それぞれが独自の信頼性およびランキングポリシーを適用することを前提としています。AWS の例えは DNS であり、ローカルレジストリは双方向の合意や専用コネクタなしに共有プロトコルを通じてフェデレーションし、ネットワーク全体で名前解決が行われる方式に似ています。

How the Pieces Fit Together

Agent Registry の顧客にとっての提案は、移行なしでのフェデレーションです。クラウド、オンプレミスシステム、SaaS ツールにまたがるエージェントインフラを持つ組織は、すべてを ARD 形式で公開すれば、環境間でディスカバリー可能にしつつローカルで制御を維持できます。また、自ドメイン上にカタログを公開すれば、任意の ARD 対応クライアントがそれを発見でき、単一ベンダーのレジストリでは到達できない組織横断的な経路を開くことができます。

AWS は他社がまだ構築中の段階で、製品をすでに提供し始めています。Google の独自 Agent Registry（Gemini Enterprise Agent Platform の一部）は、今後数か月でネイティブな ARD サポートを追加する予定で、GitHub と Hugging Face も仕様策定の作業部会に参加しています。3 つのクラウドすべてで共通するパターンは: 内部は管理・ガバナンスされたレジストリ、外部はオープンなフェデレーションプロトコル、という構造です。

注意点として、AWS の投稿で述べられた統合は方向性のものであり、製品として提供されているわけではありません。AWS は、納期を発表するのではなく、ARD が Agent Registry の顧客に何を可能にするかを示しています。また、レジストリ自体はプレビュー段階に留まります。2026年8月24日が示すのは整合性であり、最大手クラウドプロバイダーがフェデレーション対象とするオープン仕様を明示したことで、Google と Microsoft が目指すものと同一であることを示しています。