AgentCore GatewayでOpenAPI定義をツールに変換し、呼び出し元ごとの権限を適用します。本人識別情報をモデルに設定させず、既存APIへの非公開接続を保ちます。 ツールを見せる範囲と実行できる範囲をサーバー側で揃えることが焦点です。構築期間の削減見積もりはMoEngageの条件に基づくものです。 既存APIを増やさずエージェントへつなぐ AWSは10月29日、MoEngageと共同でAgentCore Gatewayの導入事例を公開しました。同社は25の開発チームが作る約400の内部REST APIを、7つのAWSリージョンにある非公開の環境で運用しています。エージェントに必要な機能は既存APIにあり、課題はその機能を権限に沿って接続することでした。チームごとにMCPサーバーを作る方式ではなく、共通の入口でAPIをツールへ変換する方針を採用しました。各開発チームはOpenAPI定義を用意し、AI基盤チームがMCPの層を担当します。原文は自社の構成と判断の事例であり、あらゆる組織で同じ期間や効果になることを示すものではありません。 本人識別とツール一覧をモデルから切り離す AgentCore GatewayはOpenAPIの操作をMCPのツールとして扱います。MoEngageの設計では、テナントや利用者などの情報をモデルが変えられる引数として見せず、呼び出し側で与えます。さらに、Cedarの方針で呼び出し元ごとにツール一覧を絞り、許可された操作だけを配信します。大量のツールを受信してから利用側で隠す方式とは、権限の境界が異なります。非公開のAPIをインターネットへ公開しない接続も重視しています。これにより、機能を持つ各製品チームと、権限や接続を管理するチームの役割が分かれます。同社は基盤開発を約6か月分省けたと見積もり、API追加が日単位から時間単位になったと報告しました。これは事例の見積もりであり、製品を使えば自動的に同じ削減が得られるとの保証ではありません。既存の定義の品質が移行の負担に影響すると見られます。 APIの説明と権限の保守を同時に進める 実務では、ツールを自動生成できることに加えて、その操作の意味が正しく説明されるかが論点になります。入力項目やエラーの説明が曖昧なら、モデルが適切なツールを選べない可能性があります。また、利用者の識別をサーバー側で与えても、後段のAPIが同じ範囲を確認するかを点検する余地があります。接続の管理を集約する方式では、共通基盤の障害が複数の仕事へ及ぶため、停止時の対応も判断材料です。新しいAPIを加える担当者と、権限を承認する担当者を定めることで、便利さと管理の整合を保ちやすくなると見られます。検証では、許可された操作が成功するだけでなく、許可外の一覧や操作が届かないかを確認する方法が考えられます。導入事例の工数削減と、自社で維持する定義、方針、監視の費用を並べて評価することが重要です。