要点：REST APIをMCPへ見せ直せる。ただし『既存の認可がある』だけでは公開判断にならない

Google Cloudは2026年9月24日、API Gatewayをremote Model Context Protocol（MCP）serverとして使い、既存のREST APIをAI agentのtoolとして公開できる機能を案内した。OpenAPI 3.x specificationへGoogle固有の設定を加え、通常のgateway deploymentを行うと、agentはHTTP POSTのMCP endpointでtools/listとtools/callを使える。別のMCP middlewareを新設してrouting、quota、認可を二重実装しなくてよい、というのが今回の実務上の変化である。

ただし『REST APIをagentに開く』ことと『安全なagent workflowにできた』ことは別だ。tool invocationは元のOpenAPI operationに定義したAPI keyまたはJWTなどの認可を再利用する一方、tools/listは既定で未認証である。公開するoperationをglobalに有効化すれば、eligibleなoperationがtoolになり得る。読み取り専用のendpointだけを公開するのか、write APIを誰のidentityで呼ぶのか、tool名と説明から何を推測できるのかを、設定より先に決める必要がある。後半は公式仕様を導入判断へ翻訳した編集部のInferenceである。

  • Fact：API GatewayはPublic Previewでremote MCP serverとして動作し、OpenAPI 3.xからMCP tool設定を導ける
  • Fact：対応するMCP lifecycleはinitialize、notifications/initialized、tools/list、tools/callに限られる
  • Fact：tools/callは下位REST operationの認可を継承するが、tools/listは既定で未認証である
  • Recommendation：初回はread-only operationを明示選択し、JWTでtool discoveryを保護できるか確認してから広げる

何が起きたか：API GatewayがOpenAPI 3.xからremote MCP endpointを生成するPublic Preview

発表主体はGoogle Cloudで、Google Developers Blogの案内日は2026年9月24日である。API Gatewayのrelease notesでは、MCPをremote serverとして構成できるPublic Previewを9月11日のfeatureとして記録している。今回のblogは、既存REST backendを変更せず、gatewayに置いたOpenAPI 3.x specificationへMCP設定を加える流れを、agent向けの利用例として説明したものだ。発表日とPreview機能のrelease-note日を同一視しない。

protocol上では、agent clientがgatewayの通常/mcp pathへJSON-RPC requestをPOSTし、gatewayがMCPのtool requestをpath、parameter、bodyを持つHTTP REST requestへ変換してbackendへ渡す。backend responseは再びJSON-RPC responseになる。path/query parameterとheaderはargumentsのtop-level property、request bodyはbody propertyから渡すとdocumentationにある。これは公開仕様上のFactであり、本稿では実際のgatewayやbackendへのrequestを送っていない。

MCPを有効にしたgatewayをAPI Hubと統合すると、MCP-specific metadata付きでAPI Hubへ公開され、Agent Registryにも自動で現れるとoverviewは説明する。これはagentに見つけやすくなる機能であり、toolの安全性、適切なpermission、正しいagent selectionを証明する評価ではない。catalogに載せる前に、誰がdiscoverでき、誰がcallでき、誰がtool definitionを変更できるかを分けて設計する必要がある。最後の文は編集部のRecommendationである。

以前との違い：MCP用の別serverではなく、既存gatewayのpolicy pathを通せる

従来、REST APIをMCP toolにするには、MCP protocolを受けてRESTへ変換するserverまたはmiddlewareを別途運用する構成が一つの選択肢だった。Googleの発表は、API Gatewayがその変換を担い、既存のOpenAPI、authentication、quota、loggingと同じgateway policy pathを使えると位置付ける。APIとMCPで別々のrouting tableやcredential検査を持つより、policyの分岐を減らせる可能性がある。

その一方で、gatewayが変換するからといってbackendの意味が変わるわけではない。configuration guideは、transcodeされたbackend requestをdirect REST callと区別できないと説明する。auditでは/mcpで終わるrequest pathやcustom metricを用いてMCP trafficを見分けられるが、backend applicationだけに『agent由来だから低権限にする』という判断を任せられない。identity、scope、operationごとのauthorizationをgatewayとbackendの双方でどう検査するかは残る設計課題である。後半は公開仕様からのInferenceである。

またMCPとmodel routingは同じAPI configで併用できない。x-google-api-management.mcpを有効にすると、x-google-model-routerは使えない。既存gatewayでOpenAI-compatibleなmodel routingをすでに使うteamは、MCPを足すだけの差分では済まず、gatewayやAPI configの分離を検討する必要がある。これは公式extension documentationにある仕様で、どちらの構成が適切かはworkloadと運用境界による。

API GatewayのMCP化で引き継げるものと、別途決めるもの
論点公開仕様で確認できること導入側で決めること
公開対象OpenAPI 3.xのeligible operationをglobalまたはoperation単位でMCP toolにできるread-only／write operationの選別、tool名・説明、破壊的操作の除外
呼び出し認可tools/callは下位REST operationのAPI keyまたはJWT policyを再利用するagentへ渡すidentity、scope、user delegation、approvalと監査
tool列挙tools/listは既定で未認証。JWT schemeを一つ指定して保護できるcatalogを見せる対象、JWT発行・失効、未認証列挙を許すか
運用gateway metrics・logsを使え、/mcp pathでMCP trafficを区別できるrate limit、異常検知、cost上限、incident時のtool停止とreview

誰に影響するか：OpenAPIでREST APIを管理し、agentへ段階的にtoolを渡したいteam

もっとも直接的に関係するのは、すでにAPI GatewayとOpenAPI 3.xでinternalまたはpartner向けREST APIを管理しており、agent用に同じcapabilityを公開したいplatform teamである。GET、POST、PUT、PATCH、DELETE operationをtoolにでき、tool nameはoperation IDを既定にしつつoperationごとのx-google-mcp-toolでnameとdescriptionを上書きできる。global enablementを選んでも、特定operationをfalseにして除外できる。

逆に、OpenAPI 2.0、stdio transport、MCP resourcesまたはprompts、SSEによるstreaming response、long-running tool callが中心のAPIは、このPreviewの対象に合わない。overviewはresourcesとpromptsを未対応、stdioを未対応、streamingまたは長時間callを未対応と明記する。OpenAPI 3.x limitationsではMCP toolをgateway当たり最大1,000個、HTTP methodをGET／POST／PUT／PATCH／DELETEに限定している。

write APIを持つteamほど、機能を『既存backendを変更しなくてよい』だけで採用しないほうがよい。tool descriptionはagentの行動選択に使われ、tools/callはREST callと同じeffectをbackendへ起こす。削除、返金、permission変更、外部送信のようなoperationは、MCP endpointへ出さない、または別identity・narrow scope・approval workflowを持たせる選択を先に検討する。これは一般的なsecurity designとしての編集部のRecommendationである。

今できること：一つのread-only operationから仕様と認可を照合する

最初の評価は、syntheticまたは公開sample dataだけを返すread-only operation一つに絞るのがよい。OpenAPI 3.x specificationでoperation ID、summaryまたはdescription、backend、既存REST security requirementを確認し、MCPをglobalで有効にする代わりにx-google-mcp-toolで公開対象を明示する。documentationはtool descriptionが空ならconfiguration validationでrejectされるとしているため、説明文を単なる実装メモではなく、agentが誤って広く解釈しない範囲へ整える必要がある。

次にtools/listをどう保護するかを決める。JWT security schemeを一つ定義し、x-google-api-management.mcp.tools-list.securityに指定すれば列挙を認証できる。Public Previewではtool discoveryにAPI keyを使えない。call側のAPI keyが設定済みでも、list側まで同じように閉じるとは限らないので、listとcallを別々にtest planへ入れるべきである。ここでの設定例は公式documentationに基づく説明であり、本稿ではcredentialを設定していない。

評価時には、正常callだけでなく、未認証のtools/list、scope不足のtools/call、存在しないtool、schemaに合わないargument、backendの4xx／5xx、長時間responseを観測対象にする。MCPではprotocolまたはapplication errorがHTTP 200とJSON-RPC error objectで返る場合があるため、HTTP statusだけを成功判定にしない。production API、customer data、write operation、課金のあるgateway deploymentを使った検証は本稿では行っていない。

  • Recommendation：tool exposureはglobal enablementではなく、read-only operationのallowlistから始める
  • Recommendation：tools/listとtools/callの認可、request path、principal、operation、effectを一つのaudit recordで追えるようにする
  • Recommendation：write operationはMCP化しない選択を含め、idempotency、approval、reversal、rate limitを別途reviewする

まだ分からないこと：Previewの実運用性能、client互換性、料金、個別projectの提供範囲

公開資料はfeatureのprotocol範囲とconfigurationを説明するが、どのMCP clientが同じhandshake、header、error handling、tool schema renderingで互換かを一覧していない。deeply nested object schemaがtools/listで完全にrenderされない場合があること、HTTP 204のようにempty bodyを返すoperationはtoolとして公開されないこともGoogleのblogは制限として挙げる。自組織のagent frameworkでどのschemaが見え、どのerrorをretryし、どのtool descriptionを選ぶかは別途確認が必要である。

また、Public Previewの料金、quota、region、SLO、support、Agent RegistryまたはAPI Hubでのaccess control、既存gatewayとのmigration、MCP trafficによるbackend cost、実際のlatencyは、この記事の照合範囲では確定していない。gateway policyを再利用しても、agentがtoolを何度callするか、paginationをどう扱うか、失敗時にretryするかで総costと負荷は変わる。

MCP化はprompt injectionへの防御そのものではない。tool側で認可があっても、agentが不適切なargumentを選べば、許可された範囲で望ましくない読み出しや変更をする可能性は残る。least privilege、tenant isolation、data minimization、server-side validation、rate limit、human approval、auditをMCP設定の外側にも置く必要がある。最後の段落は編集部のInferenceである。

次に確認する条件：GA、対応MCP method、認証方式、model routing併用の仕様が変わったとき

次に確認する条件は、MCP supportのGA、supported MCP methodとtransportの追加、streaming・long-running call・resources・promptsへの対応、tools/listの認証方式、OpenAPI 3.x limitation、tool count、model routingとの併用、pricing・quota・region・supportの更新である。Previewである以上、仕様が変わったらOpenAPI configとsecurity reviewを再実施する。

現時点の結論は、API GatewayのMCP対応を『REST APIを安全にagent化するスイッチ』として扱わないことだ。既存gatewayの認可、quota、loggingを同じ経路で使い、MCP用middlewareの重複を減らせるのは具体的な利点である。ただし公開するoperation、discoveryの認証、agent identity、write effect、backend validationは自動では決まらない。read-only toolを狭く公開し、実際のclientと監査記録で評価できるteamに向くPreviewである。後半は編集部のInferenceである。