AWS Agent Registry、実行時にMCPツールを発見する仕組みを公開

何が発表されたのか

AWSは機械学習ブログで、AWS Agent Registryを使ったランタイムディスカバリの実装例を公開した。Agent Registryは、Model Context Protocol（MCP）サーバー、エージェント、エージェントスキルをカタログ化し、発見するためのマネージドサービスである。公開者はプロトコル固有のディスクリプタと検索可能な説明文を登録する。実行時になると、オーケストレータは承認済みで発見可能なレコードを検索し、返されたエンドポイントとディスクリプタの内容からクライアントを組み立てる。

背景として記事が挙げるのは、ツールをコードに埋め込む方式の限界である。数個なら問題なく動くが、数十個になると劣化し始め、それを超えると管理できなくなる。企業システムは価格、サポート、注文、在庫、顧客データ向けに数百の内部APIを公開しており、モデルがツール名の曖昧さを解消するためにトークンを使い、依頼内容の推論に回せなくなるという。新しい機能のたびにオーケストレータのコード変更、再デプロイ、チーム横断のリリース調整が必要になる点も課題とされている。

発見・生成・実行の3段階

記事はサンプルコードの流れを「Discover → Instantiate → Execute」の3段階で説明する。Discoverでは、オーケストレータが自然言語のクエリをAgent Registryのデータプレーンに送る。検索応答にはレコードの識別子、名前、説明、レコード種別、ステータス、バージョン、そしてMCPサーバーのメタデータやA2Aのエージェントカードといったプロトコルディスクリプタが含まれる。

Instantiateでは、返されたレコードごとにディスクリプタの種別に応じたクライアントを組み立てる。サンプルのMCPサーバーはAmazon Bedrock AgentCore Gatewayのエンドポイントを指しており、オーケストレータはCognitoのOAuthアクセストークンを別経路で取得してMCPClientの生成に使う。A2AのレコードはエージェントカードのURLがAgentCore runtimeのエンドポイントを示し、boto3のデータプレーンクライアント経由で呼び出す。

Executeでは、その時点で発見されたツールだけを持つ一時的なインナーエージェントを組み立て、LLMがリクエストに合うツールを選んで結果を統合する。ターンが終わるとインナーエージェントとクライアントは破棄され、次のリクエストでは再び検索からやり直す。記事はこの方式を、リクエストごとにスコープが閉じる点が特徴だと説明している。

登録と承認のワークフロー

レコード作成時にはrecordTypeが必須で、MCPサーバーは「MCP」、A2Aエージェントは「AGENT」を指定する。プロトコル固有のメタデータはdescriptorsオブジェクトのmcpServerまたはa2aAgentCardに格納する。記事ではMCPのdataSchemaVersionとして「2025-12-11」、toolsとして「2025-06-18」、A2Aのエージェントカードとして「0.3」が示されている。ディスクリプタには接続メタデータが入るが、呼び出し時に提示すべき認証情報は含まれない。

レコードのライフサイクルはコントロールプレーンのクライアント、実行時の検索はデータプレーンのクライアントが担う。自動承認を無効にすると、レコードはDRAFTからPENDING_APPROVAL、そしてAPPROVEDへと進む。投稿とステータス更新はIAMで認可されるため、公開者と承認者の権限を分けられる。発見可能なデータプレーンが返すのは承認済みのレコードだけである。

参照アーキテクチャとデモ

サンプルの参照アーキテクチャは、Agent Registry、AgentCore Gateway、AgentCore runtime、Amazon Bedrock、Amazon Cognito、AWS Lambda、AWS Secrets Managerで構成される。オーケストレータはStrandsのエージェントとしてAgentCore runtimeにデプロイされ、discover_and_executeツールを通じて検索、クライアント生成、実行をまとめて行う。基盤モデルにはAnthropic Claude SonnetをクロスリージョンのモデルIDで指定している。

デモは3つ用意されている。1つ目は注文状況の照会でMCPのみを呼ぶ。2つ目は価格と割引で、MCPとA2Aを連鎖させる。3つ目は「返品・返金」という、一致したA2Aエージェントの名前には含まれない語を含む曖昧な意図に対して、セマンティック検索で適切なエージェントを引き当てられるかを見るものだ。

現時点で分かっていないこと

記事はセマンティック検索の例示について、あくまでデモ結果であり、カタログが大きくなればランキングが良くなるという一般的な主張ではないと明記している。検索品質は代表的なクエリで評価すべきだとしているが、評価手法の詳細には触れていない。説明文はユーザー向けの言葉で書き、隣接するレコードと区別できるようにする、という運用上の指針が示されるにとどまる。

料金、提供リージョン、一般提供かプレビューかといった情報は原文に記載がない。また原文はサンプルコードの説明の途中で切れており、複数ツールへのファンアウトなど終盤の詳細は読み取れない。導入を検討する際は、これらを別途確認する必要がある。