Google Cloudのプロジェクトを少人数で運用していると、ログの確認やVMの状態の確認をClaude CodeやGemini EnterpriseなどのAIエージェントに任せたくなります。そのためにエージェントの環境へgcloudを入れてログインすると、エージェントはその環境のgcloudの認証状態のまま動きます。どこまで操作できるかは、ログインした人の権限次第です。
2026年9月30日付のGoogle Cloud公式ブログで、gcloudとbqをリモートのMCPサーバーとして使う「Google Cloud CLI remote MCP server」がプレビューとして公開されました。ローカルにgcloudを入れる方式と何が違い、つなぐ前に何を決めておくべきかを、公式の説明と編集部が接続先を確かめた結果に分けて整理します。
ローカルのgcloudと何が違うのか
ブログ（筆者はGoogle CloudのProsper Nwankpa氏、Adam Hwang氏）は、これまでエージェントにクラウドを操作させるには、実行環境にgcloudを入れて保守する必要があったと書いています。リモートMCPでは、コマンドはGoogle Cloud基盤上の隔離されたサンドボックスで実行されます。
| 観点 | エージェントの環境にgcloudを入れる（編集部の整理） | Cloud CLIリモートMCP（Googleの説明） |
|---|---|---|
| 実行場所 | エージェントが動く端末・コンテナ | Google Cloud基盤上の隔離されたサンドボックス |
| 認証情報 | その環境にログイン済みの認証 | 環境に置かれた認証情報（ambient credentials）を持たない。Agent Identity・OAuth 2.0・IAMで認証・認可 |
| CLIの更新 | 環境ごとに版と依存を保守 | ローカルへのインストールと保守が不要 |
| Webのエージェント | 利用者がパッケージを入れられない環境では使えない | Gemini Enterpriseなどのホスト型からも使える |
| 実行の記録 | 環境ごとの設定次第 | 設定すればツール呼び出しを監査ログに記録 |
ブログによると、コマンドは認証した呼び出し元の権限で実行され、IAMの権限と組織ポリシーの制約が操作先のリソースに対して適用されます。認証は、Google Cloudのホスト型プラットフォームではキーを使わないAgent Identity、外部のランタイムではOAuth 2.0です。MCPサーバー自体に追加料金はなく、作成したリソースとデータ転送の費用だけがかかるとしています。
始めるには、プロジェクトでCloud CLI Execution API（cloudcli.googleapis.com）を有効にし、エージェントか利用者のIDに「MCP Tool User」（roles/mcp.toolUser）ロールを付け、MCPクライアントの接続先を cloudcli.googleapis.com/mcp にします。
接続先に認証なしで問い合わせて分かったこと
編集部はGoogle Cloudのアカウントを使わず、2026年10月2日に https://cloudcli.googleapis.com/mcp へ認証なしでリクエストを送りました。
- GETは405（Method Not Allowed）でした
- MCPの
initializeと、ツール一覧を返すtools/listは認証なしで応答しました - ツールは
run_gcloud_commandとrun_bq_commandの2つで、どちらもreadOnlyHint: false、destructiveHint: trueでした tools/callでコマンドを実行しようとすると401になり、OAuthの保護リソース情報の場所が返りました
その保護リソース情報は次のとおりです。
{"authorization_servers":["https://accounts.google.com/"],"bearer_methods_supported":["header"],"resource":"https://cloudcli.googleapis.com/mcp","scopes_supported":["https://www.googleapis.com/auth/cloud-platform"]}ツールの説明文には「It is NOT restricted to read-only commands.」とあり、作成・更新・削除もできると明記されています。run_gcloud_command の説明には、エージェントが実行してはならないコマンドとして auth・billing・config などが並んでいます。ただし、これはエージェントへの指示として書かれたものです。一方、ドキュメント「Use the Google Cloud CLI remote MCP server」は、セキュリティなどの理由で一部のコマンドに対応しないとしています。例として挙がっているのは gcloud auth・gcloud config・gcloud iam service-accounts・gcloud init・gcloud survey で、この一覧は網羅的ではなく予告なく変わるとされています。bq では init・pyshell・shell が対応外です。認証して試していないため、実際にどう拒否されるかは確認できていません。
図のうち「編集部確認」と書いた3点（スコープ、401、readOnlyHint）は編集部が接続して確かめた点で、それ以外はGoogleのブログの説明です。
範囲を絞るのはスコープではなくIAM
ここからは編集部の整理です。保護リソース情報が示すOAuthのスコープは cloud-platform の1つだけでした。スコープで「読み取りだけ」に絞る作りではないため、エージェントにできることは、認証したIDのIAMロールと組織ポリシーで決まります。
もう1つ注意したいのは、プロジェクトの指定が2か所ある点です。ツールの project 引数はAPIの有効化確認や課金・割り当てに使うもので、ツール説明は「This is NOT the same as the —project flag」と書いています。操作先はコマンドの --project で別に指定できます。APIを有効にするプロジェクトを1つに限っても、操作先がそのプロジェクトに限られるとは読めません。
ローカルのgcloudでも、リモートMCPでも、ログインした人の権限で動くことは変わりません。違いは、環境に認証情報を置かない点と、監査ログやModel Armorといった管理の仕組みをGoogle側でそろえられる点です。オーナー権限のアカウントでつなげば、エージェントもその権限で動きます。
つなぐ前に決めること（編集部の提案）
1. エージェント専用のIDを用意する
外部のランタイムからはOAuth 2.0で認証します。誰のアカウントで同意するかが、そのままエージェントの権限になります。管理者の個人アカウントではなく、エージェントに使わせるIDを分け、必要なロールだけを付けます。最初は参照系のロールに限り、変更が必要な作業が出てきた時点で追加を検討します。
2. 試すプロジェクトと、届く範囲を決める
先に述べたとおり、操作先はIAMで届く範囲すべてです。検証用のプロジェクトを用意し、エージェント用のIDには本番プロジェクトのロールを付けないところから始めます。フォルダや組織の単位でロールが付いていないかも確認します。
3. 監査ログを先に有効にする
ブログは、ツール呼び出しを監査ログ（cloudcli.googleapis.com/mcp のData Accessログ）に記録するよう「設定できる」と書いています。記録には、呼び出し元のID、OAuthクライアント、IAMの認可判定（mcp.googleapis.com/tools.call）を確認でき、機密性のあるコマンドの内容（payload）や個人情報は露出しないとしています。最初の接続より前に有効にし、どのIDが呼んだかを追えるか確かめます。監査ログにコマンドがどこまで残るかは確認できていないため、どのコマンドを実行したかまで追いたい場合は、エージェント側の実行記録も残しておきます。
4. 外部の文字列を読ませるならModel Armorを検討する
ログやテーブルの中身には、外部から入った文字列が混ざります。ブログは、Model Armorとの連携でプロンプトと応答を検査し、プロンプトインジェクションなどを防げるとしています。設定方法と費用は今回確認できていないため、ドキュメントで確かめてから判断します。
5. 変更・削除は人が承認する
2つのツールは、読み取りも削除も同じツールで実行します。属性も readOnlyHint: false のため、MCPクライアントの属性だけを見て自動承認すると、変更系のコマンドも素通りになり得ます。このサーバーは呼び出しごとに人が承認する設定にします。読み取りと書き込みの境界の考え方はAIエージェントに更新を許す日でも整理しました。
Google WorkspaceのMCPサーバーでも、権限は増えないが届く範囲は変わるという同じ構図があります。Google Chat MCPで決めることもあわせて参照してください。MCPそのものの仕組みはMCP完全ガイドにまとめています。
まだ分からないこと
- 一般提供（GA）の時期。 ブログはプレビューとだけ書いています
- 割り当て（クォータ）と、サンドボックスが動くリージョン。 ブログにも、10月5日に確認したドキュメントにも記載は見当たりませんでした
roles/mcp.toolUserと組み合わせるロールの最小構成。 ドキュメントでは、このロールで求められる権限はツール呼び出し（mcp.tools.call）です。コマンドの操作先への権限は呼び出し元のIAMで決まるため、用途ごとの組み合わせは確認していません- 対応外のコマンドが、実際にどう拒否されるか。 認証して試していません
- Model Armorと監査ログの費用。 MCPサーバー自体は追加料金なしですが、周辺の機能の費用は確認していません
2026年10月2日に、Google Cloud公式ブログ「Empower your agents with the Google Cloud CLI remote MCP server」（2026年9月30日付）を直接開いて確認しました。あわせて、
https://cloudcli.googleapis.com/mcpに認証なしでGET・initialize・tools/list・tools/callを1回ずつ送り、応答とツール説明を記録しました。Google Cloudのアカウントでの認証、実際のコマンド実行、監査ログとModel Armorの設定は試していません。公開前の10月5日に、ドキュメント「Use the Google Cloud CLI remote MCP server」（9月30日更新）を開いて対応外のコマンドと必要なロールを確認し、同じ接続先へのtools/listと保護リソース情報も改めて取得して、ツールの注記が変わっていないことを確かめました。
Google Cloudの運用にAIエージェントを組み込む際の権限設計や、自動化の仕組みづくりは、開発・AI・自動化のご相談からお問い合わせください。
Sources
- Empower your agents with the Google Cloud CLI remote MCP server — Google Cloud Blog（2026年9月30日）
- Use the Google Cloud CLI remote MCP server — Google Cloud ドキュメント
- Google Cloud CLI remote MCP server エンドポイント
https://cloudcli.googleapis.com/mcpのtools/list応答と、https://cloudcli.googleapis.com/.well-known/oauth-protected-resource/run_gcloud_command（2026年10月2日に編集部が取得）
