マネージドGCS MCPとは｜Toolbox版との違いと必要なIAM権限

はじめに
本記事のまとめ
マネージドGCS MCPとは
1. 提供されるツール
2. 制限事項
Toolbox版のGCS MCPとの違い
マネージドGCS MCPの使い方
1. curlでMCPエンドポイントの動作を確認する
必要なIAM権限を最小権限で検証する
1. ステージ1: storage.objectViewer のみ
2. ステージ2: roles/mcp.toolUser を追加
gcloudコマンドではなくMCP経由といえる根拠
ハマりどころと注意点
まとめ

はじめに

以前、MCP Toolbox を使って AI エージェントから Cloud Storage（GCS）を操作する方法を検証しました。その後、Google Cloud 自体がマネージドの GCS MCP サーバーを提供していると知り、「ローカルにサーバーを立てずに、権限を付与するだけで使えるのか」を実際に確かめてみました。

本記事では、マネージド GCS MCP の仕組みと使い方、MCP Toolbox 版との違い、そして必要な IAM 権限を段階的に切り分けた検証結果を紹介します。どちらの GCS MCP を選ぶか迷っている方の判断材料になれば幸いです。

本記事のまとめ

マネージド GCS MCP は Google がホストするリモートの MCP エンドポイントで、サーバーの構築・起動は一切不要
必要なのは OAuth 2.0 のトークンと IAM 権限、そしてクライアントへの URL 登録 1 行だけ
IAM の roles/mcp.toolUser がないと MCP のツール呼び出しは 403 で拒否されることを、実際の検証で確認しました。
同じ「GCS MCP」でも、マネージド版と MCP Toolbox 版は実体が異なる別物

それぞれ順番に見ていきます。

マネージドGCS MCPとは

マネージド GCS MCP とは、Google がホストする Cloud Storage 用のリモート MCP サーバーです。エンドポイントは https://storage.googleapis.com/storage/mcp で、Cloud Storage API を有効化しているプロジェクトならそのまま利用できます。

MCP（Model Context Protocol）は、AI エージェントに外部ツールを提供するための標準プロトコルです。通常はローカルに MCP サーバーを導入・起動する必要がありますが、マネージド版ではその部分を Google が肩代わりしてくれます。

詳細は公式ドキュメントと公式ブログで解説されています。

提供されるツール

実際に tools/list を呼び出して、次の 9 ツールが提供されていることを確認しました。

list_buckets — プロジェクトのバケット一覧
list_objects — バケット内のオブジェクト一覧
create_bucket / delete_bucket — バケットの作成・削除
read_object — オブジェクトの読み取り（テキスト・バイナリ対応）
read_text — テキスト読み取り（非推奨）
write_text — テキストの書き込み（上書き）
delete_object — オブジェクトの削除
get_object_metadata — オブジェクトのメタデータ取得

制限事項

公式ドキュメントに記載されている主な制限は次のとおりです。

読み取りはテキスト・PDF・画像に対応し、最大 8 MiB
書き込みはテキストのみで、こちらも最大 8 MiB
エンドポイントはグローバルのみ（リージョン指定は不可）

Toolbox版のGCS MCPとの違い

同じ「GCS MCP」という名前でも、マネージド版と MCP Toolbox 版は実体がまったく別物です。両者の違いを表にまとめます。

	マネージド版	Toolbox 版（ローカル）
実体	Google がホストする HTTP エンドポイント	ローカルで起動するプロセス（stdio）
事前準備	不要（Cloud Storage API の有効化のみ）	バイナリの導入と起動が必要
監査ログ	Cloud Audit Logs に自動記録	自前で用意
カスタマイズ	不可（標準ツールのみ）	カスタムツールを定義できる
ツールの引数名	`projectId`	`project`

ツールの引数名まで異なるため、片方の使い方をもう片方に流用するとエラーになります。両者は互換のある同一プロダクトではなく、別々の実装だと考えてください。

実際に両方を使って感じた違いもあります。Toolbox 版はセッション開始時にプロセスが起動する方式です。そのため、起動後に ADC（gcloud のアプリケーション用認証情報）を再認証しても、古い認証状態を引きずることがありました。マネージド版はリクエストのたびにトークンを渡す方式なので、この問題が起きません。

Toolbox 版のセットアップ手順は、GCS MCPの使い方｜MCP Toolboxで読み取り専用にする手順で詳しく解説しています。なお、Toolbox 版とは別に、Google 製のセルフマネージド実装として gcloud-mcp の storage-mcp も公開されています。

マネージドGCS MCPの使い方

クライアントには、リモート MCP サーバーとして URL を登録します。認証は OAuth 2.0 のみで、API キーは使えません。

ただし注意が必要です。Claude Code では URL の登録だけでは認証が通らず、アクセストークンをヘッダーに付けて登録する必要がありました（2026 年 7 月の検証時点）。

URL だけで登録した場合の挙動から説明します。

claude mcp add --transport http gcs-managed https://storage.googleapis.com/storage/mcp

この状態では /mcp に needs authentication と表示され、Authenticate を選んでも Incompatible auth server: does not support dynamic client registration というエラーで失敗しました。Claude Code の MCP 認証は Dynamic Client Registration（DCR）という方式を前提にしていますが、Google の認可サーバーは DCR に対応していません。方式の非互換なので、何度やり直しても成功しないはずです。

検証時点で接続できたのは、gcloud のアクセストークンを Authorization ヘッダーに埋め込んで登録する方法です。

claude mcp add --transport http gcs-managed https://storage.googleapis.com/storage/mcp \
  --header "Authorization: Bearer $(gcloud auth print-access-token)"

登録後は Claude Code の再起動が必要です。/mcp の Reconnect は設定ファイルを再読み込みしないため、再起動するまで認証状態が変わりません。再起動後に /mcp で connected / authenticated となり、ツールが使える状態になりました。

この方法には注意点が 2 つあります。トークンは約 1 時間で失効するため、失効したら同じコマンドでの再登録が必要です。また、トークンはローカル設定ファイル（.claude.json）に平文で保存されるので、設定ファイルやログの扱いに注意してください。恒久運用向けというより、検証用途の一時的な接続方法という位置づけになります。

なお「MCP の設定が不要」と紹介されることがありますが、正確にはサーバー側の構築・運用が不要という意味です。クライアント側への登録は上記のとおり必要になります。

curlでMCPエンドポイントの動作を確認する

MCP クライアントを介さなくても、curl で MCP の JSON-RPC を直接叩いて動作を確認できます。認証は ADC のアクセストークンを Bearer トークンとして渡すだけです。

まず initialize（MCP のハンドシェイク）を呼び出します。

curl -X POST https://storage.googleapis.com/storage/mcp \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'

次のように MCP のハンドシェイク応答が返ってきました。

{"id":1,"jsonrpc":"2.0","result":{
  "capabilities":{"prompts":{"listChanged":false},"tools":{"listChanged":false}},
  "protocolVersion":"2025-03-26",
  "serverInfo":{"name":"StatelessServer","version":"scaffolding on HTTPServer2"}}}

続けて tools/call でバケット一覧を取得します。

curl -X POST https://storage.googleapis.com/storage/mcp \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_buckets","arguments":{"projectId":"<PROJECT_ID>"}}}'

検証では initialize → tools/list → tools/call（list_buckets）がすべて成功し、プロジェクト内のバケット一覧が返ってきました。サーバーの構築どころか、専用クライアントの導入すら不要で GCS を MCP 経由で操作できています。

必要なIAM権限を最小権限で検証する

必要な権限は、MCP 呼び出し用の roles/mcp.toolUser と、操作内容に応じた storage 系ロールの両方です。まず公式ドキュメントに記載されている権限の対応を示します。

操作	必要なロール
MCP ツール呼び出し	`roles/mcp.toolUser`
オブジェクトの閲覧	`roles/storage.objectViewer`
オブジェクトの書き込み	`roles/storage.objectCreator`
バケットの作成・一覧	`roles/storage.admin`

この記載が実際に正しいのかを、検証用のサービスアカウントに権限を段階的に付与して切り分けてみました。

ステージ1: storage.objectViewer のみ

まず roles/storage.objectViewer だけを付与した状態で tools/call を呼び出します。結果は HTTP 403 で、MCP の呼び出し自体が拒否されました。

{"id":1,"jsonrpc":"2.0","result":{"content":[{"text":"Permission 'mcp.googleapis.com/tools.call' denied on resource...","type":"text"}],"isError":true}}

ステージ2: roles/mcp.toolUser を追加

同じサービスアカウントに roles/mcp.toolUser を追加して再実行すると、今度は tools/call が通過しました。list_buckets 自体は storage.buckets.list 権限の不足で別のエラーになりましたが、こちらは storage 系ロール側の問題です。

検証結果を整理すると次のようになります。

付与した権限	tools/call	備考
`storage.objectViewer` のみ	403（mcp.tools.call denied）	MCP 呼び出し自体が拒否される
+ `roles/mcp.toolUser`	通過	`list_buckets` には別途 `storage.buckets.list` が必要

さらに、storage.objectViewer の付与先をプロジェクト全体から特定バケットに絞った状態でも再検証しましたが、結果は同じでした。権限のスコープに関わらず、roles/mcp.toolUser が MCP ツール呼び出しの前提条件であることが実験で確定しました。公式ドキュメントの記載どおりの挙動です。

実務で試すときは、roles/mcp.toolUser に加えて、読み取り専用ロールを対象バケットに限定して付与するところから始めることをおすすめします。

gcloudコマンドではなくMCP経由といえる根拠

「これは gcloud コマンドのラッパーではないのか」という疑問にも答えておきます。検証の結果、gcloud を経由せず MCP プロトコルで直接通信していると判断できます。根拠は次のとおりです。

プロトコルが MCP そのもの: MCP 仕様の JSON-RPC メソッドに応答する。initialize に対して protocolVersion や serverInfo という MCP 固有のハンドシェイク構造を返す
URL パスが専用: 通常の GCS JSON API は /storage/v1/... だが、MCP は /storage/mcp という別パス
gcloud バイナリを経由していない: 検証は curl の HTTP POST だけで完結。gcloud はトークン取得にしか使っておらず、他の OAuth クライアントでも代替できる
応答形式が MCP のツール出力: content と structuredContent という MCP の tools/call 結果スキーマで返る
監査ログ: MCP サーバー経由のリクエストは Cloud Audit Logs に記録されると公式ドキュメントに明記されている

1〜4 は実際の検証で確認した事実、5 は公式ドキュメント由来の情報です。

ハマりどころと注意点

検証中に実際につまずいた点を共有します。

ツールの引数名は projectId。project と指定すると Invalid JSON payload received. Unknown name "project" というエラーになります。Toolbox 版は project なので、混同しやすいポイントです。正しいスキーマは tools/list の応答に含まれる inputSchema で確認できます。

ADC の再認証切れに注意。ADC の認証が切れている（invalid_grant / invalid_rapt）と 401 系のエラーで失敗します。gcloud auth application-default login で再認証してから実行してください。

Toolbox 版特有の認証の引きずり。Toolbox 版は起動済みプロセスが古い認証状態を保持し続けることがあり、ADC を再認証してもセッションの再起動が必要でした。マネージド版はリクエストごとにトークンを渡すため、この問題は起きません。

まとめ

本記事では、Google Cloud のマネージド GCS MCP を検証しました。要点は次のとおりです。

マネージド GCS MCP はサーバー構築不要で、OAuth トークン + IAM 権限 + クライアントへの URL 登録 1 行で使える
roles/mcp.toolUser は MCP ツール呼び出しの必須権限（段階的な権限付与の実験で確認）
Toolbox 版とは実体・引数名・運用が異なる別物

どちらを選ぶかの目安として、標準ツールで足りて運用の手間を減らしたい場合はマネージド版、カスタムツールの定義が必要な場合は Toolbox 版が向いていると考えています。なお、マネージド GCS MCP の料金については、執筆時点の公式ドキュメントに明記が見当たらなかったため未確認です。

まずは読み取り専用の権限を検証用バケットに絞って付与し、curl で initialize から順に叩いてみるのが安全な始め方です。ぜひ試してみてください。