Google CloudのMCPサーバーをIAMで権限制御する

Google CloudのMCPサーバーは、BigQueryやCloud StorageなどのAPIをGoogleがホストしてMCP経由で公開する仕組みです。ツール呼び出しには通常のリソース権限とは別にmcp.tools.callという専用パーミッションが必要で、IAMのdeny policyとallow policyを組み合わせて「誰が・どのサービスの・どのツールを呼べるか」を細かく統治できます。

Google CloudのMCPサーバーとは — BigQueryやCloud Storageをホスト型で公開する仕組み

Google CloudのMCPサーバーは、GoogleのインフラでMCPエンドポイントを稼働させ、HTTP経由でAIアプリケーションに公開する製品群です。BigQuery・Cloud Storage・Compute Engine・AlloyDB for PostgreSQL・Bigtable・Cloud Runなど、対応プロダクトのMCPエンドポイントが順次公開されています。

これは、gcloud CLIをラップしてローカルで動く「gcloud MCPサーバー」(googleapis/gcloud-mcp)とは別の製品です。gcloud MCPサーバーの権限モデルと基本的な使い方はgcloudのMCPサーバーでGoogle Cloudを自然言語操作するで扱っています。本記事が扱うのは、Googleがホストするリモート型のMCPサーバーをIAMで統治する話です。

Claude.ai・Claude Code・Claude Desktopのいずれからも、カスタムコネクタとしてこれらのMCPサーバーに接続できます。接続にはOAuth 2.0のクライアントIDとシークレットが必要で、Google Cloud Consoleの「Google Auth Platform」からクライアントを作成します。

利用の前提として、対象プロダクトのMCPサーバーをプロジェクトで有効化しておく必要があります。有効化にはserviceusage.services.enableパーミッションが必要で、Service Usage Adminロール(roles/serviceusage.serviceUsageAdmin)がこれを含みます。

gcloud services enable bigquery.googleapis.com

対象サービス名はサーバーごとに異なり、たとえばBigQueryはbigquery.googleapis.com、Compute Engineはcompute.googleapis.comです。有効化していないサービスのMCPサーバーには、IAMの設定を正しく整えていても接続できません。

MCP呼び出しには2種類の権限が同時に必要になる

Google CloudのMCPサーバーを経由してツールを呼び出すプリンシパル(利用者やエージェント)は、次の2つの権限を両方持っている必要があります。

1. Google CloudプロジェクトへのMCP呼び出し権限: mcp.tools.callパーミッション
2. 操作対象リソースへの権限: 呼び出すAPIが通常要求する権限(例: BigQueryのデータセットメタデータを取得するならbigquery.datasets.get)

どちらか一方が欠けても呼び出しは失敗します。mcp.tools.callは持っているがbigquery.datasets.getを持っていない場合も、逆にbigquery.datasets.getは持っているがmcp.tools.callを持っていない場合も、同じように失敗します。MCP経由のアクセスを止めたいときにリソース側の権限だけを剥奪しても不十分で、mcp.tools.call側も確認する必要があるということです。

定義済みIAMロール — MCP AdminとMCP Tool User

Google CloudのMCPサーバー向けには、次の2つの定義済みロールが用意されています。

mcp.tools.callはOwner・Editorロールにも含まれており、Gemini Cloud Assistの各ロール(Admin / Editor / User)にも含まれています。すでにこれらのロールを持つプリンシパルは、追加のIAM設定なしにMCP呼び出し権限を持っている状態です。

deny/allowポリシーで制御できる4つの属性

IAMのdeny policyとallow policyでは、MCP呼び出しに固有の属性を条件式に使えます。使える属性はポリシーの種類によって異なります。

request.auth.oauth.client_idはdeny policyでしか使えません。Claude CodeやClaude.ai向けに発行したOAuthクライアントIDを条件に指定すれば、「このクライアントID経由のMCP呼び出しだけを禁止する」といった制御が可能です。

全ユーザーのMCPツール利用を禁止するdeny policy

もっとも単純な例は、プロジェクト内のすべてのユーザーに対してMCPツールの利用自体を禁止するポリシーです。

{
  "displayName": "Deny access to MCP tools for all users",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": ["principalSet://goog/public:all"],
        "deniedPermissions": ["mcp.googleapis.com/tools.call"]
      }
    }
  ]
}

このポリシーを適用すると、クライアントがtools/callを呼んだ際にHTTPエラーが返るようになります。tools/listによるツール一覧の取得自体は、このポリシーの後でも引き続き成功する点に注意してください。

書き込み系ツールだけを禁止するdeny policy

読み取り専用でないツール、つまり作成・変更・削除を伴うツールの呼び出しだけを止めたい場合は、tool.isReadOnly属性を条件に使います。

{
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": ["principalSet://goog/public:all"],
        "deniedPermissions": ["mcp.googleapis.com/tools.call"],
        "denialCondition": {
          "title": "Deny read-write tools",
          "expression": "api.getAttribute('mcp.googleapis.com/tool.isReadOnly', false) == false"
        }
      }
    }
  ]
}

作成したポリシーはpolicy.jsonとして保存し、次のコマンドでプロジェクトに適用します。

gcloud iam policies create mcp-deny-policy \
  --attachment-point=cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
  --kind=denypolicies \
  --policy-file=policy.json

特定サービスだけをMCP経由で許可するallowポリシー

allow policyでは、roles/mcp.toolUserのようなIAMロールに条件式を組み合わせて、プリンシパルがMCP経由でアクセスできるサービスを絞り込めます。次の例はuser@example.comにBigQueryとCloud StorageのMCPサーバーだけを許可する設定です。

{
  "bindings": [
    {
      "role": "roles/mcp.toolUser",
      "members": ["user:user@example.com"],
      "condition": {
        "title": "Allow MCP calls for BigQuery and Cloud Storage MCP servers",
        "expression": "resource.service == 'bigquery.googleapis.com' || resource.service == 'storage.googleapis.com'"
      }
    }
  ]
}

tool.name属性を条件に加えれば、サービス単位ではなく個別ツール単位での許可もできます。Compute Engineのlist_instancesツールだけを許可する場合は、resource.service == 'compute.googleapis.com'にapi.getAttribute('mcp.googleapis.com/tool.name', '') == 'list_instances'を組み合わせます。

制限事項

IAMによるMCP制御には、公式ドキュメントが明記するいくつかの制限があります。

• request.auth.oauth.client_id属性はdeny policyでのみ使え、allow policyでは使えません
• これらの属性はmcp.tools.callパーミッションに対してのみ検証され、deny policy内で他のパーミッションと組み合わせることはできません
• タグはresource.service属性やMCP属性と混在させて条件に使えません
• resource.serviceとtool.name属性はGoogle Cloud Consoleでは扱えず、gcloud CLIでの管理が必須です
• Resource Manager MCPサーバーへのアクセス制御には、これらのMCP属性は使えません(Resource Manager側の権限管理に従います)

Claude Code・Claude.aiから接続する際の権限確認

Claude Code・Claude.ai・Claude Desktopは、いずれもカスタムコネクタとしてGoogle CloudのMCPサーバーに接続します。OAuth 2.0クライアントの作成手順自体は3つのクライアントで共通で、Google Cloud Consoleの「Google Auth Platform > Clients」でWebアプリケーションタイプのクライアントを作り、リダイレクトURIにhttps://claude.ai/api/mcp/auth_callbackを登録します。カスタムコネクタ自体の作り方はCoworkカスタムコネクタ自作ガイドでも扱っているので、リモートMCPサーバーへの接続に不慣れな場合は合わせて確認してください。

接続後にどこまで操作できるかは、この記事で扱ったIAMのallow/deny policyと、接続したGoogleアカウント(またはOAuthで認可したアカウント)が持つロールで決まります。チームでClaude Codeから共有プロジェクトのMCPサーバーに接続する場合は、個人のOwner権限をそのまま使うのではなく、roles/mcp.toolUserにresource.serviceの条件を付けて、必要なサービスだけに絞ったロールを付与するのが安全です。Claude CodeをGoogle Cloud上でチーム展開する際のIAM設計全般はClaude Code Vertex AI IAM設定とチーム展開ガイドも参考になります。

接続設定そのものには、MCPサーバーの名前・エンドポイントURL・トランスポート種別(HTTP)・OAuthスコープの入力が共通して必要です。OAuthスコープはサーバーごとに異なり、たとえばBigQueryならhttps://www.googleapis.com/auth/bigqueryのような形式です。必要なスコープは各MCPサーバーのリファレンスドキュメントに記載されており、スコープを絞るほど、そのOAuthクライアントで到達できる範囲も狭くなります。IAM側のallow/deny policyとOAuthスコープは独立した制御なので、両方を絞ることではじめて最小権限に近づきます。

よくある質問

MCP AdminとMCP Tool User、どちらを付与するのが適切ですか

権限一覧を管理する立場ならMCP Admin、特定のMCPサーバーのツールを日常的に呼び出すだけの立場ならMCP Tool Userが基本の選択です。どちらもmcp.tools.callを含むため、実際のアクセス範囲はallow/deny policyの条件式で絞り込みます。

gcloud MCPサーバーにもこのIAMロールは使えますか

使えません。roles/mcp.adminやroles/mcp.toolUserはGoogleがホストするリモート型のMCPサーバー専用のロールです。ローカルで動くgcloud-mcp(gcloud CLIのラッパー)は通常のGCP IAM権限で動作し、権限モデルが異なります。冒頭で触れた通り、両者は別製品として扱う必要があります。

deny policyとallow policyはどちらを先に設計するのが安全ですか

まず全体を絞るdeny policy(既定禁止)を敷いてから、必要な範囲だけをallow policyで開けるのが安全な設計です。全ユーザーのMCP利用を一律禁止したうえで、特定サービスだけを許可する例のように組み合わせます。

まとめ

Google CloudのMCPサーバーは、通常のリソース権限に加えてmcp.tools.callという専用パーミッションを要求します。roles/mcp.adminとroles/mcp.toolUserの2つの定義済みロールに、tool.isReadOnly・resource.service・tool.name・request.auth.oauth.client_idの属性を組み合わせたdeny/allowポリシーで、誰がどのサービスのどのツールを呼べるかを細かく設計できます。Claude CodeやClaude.aiから接続する場合も、カスタムコネクタのOAuth設定とは別に、このIAM側の統治が実際のアクセス範囲を決めることを踏まえて設計してください。