AWS Agent Registryで実現するMCPガバナンスと組織的エージェント管理

開発現場において、特定のチームが独自に作成したMCP（Model Context Protocol）サーバーが乱立し、いわゆる「野良MCP」がブラックボックス化する現象は、もはや珍しい光景ではありません。深夜の障害対応中に、誰が書いたかも分からない、ドキュメントも存在しないMCPサーバーがデッドロックを引き起こし、原因究明のためにコードの海を彷徨った経験を持つエンジニアは少なくないはずです。AWS Agent RegistryのGAは、こうした「エージェント資産の無秩序な増殖」という、現代のAI開発における深刻な技術的負債に対する、AWSからの明確な回答であると私は捉えています。

2026年8月末にGAとなったAWS Agent Registryは、単なるカタログサービスではありません。これは、組織内のエージェント、ツール、スキルを「ガバナンスプレーン」と「ディスカバリープレーン」という二層構造で分離し、承認プロセスを強制的に組み込むためのインフラです。特に重要なのは、承認済みレコードのみが検索可能になるという仕様です。これは、開発者が「とりあえず動くから」という理由でセキュリティレビューを通っていないツールを安易に導入するのを防ぐための、強力な防波堤となります。旧名前空間であるbedrock-agentcoreからagent-registryへの移行が完了し、東京リージョンでも利用可能となった今、我々エンジニアは「野良MCPをいかに排除するか」ではなく、「いかにして組織の承認フローに組み込むか」という視点への転換を迫られています。

AWS Agent Registryが管理するレコードタイプは、MCPサーバー、A2Aプロトコルのエージェントカード、スキル定義、そしてカスタムリソースの4種類です。これらがEventBridgeと密接に連携し、状態遷移ごとにイベントを発行する設計は、まさに「Infrastructure as Code」の思想をエージェント管理に持ち込んだものと言えます。承認申請がPENDING_APPROVALに遷移した瞬間にセキュリティスキャンを走らせ、重複チェックを行い、最終的に人間がサインオフする。この一連のワークフローを自動化できる点は、スケーラビリティを重視する組織にとって極めて大きな価値があります。単なるカタログ化に留まらず、監査証跡をCloudTrailに完全保存できる点は、エンタープライズ環境におけるコンプライアンス要件をクリアする上で、避けては通れない必須要件となるでしょう。

多くのエンジニアが混同しがちなのが、AWS Agent RegistryとKiro for Enterpriseが提供するガバナンス機能の棲み分けです。結論から言えば、Agent Registryは「組織の台帳」であり、Kiro for Enterpriseは「クライアント側の執行機関」です。この二つを混同して設計すると、ガバナンスが形骸化するか、あるいは過剰な制約によって開発者の生産性が著しく低下するスパゲッティ状態に陥ります。Kiro for EnterpriseのMCPレジストリ機能は、許可リストにないサーバーを強制的にブロックし、クライアントレベルで実行を拒否する強力な強制力を持っています。一方で、Agent Registryは「何が承認されているか」をカタログとして提供し、自然言語によるセマンティック検索を可能にします。

以下の表は、両者の役割と特性を比較したものです。この構造を理解することが、組織的なAIガバナンスを設計する上での第一歩となります。

この棲み分けを理解した上で、我々が取るべき戦略は「Agent Registryで承認されたレコードを、自動的にKiro for Enterpriseの許可リストJSONに変換して配信する」というパイプラインの構築です。これにより、カタログとしての検索性と、クライアント側での強制的な統制を両立させることが可能になります。特に、スキル（Skills）の配布に関しては、Kiro for Enterprise側には統制機構が存在しないため、Agent Registryのライフサイクル管理が唯一のガバナンス手段となります。スキルは自然言語の指示書であり、コードレビューとは異なる「プロンプトインジェクション耐性」や「機密情報の取り扱い」といった観点でのレビューが不可欠です。このレビュープロセスをRegistryの承認ゲートに乗せることで、初めて「安全なスキルのみが組織内で流通する」エコシステムが完成します。

結局のところ、ツールやプラットフォームを導入しただけでガバナンスが解決することはありません。重要なのは、開発者が「なぜこの承認フローを通さなければならないのか」という納得感を持つことです。Agent Registryの導入は、開発者にとって「便利なツールを探す手間が省ける」というメリットを提示できるかどうかが鍵となります。もし、Registryが単なる「管理者のための監視ツール」として機能するならば、開発者はすぐにバイパス手段を探し始めるでしょう。我々シニアエンジニアが担うべき役割は、Registryを「開発者の生産性を高めるためのカタログ」として再定義し、承認フローを可能な限り自動化して、摩擦を最小限に抑えることです。

明日から実践すべき具体的な対策として、まずは現在チーム内で乱立しているMCPサーバーの棚卸しを行うことを推奨します。そして、それらをRegistryに登録し、EventBridgeを介した自動承認フローを構築してください。特に、認証が必要なMCPサーバーについては、DCR（Dynamic Client Registration）の活用を検討すべきですが、Cognito等の認可サーバーが対応していない場合は、事前登録クライアント方式での運用を設計する必要があります。また、Kiroのmcp.jsonを直接編集させるのではなく、Registryから検索して接続情報を取得するフローを標準化し、開発者が「検索→確認→接続」という一連の動作を自然に行える環境を整えることが重要です。

最後に、我々エンジニアに突きつけられた問いを投げかけたいと思います。AIエージェントが自律的にツールを呼び出し、複雑なタスクを完遂する時代において、我々が管理すべきは「コード」なのか、それとも「エージェントの権限」なのか。もし、エージェントが承認済みのツールを組み合わせて、予期せぬ副作用を持つ操作を実行した場合、その責任は誰が負うのでしょうか。ガバナンスとは、単なる制限ではなく、AIという強力な武器を組織が安全に使いこなすための「信頼の基盤」です。あなたは、自らの組織において、エージェントの自律性と安全性のバランスをどこに設定しますか？その設計思想こそが、これからのエンジニアリングの価値を決定づけることになるはずです。