AWSは承認済みのMCPサーバーやエージェントを実行時に探す例を紹介しました。検索結果は接続の情報を返し、認証情報は別の経路で取得する設計です。 ツールを追加するたびに制御コードを変える負担を減らせます。発見できることと実行できることを分け、登録と承認の運用を整える必要があります。 多数のツールを固定したコードから切り離す AWSは10月20日、Agent Registryでツールを実行時に発見する構成を紹介しました。企業内のAPIが増えると、すべてを制御役のコードやプロンプトへ埋め込む方法では、変更や再展開が負担になります。記事は、必要な機能を検索し、対応するクライアントを作って実行する流れを示しています。RegistryにはMCPサーバー、エージェント、スキルなどの説明やプロトコル情報を登録します。原文は管理された検索カタログを使う実装例であり、検索で見つかった接続先へ無条件に実行権限を与える仕組みではありません。登録と利用の間に承認と認証を置くことが、構成の前提になっています。 発見の結果に認証情報は含めない 検索結果には、名前、説明、状態、版、接続先などの情報が含まれます。一方、呼び出し用の認証情報や認証方式は返さず、信頼された別の設定経路から取得すると説明しています。MCPとA2Aでは呼び出しの形が異なるため、受け取った情報から適切なクライアントを構成します。影響対象は、多くの部門がそれぞれ機能を開発する企業のエージェント基盤担当です。登録された説明を基に選ぶため、名前や説明の品質が実行結果を左右する可能性があります。似たツールが多数ある場合、誤った候補の選択や古い版への接続が論点になります。承認した記録だけを発見可能にする仕組みと、実際の利用権限の確認を組み合わせることで、拡張性と統制を両立する狙いです。登録の説明は、利用者が直接読む資料でもあります。検索用の記述と実際の動作がずれると、候補の選択後に初めて問題が分かるため、所有部門の継続した確認が必要と考えられます。 登録の品質を運用対象に加える 実務では、ツールの所有者、説明の更新、廃止や版の切り替えを管理する体制が論点です。コードへの固定を減らしても、カタログが古ければ適切な機能を選べません。検索精度の評価には、正しい機能を返すかだけでなく、候補がない時に無理に実行しないかも含める必要があります。検索と接続を実行ごとに行う場合、遅延や費用も増える可能性があります。認証情報を別経路に保つ設計では、その取得失敗や期限切れをどう扱うかも確認点です。原文のサンプルは構成を理解する入口であり、自社の承認手続きや業務権限を自動的に代替するものではありません。次の判断点は、登録の追加や更新があっても、同じ業務要求に対して期待する機能と権限を安定して選べるかです。廃止した機能が検索から消えるまでの動きも評価対象です。新規登録の速さだけでなく、不要になった接続先を確実に利用対象から外せるかが、運用の品質を左右します。