GoogleCloudのRemote MCPサーバ（CloudStorage / Pub/Sub / CloudRun）をClaude Codeから試してみる

はじめに

データアナリティクス事業本部のkobayashiです。

2026年4月、Google Cloudの Remote MCP（Model Context Protocol）サーバ が複数のサービスで立て続けにGAになりました。Pub/SubのAI Inference SMT、Cloud StorageのObject ContextsのGAに続き、データ系サービスの自然言語からの操作環境が整った形になりました。

BigQuery MCPサーバは2025年12月のプレビュー時点でClassmethod社内でも何本か記事が出ているので、本記事ではGAになったばかりの Cloud Storage / Pub/Sub / Cloud Run の3つをClaude Codeから試してみたいと思います。

BigQuery MCPに関するDevelopersIOの関連記事は以下を参照してください。

• Claude Desktop で Google Cloud BigQuery コネクタを設定し、Claude 組織ユーザーに利用してもらう — 本記事と同じGoogle Cloud純正のRemote MCPサーバを、Claude Desktopのコネクタとして組織配布する手順。

• Google Cloud MCPサーバをClaudeから利用する — プレビュー時点でClaude.aiのカスタムコネクタからBigQuery Remote MCPに繋いだ際の構成例。

• Claude Code から MCP Toolbox for Databases を使って自然言語で BigQuery を操作してみた — Google純正MCP登場前の選択肢だったMCP Toolbox for Databasesでの接続パターン。

• ClaudeとBigQueryをMCPサーバーで接続してみる — サードパーティ製MCPサーバ（ergut/mcp-bigquery-server）でBigQueryに接続した初期の事例。

• Use the Cloud Storage MCP server

• Use the Pub/Sub MCP server

• Use the Cloud Run MCP server

Google Cloud Remote MCPサーバとは

Google Cloudが各サービスのAPIをMCP経由で公開している純正のリモートMCPサーバです。OAuth 2.0で認証され、呼び出した本人のIAM権限の範囲でAPIが実行されます。

ポイントはサーバ側で改めてサービスアカウントなどの認証情報を持つ必要がない点です。呼び出すユーザが普段Google Cloudにアクセスしている際の権限がそのまま使われるため、IAMで「閲覧者には参照しかさせない」「特定のユーザにだけバケット作成権限を付ける」といった既存の運用設定がそのまま適用されます。

共通の準備：OAuthクライアントの作成

Claude.aiなどClaudeシリーズから接続する場合、Google CloudのOAuthクライアントを事前に作成する必要があります。一度作っておけばGoogle CloudサービスのMCPサーバで共通で使い回せます。

1. Google Cloud コンソールで「Google Auth Platform > Clients > Create client」を開く
2. Application type で Web application を選択
3. Authorized redirect URIs に以下を追加（Claude Codeから接続する場合は後述の方法で自動採番されるためコールバックポート指定時の http://localhost:{ポート}/callback を追加）
   • https://claude.ai/api/mcp/auth_callback（Claude.ai／Claude Desktopから接続する場合）
4. 作成後に表示されるクライアントIDとシークレットを控える

クライアントシークレットはパスワードと同等の扱いになるので、リポジトリにコミットしないよう注意します。

Claude Codeへの追加

Claude Codeでは claude mcp add コマンドでリモートMCPサーバを追加します。今回はOAuthのコールバックポートを 8080 に固定し、3つのサーバをまとめて登録してみます。

# Cloud Run MCP
$ claude mcp add --transport http \
    --client-id {クライアントID} --client-secret --callback-port 8080 \
    gcp-run https://run.googleapis.com/mcp

# Pub/Sub MCP
$ claude mcp add --transport http \
    --client-id {クライアントID} --client-secret --callback-port 8080 \
    gcp-pubsub https://pubsub.googleapis.com/mcp

# Cloud Storage MCP
$ claude mcp add --transport http \
    --client-id {クライアントID} --client-secret --callback-port 8080 \
    gcp-storage https://storage.googleapis.com/storage/mcp

OAuthクライアントを使い回すため --callback-port には事前にGoogle Cloud側で登録した http://localhost:8080/callback を指す 8080 を指定しています。 --client-secret フラグはマスク入力でシークレットを聞かれるので、ペーストするだけです。

登録した内容を確認します。

$ claude mcp list
gcp-run          https://run.googleapis.com/mcp
gcp-pubsub       https://pubsub.googleapis.com/mcp
gcp-storage      https://storage.googleapis.com/storage/mcp

Claude Codeを起動して /mcp コマンドで各サーバの状態を確認し、認証が未完了のものはブラウザでGoogleアカウントにログインしてOAuthフローを完了させます。

ブラウザで「○○ にGoogle Cloudへのアクセスを許可」を承認すると、Claude Code側のステータスが connected になります。

/mcp

 Manage MCP servers
    ...
    Local MCPs (/Users/xxxxxx/.claude.json [project:/Users/xxxxxx/])
    gcp-pubsub · ✔ connected · 15 tools
    gcp-run · ✔ connected · 5 tools
    gcp-storage · ✔ connected · 7 tools

Cloud Storage MCP を試す

Cloud Storage MCPサーバが提供する主な機能は以下です。

ファイルの読み書きには 最大8MiB という上限があり、巨大ファイルの転送には向きません。一方で「設定ファイルを置く」「軽量なログを書き出す」といった用途であれば自然言語からそのまま操作できるようになります。

実際にClaude Codeに依頼してみます。なお現状の create_bucket ツールはロケーション指定の引数を受け付けないため、依頼文でロケーションを指示しても呼び出し時には反映されません（実体はプロジェクトのデフォルト挙動でUS multi-regionに作られます）。場所固定が必要な場合は依頼内では作らず、別途 gcloud storage buckets create --location=... で先に作っておく形が確実です。

gcp-storage MCP を使って、kobayashi-mcp-demo というバケットを新規作成して、
そこに notes/hello.txt として "Hello from Claude Code" というテキストを書き込んで。
そのあとバケットに何が入っているかリストして見せて。

Claude Code側ではCloud Storage MCPの create_bucket、write_text、list_objects の各ツールが順に呼ばれます（Cloud Storage MCPは他に list_buckets / get_object_metadata / read_object / read_text を提供しています）。それぞれ以下の引数で呼ばれていました。

gcloud storage で作成されたバケットとオブジェクトを確認できます（バイト数は "Hello from Claude Code" の22バイト）。

$ gcloud storage ls gs://kobayashi-mcp-demo/notes/
gs://kobayashi-mcp-demo/notes/hello.txt

$ gcloud storage cat gs://kobayashi-mcp-demo/notes/hello.txt
Hello from Claude Code

$ gcloud storage buckets describe gs://kobayashi-mcp-demo --format="value(location,locationType)"
US	multi-region

実行ユーザのIAMに Storage Admin 相当の権限がない場合、書き込みや作成は当然失敗します。MCPサーバ自体に強い権限を持たせる構成ではなく、あくまで「呼び出した人ができる範囲」しかできない点が把握しやすくて使いやすいと感じました。

Pub/Sub MCP を試す

Pub/Sub MCPサーバでは以下の操作が可能です。

リージョナルエンドポイントはプレビュー段階ですが、グローバルエンドポイントはGAです。今回は前回のAI Inference SMTの記事で作成したトピックの様子を確認しつつ、新しいトピックを作って試してみます。

gcp-pubsub MCP を使って、
1. 現在のプロジェクトのトピックを一覧表示
2. demo-mcp-topic というトピックを新規作成
3. そこに「Pub/Sub MCP からのテスト送信」というメッセージを publish
を実行して。

この依頼では list_topics → create_topic → publish の各ツールが順に呼ばれます。publish のメッセージ本文は Base64エンコードされた状態 で messages[].data に渡す仕様で、Claude Code側はこれを自動でエンコードしてから呼び出してくれます（依頼文ではそのまま日本語を書けばOKです）。Claude Codeの出力例:

1. 既存トピック:
   - projects/kobayashi-masahiro/topics/wf-topics
   - projects/kobayashi-masahiro/topics/test
   - projects/kobayashi-masahiro/topics/koenv-v1
2. demo-mcp-topic を作成しました（projects/kobayashi-masahiro/topics/demo-mcp-topic）。
3. publish 戻り値: {"messageIds":["19453326447373746"]}

サブスクリプションを作っていないのでメッセージは溜まったままになりますが、新規トピックの作成と publish が自然言語の指示ひとつで完了しました。

PubSubのMCPサーバはトピック・サブスクリプションのメタ操作を担うため、AI Inference SMT のような変換ロジック自体を組み立てるのには向きません。「メッセージフローの土台を素早く準備する」「環境ごとのトピック設定の差分を確認する」用途には合うかと思います。

Cloud Run MCP を試す

Cloud Run MCPサーバはCloud Runのサービス・ジョブ・ワーカープールの管理ができます。Worker Poolsも4月にGAになったタイミングなので、こちらもまとめて取り扱える状態です。

実際に既存のサービスを一覧してから、新しいサービスを立ててみます。

gcp-run MCP を使って、
1. asia-northeast1 にある Cloud Run サービスを一覧表示
2. gcr.io/cloudrun/hello イメージを使って hello-mcp というサービスを
   asia-northeast1 に未認証アクセス可で新規デプロイ
3. デプロイ後の URL を教えて

この依頼では list_services → deploy_service_from_image → get_service の順にツールが呼ばれます（Cloud Run MCPはこの他に deploy_service_from_archive や deploy_service_from_file_contents も提供しているので、ローカルのソースコードからデプロイすることも可能です）。deploy_service_from_image の主な引数は name / project / region / template.containers[0].image で、未認証アクセス可にする場合は invokerIamDisabled=true を渡します。Claude Codeの出力例:

1. asia-northeast1 のサービス:
   - test-task (https://test-task-{プロジェクト番号}.asia-northeast1.run.app)
2. hello-mcp をデプロイしました（CONDITION_SUCCEEDED）。
3. URL: https://hello-mcp-{プロジェクト番号}.asia-northeast1.run.app

curl でアクセスすると、Cloud Run の Hello World ページが返ってきます（実際はHTML全文が返るので、ここではtitleタグだけ抜粋です）。

$ curl -s https://hello-mcp-{プロジェクト番号}.asia-northeast1.run.app | grep -o '<title>[^<]*</title>'
<title>Congratulations | Cloud Run</title>

「軽くPoCのサービスを立てて動作を確認する」「複数リージョンを跨いだ既存サービスの棚卸しをする」といった作業はもともとgcloudコマンドや管理コンソールの行き来が発生していたところで、対話的に進められるとかなり楽になります。一方、/deploy プロンプトなどはまだプレビュー段階の機能もあるため、本番のCI/CDをMCPで置き換えるよりは「探索的な操作の足回り」に使う形が現実的だと思います。

まとめ

2026年4月にGAになったCloud Storage / Pub/Sub / Cloud RunのリモートMCPサーバをClaude Codeから一気に試してみました。それぞれのサーバが純粋にAPIをMCPで包んでいるだけなので、OAuthクライアントひとつ作っておけば数行のコマンドで横並びに足回りが整います。実行権限が呼び出した本人のIAMに従う点も、サービスアカウント鍵を持ち回す必要がなくて運用上扱いやすかったです。

4月にはBigQuery MCPサーバもGAになっているため、BigQueryでクエリを組み立てつつ、結果をGCSに書き出してCloud RunのジョブからPub/Sub経由でトリガする、といった一連のデータパイプラインの組み立てまで自然言語からまとめて触れる環境が整いつつあります。今後は個別MCPでの掘り下げ記事も書いていく予定です。

最後まで読んで頂いてありがとうございました。