AI・生成AI

Google CloudのMCPサーバーが『有効化すれば動く』時代に｜AIエージェントへの権限設計を後回しにできない理由

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

QUICK CHECK

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

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

GXO COLUMN

AI・生成AI

結論：「有効化した覚えがない」MCPサーバーが、もう社内にある可能性

Google Cloudは、BigQuery・Cloud SQL・GKE・Cloud Monitoring・そしてAIエージェント基盤である Agent Platform（Gemini Enterprise Agent Platform）など、主要サービスにリモートMCP（Model Context Protocol）サーバーを標準搭載する方針を進めている。しかも2026年3月17日以降、対応サービスを有効化した時点でMCPサーバーは自動的に利用可能になり、別途MCPを有効化する操作は不要になった（Google Cloud公式ドキュメント）。

つまり、「うちはまだAIエージェントを本格導入していないから関係ない」という前提が崩れている。GKEやBigQueryを普段どおり使っているだけの企業でも、Gemini CLI・ChatGPT・Claudeといった外部のAIアプリケーションが、正しい認証情報さえ持てばそのクラウド資源に接続できる経路が、気づかないうちに「そこにある」状態になっているということだ。

押さえるべき1点：MCPサーバーの有無は「導入したかどうか」ではなく「対応サービスを有効化しているかどうか」で決まる。有効化の判断より先に、権限設計の判断を済ませておく必要がある。

なお先に時系列を明確にしておく。本記事が起点とする自動有効化は2026年7月に新しく始まった話ではなく、Google Cloudが2026年3月17日付ですでに施行済みのものだ。7月2日は新規発表日ではなく、GXOが商談の現場で権限設計の相談が増えている実感を踏まえ、施行から一定期間が経ち社内周知が追いついていないタイミングであらためて状態整理を配信するものである。

AI ASSESSMENT

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

情シス部門の稟議書作成をサポートする無料の30分壁打ち。費用対効果試算シート・失敗要因チェックリストをその場で共有します。

30分壁打ちを予約

何が起きているのか：Google CloudのMCP標準化

Google Cloudは自社サービス群を横断してMCP対応を進めており、公式発表(2025年12月時点)では当初BigQuery・GKE・Compute Engine・Maps Grounding Liteが提供済みで、Cloud SQL・Cloud Run・Cloud Monitoring・Dataplex Universal Catalog・SecOps（Google Security Operations）は順次展開の対象として挙げられていた。Google Cloud Next '26（2026年4月22日〜24日開催）では「50以上のGoogle管理MCPサーバーが一般提供(GA)またはプレビュー段階になった」と発表され、4月29日付のGoogle Cloud公式ブログでも改めて共有されている（Google Cloud Blog「Google-managed MCP servers are available for everyone」）。生成AIエージェントを構築・管理するAgent Platform自体にもリモートMCPサーバーが用意されている（Google Cloud Blog「Announcing official MCP support for Google services」、Agent Platform remote MCPサーバー利用ガイド）。自社が使うサービス個別のMCP対応状況は、導入検討時に公式の対応サービス一覧で必ず最新状態を確認してほしい。

Agent Platformのリモートmcpサーバーは、Gemini CLI・ChatGPT・Claude・独自開発のAIアプリケーションなど、外部のAIエージェントから接続してAgent Platform上のリソース(構築済みエージェント、モデル、ノートブックなど)を操作できるようにするものだ。ここで重要なのは認証の設計思想である。

項目	内容
認証方式	Application Default Credentials(ユーザーアイデンティティ)、サービスアカウント、OAuth 2.0クライアントのいずれかでIAMプリンシパルとして認証するのが基本。APIキーは「サービス側がプリンシパルを必要としない場合」に限り例外的に利用可能とされている
アクセス制御の実体	「MCP専用ロール」を新たに割り当てる方式ではなく、既存のIAMプリンシパル(ユーザー・サービスアカウント)の権限に対して、IAM Denyポリシーで`mcp.googleapis.com/tools.call`という権限文字列を対象にMCPツール呼び出しを遮断する設計になっている
サービスアカウント運用の前提ロール	サービスアカウントでMCPに接続する場合、`roles/iam.serviceAccountTokenCreator`や`roles/iam.serviceAccountUser`など、トークン発行・サービスアカウント管理に関わる既存のIAM基本ロールの理解が前提になる(MCP専用に新設されたロールではない)
自動有効化	2026年3月17日以降、対応サービスの有効化と同時にMCPエンドポイントが利用可能に
ブロック手段	IAM Denyポリシーで、`mcp.googleapis.com/tools.call`権限を組織単位・プロジェクト単位で明示的に拒否することでMCPツール呼び出しを遮断可能

出典：MCPサーバー概要、同リリースノート、Control MCP use with IAM、Authenticate to MCP serversを直接確認。「MCP Tool User」等の専用ロール名はAgent Platform個別ページを含め確認できなかったため、上記はGoogle Cloud MCPサーバー共通の公式ドキュメントに基づく内容として記載している(詳細は末尾の編集部注を参照)。

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

これまでのSaaS連携は、「このツールにAPIキーを発行する／しない」という単発の判断で済んだ。MCPが変えているのは、その判断の頻度と粒度だ。

判断の主体が増える。 従来は情シスがAPIキー発行を一元管理できたが、MCP経由の接続は開発者個人・部門のPoC単位で「Claudeにこのプロジェクトの読み取り権限を渡す」という判断が分散して発生しやすい
判断のタイミングがずれる。 サービスを有効化した時点でMCPエンドポイントが立つため、「MCPを使うと決めてから権限を設計する」という順序が成立しにくい。有効化＝経路が存在する、権限設計＝誰がどこまで通れるか、の2つが分離してしまう
判断の単位が粗くなりがちだ。 プロジェクト全体に及ぶ広めのIAMロールを「とりあえず動かすため」に付与し、後で絞り込む運用は、絞り込みが先送りされたまま本番化するケースが構造的に起きやすい

中小企業〜中堅企業でよくある失敗パターンは、PoCを担当した開発者個人のGoogleアカウントに強めのIAMロールを付け、検証用のAIエージェントからAgent Platformやデータベースへの接続を許可し続けてしまうことだ。担当者の異動・退職後もロールが残る、「動くから」という理由で本番データ基盤に同じ権限のAIエージェントを接続させてしまう——これ自体はAPIキー時代からある失敗パターンだが、MCPは有効化するだけで経路が生まれる分、この失敗の母数を増やす方向に働く。

なお、露出したMCPサーバーが外部から到達可能な状態で放置されるリスクについては、NSAの調査・指針を踏まえてMCPサーバー12,520台がネット露出、約4割は認証なし｜NSAが設計指針を公表で解説している。あの記事のテーマは「立てたMCPサーバーが誤って外部に開いてしまう事故」であり、本記事のテーマはその手前、Google Cloudのようなベンダーが公式にMCP経路を標準搭載してきたときに、企業側がどう権限を能動的に設計するかという論点である。事故対応と設計判断は別の話として両方押さえておきたい。

FREE DOWNLOAD

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

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

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

MCP権限設計チェックリスト

Agent Platformに限らず、Google CloudのMCPサーバーを使う・使う可能性がある企業は、次の項目を確認する。

棚卸し：自社が有効化しているGoogle Cloudサービスのうち、MCP対応済みのものはどれか（BigQuery、GKE、Cloud SQL、Cloud Monitoring、SecOps、Agent Platform等）を一覧化したか
ロールの粒度：MCP経由の操作に関わるIAMプリンシパル(個人アカウント・サービスアカウント)に、業務上不要な広めのロールを恒久付与していないか。サービスアカウント単位・期限付きでの発行に切り替えられるか
接続元の把握：どのAIアプリケーション（Gemini CLI、ChatGPT、Claude、社内独自エージェント等）がどのプロジェクトのMCPエンドポイントに接続しているかを把握しているか
Denyポリシーの活用：機微データを扱うプロジェクトについて、IAM Denyポリシーで特定のMCPツール呼び出しを明示的に遮断しているか
PoCの後始末：検証目的で付与した強い権限が、検証終了後も残っていないか。担当者異動時の棚卸しフローがあるか
ログの接続：MCP経由の操作が監査ログとして残り、既存の監視基盤に統合されているか

よくある質問（FAQ）

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

Q. IAMロールをきつく絞ると、AIエージェントの利便性が落ちないか？ A. 落ちる場合はある。ただし多くの失敗は「絞り込みすぎ」ではなく「広めのロールを付与したまま見直さない」ことで起きる。まずは用途ごとに必要な最小権限を洗い出し、検証段階では広め・本番移行時に絞り込む、という2段階の運用にするのが現実的だ。

Q. Google Cloud以外（AWS、Azure）でも同様の動きはあるか？ A. 主要クラウドベンダー各社がMCP対応を進めている流れ自体は共通しており、権限設計の考え方（最小権限・分離・監査ログ）はベンダーを問わず当てはまる。ただし本記事はGoogle Cloudの公式ドキュメントに基づく内容であり、他ベンダーの実装詳細については各社の公式情報を別途確認してほしい。

誰が読むべきか

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

GXOへ相談する前に整理しておくと早い情報

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

いつGXOに相談すべきか

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

GXOはAI導入アセスメントでAIエージェント導入前の要件定義・権限設計方針の整理を、AIガバナンス・LLMOps支援でMCP・IAMを含む運用ガバナンス設計を、セキュリティコンサルティングで既存のIAM権限構成のレビューを提供している。社内データベースとAIエージェントを安全に連携させたい場合はエンタープライズRAG構築も参考にしてほしい。→ AIエージェントの権限設計について相談する

MCPサーバー12,520台がネット露出、約4割は認証なし｜NSAが設計指針を公表

編集部注：公開後の更新方針

本記事は前述のとおり速報ではなく状態整理として位置づけている（起点となる自動有効化の施行日は2026年3月17日）。認証方式・アクセス制御(IAM Denyポリシーとmcp.googleapis.com/tools.call権限)の記述はGoogle Cloud公式ドキュメントを直接確認して裏取り済みだが、Agent Platform個別ページの本文詳細は全文確認できておらず、Agent Platform固有の追加ロールが存在する可能性は否定できない。Google CloudのMCP対応は継続的に機能追加・仕様変更が行われている領域でもあるため、読者が実務で使う場合は記事内の記述を固定値として扱わず、必ずGoogle Cloud公式ドキュメント原本と自社環境を突き合わせること。