AI・生成AI

Google Cloud MCPの権限設計2026｜自動有効化とIAMロールを実務で押さえるチェックリスト

2026年7月2日33分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・生成AI

結論：MCPの経路は「導入」ではなく「有効化」で立つ。守りの主役は roles/mcp.toolUser

先に要点を3つだけ置く。実務判断はここから逆算すればよい。

Google Cloudのリモートmcpサーバーは、対応サービスを有効化した時点で自動的に使える状態になる。 2026年3月17日以降、MCPを個別に有効化する操作は不要で、リモートMCPエンドポイントは「対応プロダクトを有効化すると既定で利用可能」になる（Google Cloud「MCP servers release notes」）。つまり「AIエージェントを導入したから経路ができる」のではなく、BigQueryやGKEを普段どおり使っているだけで、外部のAIアプリから正しい認証情報で到達できる経路が既にある、という順序になっている。
権限は「二重ゲート（デュアルレイヤー）」で決まる。 MCPを呼び出せるか（ゲート1）とサービスのデータを操作できるか（ゲート2）は別レイヤーだ。ゲート1は roles/mcp.toolUser（MCP Tool User、権限は mcp.tools.call）、ゲート2は各サービス側のロール（例：Agent Platformなら roles/aiplatform.user）で、両方そろって初めてツールが実際に動く（Access control with IAM、MCP roles and permissions）。
旧来の「組織ポリシーでMCPを止める」制御は廃止された。 カスタム制約 gcp.managed.allowedMCPServices による組織ポリシー制御は2026年3月17日付で非推奨・無効化され、以降はIAM（Denyポリシー、条件付きアクセス）で制御する設計に変わった（同release notes）。少し前の情報でMCP対策を立てると、この一点でつまずく。

押さえるべき1点：MCPサーバーの有無は「導入したか」ではなく「対応サービスを有効化しているか」で決まる。だからガバナンスの起点は"導入計画"ではなく"IAMの棚卸し"だ。有効化＝経路が存在する、権限設計＝誰がどこまで通れるか、この2つを分けて考える。

なお時系列を明確にしておく。この自動有効化は2026年7月に新しく始まった話ではなく、2026年3月17日付ですでに施行済みである。本記事は速報ではなく、施行から時間が経っても社内周知が追いつかず、権限設計の相談が現場で増えている実感を踏まえた「状態整理」として配信する。GXOが商談で受ける相談の中身に基づく体感であり、件数などの数値は開示していない。

AI ASSESSMENT

PoC の前に「そもそも使えるか」を30分で見極めませんか？

対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。

30分壁打ちを予約

30秒サマリー：意思決定者が最低限おさえる表

横にスクロールして確認できます

論点	結論（一次ソース準拠）
いつから自動で使える?	2026年3月17日以降、対応サービスを有効化すると別途MCP有効化なしにリモートMCPが使える
何が経路を持つ?	BigQuery・GKE・Cloud SQL・Cloud Run・Cloud Storage・Cloud Monitoring・Agent Platform 等の対応サービス（最新の対応一覧を要確認）
誰が接続してくる?	Gemini CLI・Claude・ChatGPT・自社開発エージェントなど、確立されたID（ADC／サービスアカウント／OAuth）を持つ主体
MCPを呼べる条件（ゲート1）	`roles/mcp.toolUser`（権限 `mcp.tools.call`）を対象プロジェクトで保持
データを触れる条件（ゲート2）	各サービスのロール（例：Agent Platform＝`roles/aiplatform.user`、BigQueryならBigQuery側ロール）を別途保持
止める・絞る手段	IAM Denyポリシー（`mcp.googleapis.com/tools.call` を拒否）、IAM条件で読み取り専用に制限、本番リソースへの読み書き拒否
使えなくなった手段	組織ポリシー `gcp.managed.allowedMCPServices` は2026年3月17日に廃止

出典：MCP release notes／Access control with IAM／MCP roles and permissions。実装時は必ず原本と自社環境を突き合わせること。

何が変わったのか：Google CloudのMCP標準化と「既定で有効」

MCP（Model Context Protocol）は、AIエージェントが外部ツールやデータへアクセスするための共通プロトコルだ。従来は「このツールにAPIキーを渡す／渡さない」という個別配線だったところを、標準化された経路で束ねる。Google CloudはこのMCPサーバーを自社サービス群に横断搭載してきた。2026年4月29日付のGoogle Cloud公式ブログでは「Google管理のMCPサーバーが誰でも使える状態になった」と共有され（Google-managed MCP servers are available for everyone）、Agent Platformを含む多数のサービスにリモートMCPが用意されている（Announcing official MCP support for Google services）。

重要なのは提供方式の変化だ。かつては使いたいサービスごとにMCPを有効化する操作が要ったが、2026年3月17日以降は対応サービスを有効化した時点でリモートMCPエンドポイントが既定で立つ。「MCPを使うと決めてから設計する」という悠長な順序が成り立たなくなった。経営目線で言い換えると、こういうことだ——AI活用の稟議を上げる前に、すでに社内のクラウド環境にはAIエージェントが入ってこられる玄関が付いている。玄関に鍵をかけるのは、来客を招く決断とは別の作業として、先に済ませておかなければならない。

そしてもう一つ、静かだが実務を左右する変更がある。MCP利用を組織ポリシーで面的に制御していた仕組み（カスタム制約 gcp.managed.allowedMCPServices）が2026年3月17日に廃止された（同release notes）。以前の手順書やベンダー提案が「組織ポリシーでMCPを禁止しておけばよい」と書いていたら、それは既に効かない。現在の正しい制御面はIAM——具体的にはDenyポリシーと条件付きアクセスである。この移行を知らないまま「うちは組織ポリシーで止めてあるから安心」と思い込むのが、2026年後半に最も起きやすい判断ミスだ。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

権限の正確な地図：二重ゲート（デュアルレイヤー）モデル

この記事の核心はここだ。Google管理のMCPは、アクセスを2つのゲートで制御する。ここを誤解すると、「MCPを触れないようにしたつもり」で穴が残る。

ゲート1：MCPを呼び出せるか。 MCPツールを呼ぶには roles/mcp.toolUser（MCP Tool User）がプロジェクトレベルで必要になる。このロールが持つ中核権限が mcp.tools.call で、ほかに resourcemanager.projects.get / .list を含む（MCP roles and permissions）。より広い roles/mcp.admin（MCP Admin）も同じ mcp.tools.call を含む。つまり「MCP専用ロールなど存在せず、既存ロールにDenyをかけるだけ」という理解は正しくない。MCP呼び出しの可否を司る専用ロールが実在する。

ゲート2：データを実際に操作できるか。 ゲート1を通っても、対象サービスのデータに触れるには、そのサービス側のIAMロールが別途要る。公式の説明では「ツール呼び出し元は roles/mcp.toolUser に加えて、アクセスする各Google／Google Cloudプロダクトの必要ロールを付与されていなければならない」とされる（Access control with IAM）。Agent Platformの例では、MCPツールを呼ぶ roles/mcp.toolUser と、Agent Platformリソースを管理する roles/aiplatform.user の両方が要る。BigQueryならBigQuery側の閲覧／実行ロール、という具合にサービスごとに積み上がる。

この二重構造がなぜ経営判断に効くのか。「MCPを許すか」と「データを見せるか」を別々に決められるからだ。裏を返せば、片方だけ絞って安心してはいけない。よくある誤設計は次の2パターンだ。

ゲート2（サービス側ロール）は最小化したのに、ゲート1の roles/mcp.toolUser を広く配ってしまい、「MCP経由でどのツールでも呼べる主体」を量産する。
ゲート1は絞ったが、既存の強いサービスロール（編集者・オーナー相当）を持つ個人アカウントがそのままMCP経由で通れてしまう。

さらに、IAMの条件（IAM Conditions）を使えば、リクエスト時刻・リソース名・リソースタイプ・タグなどの属性に基づいて、読み取り専用に限定する／本番リソースへの読み書きを拒否するといった制御もできる（Access control with IAM、MCP AI security & safety）。「検証はできるが本番テーブルは書き換えられない」を権限側で担保する、という設計はここで実現する。

認証の入口も整理しておく

MCPサーバーに接続する主体は、確立されたID（アイデンティティ）を持つ必要がある。認証はApplication Default Credentials（ユーザーIDやワークロードのID）、サービスアカウント、OAuth 2.0クライアントのいずれかでIAMプリンシパルとして行うのが基本で、GoogleのリモートMCPサーバーはMCPの認可仕様に準拠する（Access control with IAM）。ここで経営者が握っておくべき問いはシンプルだ——「誰の身分で、どのプロジェクトに、どこまで通れる鍵を、いま何本発行しているか」。この問いに即答できないなら、それが最初の穴である。

なぜ自社事なのか：「権限を渡す・渡さない」の判断が先送りできない

MCPが変えたのは、権限判断の"頻度・粒度・主語"だ。ここが中小企業に効く。

判断の主語が分散する。 従来は情シスがAPIキー発行を一元管理できた。MCP経由の接続は、開発者個人や部門のPoC単位で「Claudeにこのプロジェクトの読み取り権限を渡す」という判断がバラバラに発生しやすい。IT判断力の担い手が薄い（ひとり情シス・兼任情シス）会社ほど、判断の主語が曖昧になる。
判断のタイミングがずれる。 サービス有効化＝経路が立つ、なので「使うと決めてから設計」が間に合わない。玄関は先に付いている。
判断の単位が粗くなる。 「とりあえず動かすため」に広めのロールを付け、後で絞る運用は、絞り込みが先送りされたまま本番化する構造的リスクを抱える。これはAPIキー時代からある病だが、MCPは有効化するだけで経路が増える分、母数を押し上げる。

ここは「見えない攻撃面が広がる」という一般論（他社の解説記事も指摘するとおり）で終わらせず、Google Cloud特有の"既定で有効＋二重ゲート＋組織ポリシー廃止"という具体条件に落として自社に当てはめることが肝心だ。一般的なMCPセキュリティ解説は数多いが、この3条件を同時に押さえた実務手順に落ちているものは少ない。

なお、立ててしまったMCPサーバーが外部に露出する事故——設定ミスでインターネットに口が開く問題——は、テーマが手前で異なる。そちらはNSAの指針を踏まえて露出したMCPサーバーの事故と設計指針で扱っている。本記事は「ベンダーが公式に経路を標準搭載したときに、企業側がどう能動的に権限を設計するか」。事故対応（受け身）と権限設計（攻めの設計）は別物として両方おさえたい。

中小企業でこう転ぶ：3つの失敗パターン

判断フレームは、失敗の形から逆算すると腹落ちしやすい。GXOが権限設計の相談で繰り返し見るのは次の型だ（特定顧客の事例ではなく、一般的な失敗パターンの整理である）。

失敗1：PoC担当者の個人アカウントに強権限が残る。 検証のためにと開発者個人のGoogleアカウントへ広いロールを付け、そのIDでAIエージェントをAgent Platformやデータベースに接続。動いたのでそのまま本番へ。担当者の異動・退職後もロールが残る。MCPは有効化だけで経路が立つため、この"付けっぱなし"の危険が従来より広い面で顕在化する。

失敗2：ゲートの片側だけ見て安心する。 「サービス側ロールは絞ったからOK」と判断し、roles/mcp.toolUser を配りすぎる。あるいは逆に、MCPロールだけ制御して既存の編集者権限を放置する。二重ゲートの両側を同時に設計しないと穴は消えない。

失敗3：古い前提でガバナンスを組む。 「組織ポリシーでMCPを禁止済み」を安全の根拠にしてしまう。前述のとおり gcp.managed.allowedMCPServices は2026年3月17日に廃止された。制御面はIAM（Deny＋条件）へ移っている。半年前の手順書が地雷になる典型だ。

失敗4（番外）：委託先の設計を確認しないまま発注する。 AIエージェント開発を外注し、MCP接続先・IAMロール・OAuthスコープの設計が"ブラックボックスのまま"納品される。発注側が仕様を読めないと、過剰権限を検収時に見抜けない。ここは発注準備で潰せる。

MCP権限設計チェックリスト（発注前・運用前）

Agent Platformに限らず、Google CloudのMCPを使う・使う可能性がある企業は、次を上から順に確認する。印刷して情シスと開発委託先の双方でチェックする使い方を想定している。

棚卸し：自社が有効化しているGoogle Cloudサービスのうち、MCP対応済みはどれか（公式の対応一覧で最新確認）を一覧化したか。
ゲート1の管理：roles/mcp.toolUser を誰に付与しているかを把握し、業務上不要な主体から外したか。全社員・広域グループに付いていないか。
ゲート2の管理：MCP経由で触れうる各サービス側ロール（編集者・オーナー相当）を、個人アカウントに恒久付与していないか。サービスアカウント単位・期限付き発行へ切り替えられるか。
読み取り専用の担保：機微データを扱うプロジェクトで、IAM条件を使って読み取り専用に制限、本番リソースへの読み書きをDenyしているか。
Denyポリシー：止めたい範囲について、IAM Denyポリシーで mcp.googleapis.com/tools.call を組織／フォルダ／プロジェクト単位で明示拒否しているか（組織ポリシー制約 gcp.managed.allowedMCPServices は廃止済みで代替にならない）。
接続元の把握：どのAIアプリ（Gemini CLI／Claude／ChatGPT／社内独自エージェント）が、どのプロジェクトのMCPに接続しているかを把握しているか。
PoCの後始末：検証で付けた強権限が検証後も残っていないか。担当者異動時の棚卸しフローがあるか。
監査ログ：MCP経由の操作が監査ログに残り、既存の監視基盤に統合されているか。誰が・いつ・どのツールを呼んだかを追えるか。
委託先確認：外注時、MCP接続先・IAMロール・OAuthスコープの設計書を受け取り、最小権限になっているかを検収項目に入れたか。

最初の棚卸しを「30分」で始める進め方

大掛かりなツール導入を待つ必要はない。権限の穴は、まず手を動かして可視化するだけで大半が見えてくる。IT判断力の担い手が薄い会社でも回せる、最小の進め方を置いておく。

まずプロジェクト単位で「有効化しているサービス」を書き出す。請求（課金）画面や利用中サービスの一覧を見れば、どのプロダクトが動いているかは分かる。そのうちMCP対応済みのものに印を付ける（対応一覧と突き合わせる）。ここで「使っている覚えはないが有効化されているサービス」が出てきたら、それは真っ先に見直す候補だ。有効化されたまま放置されたサービスほど、経路だけが立って誰も見ていない状態になりやすい。

次にIAMの付与状況を"人"と"サービスアカウント"の両面で棚卸す。オーナー・編集者相当の強いロールを個人アカウントが恒久で持っていないか、退職・異動した人のロールが残っていないか、PoC用に作ったサービスアカウントに鍵（キー）が何本ぶら下がっているか。この3点を洗うだけで、MCP経由で本番に触れうる主体の輪郭が見える。二重ゲートで言えば、ここはゲート2（サービス側ロール）の棚卸しにあたる。

最後に**「止めるべき範囲」を決めてから制御を当てる**。全社一律で禁止するのか、機微データを扱うプロジェクトだけ本番書き込みを拒否するのか。方針を先に言語化してからIAM Denyポリシーや読み取り専用の条件を設計する。制御から入ると「とりあえず全部禁止して業務が止まる」か「怖くて何も触れない」の両極に振れやすい。方針→制御の順を守ることが、現場を止めずに穴を塞ぐコツだ。

この3ステップは、専門ベンダーに丸投げする前でも社内で着手できる。むしろ着手して「どこが分からないか」を特定してから相談したほうが、支援範囲も見積もりも締まる。

監査ログと「誰が何を呼んだか」の可視化

権限を絞ると同時に、呼び出しの記録が残る状態を作っておく。MCP経由の操作が「誰が・いつ・どのプロジェクトの・どのツールを呼んだか」として監査ログに残り、既存の監視基盤（SIEMやログ集約）に流れているか。ここが抜けていると、仮に過剰権限が残っていても、実際に何が触られたかを後追いできない。権限設計（予防）とログ（検知）は車の両輪で、片方だけでは事故の全体像がつかめない。

とくに委託開発では、納品時に「ログの出力先・保持期間・アラート条件」まで仕様化されているかを確認したい。動くものは納品されたがログ設計は空白、というのはよくある落とし穴だ。運用に入ってから「誰も見ていないログが出続けるだけ」にならないよう、監視の当番と閾値までセットで決めておく。

見積もり・ベンダー選定でここを聞く：発注側の質問リスト

「安全に権限設計してください」だけでは見積もりも品質も比較できない。発注前に次を投げると、ベンダーの実力と提案の粒度が一気に見える。曖昧に流す相手は避けたほうがよい。

「MCPの二重ゲート（roles/mcp.toolUser とサービス側ロール）を、それぞれどの単位で設計しますか」——両方に触れられない相手は要注意。
「本番リソースへの読み書きを、権限側でどう止めますか」——IAM条件・Denyポリシーの具体名が出るか。
「PoCで付けた権限の失効・棚卸しは、どの運用フローで担保しますか」——付けっぱなし対策の有無。
「MCP経由の操作ログは、どこに・どの粒度で残り、既存監視にどう統合しますか」——監査の実装。
「2026年3月の組織ポリシー廃止を踏まえ、制御面はどう設計しますか」——最新仕様の追随度を測るリトマス紙。

見積書を受け取ったら、金額の大小より**「権限設計・棚卸し・ログ統合が工数として明示的に積まれているか」**を見る。ここが「その他一式」に丸められている見積もりは、後から追加費用か、そもそも設計されないかのどちらかになりやすい。自社だけで見積もりの妥当性を判断しづらい場合は、AI導入前の第三者アセスメントで要件と権限方針を整理するところから始めると、発注の解像度が上がる。要件定義から権限・ガバナンスを組み込みたいならDX・システム開発の相談窓口で要件定義を詰めるのが早い。

他クラウドや一般原則との関係

主要クラウド各社がMCP対応を進める流れは共通で、最小権限・分離・監査ログという原則はベンダーを問わず当てはまる。ただし本記事はGoogle Cloudの公式ドキュメントに基づく内容であり、AWS・Azure等の実装詳細（ロール名・制御面）は各社の公式情報を別途確認してほしい。原則は共通でも、"どのロールで・どこを絞るか"の実装はプラットフォームごとに違う。Google Cloudの場合、その具体名が roles/mcp.toolUser・mcp.tools.call・IAM Denyであり、本記事はそこを一次ソースで固定した。

よくある質問（FAQ）

Q. AIエージェントをまだ導入していない企業も対象か？ A. 対象になりうる。MCPは「AIエージェントを導入したから使う」ものではなく、対応サービス（BigQuery・GKE等）を有効化した時点でエンドポイントが立つ。自社に活用計画がなくても、開発者や委託先が個人判断でGemini CLI等から接続できる状態になっている可能性がある。

Q. MCP専用のロールは本当にあるのか？ A. ある。roles/mcp.toolUser（MCP Tool User）がMCP呼び出しの可否を司る専用ロールで、中核権限は mcp.tools.call。加えて対象サービス側のロールが要る「二重ゲート」構造だ（MCP roles and permissions）。

Q. 組織ポリシーでMCPを全社禁止すれば安全では？ A. 以前はカスタム制約 gcp.managed.allowedMCPServices で制御できたが、2026年3月17日に廃止された。現在の制御面はIAM（Denyポリシー、IAM条件による読み取り専用化・本番書き込み拒否）である（release notes）。

Q. IAMをきつく絞るとAIエージェントの利便性が落ちないか？ A. 落ちる場合はある。ただし多くの失敗は「絞りすぎ」ではなく「広めのロールを付けたまま見直さない」ことで起きる。用途ごとに最小権限を洗い出し、検証段階は広め・本番移行時に絞る2段階運用が現実的だ。二重ゲートのおかげで「MCPは呼べるが本番データは読み取りのみ」といった中間設計も取れる。

Q. Google Cloudの契約や料金の相談もGXOにできるのか？ A. GXOはGoogle Cloudの公式サポート窓口や契約代理ではない。支援できるのは、MCP接続先・IAMロール・OAuthスコープ・監査ログ・Denyポリシーの設計を棚卸しし、自社のAI利用に合わせて最小権限化することだ。仕様・料金・提供範囲は公式ドキュメントで確認してほしい。

この記事を読むべき人

Google Cloud上でBigQuery・GKE・Agent Platform等を運用し、AIエージェント活用を検討中／一部導入済みの情シス・DX推進担当。
開発チームがPoCでAIエージェント連携を進めており、権限管理が個人依存になっていないか不安がある経営者・情報システム部門長。
ベンダーにAIエージェント開発を委託しており、MCP経由のアクセス権限がどう設計されているか把握したい発注側担当者。
「まだAIは入れていない」が、GKEやBigQueryは日常的に使っている——つまり玄関だけ先に付いている企業。

いつGXOに相談すべきか

Google CloudでAIエージェント活用を進めたいが、IAM・OAuthスコープを含む権限設計を自社だけで詰め切れる自信がない。
開発チームがPoCで使うMCP接続が、本番相当のデータやシステムに触れる権限を持ったまま放置されていないか確認したい。
AIエージェント導入を検討中で、要件定義の段階から権限・ガバナンス設計を組み込みたい。

相談前には、①有効化しているGoogle Cloudサービス一覧、②AI活用の現状（PoCか本番か・誰が担当か）、③現在付与しているIAMロールの棚卸し状況、をわかる範囲でまとめておくと早い。棚卸し未了でも相談は可能で、その場合は棚卸し自体を最初の支援範囲として設計する。

GXOはAIエージェント導入前の第三者アセスメントで権限方針を整理するところから、MCP・IAMを含む運用ガバナンス設計（AIガバナンス・LLMOps）、既存IAM構成のレビューを行うセキュリティコンサルティングまで対応する。社内データとAIエージェントを安全につなぐ設計は社内ナレッジのエンタープライズRAG構築も参考になる。要件定義から作り込む場合はシステム開発の相談窓口へ。→ AIエージェントの権限設計について相談する

裏取りと更新方針

本記事は速報ではなく状態整理である（自動有効化の施行日は2026年3月17日）。二重ゲート、roles/mcp.toolUser／mcp.tools.call、組織ポリシー gcp.managed.allowedMCPServices の廃止、IAM Denyポリシーによる制御——これらはGoogle Cloud公式ドキュメントを直接確認して裏取りした。ただしGoogle CloudのMCP対応は継続的に機能追加・仕様変更が行われる領域であり、対応サービスの範囲やロール構成は変わりうる。実務で使う際は記事内の記述を固定値とせず、必ず公式ドキュメント原本と自社環境を突き合わせること。