Google CloudがGemini EnterpriseとSnowflakeを安全に接続する構成を紹介、ADKとMCPで利用者のOAuthセッションとロール権限によるSQL実行が可能

公開：2026年10月28日

CodeCampが提供するDX人材育成が可能なプログラミングやITが学べる公開講座

Gemini EnterpriseとSnowflakeの間には、Google Agent Development Kit（ADK）とMCPを使って安全な橋渡しを構築できます。この構成のエージェントは自然言語を理解し、Snowflake Cortexを通じてSQLを生成して、利用者単位の権限でクエリを実行する仕組みです。^[1]

この記事では、Gemini EnterpriseとSnowflakeの連携でできることやSnowflake側の設定手順、認可前に確かめる権限の条件を解説します。直接接続とGoogle ADKの構成のどちらを選ぶかの目安も整理します。

ADKとMCPで接続したSnowflakeへの質問
Snowflake側で行う3段階の設定
Gemini Enterprise認可前に確かめる権限
Gemini Enterpriseの2つの連携パターン

ADKとMCPで接続したSnowflakeへの質問

この構成では、ビジネス担当の利用者が「先四半期にテキサス州で売れた上位5品目は何か」のような質問を尋ねられます。この構成のエージェントは、生のSQL実行をクライアントに公開しない設計です。^[1]

クエリの生成と実行は、Snowflake MCP server経由で公開された統制されたCortex Agentに任されます。ADKのエージェントが質問を渡すと、Snowflake MCP serverはCORTEX_AGENT_RUNでCortex Agentを呼び出す流れです。

この構成では、Gemini EnterpriseアプリとSnowflakeの各エコシステムの間に信頼境界があります。実行は、両エコシステムの間を順に進む流れです。

図1　信頼境界をまたぐ実行の流れ

この構成例では、Cortex AgentがCortex Analystのsemantic viewに基づいて質問をSQLへ変換します。SQLは認証済みの利用者のOAuthセッションとロール権限でSnowflake内で実行され、構造化した結果がADKのエージェントへ返る仕組みです。

Google Cloudが挙げる利点は、社内の意味定義に沿った決定的なSQL変換と、クエリの実行をSnowflakeの統制された境界内に保てる点です。スキーマに関するハルシネーションや検証されていないSQLの実行のリスクも減らせるとしています。

Snowflake側で行う3段階の設定

Snowflake側の設定は、OAuthのセキュリティ統合や専用ロールによるアクセス制御、Cortex AgentとMCP serverの作成の3段階です。OAuth認可は、利用者がGemini Enterpriseで1回だけ行う操作です。^[1]

図2　Snowflake側の設定の3段階

Google Cloudは、汎用のサービスアカウントでモデルに広いアクセス権を与えると、利用者がセキュリティ制限を回避できるおそれがあるとしています。この構成は、OAuth 2.0で利用者本人として処理するuser impersonationによって、このリスクに対処する設計です。

OAuthセキュリティ統合の作成

最初に、クライアントシークレットを保護するため、Snowflakeで機密タイプのOAuthクライアントを作ります。設定はSnowflake内のセキュリティ統合として作成し、ACCOUNTADMINロールで実行する手順です。

図3　セキュリティ統合の主な指定値

セキュリティ統合を作成するSQLは、次の通りです。

USE ROLE ACCOUNTADMIN;  
CREATE OR REPLACE SECURITY INTEGRATION <SECURITY_INTEGRATION_NAME> 
TYPE = OAUTH 
ENABLED = TRUE 
OAUTH_CLIENT = CUSTOM 
OAUTH_CLIENT_TYPE = 'CONFIDENTIAL' 
-- Google Cloud's official handshake receiver address: 
OAUTH_REDIRECT_URI = 'https://vertexaisearch.cloud.google.com/oauth-redirect' 
OAUTH_ISSUE_REFRESH_TOKENS = TRUE 
-- Let the connection stay alive for 90 days (max Snowflake allowed limit) 
OAUTH_REFRESH_TOKEN_VALIDITY = 7776000;

公式資料からの抜粋：Securely connecting Gemini Enterprise to Snowflake data（Step 1: Setting up the Snowflake security integration）。対象版・範囲：Google Cloudブログ「Securely connecting Gemini Enterprise to Snowflake data」の構成例。

上記のコードでは、OAUTH_REFRESH_TOKEN_VALIDITYに7776000を指定し、接続を90日間保つようにしています。90日は、Snowflakeが許す上限の値です。

SnowflakeでSYSTEM$SHOW_OAUTH_CLIENT_SECRETSを実行すると、生成されたクライアントIDとクライアントシークレットを取得できます。2つの値は、Google Cloud側の設定に必要な情報です。

Python研修一覧はこちら

目的に合うPython研修を一覧形式から探したい方は、ぜひご利用ください。

Python研修を比較する

Java研修一覧はこちら

目的に合うJava研修を一覧形式から探したい方は、ぜひご利用ください。

Java研修を比較する

PHP研修一覧はこちら

目的に合うPHP研修を一覧形式から探したい方は、ぜひご利用ください。

PHP研修を比較する

新入社員研修

目的に合う新入社員研修を一覧形式から探したい方は、ぜひご利用ください。

新入社員研修を比較する

全ての研修からも探したい方はこちら

MCP serverの作成

semantic viewを基に統制されたCortex Agentを作り、CORTEX_AGENT_RUNで公開するMCP serverを用意します。SQLの生成とクエリの実行はSnowflakeに任され、呼び出し元のOAuthの身元とロール権限が適用される設計です。

図4　Snowflake側の構成と実行時に適用される権限

生の実行ツールの扱い

Google Cloudは、CORTEX_AGENT_RUNでクエリの生成と実行がSnowflakeの統制された境界内に収まるとしています。SYSTEM_EXECUTE_SQLなど生の実行ツールは、外部クライアントへ公開しないよう求めています。

図5　Google Cloudが示す実行ツールの扱い

Google Cloudが挙げる理由は、SYSTEM_EXECUTE_SQLのような生の実行ツールを外部クライアントへ公開すると、不要な攻撃面が増える点です。Cortex Agentの一元的な統制を迂回することも、理由に挙げました。

Cortex AgentとMCP serverを作るSQLは、次の通りです。

USE DATABASE <DATABASE_NAME>;
USE SCHEMA <SCHEMA_NAME>;
USE ROLE SYSADMIN;

-- 1. Create the Cortex Agent over your semantic view
CREATE OR REPLACE AGENT <AGENT_NAME>
  COMMENT = 'Governed data assistant for business queries'
  PROFILE = '{"cortex_analyst": {"semantic_models": ["<DATABASE_NAME>.<SCHEMA_NAME>.<SEMANTIC_VIEW_NAME>"]}}';

-- 2. Provision the MCP Server exposing the Cortex Agent
CREATE OR REPLACE MCP SERVER <SERVER_NAME>
FROM SPECIFICATION $$
tools:
  - name: "run_cortex_agent"
    type: "CORTEX_AGENT_RUN"
    identifier: "<DATABASE_NAME>.<SCHEMA_NAME>.<AGENT_NAME>"
    title: "Cortex Agent Assistant"
    description: "Converts natural language questions into SQL and executes them directly within Snowflake using the caller's OAuth session permissions."
$$;

公式資料からの抜粋：Securely connecting Gemini Enterprise to Snowflake data（Step 3: Provisioning the Cortex Agent and MCP server inside Snowflake）。対象版・範囲：Google Cloudブログ「Securely connecting Gemini Enterprise to Snowflake data」の構成例。

上記のコードでは、PROFILEのsemantic_modelsにsemantic viewを指定しています。MCP serverの仕様内のツールは、typeがCORTEX_AGENT_RUN、identifierがCortex Agentの完全修飾名です。

Python基礎・実践(Django)

企業・法人向けのPython研修では、基礎から応用まで体系的に学べます。

Python研修の詳細

DX社員研修

企業・法人向けのDX研修では、実務に繋がるリスキリングでITレベルを向上させます。

DX研修の詳細

Javaエンジニア育成研修

企業・法人向けのJavaエンジニア育成研修では、Javaの基礎から応用まで確実に習得できます。

Java研修の詳細

新卒・新入社員向け研修

企業・法人に新入社員・新卒社員に向けたプログラミング研修を提供しています。

新入社員研修の詳細

コードキャンプのIT研修を全て見る

Gemini Enterprise認可前に確かめる権限

Snowflake側では、エージェント専用ロールの権限と、Gemini EnterpriseでOAuth認可を行う時点の既定値に条件があります。条件を満たさないと、クエリの実行時にエラーになったり、実行に失敗したりする場合があります。^[1]

図6　接続で用いるロールや権限と認可の順序

専用ロールへの権限付与

専用ロールはSECURITYADMINで作成して利用者に付与し、各権限はSYSADMINで与える手順です。Semantic Viewを物理テーブルの上に作る構成で与える権限は、以下の通りです。

データベースとスキーマ：USAGE権限／ウェアハウス：USAGE権限／semantic view：SELECTとREFERENCES／スキーマ内の全テーブル：SELECT権限

Semantic Viewを物理テーブルの上に作る構成では、元の物理テーブルへのSELECT権限は省けません。semantic viewだけへの付与では実行時にエラーになります。

図7　ポリシーで変わるSemantic Viewの作成先

セキュリティポリシーで元のテーブルへの直接アクセスを許可できない場合、物理テーブル上にSnowflake Secure Viewを置きます。Semantic Viewはその上に作る形です。

セキュリティポリシーで元のテーブルへの直接アクセスを許可できない場合は、Secure Viewの上にSemantic Viewを作ります。ビューはOwner's Rightsで実行するため、GenAIロールには両ビューのSELECT権限で足ります。

DEFAULT_ROLEの設定時期

SnowflakeのOAuthトークンは、認可した時点の利用者のDEFAULT_ROLEとDEFAULT_WAREHOUSEに結び付きます。既定値の設定前に認可するとその時点のロールに固定され、意図したロールが必要な権限を持たない場合はクエリの実行に失敗する点に注意が必要です。

図8　OAuth認可の前後で行う設定

既定値は、ALTER USERの2つのコマンドで対象の利用者ごとに設定します。DEFAULT_ROLEには専用ロールを、DEFAULT_WAREHOUSEにはウェアハウスを指定する形です。

認可後は、利用者がSnowflakeの既定のロールとウェアハウスを普段の設定へ安全に戻せます。この復元は任意の手順です。

OAuth認可前の確認手順

Google ADKの構成で利用者がGemini EnterpriseでSnowflakeのOAuth認可を行う場合、編集部は事前の確認を勧めます。1つは、DEFAULT_ROLEが専用ロール、DEFAULT_WAREHOUSEが対象のウェアハウスかです。

図9　Gemini EnterpriseでSnowflakeのOAuth認可前の確認点

Google ADKの構成では、専用ロールが元の物理テーブルにSELECT権限を持つかも確かめます。直接アクセスを許可できずSecure Viewの上にSemantic Viewを作る構成なら、2つのビューが対象です。

Gemini Enterpriseの2つの連携パターン

Gemini EnterpriseとSnowflakeの連携には、直接接続（Direct Connection）とカスタムオーケストレーションのパターンがあります。Google ADKを使う今回の構成は、高度なカスタムオーケストレーションのパターンです。^[1]

図10　Snowflake連携のパターン

Google ADKの構成は、Google Cloud上で複雑なマルチエージェントシステムを作る開発者向けに設計されています。例には、Snowflakeの分析結果と外部の業務ツールを組み合わせるワークフローや独自の推論ループがあります。

Gemini Agent Engineでのクロスプラットフォームの状態管理も、Google ADKの構成が想定する複雑なマルチエージェントシステムの例です。Gemini EnterpriseをSnowflakeへ直接つなぐ標準的で基本的な用途には、Google Cloudは共同ソリューションの利用を案内しています。

編集部は、Gemini EnterpriseとSnowflakeの連携方法を選ぶ際、直接接続の標準的で基本的な用途に収まるかを先に確かめる順を勧めます。複雑なマルチエージェントの処理が必要な場合に、Google ADKの構成を検討する流れです。

出典