10月30日、AWSが「How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway」と題した記事を公開した。25の開発チームが保有する約400本の内部REST APIを、MCPの知識を持たないチームに一切手を入れさせることなくAIエージェント向けツールとして公開した事例だ。「誰がMCPを管理するか」という組織的な問題をアーキテクチャで解決した実装として注目に値する。

「20個のMCPサーバー」という罠

AIエージェントを構築する際、エージェントが必要とする機能はほぼ確実に既存の内部APIとして存在している。問題は機能を作ることではなく、数百の非公開APIをエージェントから安全に呼び出せる状態にすることだ。

MoEngageは1,350以上のブランドが利用するカスタマーエンゲージメントプラットフォームで、プッシュ通知・メール・SMS・WhatsApp等のチャネルを横断するパーソナライズ配信を提供している。その裏側には25の開発チームが構築した約400本の内部REST APIが存在し、7つのAWSリージョンのプライベートVPC内で稼働している。データ所在地（データレジデンシー）要件のため、これらAPIはパブリックインターネットに公開されていない。

MCP（Model Context Protocol）はエージェントがツールを発見・呼び出すための標準プロトコルだ。素直な実装方針は各チームが自前のMCPサーバーを立てることだが、MoEngage社はこれを試算した上で却下した。

• 20本以上のMCPサーバー＝20本以上の独立したデプロイ・パッチ・プロトコル追従の対象
• キャンペーン確認→セグメント確認→配信統計確認のような横断エージェントは複数のサーバーへ同時接続する必要がある
• 各チームがMCPの知識を持つ必要が生じ、本来の開発業務と無関係なオーバーヘッドが発生する

そこでMoEngage社が打ち出した原則が、この設計全体の骨格となった。「個々の開発チームはMCPを実装しない。チームはREST APIを作り、OpenAPI仕様書を書く。MCPレイヤーはAI Platformチームが一元管理する」。

4つの制約条件とAgentCore Gatewayとの対応

MoEngageはソリューション評価の前に4つの制約を定義し、すべてを同時に満たすことを要件とした。

① パブリックエンドポイントを作らない
内部APIはポリシー上VPCプライベート。従来の回避策であるNATゲートウェイやリバースプロキシをリージョンごとに設置する方法は、7リージョン×統合数でオペレーション負荷が爆発する。

② 認証情報をモデルに触らせない
APIコールにはテナント・ユーザー・ロール・DBコンテキストが必要だ。これがLLMから見えるツールパラメータになると、モデルが誤った値を渡すリスクや、プロンプトインジェクションで上書きされるリスクが生じる。

③ 400本のツール定義をコンテキストウィンドウに詰め込まない
ツール1件あたり約50トークンのJSONスキーマとして、400件のツール一覧は2万トークン超になる。エージェントが実際のタスクを考える前にトークン予算を使い果たしてしまう。

④ ツールのスコープはクライアントではなくサーバー側で制御する
クライアント側でのフィルタリング（ADKのtool_filter等）は、既に全ツール定義がネットワークを流れた後の処理だ。書き込み操作を参照すべきでないエージェントには、そもそも定義を送るべきではない。

AgentCore Gatewayがこの4条件をどう解決するか

Amazon Bedrock AgentCore GatewayはフルマネージドのMCPサーバーだ。OpenAPI仕様を登録するとゲートウェイがMCPツールを自動生成し、バックエンドサービスへのルーティングを行う。

OpenAPIからMCPツールへの自動変換

チームが既存で管理しているOpenAPI仕様がそのままツール定義になる。各エンドポイントはCampaignsAPI___searchCampaignsのような名前のツールとして自動生成される。仕様が変わればツールが変わり、エンドポイントが追加されればツールが現れ、削除されれば消える。デプロイ作業も、MCPの知識も、AI Platformチームへの調整連絡も不要だ。

Cedarポリシーによるサーバーサイドスコープ制御

CedarはAWSが開発したポリシー言語だ。AgentCore Gatewayはこれを使い、tools/listレスポンスを構築する前に各エージェントのIAMロールに基づくフィルタリングを行う。元記事に掲載されているポリシー例は以下のとおりだ。

permit(
    principal == Agent::"campaign-qa-bot-v1",
    action == Action::"tools/call",
    resource in ToolGroup::"campaigns-read"
);

forbid(
    principal == Agent::"campaign-qa-bot-v1",
    action == Action::"tools/call",
    resource in ToolGroup::"write-actions"
);

このボットのツール一覧レスポンスには書き込みツールが含まれない。クライアント側でフィルタリングする必要がないのは、そもそもツール定義が送られていないからだ。

VPC Lattice経由のプライベート通信

ゲートウェイはAmazon VPC Latticeを通じてMoEngage内部サービスへ到達する。エージェントからゲートウェイへの経路はプライベートDNSを持つVPCインターフェイスエンドポイント経由で、パブリック経路は存在しない。新しいAPIを追加してもネットワーク構成を変更する必要がなく、7リージョン問題を根本から回避できる。

セマンティック検索によるツール探索

x_amz_bedrock_agentcore_search機能により、エージェントはツール名ではなくタスクの説明でツールを検索できる。MoEngageの実装では、モデルに公開するのは最初はsearch_toolsという1つのメタツールのみだ。モデルが何が必要かを説明すると、セマンティック検索で候補が返り、そのターン内で呼び出し可能なツールが絞り込まれる。コンテキストに入るのは最初の1定義と、検索後の数件だけで、400件分が流れることはない。

新しいAPIのオンボーディング方法

開発チームがやることは、既存のOpenAPI仕様に以下のようなブロックを追加するだけだ。

paths:
  /campaigns:
    get:
      operationId: listCampaigns
      description: |
        Returns a paginated list of campaigns.
      x-moe-mcp:
        expose:
          external: false
          internal: true
        tool_description: |
          Find campaigns by status or channel. Returns campaign ID, name,
          status, and channel. Use the returned campaign_id with
          get_campaign for full details, or send_campaign to launch it.
        param_overrides:
          status:
            description: |
              Filter by campaign status. Use 'active' for running
              campaigns, 'scheduled' for upcoming. Omit for all.

いくつか設計上のポイントがある。x-moe-mcpブロックがないエンドポイントはツールにならない。キャッシュウォームアップやマイグレーショントリガーのような内部エンドポイントが誤ってツール化されないよう、オプトイン方式を採用している。internalとexternalフラグで内部エージェント向け・公開MCPサーバー向けを独立して制御できる。

また、tool_descriptionとapi_descriptionを分けている点も重要だ。API仕様書の説明はドキュメントを読む開発者向けで、ツール説明はモデルが「いつこのツールを使うか」を判断するためのものだ。MoEngageは「実装詳細」を書いたAPI説明文をそのまま流用したところ、モデルのツール選択精度が低下したと報告している。

CIパイプラインが仕様のバリデーション・ターゲット登録・Cedarポリシー適用をすべて自動実行するため、MCPを一度も意識したことがないチームでも、パイプライン実行時間内にエンドポイントをエージェントツールとして公開できる。

現在の稼働状況

元記事によれば、AgentCore Gatewayは現在7リージョンで本番稼働しており、約400のAPIオペレーションが10本の内部エージェントに提供されている。キャンペーンQAエージェント・配信健全性監視エージェント・自然言語でセグメント構築を行うエージェント等が日常的に使われているという。どの製品チームもMCPサーバーのコードを書かず、エージェント連携のためのネットワーク設定もせず、Cedarポリシーも実装していない。 MoEngage社によれば、このアーキテクチャにより約6ヶ月分のプラットフォームエンジニアリング工数を節約できたと推定している。新規APIのオンボーディングはかつて数日かかっていたが、現在は数時間で完了する。

詳細はHow MoEngage turned over 400 APIs into agent tools with AgentCore Gatewayを参照していただきたい。