BigQueryとSnowflakeの比較：課金モデルの構造差と同時実行で決める選定基準

BigQueryとSnowflakeを並べて見積もろうとすると、比較表の「料金」の欄で手が止まります。片方はスキャンしたバイト数、もう片方はウェアハウスが動いていた秒数で請求されるため、単価を横に並べても答えが出ないからです。この記事では、2026年8月17日時点の公式料金ページとSnowflake Service Consumption Table（2026年8月10日発効）で実測した単価をもとに、課金単位の非対称性、同時実行が増えたときに請求カーブが分かれる場所、同じワークロードで請求が逆転する境界を整理します。マルチクラウド要件からの逆算と、採用を見送るべき条件まで扱います。

まとめ：スキャン量と稼働時間のどちらで課金されるかという分岐点

結論から示します。スキャン量に対して稼働時間が短いワークロード、つまり実行間隔が空くアドホック分析やバッチ集計はBigQueryのオンデマンド課金が安く収まります。逆に、スキャン量は小さいのに問い合わせが途切れないBIダッシュボードならSnowflakeのウェアハウス課金のほうが読みやすい。分岐は「スキャンしたバイト数を、合計何時間かけて処理するか」という比率にあります。

マルチクラウド要件があるなら判断はほぼ決まります。SnowflakeはAWS・Azure・Google Cloudの3社上で動き、BigQueryのクエリエンジンはGoogle Cloud上でのみ動きます。ただし東京リージョンのSnowflakeはクレジット単価が米国東部比でおよそ42%高い。同時実行の作り込みも守備範囲が違い、Snowflakeのマルチクラスターウェアハウスは Enterprise Edition 以上でしか使えません。エディション選択がそのまま同時実行設計の上限になります。

課金モデルの構造差：スキャン量課金とウェアハウス稼働秒課金の請求ロジック

比較の起点は、何を数えて請求しているかの違いです。BigQueryは既定でクエリが読んだデータ量を、Snowflakeは仮想ウェアハウスが動いていた時間を数えます。以下の単価は2026年8月17日に公式資料で確認したもので、リージョンによって変動します。

BigQueryのオンデマンド課金：読んだ列のバイト数だけが請求対象

BigQueryの既定はオンデマンド課金です。米国マルチリージョンなら毎月1 TiBまで無料で、超過分は1 TiBあたり6.25ドル。課金対象は読んだ列のバイト数で、実行時間は請求に影響しません。10秒で終わっても10分かかっても、同じ列を同じ範囲だけ読んだなら請求額は同一です。

この仕組みの帰結として、費用を下げるレバーはチューニングではなくスキャン範囲の絞り込みに寄ります。SELECT * を書かない、パーティション列を必ず絞る。この2つで請求は桁で変わります。製品そのものの仕組みはサーバーレスDWHとしてのBigQueryの仕組みで整理しました。

BigQuery Editionsのスロット時間課金：0.04ドルからの3段階

Editionsに切り替えると、課金単位はスキャン量からスロット時間へ移ります。米国リージョンでコミットメントなしなら、Standardが1スロット時あたり0.04ドル、Enterpriseが0.06ドル、Enterprise Plusが0.10ドル。1年コミットで0.036ドル・0.054ドル・0.09ドル、3年コミットで0.032ドル・0.048ドル・0.08ドルまで下がります。

課金は秒単位で、起動時に最小1分ぶんが計上される仕組み。Fluid scalingにオプトインすれば最小なしの秒課金へ切り替わります。ここが誤解されやすい箇所で、Editionsを選んだ時点でBigQueryの請求は「時間×リソース量」というSnowflakeと同じ形に変わります。切替の判断材料はオンデマンドとEditionsの分岐点にまとめました。

Snowflakeのクレジット制：サイズで倍々に増える毎時消費量

Snowflakeは仮想ウェアハウスの稼働時間をクレジットで数えます。第1世代（Gen1）標準ウェアハウスの消費量は、XSが毎時1クレジット、Sが2、Mが4、Lが8、XLが16。以降も2XLで32、3XLで64、4XLで128、5XLで256、6XLで512と倍々に増えます。サイズを1段上げれば消費量は必ず2倍。

課金は起動・再開時に最低1分ぶんを消費し、その後は秒単位で切り上げられます。停止中のウェアハウスはクレジットを消費しません。つまり請求を抑える手段はauto-suspendの短縮とクエリの集約であって、クエリ本文の書き換えではない。BigQueryのオンデマンドとは、効くレバーが逆を向いています。

Gen2とエディション単価：同じXSでも請求が3.8倍ずれる条件

2026年時点で新規作成される標準ウェアハウスは、GENERATION句を指定しなければ第2世代（Gen2）が既定になります。Gen2の消費量はGen1より高く、XSでAWSとGoogle Cloudが毎時1.35クレジット、Azureが1.25クレジット。5XLと6XLはGen2に対応しません。同じ「XS」でも世代で35%の差。

クレジットの単価はエディションとリージョンで決まります。AWS米国東部（北バージニア）ではStandardが2.00ドル、Enterpriseが3.00ドル、Business Criticalが4.00ドル、VPSが6.00ドル。AWS東京とAzure Japan Eastは2.85ドル・4.30ドル・5.70ドル・8.55ドルです。

この2軸を掛けると差が開きます。米国東部のStandardでGen1のXSを1時間動かせば2.00ドル。東京のBusiness CriticalでGen2のXSを1時間動かすと1.35×5.70で7.695ドル。同じ「XSを1時間」で3.8倍です。見積書に「XSウェアハウス」とだけ書かれていたら、世代・エディション・リージョンの3つを必ず確認してください。機能単位のクレジット消費はStreamlit in Snowflakeの料金と課金体系のような単機能の例で見ると把握しやすくなります。

ストレージ課金の水準比較：TiBとTBの単位差と履歴データの扱い

コンピュートと違い、保管費用は近い水準です。差が出るのは計測単位と、履歴データを請求に含めるかどうか。

BigQueryの単価はus-central1の公式例示、Snowflakeの単価はAWS米国東部のオンデマンドです。同じ23ドル台でも、GiB建てのBigQueryの1 TiBは10進TBより約10%多い実データ量にあたります。より効くのは最終行で、BigQueryの論理ストレージを選んでいる限りタイムトラベルとフェイルセーフのぶんは無料。Snowflakeは保持期間を延ばした履歴のぶん、ストレージ請求が増えます。

同時実行への効き方：スロット共有とマルチクラスターのスケール単位

実運用で見積りが外れる原因は、単価ではなく同時実行の扱いです。増えた負荷を、片方は待ち時間で、もう片方は金額で吸収します。

BigQueryのスロット共有：インタラクティブ1,000件という待ち行列

BigQueryは並列処理の単位をスロットと呼びます。オンデマンド課金では共有スロットプール、Editionsでは予約したスロットが割り当てられる構造。スロットが足りなくなると、クエリはキューに入って待ちます。待ち行列の上限はプロジェクトあたりインタラクティブクエリで1,000件、バッチクエリで20,000件で、超えるとクォータエラーになります。

押さえておきたいのは、オンデマンド課金では同時実行が10本でも100本でも、読むバイト数が同じなら請求額が変わらない点。増えるのは待ち時間だけです。

Snowflakeのマルチクラスター：Enterprise以上という前提と上限

Snowflakeで同時実行をさばく手段がマルチクラスターウェアハウスです。1つのウェアハウスに同じサイズのクラスタを複数持たせ、キューが発生したら追加します。この機能は Enterprise Edition 以上の提供。Standard Editionを選んだ時点で、逃げ道はウェアハウスを手で増やす運用に限られます。

クラスタ数の上限はウェアハウスサイズで決まり、XSからMまでが300、Lが160、XLが80、2XLが40、3XLが20、4XL以上は10です。動作モードはMaximized（最小と最大を同値にして固定）とAuto-scale（別値にして自動増減）の2種類。Auto-scaleではSCALING_POLICYで増やしやすさを制御します。クラスタが3本立ち上がれば消費クレジットもそのまま3倍で、同時実行の増加が遅延ではなく金額として現れる仕組みです。

同時実行が増えたときの請求：遅延で吸収するか金額で吸収するか

BigQueryのオンデマンドは、同時実行が増えても請求は横ばいでレイテンシが伸びる。Snowflakeのauto-scaleは、レイテンシを保ったまま請求が伸びます。優劣ではなく、事業側がどちらを許容できるかという問題です。朝の社内集計が15分遅れても業務が止まらないならBigQuery型、顧客向け管理画面でレスポンス3秒超が解約理由になるならSnowflake型。なおBigQueryもEditionsのautoscalingでスロットを自動追加できるため、この軸はオンデマンドを選んだ場合に限った差です。

マルチクラウド要件と既存スタックからの分岐：データの所在で決まる選定

課金モデルの前に決着がつく条件があります。データが今どこにあるか、そして置き場所に制約があるかどうか。

Snowflakeの3クラウド展開：東京は米国東部比でおよそ42%の割増

SnowflakeはAWS・Azure・Google Cloudのいずれの上でもアカウントを作れます。既存インフラがどれでも同じ製品・同じSQLで運用できる点が実務上の強み。

ただし単価はリージョンごとに設定されています。Standardエディションのクレジット単価は、AWS米国東部やAzure東部で2.00ドル、AWS東京とAzure Japan Eastで2.85ドル。差はおよそ42%です。「日本リージョンに置くべきか」は法務要件だけの話ではなく、この上乗せを固定費として許容できるかという費用の議論でもある。

BigQueryはGoogle Cloud固定：Omniで読む場合の単価差と転送料

BigQueryのクエリエンジンはGoogle Cloud上で動きます。AWSやAzureにあるデータを移さず読む手段としてBigQuery Omniがあり、オンデマンドで1 TiBあたり9.125ドル。通常の6.25ドルに対しておよそ1.46倍です。Omni向けスロットは100スロットで毎時7.50ドル。

結果を持ち帰るクロスクラウド転送にも料金がかかり、AWS北バージニアからGoogle Cloud北米で1 GiBあたり0.09ドル。Omniには対応リージョンの制限もあるため、国内案件では前提を先に確認してください。詳細はS3やBlob Storageを移さず分析する構成と対応リージョンの制約にまとめています。

既存スタックから逆算する分岐：GA4系のデータかS3上のログか

実際の案件では次の順で見ると迷いが減ります。第一に、分析対象の主要データがGA4やGoogle広告のように標準でBigQueryへエクスポートされる系統なら、BigQueryを起点にするほうが接続の作り込みが減る。第二に、主要データがS3やAzure Data Lake Storageに蓄積され、AWSやAzureのIAMで権限管理が完結しているなら、Snowflakeを同じクラウド上に置くほうが転送と権限の二重管理を避けられます。

取り込み側の課金は判断材料になりません。BigQueryのStorage Write APIはgRPC経由で1 GiBあたり0.025ドル（毎月2 TiBまで無料）、読み出しのStorage Read APIは1 TiBあたり1.10ドル（毎月300 TiBまで無料）。無料枠が大きく、通常規模では費用差が出ないためです。

暴走クエリの費用上限：バイト数で縛るかクレジットで縛るかの差

選定後に運用として効くのが、費用を止める仕組みの作り方です。ここも非対称。

カスタムクォータとリソースモニター：止める基準が違うことの実務的な帰結

BigQueryはプロジェクトやユーザー単位のカスタムクォータで1日あたりのクエリ使用量に上限を設け、個別クエリには maximum_bytes_billed を指定します。止める基準はバイト数。Snowflakeはリソースモニターでクレジット消費に上限を設け、しきい値到達時に通知・ウェアハウス停止・実行中クエリを含めた即時停止のいずれかを実行します。止める基準はクレジット、つまり時間です。

帰結として、BigQueryなら「1本のクエリが読めるバイト数」を事前に縛れます。Snowflakeで同等の歯止めを掛けるなら、ウェアハウス単位のリソースモニターとステートメントタイムアウトを組み合わせる設計になる。なおSQLの書き換え工数は、BigQueryの UNNEST とSnowflakeの LATERAL FLATTEN のように半構造化データの展開構文に集中します。移行見積りでは既存クエリの総数ではなく、VARIANTやARRAYを触っている本数を数えてください。

請求が逆転する損益分岐と、採用を見送るべきワークロードの条件

ここまでの単価で、請求が逆転する境界を数字に置きます。前提はSnowflake側がAWS米国東部・Standard（1クレジット2.00ドル）・Gen1のLサイズ（毎時8クレジット）、BigQuery側が米国マルチリージョンのオンデマンド（1 TiBあたり6.25ドル・毎月1 TiB無料）です。

スキャン量が同じでも稼働時間で10倍差がつく3ケースの費用試算

月間スキャン量を100 TiBに固定し、合計稼働時間だけを変えて比べます。

稼働時間が13倍になれば、Snowflake側の請求だけが10倍に伸びます。逆にスキャン量が10倍でも稼働時間が同じなら、Snowflake側の請求は動かない。両者は直交する軸で課金されています。

ただし同じ100 TiBを同じ時間で処理できるかは、クエリの内容とウェアハウスサイズ次第です。実案件では代表的なクエリを3本から5本選び、両環境で流して実測のスキャンバイト数と実行秒数を取ってから当てはめてください。単価表だけで決めた見積りは、ほぼ外れます。

BigQueryを採る条件：範囲を絞れるバッチと不定期のアドホック分析

次の条件が揃うならBigQueryのオンデマンドを採ります。分析が日次・週次のバッチ中心で、誰も触らない時間帯が長いこと。テーブルを日付でパーティション分割でき、クエリが必ず期間を絞ること。GA4やGoogle広告など、Google側からのエクスポートが主要データ源にあること。

この形なら、待機時間がゼロコストという性質がそのまま効きます。ウェアハウスのサイズ選定やauto-suspendの調整も発生しません。データ基盤の専任がいない組織では、この運用負荷の差が単価の差より大きく効きます。

Snowflakeを採る条件：同時接続が読めないBI基盤とクラウド制約

Snowflakeを採るのは、同時接続数が事前に読めず、かつレイテンシに約束がある場合です。Auto-scaleモードのマルチクラスターウェアハウスは、キューが発生した時点でクラスタを追加してレスポンスを保ちます。この挙動をBigQueryのオンデマンドで再現する方法はありません。

もう1つは、データをAWSやAzureから動かせない制約がある場合。この条件では議論の余地がない。ただしEnterprise Edition以上が前提になり、東京リージョンなら1クレジット4.30ドル。米国東部のStandard（2.00ドル）と比べれば2.15倍です。どちらを選ぶにせよ、収集から可視化までの層構成はデータ分析基盤構築・MLOps構築支援のような設計支援を入れると、単価比較だけで決めるより手戻りが減ります。

採用を見送るべき2つの組み合わせ：専任不在とオンデマンドの予算固定

条件を付けて言い切ります。データエンジニアが専任で1人もいない組織にSnowflakeは過剰です。ウェアハウスサイズの選定、auto-suspendの秒数調整、SCALING_POLICY、リソースモニターのしきい値設計。これらを継続的に見直せる人がいないと、クレジット消費は誰も理由を説明できないまま増えます。この条件下ではBigQueryのオンデマンドを選び、見直し対象をスキャン範囲だけに絞るほうが安く収まる。

逆に、月額予算が固定で超過が許されない案件では、BigQueryのオンデマンドをそのまま採りません。1本の SELECT * が数百ドルを一度に消費しうるためです。カスタムクォータと maximum_bytes_billed で必ず上限を設けるか、はじめからEditionsに寄せてスロット数で天井を作ります。PoCから本番移行までの体制と外注判断はPoCから本番移行までの手順と体制で整理しました。

BigQueryとSnowflakeの費用・同時実行・選定でよくある質問

選定の場でよく出る質問に、実測した単価と仕様で答えます。

BigQueryとSnowflakeはどちらが安いですか？

ワークロードの形で逆転するため、製品単位では決まりません。目安は「月間スキャン量（TiB）÷ 合計稼働時間」です。短時間で大量に読む処理が中心ならBigQueryのオンデマンドが安く、少量を長時間読み続ける処理が中心ならSnowflakeが安くなります。試算ではスキャン量100 TiB・稼働30時間でSnowflakeが480ドル対BigQuery618.75ドル、稼働400時間ならSnowflakeが6,400ドルまで伸びました。

Snowflakeを東京リージョンで使うと単価はどれくらい上がりますか？

Snowflake Service Consumption Table（2026年8月10日発効）では、AWS東京とAzure Japan Eastのオンデマンドクレジット単価がStandardで2.85ドル、Enterpriseで4.30ドル、Business Criticalで5.70ドル、VPSで8.55ドル。米国東部の2.00ドル・3.00ドル・4.00ドル・6.00ドルと比べ、いずれもおよそ42%の割増です。ストレージも1 TBあたり23.00ドルに対し東京は25.00ドルになります。

BigQueryのEditionsに切り替えるとSnowflakeと同じ課金になりますか？

課金の形は近づきます。Editionsではスキャン量ではなくスロット時間で請求され、米国リージョンのコミットメントなしでStandardが1スロット時0.04ドル、Enterpriseが0.06ドル、Enterprise Plusが0.10ドル。秒単位課金で起動時に最小1分という点も同じ構造です。違いが残るのは割り当ての粒度で、Snowflakeがウェアハウス単位でサイズを固定するのに対し、BigQueryはベースラインと最大スロット数の範囲で自動増減させます。

AWS上にあるデータをBigQueryで分析できますか？

BigQuery Omniを使えば、S3上のデータをGoogle Cloudへコピーせずクエリできます。ただしオンデマンド単価は1 TiBあたり9.125ドルで通常の6.25ドルより高く、結果を持ち帰るクロスクラウド転送も1 GiBあたり0.09ドル（AWS北バージニア発）。対応リージョンにも制限があるため、国内のS3が対象なら先に可否を確認してください。

BigQueryとSnowflakeを併用する構成は現実的ですか？

目的が分かれているなら成立します。よくある形は、Google広告やGA4のデータをBigQuery側で受けてマーケティング分析に使い、基幹系や顧客データはAWS上のSnowflakeで扱う分担です。避けたいのは同じデータを両方に置く構成。ストレージ費用が二重にかかるうえ、どちらが正本か分からなくなります。併用するならテーブル単位で正本を先に決めてください。

関連記事

• データウェアハウス（DWH）とは？仕組み・製品比較・選び方：2製品の前にDWHという枠組みから整理したい場合に
• ClickHouseとは？列指向DBの仕組みとBigQueryとの使い分け：自前運用の列指向DBという第3の選択肢を確認する
• Amazon Redshift Serverlessとは｜仕組みと料金・移行判断：AWS側で完結させる場合のDWH候補として比較する
• BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸：選定の議論を導入後の成果条件から逆算する