こんにちは！
先進技術戦略室の中谷です！
Google Cloud Next '26のアップデート情報をみている中でCloud Run MCPの存在を知り、自分なりに試行錯誤し、活用例を模索してみた結果の一部始終をこちらの記事では残しております。
この記事で分かること
- Cloud Run MCP でできること・できないこと
- 「Claude からデプロイ」の落とし穴
- Cloud Run MCP の使いどころ
- gcloud との使い分け
きっかけは単純な疑問でした。 Claude に「Cloud Run MCP サーバーって何に使うの？」 と聞いてみたら、 「Claude 上から Cloud Run へのデプロイや、 トラブルシューティングができます」 と返ってきました。 なるほど、 と一瞬思ったのですが、 すぐに引っかかりました。
Cloud Run へのデプロイって、 普通は CI/CD で回しますよね？ GitHub に push したら Cloud Build や GitHub Actions が走って、 レビューと承認を経て本番に出る。 その世界観のなかで「Claude からデプロイできます」と言われても、 「いや、 AI に本番デプロイさせるの普通に怖いが……」 というのが正直な感想でした。
そこで実際に Cloud Run MCP を Claude Code に繋いで、 デプロイも調査も一通り触ってみました。 この記事は、 その結果として自分がたどり着いた 「結局このツールはどこで使うのか」 という見立てです。 検証の手順や数値そのものではなく、 使いどころの話 に絞ります。
本番デプロイは CI/CD、 調査は Claude(MCP)。 Claude は本番の承認ゲートには入らず、 ログを覗く側に立つ。
想定読者
- Cloud Run MCP の名前は聞いたが、 「で、 何に使うの？」が腹落ちしていない方
- 「AIからデプロイできます」系のツール紹介に、 どこか実用性の引っかかりを感じる方
- gcloud やコンソールを普段使っていて、 わざわざ MCP を入れる意味があるのか知りたい方
- AIエージェントに運用作業を任せる範囲を、 現実的に見極めたい方
Cloud Run MCP がそもそも持っている道具
そもそも MCP(Model Context Protocol) は、 AI に外部のツールやデータへのアクセスを与えるための共通規格です。 その Cloud Run 版が Cloud Run MCP で、 AI(Claude など)に Cloud Run を操作させるための窓口になります。
話の前提として、 Cloud Run MCP(GoogleCloudPlatform 公式 / Apache-2.0)が AI に渡すツールはこれだけです。
| 種類 | ツール | できること |
|---|---|---|
| デプロイ |
deploy-local-folder / deploy-file-contents / deploy-container-image
|
フォルダ・ファイル・イメージをデプロイ |
| 調査 | get-service |
サービスの基本情報(URL・最終デプロイ者など) |
| 調査 | get-service-log |
ログ・エラーの取得 |
| 調査 |
list-services / list-projects
|
サービス・プロジェクトの一覧 |
| 構成 | create-project |
プロジェクト作成 |
ざっくり言うと 「デプロイする」「状態とログを見る」「一覧する」 の3系統です。 この道具立てを頭に置いて、 本題に入ります。
参考:
「Claudeからデプロイできる」は実用的か
結論から言うと、 本番運用の文脈では筋が悪い と思います。
理由はシンプルで、 本番デプロイには レビュー・承認・履歴・ロールバック といったガードレールが要るからです。 これらは CI/CD パイプラインが担う役割で、 「誰が・何を・いつ出したか」がパイプラインに残ること自体に価値があります。 そこを AI エージェントが会話の流れでポンと出せてしまうのは、 便利というより 怖い 。 統制を外す方向に働きます。
加えて、 実際に触って分かったのですが、 Cloud Run MCP のデプロイツールは 環境変数・メモリ・CPU・同時実行数・サービスアカウントといったサービス構成を指定できません(渡せるのはコードやイメージと、 プロジェクト・リージョン・サービス名だけ)。 本番に必要な構成はだいたいこの「指定できない側」にあるので、 そもそも本番デプロイの道具としては力不足です。
ではデプロイ機能に価値がないかというと、 そうでもありません。 dev・検証・プロトタイプ・ハッカソン のような「今すぐ雑に動かしたい」場面では普通に便利です。 要は 「本番のデプロイ手段」ではなく「使い捨ての実行環境を一瞬で立てる手段」 と捉えると分かりやすいです。
参考:
「調査」としての活用はどうなのか
デプロイが本番向きでないなら、 残るは 調査・トラブルシュート です。 そして触ってみると、 ここは思ったより使えました。
肝は get-service-log です。 これがデプロイ失敗時のエラーだけでなく、 稼働中サービスのランタイムエラーまで拾ってくれる 。 たとえば、 あるエンドポイント(/boom)で例外が出るアプリを動かして実際に叩くと、 ログにはこう出ます(実際の出力。 スタックは一部省略し、 URL は伏せています)。
[2026-06-26T13:39:11.843Z] [ERROR] TypeError: Cannot read properties of null (reading 'value')
at /workspace/app.js:11:16
at Layer.handle [as handle_request] (/workspace/node_modules/express/lib/router/layer.js:95:5)
at next (/workspace/node_modules/express/lib/router/route.js:149:13)
at Route.dispatch (/workspace/node_modules/express/lib/router/route.js:119:3)
[2026-06-26T13:39:11.840Z] [ERROR] HTTP Request: GET StatusCode: 500 ResponseSize: 372 Byte - https://<service>-xxxx-an.a.run.app/boom
[2026-06-26T13:39:10.048Z] [INFO] HTTP Request: GET StatusCode: 200 ResponseSize: 191 Byte - https://<service>-xxxx-an.a.run.app/
アプリの例外スタックトレースと、 HTTP のステータスコードがそのまま取れます。 これを AI が自分の文脈に取り込んで、 「/boom で app.js:11 の null 参照が原因ですね」 と切り分けてくれる。 ログを人間がコピペして貼り直す手間が消えるのは、 思ったより効きます。
「デプロイは怖いけど、 ログを読ませて一次切り分けさせる」 のは、 確かに自然な使い方だと感じました。
参考:
でも、 それgcloudで完結するのでは？
はっきり言ってしまうと、 gcloud やコンソールに慣れている人には、 Cloud Run MCP は要りません。
理由は、 MCP でできる調査は gcloud のサブセット だからです。 触っていて「これは MCP からは無理だな」 と分かったものを並べると、 けっこうあります。
| 調査でやりたいこと | Cloud Run MCP | gcloud / コンソール |
|---|---|---|
| デプロイ失敗・ランタイムのログ | できる | できる |
| サービス/プロジェクトの一覧 | できる | できる |
| メトリクス(CPU・メモリ・レイテンシ・リクエスト数) | できない | できる |
| リビジョン一覧・トラフィック配分 | できない | できる |
| IAM・権限まわりの確認 | できない | できる |
| ログの絞り込み(期間・重大度・全文検索) | できない | できる |
| Cloud Build のビルドログ | できない | できる |
つまり Cloud Run MCP は 新しい能力を足してくれるわけではない 。 少し深く調べようとすると、 結局 gcloud かコンソールに戻ることになります。 「MCP があれば gcloud を卒業できる」 ような道具ではない、 という点は知っておいた方がいいと思います。
さらに言えば、 Claude Code のように シェルを持つクライアントなら、 gcloud をそのまま実行できます。 実際この検証中も、 MCP が不安定なときは gcloud run revisions list でデプロイ結果を見たり、 gcloud run services update --set-env-vars で環境変数を入れたりしていました。 その出力も同じく会話の文脈に入りますし、 できることは gcloud の方が多い。 つまり Claude Code に限れば、 MCP の優位はかなり薄い のです。
Cloud Run MCP でできることは gcloud / コンソールの一部。 メトリクス・IAM・リビジョン・ビルドログには手が届かない。
Cloud Run MCP の真価はどこにあるのか
ここまで否定的に聞こえたかもしれませんが、 Cloud Run MCP にちゃんと価値が出る場面はあります。 ただしそれは「能力の高さ」ではなく、 「どんなクライアントから、 どれだけ安全に Cloud Run へ触れるか」 という方向の価値です。
たしかに「Cloud Run の状態やログが、 AI の会話の文脈に直接入ってくる」 のは便利です。 gcloud の出力を人間がコピペして AI に貸す、 という往復が消えます。 ただ、 ここで前の章の引っかかりが効いてきます。 Claude Code のようにシェルを持つクライアントなら、 gcloud を直接叩いても同じく文脈に入る 。 だから「文脈に入ること」そのものは、 MCP だけの強みではありません。
ログや状態が会話の文脈に直接入る。 ただしシェルを持つ Claude Code なら、 gcloud 直叩きでも同じことができる。
では、 MCP 固有の強みは何か。 自分の見立ては3つです。
- シェルを持たないクライアントから Cloud Run に触れる、 ほぼ唯一の手段になる。 Claude Desktop や claude.ai のようなチャット型ホストは、 任意のコマンドを実行できません。 そこでは gcloud を叩けないので、 Cloud Run に触るには MCP が要る。 gcloud を直接叩ける Claude Code は、 むしろ“シェルを持つ例外”です。
- AI の知識ズレに左右されにくい。 gcloud のコマンド体系は LLM の学習データに依存するので、 古いコマンドや存在しないフラグを AI が叩いて空振りすることが起きます。 MCP はツール契約(ツール名・入力スキーマ)がプロンプトに明示提示されるので、 AI は「使えるのはこれだけ・引数はこの形」と最初から知っている。 誤コマンドが構造的に出にくいのは MCP 側の利点です。
-
構造化された入出力で AI が誤読しにくい。 gcloud はテキスト出力なので、
--format=jsonを指定し忘れると AI がパースする過程で読み違える余地が残ります。 MCP は最初から JSON 構造でレスポンスが返るので、 ログの timestamp / severity / message のようなフィールドを取り違えにくい。 小さな差ですが、 調査の精度に効いてきます。
この観点で整理すると、 活きる人・場面と、 要らない人・場面がはっきりします。
使うと活きる人・場面と、 要らない・向かない人・場面。 gcloud 熟練者や本番デプロイには向かない。
現実的な使い方の落としどころ
自分なりの落としどころはこうです。
- 本番デプロイには使わない。 そこは CI/CD の領域で、 AI に渡すべきではない。
- dev・検証ループの相棒として使う。 「直す → 一瞬で上げる → ログを読ませる → また直す」 を、 Claude の会話のなかで文脈を切らさず回す。 ここがいちばん気持ちよく回ります。
- 調査は『一次切り分け』の入口として使う。 AI にログを読ませて当たりをつけ、 メトリクスや IAM まで踏み込む深掘りは gcloud / コンソールにバトンタッチする。
- クライアントで選ぶ。 Claude Code のように gcloud を直接叩ける環境なら、 無理に MCP を挟む必要はない。 MCP をあえて選ぶのは、 シェルを持たないクライアント(Claude Desktop など)や、 AI のコマンド誤り・出力の読み違いを構造的に減らしたいときです。
本番には触らせず、 dev・検証ループの相棒に。 深掘り(メトリクス・IAM)は gcloud / コンソールへ。
要は 「本番の運用ツール」ではなく「開発と一次調査を会話のなかで回すためのアダプタ」 です。 そう位置づけると、 期待値を間違えずに付き合えると思います。
最後に
MCP 全般に言えることかもしれませんが、 この種のツールは 「AI の手数を増やす」より「AI に文脈を渡す」 ところに本質がある気がしています。 Cloud Run MCP も、 Cloud Run に新しいことができるようになる魔法ではなく、 シェルを持たないクライアントからでも Cloud Run をその文脈に引き込み、 ツール定義と構造化された出力で AI に渡せるアダプタ 、 という距離感でした。
なので「使うべきか」 の答えは、 ツールの優劣ではなく あなたがどのクライアントで作業しているか で決まると思います。 ターミナルや Claude Code で gcloud を叩ける環境なら、 無理に入れる必要はありません。 逆に、 シェルを持たないチャット型のクライアントで Cloud Run に触れたい、 あるいは AI に正しいコマンドと構造化された結果を渡して調査の精度を上げたいなら、 出番があります。
あなたなら、 Cloud Run MCP をデプロイに使いますか、 それとも調査だけに留めますか。 自分は今のところ、 「本番には触らせない。 dev の相棒と、 ログ読みの入口」 に落ち着いています。