公開：2026年10月21日, 最終更新：2026年10月21日
AWSは、AIエージェントがビルド時にツールを固定化せず、実行時にModel Context Protocol（MCP）サーバーやエージェントを動的に探索・接続できるマネージドサービス「AWS Agent Registry」の実装方法を、公式機械学習ブログで解説した。
30秒サマリー
- AWS Agent Registryはエンタープライズの大規模APIカタログに対し、エージェントが実行時にセマンティック検索で必要なツールだけを動的に取得する仕組みを提供する
- ツールのハードコードを排除することで、新機能追加時のオーケストレーター改修・再デプロイ・チーム間調整が不要になるとAWSは説明する
- 探索結果には接続メタデータのみが含まれ、認証情報は別経路で取得する設計により、セキュリティの分離を実現している
AWS Agent Registryの実装パターンと「Discover→Instantiate→Execute」ループの要点
AWSの公式機械学習ブログは、AIエージェントが実行時にツールを動的に発見・接続するパターンとして、AWS Agent Registryを活用した実装例を公開した。従来のビルド時ハードコード方式では、数十件規模でパフォーマンスが低下し、数百件に達すると管理不能になるという課題を背景として説明している。
AWS Agent Registryは、MCPサーバー・エージェント・エージェントスキルのカタログ化と探索を担うマネージドサービスとして紹介されている。オーケストレーターはリクエストごとに自然言語クエリをRegistryのデータプレーンに送信し（Discover）、返却されたディスクリプタからMCPクライアントまたはA2Aエージェントのクライアントを構築し（Instantiate）、リクエストスコープ内に限定した一時的なサブエージェントを生成してツールを実行する（Execute）。ターンが終了すると、このサブエージェントとクライアントは破棄され、次のリクエストでは再度検索が行われる。
ブログで示された参照アーキテクチャには、AWS Agent Registry・Amazon Bedrock AgentCore Gateway・Amazon Bedrock AgentCore runtime・Amazon Bedrock・Amazon Cognito・AWS Lambda・AWS Secrets Managerが含まれる。探索結果にはエンドポイントなどの接続メタデータは含まれるが、呼び出し認証情報は含まれず、認証は別途信頼できる設定経路から取得する設計となっている。
Registryへのレコード登録には承認ワークフローが設けられており、DRAFTからPENDING_APPROVALを経てAPPROVEDに遷移したレコードのみがデータプレーンの探索対象となる。ブログでは、キーワードとセマンティック検索を組み合わせたハイブリッド検索が利用可能であることも説明しており、「return and refund」という語句がAgent名に含まれていなくてもカスタマーサポートエージェントが正しく探索される例をデモシナリオとして紹介している。ただしブログ自体が、カタログの件数増加が自動的に検索ランキングを向上させるとは言及していない点も明示している。
AWS Agent Registryの主な仕様・数値
- サービス種別：マネージドサービス（AWS Agent Registry）
- 対応プロトコル：MCP（Model Context Protocol）、A2A（Agent-to-Agent）
- 検索方式：ハイブリッド（キーワード＋セマンティック検索）
- 使用モデル（サンプル）：Anthropic Claude Sonnet（クロスリージョンモデルID経由）
- MCPディスクリプタ dataSchemaVersion：2025-12-11（サーバーメタデータ）、2025-06-18（ツール定義）
- A2Aディスクリプタ dataSchemaVersion：0.3
- 承認フロー：DRAFT → PENDING_APPROVAL → APPROVED（手動承認設定時）
- 認証方式（サンプル）：Cognito JWT認証（Gateway向け）、IAM署名Boto3（AgentCore runtime向け）
出典: AWS Machine Learning Blog（公式ブログ）
なぜ重要か（編集部の分析）
編集部の見方では、このパターンの本質的な意義はエージェントと社内APIカタログの「疎結合化」にある。従来のハードコード型では、APIが増えるたびにオーケストレーターのコード修正・再デプロイ・多チーム間調整が必要だったが、Registry経由の動的探索に移行すれば、新APIの追加はRegistry登録と承認ワークフローの完了だけで済む。これはAIエージェント基盤のスケーラビリティを根本的に変える設計思想であり、エンタープライズでのAIエージェント本格展開の前提条件の一つになりうる。
日本企業への示唆（編集部の分析）
編集部の分析として、社内に多数のAPIを抱える日本の大企業・金融機関・製造業にとって示唆は大きい。まず既存の社内API資産をMCPサーバーまたはA2Aエージェントとして整備・登録する工程が先決となる。承認ワークフローの設計（誰がどのAPIを承認するか）はガバナンス上の重要論点であり、情報セキュリティ部門と連携した制度設計が必要になる。認証情報がRegistry探索結果に含まれない設計は企業ポリシーとの整合性が取りやすい一方、別途の認証管理基盤（Cognito・Secrets Manager等）の整備コストも見込む必要がある。
背景・経緯
エンタープライズシステムでは価格・サポート・受注・在庫・顧客データなど数百に及ぶ内部APIが存在する。従来のAIエージェント実装では、これら全ツールをビルド時にオーケストレーターへ組み込む方式が主流だったが、規模拡大とともにトークン消費増・管理コスト増・デプロイ分離困難という問題が顕在化してきた。AWSはこの課題に対応するマネージドサービスとしてAWS Agent Registryを提供しており、今回のブログはそのPythonサンプルを用いた実装解説として公開された。
AWS Agent Registryについてよくある質問
Q. AWS Agent Registryの探索結果には認証情報も含まれるか？
A. 含まれない。AWS Agent Registryの探索結果にはエンドポイントなどの接続メタデータのみが返され、呼び出し認証情報や認証スキームは含まれない。アプリケーションは別途信頼できる設定経路から認証情報を取得する必要がある。
Q. AWS Agent Registryはどのプロトコルに対応しているか？
A. ブログの説明によると、MCPサーバー（recordType=”MCP”）とA2Aエージェント（recordType=”AGENT”）の両プロトコルに対応している。それぞれ異なるディスクリプタ形式（mcpServerまたはa2aAgentCard）でレコードを登録する。
Q. AWS Agent Registryで新しいAPIを追加する際にオーケストレーターの再デプロイは必要か？
A. ブログの説明では、動的探索パターンを採用することで、新しいAPIをRegistryに登録・承認するだけで利用可能になり、オーケストレーターのコード変更や再デプロイは不要になるとしている。
