既存サービスがOpenAPI 3.xに適合し、REST操作をツールとして呼ばせるだけなら、Google Cloud API GatewayのMCPプレビューで小さく試せます。本番前にはツール発見の保護、実行時の認証、ストリーミングなどの制限を個別に確認してください。Googleは2026年9月24日にPublic Previewを発表しています。
API開発者：既存RESTサービスを生かし、Agent専用のMCPサーバー実装を減らしたい方。
プラットフォーム担当者：OpenAPI、認証、割り当て、ログがどこまで引き継がれるか確認したい方。
AI製品チーム：業務APIの読み取り・書き込み範囲を定めてから公開したい方。
1Google Cloud API Gateway MCP接続で、既存REST APIをどうツール化するか
更新確認：2026年9月25日。 製品状態、対応範囲、制限は、Googleの2026年9月24日発表とAPI Gateway MCP公式ガイドで照合しました。プレビュー中の挙動は更新される可能性があるため、導入時にも公式資料を再確認してください。
この方式では、既存のOpenAPI 3.x仕様にMCP用の設定を加えてAPI Gatewayへデプロイし、ゲートウェイをMCPの接続先として使います。Agentからのツール呼び出しをRESTリクエストへつなぐ構成であり、バックエンドの業務ロジックや入力検証がAgent向けに自動改修されるわけではありません。MCP設定の公式手順とAPI configの作成手順を照らし、仕様の検証とデプロイを分けて進めます。
作業は、まずOpenAPI定義で公開対象の操作と入力を確認し、次にMCP設定を追加してAPI configを作成、検証用環境へデプロイします。その後、クライアントからツール一覧を取得し、読み取り操作、認証、ログを順に確かめます。ツール名だけで目的が伝わるか、必須入力や値の意味が仕様から読み取れるかも点検してください。特に書き込み操作は、Agentが誤った引数で実行した場合の影響まで確認します。
2ツール発見と呼び出しで、認証境界はどう違うか
MCPの基本フローでは、クライアントが初期化し、tools/listで利用可能なツールを調べ、tools/callで選んだ操作を呼び出します。公式ガイドではこれらのメソッドが扱われていますが、tools/listは既定で公開される挙動があります。そのため、本番環境ではツール一覧の取得自体を認証で保護できているか確認してください。MCP概要に示されるこの境界を、REST操作の認証とは分けて評価するのが要点です。
ツール呼び出しでは、対象のREST操作に設定済みの認証が引き続き適用され、API Gatewayの割り当てやログも関連する既存ポリシーの範囲で利用できます。API Gatewayの割り当てとプラットフォームログを確認し、資格情報がどの主体に属するか、Agentからバックエンドまでどの区間で検証されるかを試験してください。既存ポリシーの継続は、ツール単位の認可、危険な操作の承認、Agentの安全な動作まで保証するものではありません。
3Agentクライアントで接続する場合と、Gatewayに任せる範囲
接続試験では、公式資料に従ってMCPクライアントにゲートウェイの接続先と必要な資格情報を設定し、ツール一覧の取得から読み取り操作の実行まで確認します。ADKなどを使う場合も、Agentの計画、ツール選択、再試行、利用者への承認依頼はAgent側の設計です。GatewayはAPIとの接続を担いますが、すべてのMCPクライアントが同じ認証方式や接続挙動で動くとはみなさず、採用するクライアントごとに互換性を検証してください。
4ストリーミングや長時間処理が必要なら、プレビュー制限を先に照合する
OpenAPI 3.xに適合することだけを理由に、本番の長時間処理やリアルタイム応答を移し替えるのは避けます。OpenAPI 3.xの制限一覧とMCP資料を読み、必要なリソース、プロンプト、ストリーミング、長時間ツール呼び出しが現在のプレビューで対応されるか、個別に確認してください。必要な機能が対象外なら、自前のMCP実装を維持するか、機能更新を待つのが妥当です。
採用判断は、次のチェック項目で分けてください。
- [ ] OpenAPI 3.xに適合し、必要な操作がRESTツール呼び出しに収まる場合は、検証用環境でプレビュー接続を試します。
- [ ] ツール発見を認証で保護でき、実行時の資格情報と読み書き範囲を検証できる場合は、読み取りなど限定した操作から段階的に評価します。
- [ ] リソース、プロンプト、ストリーミングなどの必須機能が不足する場合は、既存のMCP実装を置き換えず、要件を満たす経路を残します。
- [ ] 書き込み権限を渡すのに承認や操作範囲を制御できない場合は、本番接続を保留し、権限設計を先に整えます。
5API接続の検証と、Appleツールチェーンの検証は分ける
業務APIをAgentに公開することと、macOSアプリをビルド・テストすることは別の作業です。MCP GatewayはAPIツールの接続を担いますが、Xcodeを使うビルド環境やAppleプラットフォーム上の検証環境にはなりません。Appleツールチェーンが必要な場合は、Xcodeのシステム要件を確認し、API接続の受け入れ試験とは分けて環境を選定してください。
導入の節目は、仕様と公開操作の確定、認証境界の試験、必要機能とプレビュー制限の照合です。API接続だけなら既存の実行環境を使えばよく、Appleアプリの構築・試験が含まれる場合に限ってMac環境を別途評価します。権限設計や接続後の受け入れ項目を整理するには、Agent向けAPI接続と権限設計のガイドを参照してください。macOS側の実行環境が必要になった際は、Mac環境の利用方法と確認事項で作業範囲に合うかを確かめます。
既存のMCP実装を維持する場合は、Gatewayのプレビュー対象外機能を自前で補う必要があり、運用箇所が増え、認証やログの確認も分散しやすくなります。一方、API Gateway経由へ切り替えても、Agentの権限設計やmacOSアプリの実行環境まで代替できるわけではありません。REST APIの限定公開はGatewayで検証し、Appleツールチェーンが必要な作業はMac環境で別に受け入れる構成が適しています。
まずはツール発見の保護と読み取り操作の認証を確認し、書き込み操作は承認経路が整うまで本番公開しないでください。macOSでのビルドやクライアント検証が必要になった場合は、常設環境を購入する前に短期のMacレンタルが適するかを比較し、必要期間と作業内容に合う実行環境を選びます。
vpstix M4 リモートノード
AIエージェントの開発・検証環境に、vpstixの専有Macを
REST APIとAIエージェントの連携を、専有のMac mini環境で検証しませんか。