はじめに：MCPサーバーをまた作るのかという課題

AIエージェントを実務に組み込んでいると、最終的には社内のREST APIをツールとして公開する必要が出てきます。しかし従来の方法は手間がかかります。エージェントから呼び出せるようにするために別のMCPサーバーを構築し、ゲートウェイがすでに処理していたルーティング・認証・クォータのロジックをそのサーバーに再実装しなければなりませんでした。管理対象が増えるだけです。

Google Cloud API Gatewayはこの部分を整理しました。すでにデプロイしているOpenAPIスペックにMCP関連のアノテーションを付けるだけで、ゲートウェイ自体がリモートMCPサーバーとして動作します。新たにホスティングするサーバーも、保守するコードも不要です。現在はPublic Preview段階で、RESTおよびOpenAPI 3.xバックエンドを既存の認証体系のままサポートしています。

本記事では、実際にスペックを修正し、デプロイし、ADKエージェントに接続する流れを順を追って解説します。

この機能の公式発表内容は根拠資料で確認できます。

Google Cloud API Gateway architecture diagram connecting REST APIs to AI agents via MCP protocol System Abstract Visual

実装の核心：OpenAPIスペックにMCPアノテーションを付与する

ステップ1. スペックでMCPを有効化

既存のOpenAPIスペックの上部にx-google-api-management.mcp: trueを追加すると、そのスペックの全オペレーションがMCPツールの候補になります。バックエンドのアドレスも併せて指定してください。

openapi: 3.0.4
info:
  title: Order Service
  version: 1.0.0
x-google-api-management:
  mcp: true  # このスペックのオペレーションをMCPツールとして公開
  backends:
    orders-backend:
      address: https://orders-a1b2c3-uc.a.run.app
paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      description: Returns the current status, carrier, and ETA for an order.
      x-google-backend: orders-backend
      x-google-mcp-tool:
        name: get_order_status
        description: "Look up the delivery status and ETA of a customer order.
          Use this when the user asks where an order is or when it will arrive."
        parameters:
          - name: orderId
            in: path
            required: true
            schema:
              type: string

ここで重要なのは**descriptionの書き方**です。LLMはツールの説明を見て呼び出すかどうかを判断するため、「何を返すか」よりも「いつ、なぜこのツールを使うべきか」を書く必要があります。上記の例のように、ユーザーの質問シナリオをそのまま含めるのが効果的です。

ステップ2. ゲートウェイのデプロイ

通常どおりAPI configをデプロイするだけです。API GatewayがMCP対応の設定を自動生成し、/mcpベースパスで配信を開始します。追加のインフラプロビジョニングはありません。

ステップ3. ツール検索の権限制御

デフォルトではtools/listは認証なしで公開されています。開発中は便利ですが、本番ではツール名と入力スキーマがそのまま公開される点に注意が必要です。本番環境ではJWTを要求してください。APIキーではこのメソッドを保護できません。

x-google-api-management:
  mcp:
    tools-list:
      security:
        orderServiceJwt: []  # オブジェクト形式にするとMCP全体が有効化される

tools/callは設定に関わらず、常に既存RESTオペレーションの認証を強制します。検索はブロックし、呼び出しは許可する構造がデフォルトというわけです。

ステップ4. ADKエージェントへの接続

MCPクライアントをゲートウェイの/mcpエンドポイントに向けるだけです。ADKではMcpToolsetにゲートウェイが期待する資格情報を渡せば完了します。

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import McpToolset, StreamableHTTPConnectionParams

order_tools = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp",
        headers={"x-api-key": API_KEY},
    )
)

agent = Agent(
    model="gemini-2.5-flash",
    name="order_support_agent",
    instruction="Help the user check on their orders.",
    tools=[order_tools],
)

ゲートウェイはツールの引数をRESTのpath・query・body・headerにマッピングし、既存ポリシーを通したうえでレスポンスをMCP結果に変換します。実際のワイヤ上でどう見えるかは、次のように呼び出して確認できます。

curl -X POST "https://my-gateway-a12bcd345e67f89g0h.uc.gateway.dev/mcp" \
  -H "content-type: application/json" \
  -H "MCP-Protocol-Version: 2025-11-25" \
  -H "x-api-key: $API_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"get_order_status","arguments":{"orderId":"A-1042"}}}'

レスポンスはJSON-RPC形式で返ります。

{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text",
"text":"{\"orderId\":\"A-1042\",\"status\":\"IN_TRANSIT\",\"eta\":\"2026-09-24\"}"}],
"isError":false}}

MCPトラフィックとRESTトラフィックが同一のポリシーパスを共有する点がこの構造の要点です。認証・クォータ・ログをMCP用に別途作る必要はありません。

Developer deploying OpenAPI spec with x-google-mcp-tool annotations on Google Cloud console Algorithm Concept Visual

注意点と制約：現時点で使えないもの

Public Preview段階のため、カバレッジに制約があります。実務投入前に必ず確認すべき項目です。

項目現状実務への影響
REST / OpenAPI 3.xバックエンド対応大半の社内APIをカバー
既存認証体系（JWT、APIキー）そのまま再利用マイグレーションコストなし
MCP resources / promptsロードマップまずはツール呼び出しのみ対応
レスポンスストリーミングロードマップ長時間応答はポーリングが必要
Model Armorペイロード検査ロードマップセキュリティポリシーは別途設計が必要
HTTP 204など空ボディ応答非公開削除・状態変更APIはツール化不可
深いネストのオブジェクトスキーマtools/listで一部非表示複雑なリクエストモデルは簡略化を推奨
ゲートウェイあたりのツール数最大1,000大規模APIは分割デプロイを検討
MCP + モデルルーティングの同時有効化不可同一API configで併用不可

特に空ボディ応答（204）が公開されない点は意外と影響が大きいです。「注文キャンセル」「状態変更」のようなアクション系APIはレスポンスボディを持たないことが多いからです。こうしたオペレーションは別途ラッパーを用意するか、レスポンスに確認メッセージを含める形で回避する必要があります。

もう一点、tools/listを認証なしで公開すると、ツール名と入力スキーマがそのまま露出します。内部API構造を外部に知らせることになるため、本番デプロイ時には必ずJWTセキュリティ設定を行ってください。

日本開発エコシステムでの適用文脈

日本のエンタープライズ環境では、APIゲートウェイがすでに社内標準として定着しているケースが多く見られます。この機能の真の利点は既存ゲートウェイポリシーをそのまま再利用できる点です。別途MCPサーバーを立てるとセキュリティ部門・インフラ部門と再協議が必要になりますが、この方式はすでに承認済みの認証・クォータ体系を通すため、社内承認プロセスが大幅に短縮されます。

ただし、Cloud Run以外のオンプレミスバックエンドや社内ファイアウォール内のサービスは別途検討が必要です。API Gatewayがパブリックエンドポイントに出る構造のため、内部網専用APIをそのまま公開してはいけません。VPCルーティング設計を先に確認してください。

次の学習ステップ

MCPの仕様そのものを理解したい場合は、Model Context Protocolの公式仕様（tools、resources、promptsの3プリミティブ）を読むことをおすすめします。QiitaではADKとMCPを組み合わせたエージェント構築の記事が増えているので、実装パターンの比較に役立ちます。

AI agent using McpToolset in ADK to call order status REST API through gateway Programming Illustration

まとめ：今日から最初のツールを公開してみましょう

整理すると以下のとおりです。

  1. 既存OpenAPIスペックにx-google-api-management.mcp: trueを1行追加
  2. オペレーションごとにx-google-mcp-toolでツール名と説明を指定（説明は「いつ使うか」中心に）
  3. 通常どおりデプロイ → /mcpパスで自動配信
  4. 本番ではtools/listにJWTセキュリティを必須化
  5. ADKのMcpToolsetでエージェントに接続

別サーバーを運用しなくてよい点が最大の変化です。認証・クォータ・ログがMCPとRESTにまたがって単一のポリシーパスに統合されるため、セキュリティ監査の観点でも説明しやすい構造といえます。

次のステップとしては、MCP resourcesとpromptsがロードマップにありますので、ツール呼び出し以外にコンテキスト提供まで拡張されるタイミングを注視するとよいでしょう。それまではツール説明を精緻に磨くことに集中してください。LLMがツールを誤選択する問題の8割は、説明の不足に起因します。

あわせて読みたい記事

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。