gcloudのMCPサーバーでGoogle Cloudを自然言語操作する

gcloud MCPサーバーは、gcloud CLIをラップしてClaude CodeなどのAIアプリケーションから自然言語でGoogle Cloudを操作できるようにするOSSです。Node.js製の単一パッケージとして配布され、コマンド構文や複雑なフラグを覚えなくても「このプロジェクトのCompute Engineインスタンスを一覧して」のような指示で操作できます。実行できるgcloudコマンドには制約があり、権限も接続中のgcloudアカウントにそのまま連動します。

gcloud MCPサーバーとは — gcloud CLIをラップするnpmパッケージ

gcloud MCPサーバーはgoogleapis/gcloud-mcpリポジトリでGoogleが公開しているMCP実装で、npmパッケージ@google-cloud/gcloud-mcpとして配布されます。同じリポジトリでは、Cloud Loggingやトレースを扱うobservability-mcp、Cloud Storageを操作するstorage-mcp、バックアップ・DRを扱うbackupdr-mcpも併せて公開されています。

gcloud MCPサーバー自体が提供するツールはrun_gcloud_commandの1つだけです。これは任意のgcloudサブコマンドを1回の呼び出しで1つ実行するツールで、Claudeが状況に応じて必要なコマンドを組み立てて呼び出します。

Google Cloudにはこれとは別に、BigQueryやCloud StorageなどをGoogle自身がホストしてHTTP経由で公開する「Google Cloud MCPサーバー」という製品群もあります。こちらはIAMのdeny/allowポリシーで統治する仕組みが用意されており、Google CloudのMCPサーバーをIAMで権限制御するで扱っています。ローカルで動く本記事のgcloud MCPサーバーとは配布形態も権限モデルも別物なので、混同しないよう注意してください。

同じリポジトリにある3つの兄弟サーバー

googleapis/gcloud-mcpリポジトリは、gcloud MCPサーバー以外にも用途別のMCPサーバーをホストしています。gcloudコマンド全般を扱うgcloud MCPサーバーに対して、これらは特定のGoogle Cloud APIに特化した設計です。

導入方法はどれも共通で、パッケージ名を差し替えるだけです。ログ調査に特化したいだけならgcloud MCPサーバーではなくobservability-mcpを単体で入れる方が、ツール数が絞られてモデルの誤選択も減らせます。

なお、Firebase・Google Analytics・GKE(Google Kubernetes Engine)・Cloud Run向けのMCPサーバーは、それぞれ別リポジトリで別チームがメンテナンスしています。README内の「Other Google Cloud MCP servers」に一覧がありますが、gcloud MCPサーバーとは配布元もリリースサイクルも別なので、導入前にそれぞれのドキュメントを確認してください。Cloudflareも汎用と製品別のMCPサーバー群を公式提供しており、Cloudflare MCPサーバー一覧にまとめています。

Claude Codeにgcloud MCPサーバーを追加する

前提はNode.js 20以上と、ローカルにインストール済みのgcloud CLIです。gcloud auth loginまたはgcloud auth application-default loginで認証を済ませた状態で、次のコマンドを実行します。

claude mcp add gcloud -- npx -y @google-cloud/gcloud-mcp

接続状態はclaude mcp listで確認できます。gcloud: npx -y @google-cloud/gcloud-mcp - ✓ Connectedと表示されれば準備完了です。チーム全員に配りたい場合は--scope projectを付けて.mcp.jsonにコミットします。claude mcp addのスコープ・認証・トラブルシュートの詳しい仕様はClaude Code MCP設定ガイドにまとめています。

Claude Desktopではclaude_desktop_config.jsonのmcpServersに同じ形のJSONを書きます。

{
  "mcpServers": {
    "gcloud": {
      "command": "npx",
      "args": ["-y", "@google-cloud/gcloud-mcp"]
    }
  }
}

VS CodeやCursorなど他のMCPクライアントでも、commandとargsは同じ値をそのまま流用できます。Gemini CLI向けにはnpx @google-cloud/gcloud-mcp init --agent=gemini-cliという専用の初期化コマンドが用意されており、Gemini CLI拡張として自動登録されます。

run_gcloud_commandは1コマンドずつ実行する

run_gcloud_commandのツール定義には、モデル向けの細かい指示が埋め込まれています。中でも実務に直結するのが次の制約です。

• パイプ・リダイレクト・サブシェルの禁止: |や>、$(...)のようなシェル演算子は使えません
• コマンドチェーンの禁止: 1回の呼び出しで複数コマンドを連結する実行は失敗します
• SSH系コマンドの拒否: gcloud compute sshやgcloud interactiveのような対話セッションは動きません

READMEの謳い文句には「複数のクラウド操作を1つの繰り返し可能なコマンドにチェーンできる」とありますが、これはシェルレベルでの連結ではありません。実際には、Claudeがrun_gcloud_commandを会話の中で複数回呼び出し、1ステップずつ結果を確認しながら進める形でワークフローを組み立てます。「プロジェクト内の停止中インスタンスを一覧して、それぞれのラベルを確認してから削除して」のような指示は、内部的には一覧取得・ラベル確認・削除の複数回のツール呼び出しに分解されて実行されます。

ツールの説明文には、データ量を抑えるための細かい指示も埋め込まれています。「必要な情報だけを--format=json(part.key)のような射影(projection)で絞り込む」「フィルタ条件が分からないときは--limit=1 --format=jsonで1件だけ取得してキー構造を確認してから絞り込む」といった指示です。この振る舞いのおかげで、Compute Engineインスタンスが数百台ある環境でも、必要な列だけを取得してコンテキストを圧迫しにくくなっています。フィルタ条件を--filterに渡す際は、コロンの右側をクォートしないという細かい作法まで指定されており、モデルが誤ったフィルタ構文を生成しにくい設計です。

デフォルトで拒否されるコマンド

gcloud MCPサーバーには、AIエージェントには向かないコマンドを止めるデナイリスト(access control list)が組み込まれています。デフォルトで拒否されるのは次のコマンド群です。

拒否されたコマンドを実行しようとすると、エラーメッセージとともに代替コマンドの候補が返されることがあります。デナイリストの現在の内容は、ツールに["gcloud-mcp", "debug", "config"]という引数を渡して呼び出すと確認できます。

権限はgcloudアカウントにひもづく

gcloud MCPサーバーの実行権限は、接続時にアクティブなgcloudアカウントの権限にそのまま連動します。個人の開発環境でOwner権限のアカウントを使っている場合、AIエージェントも同じOwner権限でGoogle Cloudを操作できてしまいます。現在どのアカウントが使われているかは、gcloud config get-value accountで確認できます。

チーム開発では、Claude Codeを起動するたびに開発者本人のOwner権限がAIエージェントにそのまま渡ってしまう状態が最大のリスクです。誤操作でリソースを削除してしまうリスクも、意図しないプロジェクトを操作してしまうリスクも、権限を絞ることで小さくできます。

最小権限で運用したい場合は、サービスアカウントのimpersonation(なりすまし)を使います。まず対象のサービスアカウントに対して、自分のプリンシパル(IAMでの権限の付与対象)にroles/iam.serviceAccountTokenCreatorロールを付与してもらいます。そのうえで、次のいずれかの方法でimpersonationを有効にします。

gcloud config set auth/impersonate_service_account SERVICE_ACCOUNT_EMAIL

このコマンドを実行すると、以降のすべてのgcloudコマンド(gcloud MCPサーバー経由のものも含む)が指定したサービスアカウントの権限で実行されます。単発のコマンドだけimpersonationしたい場合は、コマンドごとに--impersonate-service-accountフラグを付ける方法もあります。

サービスアカウント側には、Compute Engineの参照専用ロールのような、業務に必要な最小限のロールだけを割り当てます。これはgcloud CLI全般に共通するIAM権限の話であり、Google自身がホストする「Google Cloud MCPサーバー」がMCP呼び出しそのものに要求するmcp.tools.callパーミッションとは別の仕組みです。

「本番環境には読み取り専用のIDだけを渡す」という設計方針自体は、他のMCPサーバーでも共通です。Kubernetes向けのMCPサーバーでの権限設計はKubernetes MCPサーバーの権限設計で扱っています。

gcloud MCPサーバーの使い分け早見表

よくあるつまずき

• 「一気にやって」と頼んでも1ステップずつしか進まない: run_gcloud_commandはコマンドチェーンを想定していない仕様です。複数ステップに分けて依頼するか、Claude自身が複数回ツールを呼ぶのを待つのが正しい使い方です
• SSHで入りたい操作が動かない: compute ssh系はデナイリストで拒否されています。対話操作が必要な場合はターミナルから直接gcloudコマンドを実行してください
• 意図しないプロジェクトで実行されてしまう: gcloud config get-value projectで現在のアクティブプロジェクトを確認してから依頼すると安全です。プロジェクトを跨ぐ操作では、依頼文に対象プロジェクトIDを明示するのが確実です
• APIが有効化されていないというエラーが出る: ツールの指示には「必要なAPIは有効化済みと仮定し、勝手に有効化しない」とあります。事前にgcloud services enableで対象APIを有効化しておく必要があります

まとめ

gcloud MCPサーバーは、gcloud CLIの操作を自然言語に変換するラッパーです。claude mcp addで数十秒で導入できる一方、run_gcloud_commandは1回につき1コマンドしか実行できず、SSH系コマンドも動きません。複雑な操作は会話の中での複数回呼び出しに分解されると理解しておくと、期待値のズレを防げます。チーム運用では、Ownerアカウントをそのまま使わずサービスアカウントのimpersonationで権限を絞るのが最初のステップです。