AWS Agent Registryのランタイム検出、ツール接続をビルドから切り離す
AWSは10月20日、AWS Agent Registryのランタイム検出について詳しく説明し、すべての機能をエージェントにハードコードする方法に代わる選択肢を示した。このアプローチではツールの選択を実行中のアプリケーションへ移し、リクエストを統括するオーケストレーターが接続先を選ぶ前にカタログを検索する。この変化は、多くのチームが部門をまたいでツールカタログを拡大し始めるまで無理なく維持できるアーキテクチャに問いを投げかける。
中心となる対立は、ビルド時の接続設定と実行時の選択だ。ビルド時の接続設定では、開発者は利用可能な機能を明示的に把握できる。実行時の選択では、その一覧を独立して変更できる一方、検索結果がアプリケーションの振る舞いの一部になる。問題は、オーケストレーターのリリースサイクル外で機能を進化させつつ、チームが予測可能な実行を維持できるかどうかにある。
Anthropicもオンデマンドでツールを読み込む方法を提唱しており、このAWSの事例には認識しやすい業界の参照点がある。AWSはこの議論を、モデルのコンテキストと並んで承認、所有権、接続情報、アクセス規則が重要となるエンタープライズのカタログ管理へと持ち込む。開発者やエンタープライズの購入者にとって重要な変化は組織面にある。ツールの利用可能性は、アプリケーションの追加デプロイではなく、カタログのガバナンスに依存し得る。
AWS Agent Registryのランタイム検出は接続先を選ぶタイミングを変える
runtime discovery walkthroughでは、Discover、Instantiate、Executeというループが示されている。サンプルでは、注文管理サーバーを価格設定エージェントとカスタマーサポートエージェントに接続する。これらは、独立して評価されたエンタープライズ導入の証拠ではなく、デモンストレーション用のシナリオである。
この例では、アプリケーションがAIシステムにツールとコンテキストを公開する方法を標準化するModel Context ProtocolであるMCPを使用している。また、エージェント間の通信を担うエージェント間プロトコルであるA2Aも使用している。両者を同じ検出ループに組み込むことで、この例は個別機能のカタログを超えた意味を持つ。
アーキテクチャ上の変化は、オーケストレーターがすべての接続をビルド時に抱えるのではなく、リクエストを受け取った後に接続先を選択する点にある。
この違いは、「検出」という言葉だけから想像される以上に注目に値する。開発者が参照するカタログは、実装時に統合先を選ぶ助けとなる。実行時に参照するカタログは、特定のリクエストに対してアプリケーションが利用できる統合先を決定する助けとなる。
これは、機能を追加することの意味を変える。明示的な接続設定では通常、開発者がオーケストレーターを出荷する前に統合の配置先を決める。実行時の選択では、互換性のある機能がカタログを通じて候補に加わり得る。アプリケーションには、検出した対象を解釈し利用するための規則がなお必要だ。
この違いは、レビュー担当者が確認すべき対象も変える。オーケストレーターのソースコードをレビューしても、将来的に利用可能となる機能の完全な集合が必ずしも分かるわけではない。有用なレビューでは、カタログ、公開権限、承認慣行、互換性に関する期待も考慮する必要がある。
すでに注文に関する問い合わせを処理している仮想的なエンタープライズアシスタントを考えてみよう。サポートチームが保証請求向けの専門機能を導入する。アーキテクチャ上の利点は、その専門機能を、調整アプリケーションに別の名前付き統合を追加せずに検出可能にできることだろう。
この利点は互換性に依存する。不慣れな接続方式を持つ新規公開サービスは、依然として統合作業を生む。ランタイム検出は一部の判断を後ろへ移すが、あらゆるサービスを即座に利用可能にするものではない。
したがって重要な境界は、アプリケーションがサポートする接続契約である。開発者は、プロトコル、アクセス手段、実行ポリシーの制御を維持しながら、その契約の範囲内で新しい機能を許可できる。これは、普遍的なプラグアンドプレイ統合よりも限定的で有用な約束だ。
AWS Agent Registryのランタイム検出を評価する読者がまず問うべきなのは、このアーキテクチャが実際にどの変更を切り離すのかという点である。互換性のある機能を追加することは、機能が実行される規則を変えることとは異なる。
プラットフォームチームはカタログ公開の課題を引き継ぐ
AWSは、governed capability catalogを、公開および承認ワークフローを備えた管理型の検出サービスとして説明している。そのドキュメントでは、公開者、キュレーター、コンシューマーを区別している。これらの役割は重要な組織上の帰結を明らかにする。機能の検出には継続的な所有責任が必要だ。
実行時の選択は、調整作業を個々の統合リリースから、カタログの公開、レビュー、保守へと移す。
プラットフォームエンジニアは最も直接的な圧力に直面する。ビルド時の接続設定では、アプリケーションリポジトリが明白な調整ポイントとなる。変化するカタログでは、どの機能が一体として扱われるべきか、どの変更に広範なレビューが必要かを定義する別の方法が必要になる。
機能の所有者には異なる責務がある。コンシューマーがいつそれを選択すべきか理解できなければ、動作するエンドポイントだけでは不十分だ。所有者は、想定するタスク、重要な除外事項、期待される入力、運用上の制限を、別チームが接続を評価できるほど明確に記述すべきである。
これは、チーム間の共有インターフェースを維持することに似ている。説明は意味を担い、接続契約はソフトウェアが実際に何を行えるかを決める。いずれかに弱点があれば、調整エージェントが確実に解消できない混乱が生じ得る。
承認にも具体的な目的が必要だ。組織は、機能を受け入れる前にセキュリティ態勢、所有責任、サポートの約束、互換性を確認するかもしれない。これらの確認は異なる問いに答えるため、承認というラベルがあらゆる保証の略称になるべきではない。
承認済みのサービスであっても、特定のユーザーリクエストには不適切な場合がある。本番環境のレポーティングツールは主題に関連していても、リクエストした従業員には利用できない可能性がある。サポート機能はポリシーを説明できても、注文を変更する権限を持たない場合がある。
エンタープライズの購入者にとって、これはより具体的な調達上の議論を示唆する。誰がカタログレコードを保守するのか、誰が変更を承認するのか、公開済みの機能が利用不能になったとき誰が対応するのかを問うべきだ。管理型の検出サービスだけでは、こうした社内責任を割り当てられない。
同じ区別は組織の知識にも当てはまる。チームには、機械可読なレコードと並んで、意思決定、例外、運用手順を共有する場所が必要だ。searchable knowledge baseはこの文書化のニーズに対応し、レジストリは実行時の検出を担う。
課題は単にすべてを集中化することではない。広すぎるカタログはガバナンスが難しくなり得る一方、狭く孤立したカタログは、検出によって減らすべき調整上の問題を温存しかねない。チームは実際の所有責任と利用パターンに沿って境界を選ぶべきだ。
進捗を測る有用な指標は、リリース間の依存関係が減ることだろう。新しい機能のたびにオーケストレーターの編集、調整された承認、手作業によるコンシューマー更新がなお必要であれば、組織はディレクトリを得ただけで、アーキテクチャ上の独立性をあまり実現していない。
逆に、独立した公開は見えない振る舞いの変更を意味すべきではない。コンシューマーには、どの機能がアプリケーションの到達範囲に加わったかを理解する手段が必要だ。所有責任と変更に関するコミュニケーションが明示的であり続けるとき、運用上の独立性は最もよく機能する。
このループは検索、接続、実行を分離する
AWS Agent Registryのランタイム検出の仕組みは、各段階を別個の判断として扱うと明確になる。関連する機能を見つけること、接続を確立すること、どのアクションを取るかを決めることは関連したタスクだ。それぞれに異なる根拠と異なる制御が必要となる。
AWSは、意味に基づくセマンティックマッチングとキーワードマッチングを組み合わせるhybrid registry searchを文書化している。名前、説明、プロトコル記述子が関連性に影響する。記述子とは、機能とその接続情報を記述する構造化メタデータである。
検索ドキュメントでは、検出可能な結果が承認済みレコードに限られることも示されている。検索インデックスは結果整合性を持つため、承認済みの変更がすぐにあらゆる場所で可視化されるわけではない。これらの特性により、検出はガバナンスの仕組みであると同時に、変化する実行時依存関係にもなる。
検索は候補集合を絞り込むが、アプリケーションにはなお有効な接続を確立し、適切なアクションを選ぶ必要がある。
AWSのサンプルでは、検出は機能を呼び出すために必要な認証情報である呼び出し資格情報なしに、接続メタデータを返す。アプリケーションは資格情報を別途取得する。その後、検出された機能から一時的な内部エージェントを組み立て、リクエスト後にクライアントを解放する。
関連性は権限を確立しないため、この分離は重要だ。あるサービスはリクエストに非常によく合致していても、アプリケーションからアクセスできない場合がある。逆に、アプリケーションが有効な資格情報を持つサービスであっても、現在のタスクを扱うべきではない場合がある。
したがって、アプリケーションが関連するクライアントを構築するinstantiate段階は、統合の境界として理解すべきだ。ソフトウェアは記述子を解釈し、接続タイプを認識し、確立済みの認証経路を適用しなければならない。検索結果はこれらの確認に代わるものではない。
execute段階は別の境界を導入する。サポート機能を選んでも、アプリケーションが情報を取得すべきか、変更を提案すべきか、その変更を実行すべきかは決まらない。組織は、取得における関連性にそれらを表現させるのではなく、実行ポリシーでこうした区別を定義すべきである。
仮想的な返金リクエストはこの違いを示す。検出によってポリシー専門機能と注文情報サービスが特定されるかもしれない。それでもアプリケーションには、顧客の本人確認、正しい取引の取得、適格性に関する助言と返金を実行する権限の区別が必要となる。
このアーキテクチャが魅力的なのは、リクエストに対してモデルが目にする対象を絞り込めるためだ。同時に、上流の依存関係も生む。モデルが機能を選択する前に、適切な機能が候補集合に到達しなければならない。有能なモデルでも、受け取っていない統合を選択することはできない。
これは各段階を別々に評価することを示唆する。候補が欠けているなら検出の問題だ。接続が拒否されるなら認証または互換性の問題だ。接続に成功した後の不適切なアクションは実行の問題である。これらを単一の障害カテゴリにまとめると、改善の対象を絞り込みにくくなる。
このループは、以前の結果の再利用であるキャッシュが、どこでポリシー上の選択となるかも明らかにする。検出結果を再利用すれば繰り返しの作業を減らせるかもしれないが、チームは鮮度と機能の撤回がその選択にどう影響するかを決めるべきだ。適切なバランスは、アプリケーションの影響の大きさに依存する。
Anthropicのツール検索は、より広いアーキテクチャ上の変化を示す
AWSは、クラウドカタログ管理を超える問題に取り組んでいる。Anthropicのオンデマンドツール検索では、ツール定義を関連性が生じるまで遅延させる手法が説明されている。共通する考え方は、生成時に利用できる情報であるモデルのコンテキストへ、完全な機能ライブラリを配置しないことだ。
Anthropicが公開したアプローチでは、選択された定義に遅延読み込みのマークを付ける。Claudeはその後、関連ツールを検索し、必要に応じてその定義を受け取れる。これは、両アプローチを互換性のある製品として扱わずにAWSの方向性を理解するうえで有用な文脈となる。
共通する設計原則は選択的な公開であり、統合に関する責任は各システム固有のままである。
この比較は、基礎となるアーキテクチャ上の選択とベンダーの位置づけを分けて考える助けになる。すべてのツールを先に読み込むことが無駄である点にはチームで合意できる一方、最重要ワークフローには明示的な接続を選ぶこともできる。選択的な公開は、すべてのアプリケーション判断を動的にする必要を意味しない。
この比較は、新規性を過度に主張することも防ぐ。ランタイムでの発見は、拡大する機能ライブラリを管理するより広範な取り組みの一部だ。AWSの例は、業界が問題をようやく発見したことを示すのではなく、具体的なエンタープライズパターンを提示している。
プラットフォームチームにとって重要な問いは、カタログに関する判断をどこに置くべきかだ。一部のアプリケーションでは、個別に保守される機能をまたぐ中央統制されたディレクトリが必要となる。別のアプリケーションでは、既存のツールライブラリがモデルで利用可能なコンテキストを圧倒しないようにすることが主な課題となる。
これらの要件は重なるものの、同一ではない。プロンプトを小さくしても、承認ワークフローが自動的に提供されるわけではない。統制されたカタログがあっても、特定のモデルやタスクに最適な選択戦略が自動的に決まるわけではない。
明示的な配線を支持する最も強い主張にも、公平に耳を傾ける価値がある。ワークフローに安定した順序と限定的な機能セットがある場合、開発者は意図した接続を直接確認できる。ランタイム検索は、別の判断ポイントを正当化する明確な利点を示す必要がある。
仮想的な定期照合プロセスは、そのケースをよく示している。アプリケーションが常にレコードを取得し、比較し、承認済みレポートを書き込むなら、同じ機能を毎回検索しても価値はほとんど加わらない可能性がある。順序そのものが、すでにビジネス要件を表現している。
汎用アシスタントは異なる状況に直面する。依頼は無関係なタスクにまたがり得るうえ、利用可能な機能はそれぞれ独立して変化するチームに属し得る。完全で明示的なインベントリを維持することが継続的な調整作業を生む場合、ランタイム選択はより説得力を増す。
ここから、実践的な評価原則が導かれる。同じタスクと変更シナリオに対してアーキテクチャを比較することだ。通常の実行、機能追加、障害、復旧を含める。説得力のあるデモは、柔軟性が本質的に価値あるものだと仮定するのではなく、動的選択が有効な場面を示すべきである。
購入者は、カタログ規模だけでアーキテクチャを判断することにも抵抗すべきだ。より意味のある問いは、カタログが変化しても有用な機能を発見でき、正しく適用できるかどうかである。通常の依頼でも手動ルーティングが必要なら、印象的なインベントリの価値は限定的だ。
発見品質には独自の本番環境での証拠が必要
最も重要な不確実性は、デモの先にある挙動に関するものだ。AWSのウォークスルーはループを示しているが、特定のエンタープライズカタログがどのように機能するかを立証するものではない。本番環境での主張は、アーキテクチャ図ではなく代表的な評価に基づくべきである。
discovery APIは、関連度順に並べられた一致メタデータを返し、構造化フィルタリングをサポートする。これにより候補セットは、観測可能なアプリケーション出力となる。チームは、モデルが次に何をしたかを調査する前に、discoveryが何を返したかを確認できる。
本番環境の評価では、機能を使用すべきでない依頼も含め、discoveryが必要な機能を提供するかを測定すべきである。
まず、もっともらしい結果と十分な結果の違いから始める。請求の専門家は注文に関する質問と関連しているように見えても、回答に必要な配送情報を持たないかもしれない。評価者は、関連する説明を持つ結果で満足するのではなく、完了に必要な機能を特定すべきである。
曖昧な依頼には特に注意が必要だ。ユーザーが「注文を直して」と求める場合、住所変更、請求修正、破損品の報告を意味しているかもしれない。安全なアプリケーションは、強い検索一致を確定した意図と解釈するのではなく、確認が必要な場合を認識すべきである。
ネガティブケースも同様に重要だ。一部の依頼では、カタログに適切な機能がないため接続を作成すべきではない。別の依頼では、ユーザーに権限がない、または要求された操作がアプリケーションの範囲を超えるため停止すべきである。
カタログの成長は、明示的なテスト条件にすべきである。重複する機能の追加、説明の改訂、サービスの廃止後に、チームは同じ評価を繰り返すことができる。これにより、オーケストレーターのソースが変わらなくても、通常の保守変更によって依頼のルーティングが変化するかどうかが明らかになる。
説明の品質も、宣伝的な表現を助長せずに評価すべきである。公開者には、自らの機能を発見可能にしたいという動機がある。レビュー担当者は、あらゆる隣接タスクを扱えると主張する説明よりも、正確な適用範囲と除外事項を重視すべきである。
discoveryと認証が分離されていることで、有用な障害ケースをテストできる。関連する機能であっても、認証情報の期限切れ、利用できないエンドポイント、互換性のないレスポンスがあり得る。アプリケーションは、より不適切な操作に黙って置き換えることなく、制約を説明すべきである。
復旧も同等に精査する必要がある。情報検索の再試行と、業務レコードを変更するリクエストの再試行は異なる。チームは、自動復旧によって操作を再発行できるようにする前に、その操作が安全に繰り返せるかを確立すべきである。
運用上の証拠は、リクエストを選択された機能および最終的な結果につなげるべきである。そうでなければ、流暢な回答が、失敗した検索、意図しないフォールバック、または完了しなかった操作を覆い隠す可能性がある。レビュー担当者には、応答品質だけでなく実行に関する証拠も必要だ。
評価が失敗した場合には、責任の所在という問題もある。責任者は、機能の公開者、カタログのキュレーター、またはアプリケーションチームかもしれない。こうした責任を早期に定義すれば、部門をまたぐランタイム選択の運用が容易になる。
AWS Agent Registryのランタイムdiscoveryについて、防御可能な約束は、定義された境界内でのアーキテクチャ上の柔軟性である。精度向上、運用負荷の低減、保守の容易化は、各デプロイメントが実証すべき成果であり続ける。
移行、カタログ成長、独立した公開を注視する
直近の観測ポイントは具体的だ。AWSのregistry migration guideによると、専用のagent-registry名前空間は2026年8月6日に開始された。名前空間とは、インターフェースや設定全体で使用されるサービス識別子である。プレビュー版のbedrock-agentcore registry名前空間のサポートは10月30日に終了する。
このガイドは、サービスエンドポイント、権限、クライアント、リソース識別子、および関連設定に影響する変更を説明している。ほかのAgentCoreの提供機能は、このregistry名前空間変更の影響を受けないとしている。したがって、既存のプレビュー利用者にとって、移行は短期的な運用上の懸念事項である。
次に求められる証拠は、移行の完了、カタログ成長下での安定したdiscovery、そして不要なオーケストレーター変更を避ける機能追加を示すべきである。
まず、プレビュー利用者が移行を完了し、discoveryパスを検証するかを注視する。設定更新が成功した後には、意図したアプリケーションが承認済み機能を引き続き見つけて呼び出せることを示す証拠が必要である。これは運用継続性への信頼を強めるだろう。
移行の失敗だけで、ランタイム選択が無効になるわけではない。ただし、変化するマネージドインターフェースに依存する保守上の要求は明らかになる。チームは、サービス移行の問題と、検索または実行設計の弱点を区別すべきである。
次に、依頼セットを固定したままカタログを拡張する評価を注視する。有用なシグナルは、重複や曖昧さが増えても必要な機能が継続して発見されることだ。成功例だけを報告しても、中心的なスケーリングの問いは未解決のままである。
選択品質の悪化を示す証拠は、追加の制御なしに広範な導入を進める根拠を弱める。説明基準、カタログ境界、フィルタリング、または評価実務の見直しが必要であることを示唆する。カタログの拡張は、テストに値する挙動の変化として扱うべきである。
第三に、独立したチームが日常的なオーケストレーター編集なしに、互換性のある機能を公開できるかを注視する。これは、接続をビルドから切り離すことで示唆される組織上の見返りである。最も強い証拠には、公開だけでなく、オンボーディング、認証設定、所有権、撤回が含まれるだろう。
追加のたびに調整アプリケーションで特別な処理が必要になるなら、このアーキテクチャが提供する独立性は、その図が示唆するほど大きくない。予測可能な挙動を維持しながらチームが機能を追加できるなら、ランタイムdiscoveryはリリース調整に測定可能な変化をもたらしたことになる。
これらのシグナルは、自律型エージェントに関する大まかな予測よりも重要だ。移行中の継続性、成長中の信頼できる選択、機能変更時の調整削減という、観測可能なエンジニアリング成果に設計を結び付けるからである。
初期評価では、機能の所有権がすでにチームをまたいでいる範囲を限定したワークフローを選ぶ。AWS Agent Registryのランタイムdiscoveryを導入する前に、現在のリリース依存関係と障害時の挙動を確立する。代表的な依頼、想定される機能、許容できない操作を明確に保つ。通常の依頼を、曖昧な質問、存在しないサービス、アクセス拒否と比較する。次に、互換性のある機能を導入し、公開、承認、認証、discovery、実行の各段階で実際に何が変わるかを検証する。将来の保守担当者が境界を理解できるよう、技術的判断とともに所見を保存する。カタログを拡張する前に、アプリケーションが拡張しやすくなった一方で、その挙動に責任を持つ人々にとって理解可能なままであるかを問う。
