こんにちは!
KDDIアイレットの取り組みとして6月22日〜7月3日の期間で開催中の「Google Cloud Next '26 / Google I/O やってみた系ブログリレー」、 本日は7日目の投稿です。
今回は Next '26 で GA が発表された Google ホストの Cloud Run Remote MCP (https://run.googleapis.com/mcp) を取り上げます。 これが何を意味する発表だったのかは、 この 1 年の文脈を踏まえると一気にはっきりするので、 時系列で整理してみました。
前回の記事はこちら
本記事の前提: 本記事は 2026 年 6 月時点 の公式ドキュメントと
GoogleCloudPlatform/cloud-run-mcpのコミット履歴に基づく 時系列整理と考察 です。 各時期の機能仕様や Google 側のホスティング状況は更新が速いので、 最新は 公式ドキュメント と リポジトリ でご確認ください。
この記事で分かること
- Cloud Run × MCP が 2025 年 5 月から 3 段階で進化してきた経緯
- Next '26 で GA された
https://run.googleapis.com/mcpが何を解決して何を残しているか - 結局どの段階を選ぶべきか
想定読者
- Cloud Run を業務で触っている開発者
- MCP / Model Context Protocol という言葉は聞いたことがあるが、 自分で組み込んだことはない方
- AI エージェントから GCP リソースを触らせる構成に興味がある方
- Next '26 で Cloud Run × MCP まわりに何があったかをキャッチアップしたい方
1 年でホスト先が 3 回変わった
先に全体像です。 Cloud Run × MCP の 1 年は、 ざっくりこの 3 段階で進化してきました。
| 観点 | 第 1 段階 (ローカル npx) | 第 2 段階 (自前 Cloud Run) | 第 3 段階 (Google ホスト GA) |
|---|---|---|---|
| 時期 | 2025-05 〜 | 2025-12 〜 | 2026-04 〜 |
| 起動・保守 | 自分の PC | 自分の Cloud Run | |
| エンドポイント | stdio |
https://*.run.app (自分のドメイン) |
https://run.googleapis.com/mcp (固定) |
| 認証 | ローカル gcloud | Invoker + proxy | OAuth + IAM |
| チーム共有 | 各自セットアップ | 共通 URL を共有 | 共通 URL を共有 |
| 料金 | 無料 | Cloud Run 課金 | 無料 |
| 提供元 | OSS パッケージ | OSS を自分でデプロイ | Google 公式運営 |
ざっくり言うと、 設定ファイルに 1 ブロック書くだけで Cloud Run が AI から触れる時代 に到達したというのが第 3 段階の意味です。 ここからは、 それぞれの段階で何が解けて、 何が残ったかを見ていきます。
なお「Cloud Run MCP」 という言葉は、 段階によって指すものが微妙に違います。 第 1・第 2 段階は GitHub の GoogleCloudPlatform/cloud-run-mcp という OSS パッケージのこと、 第 3 段階は Google が運営する Cloud Run Remote MCP server (https://run.googleapis.com/mcp) のこと。 ここを混同せずに読み進めてもらえると分かりやすいです。
第 1 段階 (2025-05 〜) — OSS としてのローカル起動
2025 年 5 月 6 日、 GoogleCloudPlatform/cloud-run-mcp という OSS リポジトリが GitHub に登場しました。 中身は Node.js 製の MCP サーバで、 当初は stdio で動くローカル MCP として配布。 各自が npx -y @google-cloud/cloud-run-mcp を起動して、 Claude Desktop や Claude Code から stdio 経由で接続する構成でした。 認証はローカル gcloud の Application Default Credentials がそのまま使われます。 5 月 21 日には get_service_log ツールも追加され、 8 月の v1.1.0 で npx 配布が安定。 個人で触る範囲では一気に使いやすくなりました。
ただ、 個人で触っているうちは楽しい一方で、 チームで使い始めた瞬間に 「各自セットアップが揃わない」 問題 にぶつかります。 全員が npm パッケージを入れ、 認証を揃え、 .mcp.json を書く必要がありました。 メンバーが入るたびに同じ手順を繰り返すことになり、 「うちのチームはこの MCP」 という運用が事実上成立しにくい状態でした。
実はこれ、 リポジトリ側も初期から見据えていたようで、 公開から 2 週間も経たない 2025-05-19 に README へ「Call out how to host MCP servers」 (ホスト方法を明示) というコミットが入っています。 ローカル起動はあくまで初期段階の選択肢で、 メンテナはもっと先を見ていたわけです。
第 2 段階 (2025-12 〜) — 自前 Cloud Run にホストして共有
2025 年 12 月、 状況が動きます。 2025-12-10 にリポジトリへ Bump mcp sdk to 1.24.3 and add support for Host validation (リモートホスト用の対応) が入り、 翌 12-11 に v1.6.0 がリリース。 同時期に公式ドキュメント Host MCP servers on Cloud Run と Build and deploy a remote MCP server on Cloud Run が整備され、 README にも「Set up as remote MCP server」 セクションが追加されて、 「Cloud Run MCP を Cloud Run 自身にホストする」 構成が公式に文書化 されました。
メンバーは gcloud run services proxy cloud-run-mcp --port=3000 でローカルプロキシを立てて、 Claude からは http://localhost:3000/sse 経由で接続。 認証は Cloud Run Invoker IAM で利用者を絞れます。 これで「うちのチームはこの URL を使う」 が成立し、 メンバーは npx を入れる必要がなくなり、 MCP サーバのバージョンアップも 1 か所で完結します。
ただ、 第 1 段階の「各自セットアップ」 問題は解けた代わりに、 インフラ運用の問題が乗ってきた 形です。 自前で Cloud Run を立てて、 各メンバーが別ターミナルで proxy を回しっぱなしにして、 コンテナの SA に Cloud Run / Logging 操作権限を付けて、 バージョンアップのたびに再デプロイする。 「ローカルにプロセスを立てる手間」 と「自分の Cloud Run を運用する手間」 を天秤にかけて、 チーム共有のために後者を引き受けるという設計判断でした。
第 3 段階 (2026-04 〜) — Google ホストの GA エンドポイントに収束
2026 年 4 月 23 日、 Google Cloud 公式ブログ「What's new for Cloud Run at Next '26」 で、 Cloud Run の Remote MCP サーバが GA (Generally Available) になったと発表されました。
"To make it even easier for developers or agents to deploy code, we are launching an official remote Cloud Run MCP (Model Context Protocol) server, giving you the tools to manage and deploy apps. Now GA."
ポイントは「Google が自分で運営している MCP サーバが正式公開された」 こと。 ユーザー側がデプロイするのではなく、 既に Google が立てている https://run.googleapis.com/mcp という固定 URL を Claude に登録するだけで使えるようになった、 という話です。 認証は OAuth 2.0 + IAM、 自前ホスト不要・proxy 不要・コンテナ運用不要で、 SDK 更新やセキュリティパッチも Google 側が保守します。
ローカル npx 版との一番の違いは 提供ツールセット です。 ローカル版 (8 tools) と Google ホスト版 (5 tools) を並べると、 中身がわずかに違います。
| 機能 | ローカル cloud-run (8 tools) |
Google ホスト (5 tools) |
|---|---|---|
| サービス一覧・詳細 |
list_services / get_service
|
list_services / get_service
|
| サービスログ取得 | get_service_log |
なし |
| プロジェクト管理 |
list_projects / create_project
|
なし |
| デプロイ系 | コンテナ / ファイル内容 / ローカルフォルダ | コンテナ / ファイル内容 / GCS アーカイブ |
差分のポイントを 1 段で言うと、 「ログ取得とプロジェクト管理系は Google 版で削られ、 ローカルフォルダ直接デプロイは GCS アーカイブ経由に変わった」 という整理になります。 とくに get_service_log の不在は体感として大きく、 「エラー出てるアプリのログを Claude に読ませる」 という前回記事で書いた使い方は Google ホスト版だけでは完結しません。 ログ系はローカル版 MCP か gcloud run services logs で補う併用が想定されます。
なお、 認証 (OAuth + IAM) のクライアント側手順や Claude Code から繋いだ際のハマりどころは、 別の「やってみた」 記事として後日まとめる予定です。
結局どれを使えばいいのか
3 段階それぞれの「使うと活きる場面」 を整理するとこうなります。
なお「書き込み系は CI/CD・調査系は AI」 という住み分けはどの段階でも通用するので、 興味があれば前回の記事 もあわせてどうぞ。
最後に — この流れの本質は SaaS 化
3 段階を並べてみると、 これは MCP に限らず ソフトウェアの提供形態が辿る典型パターン だと感じます。 OSS をローカルで動かし、 自分のクラウドにホストし、 最後は提供元が SaaS として運営する。 Postgres → Cloud SQL、 Elastic → Elastic Cloud と同じ構図を、 Cloud Run × MCP は わずか 1 年で駆け抜けた わけです。 Google Cloud は既に Cloud Storage 用の MCP サーバも公開しており、 主要な GCP サービスごとに https://<service>.googleapis.com/mcp 形式のエンドポイントが揃うのも遠くなさそうです。 1 年前なら「自分の PC で npx を立てる」 しかなかったことを思うと、 ずいぶん遠くまで来ました。
参考リンク
- What's new for Cloud Run at Next '26 | Google Cloud Blog (2026-04-23)
- Use the Cloud Run remote MCP server | Google Cloud Documentation
- MCP Reference: run.googleapis.com | Google Cloud Documentation
- Host MCP servers on Cloud Run | Google Cloud Documentation
- Build and deploy a remote MCP server on Cloud Run | Google Cloud Documentation
- GoogleCloudPlatform/cloud-run-mcp (GitHub)
- Model Context Protocol 公式
- Cloud Run MCP のベストな使い方を探った結果 (前回記事)