Google Cloud API GatewayがMCPサーバーとして機能

API Gatewayは単一のエンドポイントで標準的なMCP JSON-RPCリクエストを受け付け、各tools/callを対応するREST呼び出しに変換する。既存ポリシーを適用したうえで応答をMCP形式に戻す。変換後のリクエストは通常のRESTコールと区別がつかないため、MCPとREST は同じポリシー経路を共有し、1つの操作は呼び出し方に関わらず同じクォータ配分を使う。 設定の流れは4段階である。まずOpenAPI 3.0.xまたは3.1.xの仕様に注釈を付ける。OpenAPI 2.0は非対応で、先に移行が必要となる。ドキュメント単位では`x-google-api-management.mcp`で有効化し、個別操作は`x-google-mcp-tool`でカスタマイズまたは除外する。公開する操作にはバックエンドと空でないdescriptionが必要で、LLMがツールを呼ぶ判断に使うため、何を返すかだけでなくいつ・なぜ使うかを書くよう勧めている。次に通常どおりAPI構成をデプロイすると、/mcpのベースパスでMCPの提供が始まる。 tools/listは既定で認証不要で、開発には便利だがツール名と入力スキーマが誰にでも見える。本番ではJWTを要求する設定が可能で、この方法ではAPIキーは使えない。tools/callは、探索を保護するかどうかに関わらず、元のREST操作が求める認証を常に適用する。接続はMCPクライアントを/mcpに向けるだけで、ADKではMcpToolsetとStreamableHTTPConnectionParamsにゲートウェイが期待する認証情報を渡す例が示されている。 API hubと連携するとMCP固有のメタデータ付きで公開され、Agent Registryにも自動で表示される。Public PreviewはRESTとOpenAPI 3.xバックエンドが対象で、MCPのリソースとプロンプト、レスポンスのストリーミング、Model Armorによるペイロード検査はロードマップにある。制約として、HTTP 204のように本文が空の操作は公開されず、深くネストしたオブジェクトスキーマはtools/listで完全に表示されない場合がある。1つのゲートウェイで提供できるツールは最大1,000個で、MCPとモデルルーティングは同じAPI構成で併用できない。 位置づけとして、API GatewayはGoogle Cloudのゲートウェイ群の軽量な入口である。ライフサイクル管理や高度なトラフィックポリシー、収益化まで含む本格的なAPI・MCPプラットフォームにはApigee、エージェントが外部へ呼び出す先の統制にはAgent Gatewayを使うと説明している。

Google Developers Blogより