10月27日、Google Cloudが「Bridge Gemini Enterprise and Snowflake with Google ADK」と題した記事を公開した。生SQLをクライアント側で生成・実行させるという"よくある失敗パターン"を正面から避け、SQLの生成と実行をSnowflakeの境界内に閉じ込めるアーキテクチャを、Google ADKとMCPを使って実現する方法が詳しく解説されている。
何が面白いか：「SQLを外に出さない」設計
エンタープライズAIにおけるよくある失敗パターンは、AIエージェントに広すぎる権限を持つサービスアカウントを渡し、生SQLをクライアント側で生成・実行させることだ。スキーマのハルシネーション（存在しないテーブルや列を使ったSQLの生成）や、セキュリティポリシーの迂回リスクが生じる。
この記事が提示するアーキテクチャは、その問題を正面から解決する。SQLの生成と実行を両方ともSnowflakeの境界内に閉じ込めるのが核心だ。
ここで登場する2つのキーワードを簡単に整理しておく。Google ADK（Agent Development Kit）はGoogleが提供するAIエージェント構築フレームワークで、マルチエージェントの調整や外部ツール連携を担う。MCP（Model Context Protocol）はAIモデルが外部ツールやデータソースと標準化された形でやり取りするためのプロトコルで、SnowflakeはこのMCPサーバーを提供することでADKエージェントとの連携を実現する。
具体的には、ユーザーが「テキサス州で先四半期に最も売れた商品トップ5は？」と自然言語で質問すると、次のように処理が流れる：
- Google ADKエージェントがユーザーの質問をSnowflake MCPサーバーに渡す
- Snowflake Cortex Agent（
CORTEX_AGENT_RUN）がセマンティックビューを元に自然言語→SQLへ変換し、そのままSnowflake内で実行する - 構造化された結果だけがADKエージェントに返ってくる
重要なのは、raw SQLをクライアント（ADKエージェント側）に渡さない点だ。記事では「SYSTEM_EXECUTE_SQLのような生実行ツールを外部クライアントに公開することは、不必要なセキュリティ攻撃面を増やし、Cortex Agentのガバナンスを迂回する」と明示的に警告している。
権限設計の実践的なポイント
セキュリティまわりで特に実務に効く注意点が3つ述べられている。
1. セマンティックビューだけへのアクセス付与は不十分
セマンティックビューのSELECT権限だけを付与しても、背後にある物理テーブルへのSELECT権限がなければクエリ実行時にランタイムエラーになる。物理テーブルへの直接アクセスをセキュリティポリシーが許可しない場合は、Snowflake Secure Viewを物理テーブルの上に置き、その上にセマンティックビューを構築する方法が推奨されている。Secure ViewはOwnerの権限で動くため、GenAIロールにはSecure ViewとSemantic ViewのSELECTだけを付与すればよい。
2. OAuthトークンのバインドタイミングに注意
SnowflakeのOAuthトークンは、認可した瞬間のユーザーのDEFAULT_ROLEとDEFAULT_WAREHOUSEに固定される。認可前にこれらが正しく設定されていないと、意図しないロールでセッションが固定され、クエリが失敗する。手順としては「デフォルトを設定→Gemini EnterpriseでOAuth認可→（必要なら）デフォルトを元に戻す」の順番が必須だ。
3. OAuth 2.0でユーザーインパーソネーション（impersonation）を実現
サービスアカウント1つに広い権限を与える代わりに、OAuth 2.0を使って実行ユーザーのセッションと権限でクエリを走らせる。クライアントシークレットを保護するためSnowflake側でConfidential OAuth Clientを設定し、最小権限の原則に基づいた専用ロールをエージェント用に作成する。ユーザーインパーソネーションとは、エージェントが共有サービスアカウントではなく「操作しているユーザー自身」として認証・実行する仕組みであり、監査ログの追跡可能性やロールベースのアクセス制御を維持するうえで重要な設計選択だ。
統合パターンの選び方
記事は最初に、この実装が「高度なカスタムオーケストレーション」パターンであることを明示している。複数エージェントのワークフロー、外部エンタープライズツールとの組み合わせ、クロスプラットフォームの状態管理などが対象だ。
単純にGemini EnterpriseをSnowflakeに直接つなぐ標準的なユースケースには、Snowflake公式のクイックスタートガイドが適している。
デプロイはCLI一発
ADKエージェントのデプロイは、Google Agents CLI（agents-cli）を使えばコンテナビルドや複雑なPythonスクリプトは不要だ。agents-cliはGoogle ADKエコシステムが提供するデプロイ専用CLIツールで、ADKエージェントをGoogle Cloud上のAgent Platformへ展開する作業を自動化する。CLIがコードのパッケージングからサーバー設定、デプロイパイプラインまで自動処理し、完了後にAgent Platformのリソースパス（projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID）が出力される。
デプロイ後はGoogle Cloud ConsoleのGemini Enterpriseページからエージェントを登録し、SnowflakeのOAuth設定（Token URI、Authorization URI、クライアントIDとシークレット）をマッピングする。一点注意として、Authorization URIの末尾に&response_type=codeを付加する必要がある。これがないとOAuth 2.0の認可コードフローがトリガーされない。
コードのAUTH_IDとGoogle Cloud ConsoleのAuthorization Nameは完全一致が必須だ（Snowflake側のSecurity Integration名は一致不要）。
詳細はBridge Gemini Enterprise and Snowflake with Google ADKを参照していただきたい。
