Google が REST を API Gateway の MCP に載せたあと、発見がまだ JSON な理由：OpenAPI 3.x から tools/list へ

結論から：Gateway が MCP Server を肩代わりする。発見契約はなお JSON である。2026 年 9 月 24 日、Google の開発者ブログは、Cloud API Gateway が Public Preview で、すでにデプロイした OpenAPI 3.x 操作をリモート MCP ツールとして出せると書いた——別の MCP Server を建て、ホストする必要はない。ドキュメントは先に着いた：9 月 11 日のリリースノートはすでに Enable MCP を載せている。Gateway は /mcp で標準 JSON-RPC を受け、tools/call を既存の REST リクエストへトランスコードし、JWT、API Key、クォータ、ログを一本のポリシー経路に置く。Agent が見るのは「REST が魔法になった」ではない。tools/list が出すツール名と input schema である——なお JSON。

本稿は 2026 年 9 月 30 日時点。その日なお有効な開発者ブログと API Gateway ドキュメントに拠る。本サイトにはすでに MCP とは何か、Skill 発見がなお JSON である理由、悪意ある JSON と Tool Calling がある。本稿が答えるのは次だけ：OpenAPI が Gateway に載ったあと、どの JSON 層を先に確かめ、どの層が既定で開いているか。

Gateway が MCP Server になったとき、実際に出たもの

公式の一文は短い：企業の能力の大半は REST の後ろにあり、Agent からは見えない。チームはたいてい第二の MCP Server を立て、ルーティング、認証、クォータをもう一度実装する。API Gateway は Google Cloud のゲートウェイ列の、軽い入口である。数分で管理し Agent へ出したい Cloud Run サービスはここへ行く。フルライフサイクル、重いトラフィックポリシー、マネタイズは Apigee に残る。外向きの Agent 呼び出し——この種の MCP Server を含む——は Agent Gateway を通る。外向きのモデルルーティングは逆方向であり、MCP と同じ API config を共有できない。

サポートするライフサイクルメソッドは四つだけ：initialize、notifications/initialized、tools/list、tools/call。それ以外（resources/*、prompts/*）は JSON-RPC -32601 を返す。転送は HTTP POST。stdio はない。サンプルヘッダは MCP-Protocol-Version: 2025-11-25。仕様そのものは 2026-07-28 にハンドシェイクを動かした；このプレビューは 2025-11-25 に釘を打つ。バージョン文字列さえ、JSON エンベロープで先に揃えるフィールドである。

もう一本 MCP Server を書くことではない

トランスコード後の REST リクエストは、ブラウザや SDK の呼び出しと見分けがつかない。クォータは操作ごと；MCP と REST は枠を共有する。バックエンドは Agent 向けに第二のインタフェースを増やさない。変わるのは発見：以前は人が OpenAPI を読んだ；いまモデルは tools/list の中の JSON Schema を読む。

だから「運用する MCP Server がない」は「保守する JSON 契約がない」ではない。空の description、深いオブジェクト、残った 2.0 は、発見面またはトランスコードで露わになる。MCP とは何か を見よ。

契約は OpenAPI 3.x から生える

ドキュメントで MCP を開くのは x-google-api-management.mcp。操作ごとには、x-google-mcp-tool で改名、description の書き換え、または false で退出できる。出す操作にはバックエンドと空でない description が要る。資格があるのは GET / POST / PUT / PATCH / DELETE だけ。ツール名は [A-Za-z0-9_.-]{1,128} に合い、Gateway 上で一意でなければならない。

公式の最小形（ページ上は YAML；意味は JSON オブジェクト）：

x-google-api-management:
  mcp: true
paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      description: Returns the current status, carrier, and ETA for an order.
      x-google-mcp-tool:
        name: get_order_status
        description: "Look up the delivery status and ETA of a customer order."
      parameters:
        - name: orderId
          in: path
          required: true
          schema:
            type: string

description は、モデルが「いつ呼ぶか」を決める主信号である。Google が求めるのは when / why であり、戻るものだけではない。path、query、body、header の schema がツール arguments になる。入れ子のオブジェクトは tools/list で完全には展開されないことがある——文書化されたプレビュー制限であり、バリデータが壊れたのではない。先にローカルで OpenAPI を平らにし、Gateway の input schema と Diff せよ。

tools/list は既定で無認証

既定では誰でも POST /mcp してカタログを受け取れる：名前、description、input schema。開発には便利。本番ではパラメータ契約を公開する。Google は tools/list に JWT を勧める。Public Preview ではAPI Key はこのメソッドを守れない。オブジェクト形も MCP を全域で開く；出したくない操作には x-google-mcp-tool: false が要る。

x-google-api-management:
  mcp:
    tools-list:
      security:
        orderServiceJwt: []

tools/call は、発見面を閉じていてもいなくても、常に下層の REST 認証を実行する。開いたカタログと閉じた呼び出しは別物である。ツール名と schema が機密なら、出荷前に tools/list をロックせよ。それは 悪意ある JSON ガイド と同じ層である：モデルが見る契約が広いほど、注入面も広い。

tools/call はなお JSON-RPC

ドキュメントの電文の形は：

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"get_order_status","arguments":{"orderId":"A-1042"}}}

Gateway は arguments を path / query / body / header へ戻し、ポリシーを走らせ、バックエンド応答を MCP result として包む。デバッグでは層を分けよ：外のエンベロープは JSON-RPC；内のペイロードは業務 JSON。パース失敗はどちらか一方に属する。ADK サンプルは Streamable HTTP を …/mcp に向け、Gateway がすでに期待する資格情報をなお送れる。

Gateway を API hub に繋ぐと、MCP を開いた config は MCP メタデータ付きで公開され、Agent Registry に現れる。ディレクトリは変わった。フィールド契約は変わっていない：なおあなたの OpenAPI から生えた schema である。Skill 発見は別の JSON ドキュメントである——SEP-2640 と skill://index.json を見よ。二つのカタログを一枚の表に混ぜるな。

Public Preview で先に読む制限

• OpenAPI 2.0 は非対応。先に 3.x へ上げよ。
• 空の本文（HTTP 204）の操作はツールとして出ない。
• 深く入れ子のオブジェクト schema は、tools/list で切り詰められることがある。
• 一つの Gateway が出せるのはおよそ 1,000 ツールまで。
• MCP と model routing は一つの API config を共有できない。
• resources / prompts、応答ストリーミング、Model Armor 検査はなおロードマップ上にある。

これらは「あとで磨く」ではない。204 の操作はカタログから消え、モデルは別のものを呼ぶ。切り詰められた schema は、strict バリデータとも本物のバックエンドとも合わない。MCP 2026 移行ガイド はプロトコル版の話である。本稿が足すのは：Gateway が生成する list は、リポジトリの完全な OpenAPI と等しくないことがある。

スイッチを入れる前に確かめる四つの JSON

1. リポジトリの OpenAPI 3.x。2.0 は先に上げよ。出す操作には空でない description、バックエンド、合法なツール名がある。
2. Gateway の tools/list。input schema が切り詰められていないか、余分な操作が漏れていないかを見よ。
3. 本物の tools/call 一本。arguments は REST へ戻るか。エンベロープは JSON-RPC 2.0 か。
4. 発見面のセキュリティオブジェクト。tools/list が開いたまま出荷するな。JWT の scheme 名は、すでに components.securitySchemes の下になければならない。

ローカル JSON ツールで仕様を見る

MCP を開く前に、ブラウザで三つのテキストを広げよ：OpenAPI（先に YAML を JSON へ）、tools/list 応答一通、tools/call へ送る arguments オブジェクト。

• JSONバリデーター — 文法が合法か；Schema があれば必須と余分なキーを合わせて見る。
• JSON ↔ YAML — 大半の OpenAPI は YAML で生きる；list と Diff する前に変換せよ。
• JSON Diff — リポジトリの parameters schema と、Gateway が返した inputSchema を比べる。

データはブラウザを出ない。契約を平らにしてから、Gateway のスイッチを入れよ。Gateway はトランスコードする。フィールド名と required は、プレビューの切り詰めと一緒に緩めてはならない。

FAQ

まとめ

API Gateway が持ち去るのは MCP Server プロセスである。JSON 契約は持ち去らない。OpenAPI 3.x が tools/list を生やす。tools/call は JSON-RPC のまま。ポリシーはすでに持っている REST ポリシーのまま。開いたカタログ、切り詰められた入れ子 schema、消えた 204 操作は、出荷前の確認である——「プレビューを開いた、終わり」ではない。

先にローカルで OpenAPI、list 応答、call サンプルを平らに見てから、mcp: true をセットせよ。Gateway はトランスコードする。フィールド契約は、プレビュー制限と一緒に緩めてはならない。