Google Cloud API GatewayがMCPサーバー対応｜既存REST APIをAIエージェントのツール化する仕組みと注意点【2026年9月】

AIニュース解説

AIエージェントに社内システムや業務APIを操作させようとすると、意外に手間がかかるのが「既存APIをMCPツールとして公開する部分」です。REST APIそのものはすでにあるのに、エージェントから呼び出すためだけに別のMCPサーバーを用意し、認証、ルーティング、クォータ、ログ管理を二重に実装すると、運用対象が増えてしまいます。

Googleは2026年9月24日、Google Cloud API GatewayがModel Context Protocol（MCP）のリモートサーバーとして動作できる機能をPublic Previewで公開しました。OpenAPI 3.xの定義へMCP用の拡張を加えることで、既存REST APIの操作をAIエージェントから利用できるMCPツールとして公開できます。バックエンドを書き直すのではなく、API GatewayがMCPのJSON-RPCと既存REST APIの間を変換する仕組みです。

SE実務で注目したいのは、単に「MCPに対応した」ことよりも、既存の認証・クォータ・ログと同じ管理経路を使える点です。一方で、2026年9月27日時点ではPublic Previewであり、OpenAPI 2.0非対応、ストリーミングや長時間実行ツール非対応、MCP Resources／Prompts非対応、Model Routingとの同一API設定での併用不可など、設計前に確認したい制限もあります。

先に結論：既存REST APIをエージェント向けに再利用しやすくなった

今回の機能が向いているのは、すでにGoogle Cloud API GatewayでREST APIを管理しており、そのAPIの一部をAIエージェントから安全に呼び出せるようにしたいケースです。OpenAPI 3.xの定義を中心に、どの操作をMCPツールとして公開するかを選び、既存のGatewayへMCPリクエストを受ける入口を追加できます。

特に重要なのは、MCP専用バックエンドへ業務ロジックをコピーする必要がないことです。API Gatewayはtools/callを既存RESTリクエストへ変換し、バックエンドから返ったHTTPレスポンスをMCPの結果へ戻します。直接RESTで呼ばれた場合も、MCP経由で呼ばれた場合も、同じバックエンドと同じ認証・クォータ・ログの仕組みを使えるため、統制点を増やしにくい構成にできます。

ただし、「既存APIがあるなら、そのまますべてAIへ公開すればよい」という話ではありません。AIエージェントは人間が画面から操作する場合よりも短時間に多くのツールを呼ぶ可能性があり、誤った引数や意図しない操作のリスクもあります。MCP対応は接続を簡単にする機能であって、業務権限や承認フローまで自動的に安全になる機能ではありません。

Google Cloud API GatewayのMCP対応で何が変わったのか

これまで、既存REST APIをMCPクライアントから使いたい場合、一般にはMCPサーバーを別途用意し、MCPのtools/listやtools/callを受け取ってREST APIへ橋渡しする実装が必要でした。小規模な検証なら実装できますが、本番運用では認証方式、監視、障害対応、バージョン管理、スケーリング、クォータなどの運用項目が増えます。

今回のPublic Previewでは、API Gateway自体がリモートMCPサーバーとして振る舞います。Googleの公式発表では、既存のOpenAPI 3.x仕様へx-google-api-management.mcpを追加し、必要に応じて各操作へx-google-mcp-toolを設定する方法が案内されています。デプロイ後はGatewayの/mcpエンドポイントへMCPクライアントを接続できます。

つまり、アプリケーションの業務APIを「REST版」と「MCP版」に二重実装するというより、Gatewayで1つのAPI定義から2つの呼び出し経路を扱う考え方です。すでにCloud RunなどでRESTサービスを運用している場合、エージェント対応のためだけに新しいサーバーを増やさずに済む可能性があります。

MCPリクエストがREST APIへ変換される仕組み

処理の流れは比較的シンプルです。MCPクライアントはAPI Gatewayの/mcpへJSON-RPC形式でリクエストを送ります。GatewayはMCPメソッドを確認し、tools/callで指定されたツール名と引数をOpenAPI定義へ照合します。その後、パスパラメータ、クエリ、リクエストボディ、ヘッダーへ変換し、既存のバックエンドへ通常のHTTPリクエストとして送信します。

  1. MCPクライアントが/mcpへ接続する
  2. initializeでプロトコル情報を交換する
  3. tools/listで利用可能なツールを取得する
  4. エージェントが必要なツールを選ぶ
  5. tools/callでツール名と引数を送る
  6. API GatewayがRESTリクエストへ変換する
  7. 既存バックエンドが処理してHTTPレスポンスを返す
  8. GatewayがMCPレスポンスへ変換してクライアントへ返す

バックエンドから見ると、MCP経由の呼び出しも通常のREST呼び出しと同じ形です。Googleのドキュメントでは、変換後のバックエンドリクエストは直接REST APIを呼んだ場合と区別できないと説明されています。既存のAPI実装をそのまま利用しやすい反面、バックエンド側だけを見て「これはAIエージェントから来た操作だから別処理にする」と判定する設計はできません。必要ならGatewayの経路、認証主体、ログ、追加ヘッダーなど別の統制方法を検討する必要があります。

OpenAPI 3.xにMCP設定を追加する

導入の前提はOpenAPI 3.xです。OpenAPI 2.0はMCP機能の対象外なので、古いSwagger 2.0定義でAPI Gatewayを運用している場合は、先に仕様を移行する必要があります。

Googleの公式例では、ドキュメントレベルでMCPを有効化し、個別の操作にツール名や説明を付けます。ツール名は最大128文字で、英数字と一部記号を使う形式に制限されています。また、各ツールには空でない説明が必要です。

openapi: 3.0.4
info:
  title: Order Service
  version: 1.0.0

x-google-api-management:
  mcp: true

paths:
  /orders/{orderId}:
    get:
      operationId: getOrderStatus
      description: Returns the current order status.
      x-google-mcp-tool:
        name: get_order_status
        description: "注文IDから配送状況を確認する。配送状況の問い合わせ時に利用する。"

ここで軽視しにくいのがdescriptionです。MCPクライアント側のLLMは、ツール名だけでなく説明を見て「いつ、なぜ、このツールを呼ぶか」を判断します。API開発者向けに「注文情報を返す」とだけ書くより、「配送状況を尋ねられたときに利用する」のように利用条件を明確にした方が、エージェントが誤ったツールを選ぶリスクを減らしやすくなります。

また、MCPをグローバルで有効にすると、条件を満たす操作がツールとして公開されます。公開したくない操作はx-google-mcp-tool: falseで明示的に除外できます。削除系や管理者向け操作まで一括公開しないよう、最初は必要最小限の操作だけを選ぶ設計が現実的です。

認証で特に注意したいのはtools/list

今回の機能で実務上もっとも見落としやすいのが、ツール一覧を返すtools/listの扱いです。Googleの公式ドキュメントでは、initializeとnotifications/initializedは認証なし、tools/callは元のREST操作で定義した認証を再利用すると説明されています。

一方、tools/listは標準では認証なしです。つまり対策しなければ、ツール名や入力スキーマを外部から列挙される可能性があります。実行自体が認証で守られていても、「どのような業務操作が存在するか」という情報が公開されることは、社内システムでは避けたいケースがあります。

本番利用を考えるなら、tools-list.securityでJWT認証を設定することを優先したいところです。Public Preview時点では、tools/listの保護にAPIキーは使えず、JWTセキュリティスキームが必要です。さらに、MCP設定をオブジェクト形式で書いてtools/list認証を有効化すると、MCPがグローバルで有効になるため、公開したくない操作の明示的な除外も確認する必要があります。

「実行できないから一覧は公開しても問題ない」とは限りません。ツール名に内部業務名、管理機能名、顧客情報の扱いを推測できる名称が含まれる場合、一覧だけでも情報価値があります。エージェント向けAPIでは、実行権限だけでなく、ツールの発見範囲もアクセス制御の対象として設計した方が安全です。

既存の認証・クォータ・ログを共通化できるメリット

API GatewayをMCPの入口として使う利点は、既存REST APIで使っている統制を再利用しやすいことです。Googleの発表では、MCP経由で変換されたリクエストにも、元の操作へ設定済みのJWTまたはAPIキー認証、クォータ、ログが適用されると説明されています。

この点は、MCPサーバーを別アプリとして新設する構成との差になりやすい部分です。別サーバー方式では、MCP側にも認証やレート制限を実装し、REST側との設定差分を管理する必要が出ます。API Gatewayで一本化できれば、少なくとも入口のポリシーを同じ場所で管理できます。

また、MCPリクエストも通常のAPI Gatewayメトリクスとログへ記録されます。MCPトラフィックは/mcpというパスなどから識別できます。業務エージェントを運用するときは、成功率だけでなく、ツールごとの呼び出し回数、認証エラー、引数不正、バックエンドエラー、想定外の大量呼び出しも監視対象にすると、異常を見つけやすくなります。

SE実務では「既存APIのAI対応窓口」として考えると分かりやすい

実務での位置づけは、新しい業務ロジックを作るサービスというより、既存APIをAIエージェントへ安全に見せるための窓口に近いです。

たとえば、受注管理システムに「注文状況取得」「配送先変更」「注文キャンセル」のREST APIがすでにあるとします。問い合わせ対応エージェントへ注文状況だけを使わせたい場合、GET /orders/{id}だけをMCPツールとして公開し、変更や削除操作は公開しない構成にできます。運用が安定してから、承認付きで変更系ツールを追加する方が安全です。

フリーランスSEが顧客案件へ提案する場合も、「AIエージェントを入れるので既存システムを作り直す」という説明より、「既存REST APIの一部をGateway経由でMCPツールとして公開する」と整理した方が、影響範囲を切り分けやすくなります。バックエンドの改修量、認証方式、監視、対象操作を個別に見積もれるためです。

一方で、APIそのものが整備されていない業務や、人間が画面でしか実行できない操作に対しては、API GatewayのMCP対応だけでは解決しません。MCPは既存機能への標準化された接続方法であり、業務APIを新たに生成する機能ではありません。

既存のAIモデルルーティング機能との違い

同じGoogle Cloud API Gatewayには、2026年8月にAIモデルルーティング機能もPublic Previewとして追加されています。名前が似た「AI向けGateway機能」なので混同しやすいですが、通信方向と目的が違います。

機能 主な目的 通信のイメージ
MCP対応 既存REST APIをエージェントが呼べるツールとして公開する AIエージェント → API Gateway → 業務REST API
Model Routing アプリから複数LLMへの呼び出しを共通入口へまとめる アプリ → API Gateway → Gemini／Claude／OpenAI系モデル

MCP対応は「AIが業務システムを呼ぶ入口」、Model Routingは「業務システムがAIモデルを呼ぶ出口」と考えると理解しやすくなります。

さらに重要なのは、Public Preview時点ではMCPとModel Routingを同じAPI構成で同時に有効化できないことです。既存記事で紹介したModel Routingを使っているAPI設定へ、そのままMCP機能を足す設計はできません。必要ならAPI構成を分け、用途ごとにGatewayを整理する必要があります。

Model Routing側の詳細は、既存記事「Google Cloud API GatewayのAIモデルルーティングとは？」で整理しています。

Public Preview時点の主な制限

本番導入を急ぐ前に、2026年9月27日時点の制限を確認しておく必要があります。Googleの公式ドキュメントで確認できる主な制限は次のとおりです。

  • MCP Resources（resources/*）は非対応
  • MCP Prompts（prompts/*）は非対応
  • stdioトランスポートは非対応
  • OpenAPI 2.0は非対応
  • ストリーミングまたは長時間実行のツール呼び出しは非対応
  • MCPとModel Routingを同じAPI設定で併用できない
  • APIキーでtools/listを保護できない。保護にはJWTが必要
  • レスポンス本文がないHTTP 204などの操作はMCPツールとして公開されない
  • 深くネストされたオブジェクトスキーマはtools/listで完全に表現できない場合がある
  • 1つのGatewayで公開できるツールは最大1,000個

これらは「MCPが使えるか」だけでなく、どの業務を対象にできるかへ直結します。たとえば、大きなファイルを長時間処理するバッチ、逐次結果を返す処理、非同期ジョブを1回のツール呼び出しで完結させたい場合は、そのまま当てはめにくい可能性があります。

Preview機能は仕様が変わる可能性もあります。Google CloudのPre-GA Offerings Termsが適用されるため、サポート条件を含め、本番の中核機能へ採用できるかは組織のルールと合わせて判断する必要があります。

導入前に確認したい5つの設計ポイント

1. 本当にAIへ公開してよい操作か

既存APIを機械的に全部公開せず、まず読み取り専用から始める方が安全です。更新・削除・送金・権限変更など、影響が大きい操作には、人間の承認や追加認証、利用回数制限を検討します。

2. ツール説明がエージェントの判断材料になる

LLMはツール名と説明を見て利用判断します。APIの技術仕様だけでなく「どの利用者要求で使うのか」「どんな場合は使ってはいけないのか」が分かる説明にします。似た用途のツールを大量に作ると誤選択が増える可能性があるため、粒度も見直します。

3. tools/listの公開範囲を決める

ツール実行だけでなくツール一覧の閲覧も認可対象として考えます。社内専用のMCPサーバーなら、JWTによるtools/list保護を前提に検討するのが無難です。

4. APIの既存クォータがエージェント利用に耐えられるか

エージェントは1つのユーザー要求に対して複数回ツールを呼ぶことがあります。人間向け画面のアクセス数を前提に設定したクォータでは足りない場合がある一方、無制限に広げると誤動作時の負荷が大きくなります。1タスク当たりの想定ツール回数を計測してから設定を調整したいところです。

5. ログだけで事故を追跡できるか

GatewayログにAPI呼び出しは残せても、「なぜエージェントがそのツールを選んだか」は別のエージェント実行ログに残す必要があります。プロンプト、ツール選択、引数、API結果、最終回答を関連IDで追跡できるようにすると、障害調査と監査がしやすくなります。

向いているケースと向いていないケース

向いているのは、Google Cloud上ですでにAPI Gatewayを利用し、OpenAPI 3.xで管理しているREST APIの一部をAIエージェントへ公開したい環境です。特にCloud Runなどのバックエンドを既存の認証・クォータ・ログと一緒に管理している場合、MCP専用サーバーを新設しない構成を検討しやすくなります。

一方で、MCP ResourcesやPromptsを使いたい、stdio前提のローカルMCPサーバーが必要、長時間実行やストリーミングが必須、Google Cloud以外の複数環境へ柔軟に展開したい、といった要件では専用MCPサーバーの方が扱いやすい場合があります。

また、API Gateway自体を使っていない小規模システムでは、MCPのためだけにGatewayを導入すると構成がかえって複雑になる可能性があります。既存インフラ、運用体制、セキュリティ要件を含め、「MCPサーバーを減らせるか」ではなく「運用責任をどこへ集約したいか」で判断する方がよいでしょう。

試すなら読み取り専用APIから始める

最初の検証では、注文照会、在庫確認、ステータス取得など、失敗しても業務データを書き換えないAPIを1〜3個だけ公開するのがおすすめです。公式仕様上、MCPをグローバルで有効にする方法もありますが、初期検証では公開対象を明確に絞った方が挙動を把握しやすくなります。

  1. 既存OpenAPI定義が3.xか確認する
  2. 読み取り専用の対象操作を選ぶ
  3. ツール名と説明をエージェント向けに見直す
  4. tools/listのJWT認証を設定する
  5. 検証用Gatewayへデプロイする
  6. initialize、tools/list、tools/callを順に確認する
  7. 正常系だけでなく、認証失敗・不正引数・存在しないツールも確認する
  8. Gatewayログとエージェント側ログを突き合わせる
  9. 呼び出し回数とバックエンド負荷を計測する
  10. 問題がなければ更新系操作を段階的に検討する

「MCPでつながった」ことをゴールにせず、権限、ログ、誤操作、負荷、障害時の切り分けまで確認しておくと、本番へ進む判断がしやすくなります。

まとめ

Google Cloud API GatewayのMCP対応は、既存REST APIをAIエージェント向けのツールへ変換するための管理ポイントをGatewayへ集約できる機能です。OpenAPI 3.xへ設定を追加し、/mcpを通じてtools/listとtools/callを提供することで、専用MCPサーバーを別途構築しなくても、既存バックエンドを再利用できます。

SE実務では、認証・クォータ・ログをRESTとMCPで共通化できる点が大きなメリットです。一方、tools/listがデフォルトで未認証であること、Model Routingと同一API設定で併用できないこと、Resources／Prompts／ストリーミング／長時間実行が未対応であることなど、Preview段階の制約は無視できません。

既存のGoogle Cloud APIをエージェントへ接続したい場合は、まず読み取り専用APIを少数公開し、JWTによるツール一覧保護、ログ、クォータ、エラー処理を確認するのが現実的です。専用MCPサーバーを増やす前に「すでにGatewayで管理しているREST APIをそのまま活かせないか」という観点で検討すると、システム全体をシンプルに保てる可能性があります。

参考情報

※本記事は2026年9月27日時点のGoogle公式情報を基にしています。MCP対応はPublic Previewであり、仕様、制限、サポート条件は今後変更される可能性があります。実際の導入前に最新のGoogle Cloud公式ドキュメントを確認してください。

コメント