AWS Agent Registryでランタイムにツールを発見

ツールをコードに固定する方式は数個なら問題ないが、数十個を超えると劣化し、社内APIが数百に及ぶ企業システムでは管理できなくなる。モデルがユーザーの要求を考えるより、ツール名の区別にトークンを使う場面も出る。新機能のたびにオーケストレーターの修正と再デプロイが必要になる点も課題として挙げられている。解決策として、エージェントが関連ツールを実行時に検索する方式を示している。 AWS Agent Registryは、MCPサーバー、エージェント、エージェントスキルをカタログ化して検索できるマネージドサービスである。オーケストレーターは自然言語のクエリを送り、承認済みで検索可能なレコードを受け取る。レコードにはエンドポイントやMCPメタデータ、A2Aのエージェントカードなどが含まれるが、呼び出し用の認証情報は含まれない。MCPではCognitoのOAuthトークンを別途取得し、A2Aではboto3がAWS認証情報で署名する。 サンプルでは、検索結果から作ったクライアントのツールだけで、リクエスト単位の内部エージェントを組み立てる。大規模言語モデル（LLM）が適切なツールを選び、結果をまとめた後、内部エージェントとクライアントは破棄される。オーケストレーターはStrandsエージェントとしてAmazon Bedrock AgentCore runtime上で動き、モデルにはAnthropic Claude Sonnetをクロスリージョンのモデル IDで設定している。 承認を手動にすると、レコードはDRAFT、PENDING_APPROVAL、APPROVEDの順に遷移し、承認済みのものだけが検索対象になる。申請と承認はIAMで認可されるため、公開者と承認者の権限を分けられる。デモは注文状況のMCPのみ、価格と割引でMCPとA2Aを連鎖、返品と返金の意図に対する意味検索の3種類である。 ブログは、カタログが小さく安定している場合や、処理順が固定されたパイプラインでは、ビルド時に明示的に組み込む方が単純だと述べている。検索品質はカタログの規模ではなく、説明文やクエリ設計、評価に左右されるとも指摘している。最後に、自社のMCPサーバーかエージェントを1つ登録し、記述子、承認状態、認証経路、検索挙動を確認するよう勧めている。

AWS Machine Learning Blogより

推移を表示するための継続的な観測データがまだ足りません。