売上のデータはSnowflakeにある。社員がGemini Enterpriseで「先月、東日本でいちばん売れた商品は？」と聞けば答えが返るようにしたい。ただ、エージェントに強い権限のサービスアカウントを1つ持たせると、本来は見られないはずの部署のデータまで、誰でも聞き出せてしまうおそれがあります。Google Cloudの公式ブログも、汎用のサービスアカウントで広い権限をモデルに与えることを、企業のAIの大きな危険として挙げています。
Google Cloudは2026年10月27日、Gemini EnterpriseとSnowflakeを、Agent Development Kit（ADK）とModel Context Protocol（MCP）でつなぐ手順を公開しました。問い合わせは、聞いた本人のOAuthのセッションとSnowflakeのロールの権限で実行されます。この記事では、ブログの構成と手順を整理し、設定でつまずきやすい点を、ブログの注意書きとSnowflake・Google Cloudのドキュメントから拾います。ブログの例にはSnowflakeのドキュメントと合わない箇所もあるため、その点も手順の中で示します。
どこでSQLが作られ、誰の権限で実行されるか
ブログの構成では、Gemini Enterprise側のエージェントは、SQLを自分では書きません。
- 利用者がGemini Enterpriseで質問する
- ADKで作ったエージェントが、質問の文をSnowflakeのMCPサーバーへ渡す
- MCPサーバーが、Snowflakeの「Cortex Agent」を呼ぶ（
CORTEX_AGENT_RUNという種類のツール）。Cortex Agentは、Cortex Analystの「セマンティックビュー」を使って、質問をSQLに変える - SQLはSnowflakeの中で、利用者のOAuthのセッションとロールの権限で実行され、結果がエージェントへ返る
ブログは、この形の利点として、社内の定義に沿った決まったSQLへの変換になること、実行がSnowflakeの管理の境界の中に留まること、存在しない列を作り出したり検証されていないSQLを実行したりする危険が減ることを挙げています。そのうえで、SYSTEM_EXECUTE_SQL のような生のSQLを実行するツールを外部のクライアントに公開しないよう注意しています。Snowflakeのドキュメントも、Cortex Agentは呼び出した人のセッションのロールで動くと説明し、業務の質問に使うMCPサーバーではCortex Agentだけをクライアントに見せることを勧めています。
なお、ブログは、この構成を「高度な・独自のオーケストレーション」の型と位置づけています。複数のエージェントを組み合わせる、Snowflakeの結果をほかの社内ツールと組み合わせる、といった開発向けです。Gemini EnterpriseをSnowflakeへ直接つなぐ基本の用途には、Snowflakeの案内する共同のソリューションを使うよう書いています。このガイドはSnowflakeとGoogleの担当者が書いたもので、ADKのエージェントは作らず、Gemini Enterpriseのデータストアに直接MCPサーバーを追加します。
手順の流れ
ブログの手順は次のとおりです。
- Snowflakeでセキュリティ統合を作る: 秘密を守れる種類のOAuthのクライアントを作る。リダイレクト先は
https://vertexaisearch.cloud.google.com/oauth-redirect。ブログの例では、リフレッシュトークンの有効期間を7776000秒（90日）にしている。Snowflakeのリファレンスでは、90日は上限で既定値でもあり、最小は1時間。SnowflakeはMCP向けに、ALLOWED_ROLES_LISTで使えるロールをMCP用のものに絞るよう勧めている - エージェント用のロールを作る: データベース、スキーマ、ウェアハウスの利用、セマンティックビューの参照、元の表の参照を、専用のロールに与える。ブログの例はスキーマ内のすべての表に
SELECTを与えているが、Snowflakeは、MCPのクライアントのためだけに広い権限を与えないよう書いているので、使う表に絞る。Cortex Agentの呼び出しにはSNOWFLAKE.CORTEX_USERかSNOWFLAKE.CORTEX_AGENT_USERのデータベースロールも要る（CORTEX_USERは既定でPUBLICに付いている） - Cortex AgentとMCPサーバーを作る: セマンティックビューを使うCortex Agentを作り、それを
CORTEX_AGENT_RUNのツールとして公開するMCPサーバーを作る。ブログのSQLの例はセマンティックビューをPROFILEに書いているが、SnowflakeのリファレンスではPROFILEは表示名などの項目で、ツールとセマンティックビュー、ウェアハウスはFROM SPECIFICATIONの仕様に書く。ツールのないエージェントは、データを問い合わせられない - MCPサーバーのURLを調べる: ロールにエージェントとMCPサーバーの利用を許可し、URLを組み立てる。ブログは
DESCRIBE MCP SERVERの出力でURLを確かめるとしているが、Snowflakeのリファレンスの出力の項目にURLはない。https://<アカウントのURL>/api/v2/databases/<データベース>/schemas/<スキーマ>/mcp-servers/<サーバー名>の形式に当てはめる。ホスト名にアンダースコアがあると接続の問題が起きるため、ハイフンにする - ADKでエージェントを書く: Gemini Enterpriseが渡すOAuthのトークンを、
AUTH_IDという識別子で取り出し、MCPへの要求のヘッダーに付ける。ブログの例のモデルはGemini 2.5 Flashだが、Googleのモデルの一覧では提供終了日が2026年10月20日で、後継にgemini-3.8-flashかgemini-3.5-flash-liteが挙がっている。モデルは一覧を見て選び直す - Agent Runtimeへデプロイする:
agents-cli deploy --deployment-target agent_runtime - Gemini Enterpriseに登録する: コンソールでアプリを選び、Agents → Add agent → Custom agent via Agent Runtimeの順に進み（ブログの表記はCustom agent via Agent Platform）、Snowflakeから取り出したクライアントIDと秘密、トークンと認可のURIを入れる
つまずきやすい4つの点
ブログには、実行時の失敗につながる注意書きが、手順の中に散らばっています。登録の前に、次の4点をまとめて確かめます。
| 点 | ブログの記載 | 起きること |
|---|---|---|
| 元の表の権限 | セマンティックビューだけでなく、その元の表にもSELECTの権限が要る | ビューだけに権限を与えると、実行時にエラーになる |
| 既定のロールとウェアハウス | OAuthのトークンは、認可した瞬間の DEFAULT_ROLE と DEFAULT_WAREHOUSE に結び付く | 既定値を設定する前に認可すると、違うロールに固定され、問い合わせが失敗する |
| 認可のURIの末尾 | 認可のURIの末尾に response_type=code を付ける | Google Cloudが認可コードの流れを始めるために必要 |
| 名前の一致 | ADKのコードの AUTH_ID と、登録画面の認可の名前は完全に一致させる | 一致しないと、トークンがコードに渡らない。Snowflake側のセキュリティ統合の名前は一致させなくてよい |
元の表の権限は、Snowflakeの資料の読み方に注意が要ります。セマンティックビューのリファレンスは、ビューを問い合わせるだけなら元の表の SELECT は要らないと書いています。ただし、Cortex Agentはセマンティックビューの定義を読み、元の表に対するSQLを作ります。MCPのドキュメントの権限の例と、SnowflakeとGoogleのガイドも元の表に SELECT を与えているので、この構成ではブログの注意に従います。また、権限が足りないツールがあっても、既定では実行全体は止まらず、使えるツールだけで続きます（tool_not_accessible の既定値 accept）。導入の前に、実際の利用者のロールで答えを確かめます。
元の表に直接の権限を与えられない場合、ブログは、元の表の上にSnowflakeのSecure Viewを置き、その上にセマンティックビューを作る方法を示しています。Snowflakeのビューは所有者の権限で実行されるため、利用者のロールにはSecure Viewとセマンティックビューの権限だけで足りる、という説明です。
既定のロールとウェアハウスは、利用者がGemini Enterpriseで1回だけ認可する前に、エージェント用のものへ切り替えておきます。ブログは、認可の後なら元の既定値に戻してよいとしていますが、この点はSnowflakeのドキュメントでは確かめられませんでした。
Gemini Enterpriseのドキュメントによると、認可のIDは認可の名前から作られ、後から変えられません。AUTH_ID はこのIDと一致させるので、登録の前に名前を決めておきます。
Snowflakeの資料と照らして確かめる点
既定のロールとウェアハウスの扱い: Snowflakeのドキュメントが説明しているのは次の3点です。ウェアハウスが認可の時点に結び付くという説明は見当たりません。
- ロールの指定（
session:role:<ロール名>）を省くと、利用者の既定のロールが使われる。MCP向けの推奨の設定も、MCP用のロールとウェアハウスを利用者の既定値にしておく形で、元に戻す手順はない - 既定のウェアハウスが空だと、セッションの開始に失敗する
- Cortex Agentのツールが使うウェアハウスは、エージェントの仕様に書いたもの。指定がなければ、利用者の既定のウェアハウスが使われる
スコープ（scope）とロール: ブログの認可のURIの例は scope=session:role-any です。Snowflakeのドキュメントでは、このスコープはセキュリティ統合の OAUTH_ANY_ROLE_MODE が ENABLE か ENABLE_FOR_PRIVILEGE のときだけ有効で、それ以外では認可の要求が拒否されます。既定値は DISABLE で、ブログのセキュリティ統合の例には設定がありません。このパラメーターはプレビューの機能で、有効にすると、セッションは利用者に付与されたロールへ切り替えられるようになります。
ロールを1つに固定するなら、session:role:<ロール名> のスコープを使い、そのロールを ALLOWED_ROLES_LIST に入れる方法があります。SnowflakeとGoogleのガイドはこの形で、利用者には既定のウェアハウスだけを設定し、既定のロールは変えていません。ただし、このガイドはADKを使わない構成です。
スコープとリフレッシュトークン: Snowflakeのドキュメントでは、スコープに refresh_token を含めて利用者が同意しないと、リフレッシュトークンは発行されません。ブログの例のURIには含まれていないため、90日の設定を生かすなら足します。発行されなければ、既定で10分のアクセストークンが切れたあとは、認可のやり直しになるはずです（編集部では未検証）。
導入の前に決めておくこと
ここからは編集部の提案です。
- 誰に、どの範囲のデータを聞かせるか: 利用者の権限で実行される構成では、答えの範囲はSnowflakeのロールの設計で決まります。エージェント用のロールを部署ごとに分けるか、既存のロールを使うかを、先に決めます。利用者ごとに範囲を変えたいのにクライアントがロールのスコープに対応しない場合は、専用のロールを持つMCPサーバーを分けるよう、Snowflakeは案内しています
- セマンティックビューの定義を誰が持つか: 質問がどのSQLになるかは、セマンティックビューの定義に左右されます。「売上」「東日本」のような業務の言葉の定義を、データの担当者と確かめておきます
- 90日後の再認可: ブログの例のリフレッシュトークンの有効期間は90日です。これはSnowflakeの上限でもあり、延ばすにはSnowflakeのサポートへの依頼が要ります。リフレッシュトークンが発行される設定かを確かめたうえで、期限が切れたときに、利用者にどう再認可してもらうかを決めておきます
- 基本の用途で足りないか: ブログ自身が、基本の用途には共同のソリューションを案内しています。独自のエージェントを作り、デプロイし、保守する費用に見合う用途かを確かめます
ADKでエージェントを作るときの言語とツールの定義はGoogleのADKは5言語に 既存システムの言語で作るで、Gemini Enterpriseから社内のシステムをMCPでつなぐ認証はGemini EnterpriseのMCP Apps 社内画面をつなぐ前にで扱いました。
確認した範囲
2026年11月6日に、Google Cloud公式ブログの「Securely connecting Gemini Enterprise to Snowflake data」（2026年10月27日）と、Snowflakeのドキュメント（MCPサーバー、Cortex Agents、OAuthのセキュリティ統合、セマンティックビュー、
CREATE AGENT、DESCRIBE MCP SERVER）、Gemini EnterpriseのADKエージェントの登録のドキュメント、Googleのモデルの一覧を開いて確認しました（資料調査）。ブログが案内する共同のガイドは、snowflake.comが開けなかったため、GitHubの公開リポジトリ（Snowflake-Labs/sfquickstarts）の原稿で読みました。Gemini Enterpriseが渡すトークンをADKの
tool_context.stateから取り出す方法はブログの例の書き方で、Gemini Enterpriseのドキュメントでは確かめられていません。登録のドキュメントの説明はGoogle Cloudのリソースへの認可が対象です。認可の後に既定値を戻してよいかも、ブログだけの記載です。MCPサーバーとCortex Agentの料金や対応リージョンは確かめていません。手順を確かめたGemini EnterpriseのドキュメントはStandard、Plus、Pay-as-you-go、Frontlineのエディション向けで、Businessエディションは確かめていません。Gemini EnterpriseとSnowflakeをつないでの検証もしていません。導入の前に決めておくことは、編集部の提案です。
社内のデータ基盤にAIエージェントをつなぐ設計、権限とロールの整理は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Securely connecting Gemini Enterprise to Snowflake data（Google Cloud Blog、2026年10月27日）
- Snowflake-managed MCP server（Snowflakeのドキュメント）
- Cortex Agentsのアクセス制御と認証（Snowflakeのドキュメント）
- CREATE SECURITY INTEGRATION（Snowflake OAuth）
- Configure Snowflake OAuth for custom clients（Snowflakeのドキュメント）
- CREATE AGENT（Snowflakeのリファレンス）
- DESCRIBE MCP SERVER（Snowflakeのリファレンス）
- Agentic AI for Your Lakehouse: Snowflake Cortex and Gemini Enterprise on Iceberg（SnowflakeとGoogleのガイドの原稿）
- Register and manage ADK agents hosted on Agent Runtime（Gemini Enterpriseのドキュメント）
- Model versions and lifecycle（Googleのモデルの一覧）
