BigQuery MCP と Snowflake Cortex 周辺｜エンタープライズでの権限・コスト上限（要調査）

エンタープライズにおけるデータ活用の最前線は、単なる集計や可視化から、LLM（大規模言語モデル）をデータ基盤内で直接駆動させるフェーズへと移行しました。その中核を担うのが、Google CloudのBigQuery MCP（Model Control Plane / Vertex AI連携）と、Snowflake Cortex AIです。

これらの技術の最大のメリットは、データを外部のAPIにエクスポートすることなく、強固なガバナンスが維持されたデータウェアハウス（DWH）内で推論を完結できる点にあります。しかし、実務担当者にとっての最大の懸念は「誰が、どの範囲まで実行できるか（権限）」、そして「予期せぬコスト増大をどう防ぐか（コスト上限）」という運用設計です。

本記事では、IT実務者の視点から、両プラットフォームにおける権限設計とコスト管理の仕様を徹底的に解説します。

1. BigQuery MCP（Model Control Plane）によるAIガバナンス

BigQueryにおけるLLM活用の中核は、Vertex AIとのシームレスな連携にあります。従来のようにPythonコードを介してデータを転送するのではなく、SQLの ML.GENERATE_TEXT などの関数を用いて、DWH内のデータに直接AIを適用します。

Vertex AIリモートモデルの権限設計（IAM）

BigQueryからVertex AIのモデル（Geminiなど）を呼び出すには、Google CloudのIAM（Identity and Access Management）による多層的な権限設定が必要です。具体的には以下の設定が必須となります。

• BigQuery Connection Service Agent: BigQueryがVertex AIにアクセスするためのサービスアカウント（service-PROJECT_NUMBER@gcp-sa-bigqueryconnection.iam.gserviceaccount.com）に対し、「Vertex AI ユーザー」ロールを付与します。
• エンドユーザーの権限: SQLを実行するユーザーには、BigQueryのジョブ実行権限に加え、対象のConnectionに対する利用権限（bigquery.connections.delegate）が必要です。

この設計により、「データは見れるが、高コストなAI関数は実行できない」といった職務分掌が可能になります。これは、以前紹介したモダンデータスタックのツール選定におけるガバナンスの考え方とも共通する、非常に重要なポイントです。

コスト監視とクォータ制限

BigQueryからLLMを呼び出す際のコストは、主に「Vertex AIのトークン課金」と「BigQueryのクエリ課金（またはリザーブドスロット消費）」の合算になります。コスト爆発を防ぐためには、以下の制限をかけるのが実務上の定石です。

1. Vertex AIのAPIクォータ設定: Google Cloudコンソールから、プロジェクト単位またはリージョン単位で「1分あたりのリクエスト数」や「1分あたりのトークン数」に上限を設定します。
2. BigQueryの最大課金バイト数設定: クエリ実行時に --maximum_bytes_billed を指定、またはプロジェクトレベルで制限をかけ、AI関数が大量の行（数百万行など）に対して無意識に実行されるのを防ぎます。

2. Snowflake Cortex AIによるセキュアなAI推論

Snowflake Cortexは、Snowflakeが管理するインフラ内でフルマネージドなLLM機能を提供するサービスです。外部API（OpenAI等）を一切呼び出さず、Snowflakeのコンピュートリソース内で推論が完結するため、機密データの扱いに極めて適しています。

Cortex Functionsの権限設計（RBAC）

Snowflakeでは、標準的なRBAC（ロールベースのアクセス制御）をCortexに適用します。特定のユーザーやロールにのみCortexの使用を許可するには、以下の権限を付与します。

GRANT USAGE ON FUNCTION snowflake.cortex.complete(string, array) TO ROLE power_user_role;

このように関数単位で権限を制御できるため、安価な SNOWFLAKE.CORTEX.SUMMARIZE（要約）は全社解放し、高価な SNOWFLAKE.CORTEX.COMPLETE（生成）は特定の部署のみに制限するといった運用が可能です。

リソースモニタによるコスト上限の設定

Snowflakeで最も恐ろしいのは、意図しないフルスキャンによってWarehouseのクレジットが激しく消費されることです。Cortex AIの利用料は、実行に使用したコンピュート（Warehouse）のコストに加え、モデルごとのトークン消費に応じたクレジットが加算されます。

• リソースモニタの設定: Cortexを実行する専用のWarehouseを作成し、リソースモニタで「月間1,000クレジットを超えたら即時中断」といったハードリミットを設定します。
• クエリタイムアウトの設定: STATEMENT_TIMEOUT_IN_SECONDS を短めに設定し、異常なループや重い処理が続くのを防止します。

特に、広告最適化などの自動化アーキテクチャにAIを組み込む場合、バッチ処理の失敗による無限リトライがコスト事故を招くリスクがあるため、これらのリミッター設定は必須と言えます。

3. 【徹底比較】BigQuery MCP vs Snowflake Cortex

両者の実務的な違いを比較表にまとめました。選定の際の判断基準として活用してください。

公式の料金詳細は、それぞれの公式ドキュメント（Google Cloud Vertex AI Pricing / Snowflake Cortex Billing）を必ず参照してください。

4. 実務における権限・コスト管理の具体的な設定ステップ

BigQuery：最小権限原則に基づく設定

BigQuery MCPを安全に運用するためのステップです。

1. 専用Connectionの作成:
   bq mk --connection --location=US --project_id=my-project --connection_type=CLOUD_RESOURCE my-ai-connection
2. サービスアカウントへの権限付与:
   作成されたConnectionのサービスアカウントを確認し、IAMで「Vertex AI ユーザー」を付与。
3. ユーザーへの制限:
   特定のデータセットをソースとするクエリのみにAI関数の実行を許可するよう、ビュー（View）を作成し、ユーザーにはそのビューへの権限のみを与えることで、元データへの直接アクセスと無制限なAI実行を制限します。

Snowflake：コスト事故を防ぐ Warehouse 分離

Snowflake Cortexでは、ワークロードの分離が最大の防御策です。

1. AI専用Warehouseの作成:

   CREATE WAREHOUSE AI_WH WAREHOUSE_SIZE = 'XSMALL' AUTO_SUSPEND = 60;

2. リソースモニタの紐付け:
   特定のクレジットを超えた際に、AI_WHのみを停止させる設定を入れます。これにより、通常のBIレポート（別のWarehouseを使用）を止めずに、AI処理だけを緊急停止できます。
3. ネットワークポリシーの確認:
   Cortex自体はSnowflake内部で動作しますが、外部APIモデルを呼び出すような設計（External Network Access）を行う場合は、IDガバナンスとアカウント管理の観点から、アクセス可能なドメインをホワイトリスト形式で制限してください。

5. よくあるエラーと対処法

• 403 Permission Denied (BigQuery): 大半はConnectionのサービスアカウントにVertex AIの権限が不足しているか、リージョンが一致していない（例：ConnectionはUSだがVertex AIはasia-northeast1）ことが原因です。
• Object does not exist (Snowflake): SNOWFLAKE.CORTEX.COMPLETE などの関数が見つからない場合、そのロールに USAGE 権限が与えられていないか、Cortexがまだ有効化されていないリージョンを使用している可能性があります。
• Quota Exceeded: 短時間に大量の行に対してLLM関数を実行すると発生します。SQLで LIMIT をかけてテストするか、データの更新差分のみを処理するインクリメンタルな設計（dbt等を利用）に変更してください。

6. まとめ：持続可能なAIデータ基盤を構築するために

BigQuery MCPとSnowflake Cortexは、これまで「Pythonエンジニアがいなければ不可能」だった高度な分析を、SQLだけで実現可能にしました。しかし、その手軽さゆえに、権限管理とコスト管理の不備は即座に致命的なリスクとなります。

まずはスモールスタートとして、特定のプロジェクト専用のWarehouseやConnectionを隔離して構築し、リソースモニタ等で「物理的な上限」を設定した上で開放することをお勧めします。こうした基盤の堅牢性が、最終的にはBIとAPI連携による経営の可視化を加速させる原動力となります。

データ基盤の構築は手段であり、目的は意思決定の高速化です。AIという強力なツールを、ガバナンスというブレーキとセットで正しく使いこなしていきましょう。