はじめに
こんにちは！Martimです！
今回、2026年4月9日、AWSはAmazon Bedrock AgentCoreの新機能としてAWS Agent Registryをプレビュー公開しました。
AIエージェントを実際に組織で運用したことのある方なら、こんな経験をしたことがあるのではないでしょうか。
- 「このコスト集計の処理、誰かが別のチームで作ってなかったっけ？」
- 「このエージェント、誰がオーナーで、本番環境で動いていいものなのか？」
- 「先月デプロイしたエージェント、どこに置いたっけ？」
これはAgent Sprawl-エージェントスプロールと呼ばれる問題で、エージェントの数が増えるにつれて組織全体での可視性と管理が困難になる現象です。AWS Agent Registryはこの問題に正面から向き合ったサービスと考えています。
Agent Sprawlとは何か
エージェントは従来のアプリケーションより圧倒的に速いペースで増殖します。LLMをベースにしたエージェントは、ちょっとしたPythonスクリプトと数行のSDKコードで動くため、各チームが思い思いに作り始めます。
その結果、組織には3つの問題が生まれます。
可視性の欠如 - どのエージェントが存在するか、誰も全体像を把握していない状態になります。AWSやオンプレ、他クラウドにまたがって散在するエージェントは、中央カタログがなければ存在を知る手段がありません。
ガバナンスの欠如 - セキュリティレビューや承認を経ていないエージェントが本番環境で動き始めます。誰が公開してよいか、誰が使ってよいかのルールが機能しません。
重複開発 - 隣のチームがすでに作ったものを知らずに作り直します。エンジニアリングリソースが無駄に消費されます。
Zuoraは50本のエージェントをSales、Finance、Product、開発チームにまたがって展開していますが、この規模になると中央カタログなしでの管理は現実的ではありません。
AWS Agent Registryの概要
AWS Agent Registryは、組織内のエージェント・ツール・MCPサーバー・エージェントスキル・カスタムリソースを一元管理するフルマネージドのカタログサービスです。
重要な点として、AWS上のリソースだけを対象にしていません。他クラウドやオンプレミスで動くエージェントも登録・管理の対象になります。組織全体のエージェントランドスケープを一箇所で把握することが設計思想の根幹にあります。
登録できるリソース種別
| 種別 | 説明 |
|---|---|
| Agent | A2Aプロトコルに対応したエージェント |
| MCP Server | Model Context Protocolサーバー |
| Agent Skill | 特定機能に特化したスキル単位 |
| Tool | 個別のツール関数 |
| Custom Resource | 組織独自のカスタムスキーマ |
主要機能
レコードとメタデータ管理
Registryに登録される1件1件の情報をレコードと呼びます。各レコードには以下のメタデータが紐付きます。
- エージェント名・説明・バージョン
- オーナー・チーム情報
- 対応プロトコル（MCP / A2A）
- エンドポイントURL
- コンプライアンスステータス
- タグ
レコード登録は2通りの方法で行えます。コンソール・SDK・CLIから手動でメタデータを入力する方法と、MCPまたはA2Aエンドポイントを指定してRegistryが自動でツールスキーマや説明を取得するURL-based discoveryの方法です。
ハイブリッド検索
検索はキーワード検索とセマンティック検索を組み合わせたハイブリッド方式を採用しています。短いクエリはキーワードマッチ、長い自然言語クエリはセマンティック理解も加わります。
これにより「payment processing」と検索すると「billing」や「invoicing」とタグ付けされたエージェントも引っかかります。命名規則が統一されていない組織でも実用的に機能する設計です。
承認ワークフローとガバナンス
レコードのライフサイクルは以下のステータスで管理されます。
Draft → Pending Approval → Approved → (Deprecated)
Auto-approvalをオフにすることで、管理者による承認を必須にできます。IAMポリシーを使って「レコードを作成・提出できる人」と「承認できる人」を分離できるため、開発者と承認者を別ロールとして設計することが可能です。
すべてのAPI操作はCloudTrailに記録されるため、監査証跡も自動で確保されます。
アクセス方法
Registryへのアクセス手段は3つあります。
AgentCore Console - ブラウザからGUIで操作します。
AWS CLI / SDK - boto3 1.42.87以降でbedrock-agentcore-controlクライアントとbedrock-agentcoreクライアントを使って操作します。
MCPサーバーとして - RegistryはそれじたいがMCPエンドポイントを持っており、KiroやClaude CodeなどMCP互換のIDEから直接クエリできます。これが最も強力な使い方で、エージェント自身がRegistryを検索して他のエージェントを動的に発見・呼び出すことを可能にします。
認証はIAMとOAuth（Custom JWT）の両方をサポートしています。外部のIDプロバイダーを持つ組織はOAuthを使ってIAMクレデンシャルなしに独自の検索UIを構築できます。
マルチエージェント構成における位置づけ
Agent Registryの真価が発揮されるのは、複数のエージェントをオーケストレーターが動的に呼び出すマルチエージェント構成においてです。
[ユーザーの指示]
「今月のAWSコストをウェルアーキテクト観点で評価してくれ」
↓
[オーケストレーターエージェント]
RegistryのMCPエンドポイントに問い合わせ
「コスト系のエージェントある？」→ Cost Summary Agentを発見
「WA評価系のエージェントある？」→ WAF Agentを発見
↓
[Cost Summary Agent] Cost Explorerからデータ取得・整形
↓
[WAF Agent] 5つの柱で評価・レポート生成
↓
[オーケストレーター] 結果を統合してレスポンス
Registryがない構成では、オーケストレーターは呼び出し先のエンドポイントをコードにハードコードしておく必要があります。Registryがあれば、エージェントを追加するたびにオーケストレーターのコードを修正する必要がなくなります。新しいエージェントをRegistryに登録するだけで、オーケストレーターが自律的に活用し始めます。
今後のロードマップ
現在プレビューの機能として、以下が将来的に追加予定です。
- AgentCore・Kiro・Amazon Quick Suiteでデプロイしたエージェントの自動インデックス
- 複数Registryをまたいだクロスレジストリフェデレーション
- AgentCore Observabilityと連携したエージェントの運用メトリクス表示（レイテンシ・アップタイム等）
- AWS Resource Access Managerとの統合
利用可能リージョンと料金
現在プレビュー提供中のリージョンは以下の5つです。東京リージョンも含まれています。
- Asia Pacific (Tokyo) / ap-northeast-1
- US East (N. Virginia)
- US West (Oregon)
- Asia Pacific (Sydney)
- Europe (Ireland)
次回予告
今回はAWS Agent Registryの概要と機能についてまとめました。
実際にRegistryを作成し、Cost Summary AgentをStrands Agents SDKで実装してAgentCore Runtimeにデプロイ、Registryへの登録からKiro経由でのMCPアクセスまでを試した内容を次回の記事で公開します。マルチエージェント構成でRegistryのMCPエンドポイントを使ってエージェントが動的に他エージェントを発見・呼び出す動作確認まで行う予定です。
まとめ
AWS Agent Registryは、エージェントが「作るだけ」の時代から「組織として管理・統治する」時代への移行を支えるインフラです。エージェントの数が増えるほど、中央カタログの有無がエンジニアリング効率とセキュリティリスクに直結するようになります。
現時点ではプレビューですが東京リージョンでも利用可能なため、今のうちに触っておくことをお勧めします！
それでは！よいAWSライフを！