オンプレミスのデータウェアハウス（DWH）の保守期限まで、あと1年です。夜間バッチが朝8時までに終わらない日が、月に何度か出ています。ベンダー3社から提案が届き、どの資料にも「御社に最適」と書いてあります。経営企画からは「来期の予算に載せたいので、結局いくらになるのか教えてほしい」と聞かれました。しかし3社の見積もりは、課金の単位がクレジット、スキャン量、DBUとばらばらで、横に並べることすらできません。これでは比べようがありません。

Snowflake・BigQuery・Databricksは、どれもデータの保管と計算を切り離し、計算だけを増やしたり止めたりできる作りです。違いが出るのは、計算をどう止めるか、何に対してお金を払うか、チームにどんなスキルを求めるかの3点です。この3点を、今使っているクラウドと主な処理の中身に当てはめると、候補は1つか2つに絞れます。

状況から候補を絞る早見表

まず、自社の状況にいちばん近い行を探してください。右の列は、その製品を選んだあとに実際に詰まりやすい点です。

自社の状況まず検討する候補これを選ぶと後で困ること
GA4やGoogle広告など、データがGoogle Cloudに集まっているBigQuery請求額がクエリの書き方で大きく振れる。列や期間を絞る習慣がないチームでは、月末の請求で驚く
AWSやAzureが中心で、分析はSQLとBIが主Snowflake計算資源（仮想ウェアハウス）のサイズと自動停止を誰かが見ていないと、動きっぱなしの課金が続く
需要予測などの機械学習を、データの加工から学習まで通して回したいDatabricksSQLだけを書くメンバーには、ノートブックやSparkの作法が学習の負担になる
専任のインフラ担当がいないBigQuery、またはSnowflakeサーバーの台数を決めなくてよい代わりに、使い方の上限や規律を自分たちで決める必要がある
グループ会社や取引先とデータを受け渡したいSnowflake相手がSnowflakeを持っていない場合、閲覧用アカウントの計算費は提供する側の負担になる
複数のクラウドにまたがって使うSnowflake、Databricksクラウドやリージョンをまたいでデータを動かすと、転送料がかかる

「どれが一番速いか」で比べても、決め手にはなりません。データがすでにどのクラウドにあるかで、認証やデータ連携の手間が大きく変わるからです。迷ったら、データがいま置かれている場所に寄せる案から検討します。

課金の単位が違うので、同じ使い方で試算して比べる

見積もりが並べられないのは、3製品が別々のものに値段を付けているからです。公式ドキュメントで確かめた仕組みを、表にまとめます（2026年10月17日に参照）。

製品何に対して払うか止めるとどうなるか公式で確かめた既定値と数字
Snowflake仮想ウェアハウスの稼働時間を、クレジットで数える停止中は計算のクレジットがかからない秒単位の課金で、起動のたびに最低60秒。自動停止と自動再開は既定で有効で、CREATE WAREHOUSEの自動停止の既定は600秒。第1世代では1時間あたりXSが1、Sが2、Mが4、Lが8クレジット
BigQueryオンデマンド方式では、クエリが処理したデータ量。容量方式では、確保したスロットの時間クエリを流さなければ計算費はかからない。保管料は別にかかるオンデマンドは1TiBあたり6.25ドル（料金表のus-central1など）。毎月最初の1TiBの処理と、10GiBの保管は無料
DatabricksDBU（処理量をならした独自の単位）単価はDBUの価格表で決まるストレージやネットワークの費用は、利用するクラウド側で別にかかる。SQLの用途では、公式はサーバーレスのSQLウェアハウスを推奨している

金額の単価は契約形態やリージョンで変わります。そのため、ここでは「同じ使い方をしたら、どこで費用が膨らむか」を例で見ます。

BigQueryの例：期間で絞るだけで、請求が10分の1になる

BIのダッシュボードから月に2,000回クエリが流れ、1回ごとに50GiBを読むとします。月の処理量は10万GiB、TiBに直すと約97.7TiBです。無料の1TiBを引いた96.7TiBに6.25ドルを掛けると、約604ドルになります。

同じ表を日付でパーティション分割し、ダッシュボードが直近7日分だけを読むように直したとします。1回の読み込みが5GiBに減れば、月の処理量は約9.8TiBです。無料分を引いて計算すると、約55ドルに下がります。変えたのは期間の条件だけです。金額はどちらも説明のための例です。

-- 直す前：全列・全期間を読む
SELECT * FROM `project.dataset.events`;

-- 直した後：必要な列だけを、パーティション列で期間を絞って読む
SELECT user_id, event_name
FROM `project.dataset.events`
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY);

気をつけたいのは、クラスタリングしていない表では、LIMITを付けても読み込む量が減らないことです。歯止めは別に要ります。クエリごとに「課金する最大バイト数」を設定すれば、見積もりがそれを超えたクエリは課金されずに失敗します。プロジェクトやユーザーごとに、1日の処理量の上限（カスタム割り当て）も設定できます。

Snowflakeの例：自動停止の秒数で、稼働時間が変わる

BI用にSサイズのウェアハウスを1つ立て、平日の9時から19時までクエリが途切れず来るとします。1日10時間×2クレジット×20日で、月400クレジットです。実際にクエリが集中するのが1日3時間なら、自動停止がきちんと効けば月120クレジットで済みます。差は3倍以上です。

ここで効いてくるのが、自動停止までの待ち時間です。既定の600秒のままだと、最後のクエリから10分は動き続けます。9分おきにクエリが来るダッシュボードなら、一度も止まりません。待ち時間は用途に合わせて短くし、重いバッチとBIは別のウェアハウスに分けます。

-- BI用とバッチ用を分け、自動停止を短くする
CREATE WAREHOUSE bi_wh
  WAREHOUSE_SIZE = 'SMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

CREATE WAREHOUSE batch_wh
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

クレジットの単価は、エディションやリージョン、契約で変わります。予算に載せる前に、ベンダーへ自社の条件での単価を確認してください。

製品ごとの使いどころと、選ばないほうがよい条件

Snowflake：SQLとBIが中心で、計算を用途ごとに分けたいとき

Snowflakeは、データを1か所に置いたまま、夜間バッチ用、BI用、分析用と計算資源を分けて立てられます。重いバッチが走っても、別のウェアハウスで動くダッシュボードは遅くなりません。冒頭の「朝までにバッチが終わらず、分析も遅くなる」悩みには、この分け方がそのまま効きます。

運用で助かる機能もあります。過去の状態を参照できるタイムトラベルは、既定の保持期間が1日です。Enterprise Edition以上なら、永続的なテーブルで最大90日まで延ばせます。負荷に応じてクラスタの数を増やすマルチクラスタも、Enterprise Editionの機能です。見積もりのエディションが何かは、最初に確かめておきます。

取引先とのデータ共有では、相手がSnowflakeを使っていなくても、閲覧用のリーダーアカウントを発行して渡せます。ただし、リーダーアカウントで使われた計算のクレジットは、提供する側が支払います。共有先が多い場合は、その費用も予算に入れてください。

機械学習のモデルづくりが主役になる会社では、Snowflakeだけでは手が足りない場面が出てきます。その場合は、次に挙げるDatabricksとの併用か、Databricksを主にする案と比べます。

BigQuery：Google Cloudにデータがあり、サーバーを持ちたくないとき

BigQueryは、計算資源のサイズや台数を利用者が決めません。オンデマンド方式では、通常は最大2,000スロットまでを同時に使えると料金表に書かれています。インフラの担当者がいない会社でも、SQLを書けばすぐ集計を始められます。

その代わり、費用はクエリを書く人の数と癖に左右されます。分析者が20人いて、全員が気軽に全期間を読むと、先ほどの試算のように請求が膨らみます。表をパーティション分割すること、課金の上限を設定すること、実行前に処理量の見積もりを見ることの3つを、導入初月のルールにしておきます。利用が大きく安定してきたら、スロットを時間単位で確保する容量方式に切り替えると、月々の費用が読みやすくなります。

Databricks：機械学習と大規模な加工が中心のとき

Databricksは、データの加工から機械学習、SQLでの分析までを1つの基盤で扱えます。Bronze・Silver・Goldの3層でデータの品質を段階的に上げていく整理（メダリオンアーキテクチャ）も、Databricksの公式ドキュメントで説明されています。

SQLでの分析とBIだけが目的なら、SnowflakeやBigQueryより覚えることが多くなります。今は使わなくても、2年以内に機械学習を自社で回す計画があるかどうかで判断します。仕組みとDWHとの使い分けは、Databricksとは：レイクハウスの仕組みと、DWHとの使い分けにまとめています。

移行は1つの分析領域から、旧環境と並べて確かめる

全社のデータを一度に移そうとすると、要件が膨らんで止まります。売上の日次集計のような分析領域を1つ選び、旧環境と並べて動かしながら、数字と費用を確かめます。

月やること終わったと言える目安
1か月目移す分析領域を1つ選び、旧環境で月に何回、どれだけの量が読まれているかを数えるクエリの回数と読み込み量の実績が、表になっている
2か月目候補の製品で、その領域の取り込みと集計を作る。費用の上限と自動停止を最初に設定する旧環境と同じ数字が出ている
3か月目旧環境と並べて1か月動かし、実際の請求額を見る請求額が試算と2割以上ずれていない。ずれた理由を説明できる
4か月目以降次に移す領域を決める移した領域の利用者が、旧環境を見なくなっている

3か月目に請求額を確かめてから広げると、経営企画に出す予算の根拠が、試算から実績に変わります。

DWHを選んだあとに決めること

DWHは、データを取り込み、使える形に整え、BIで見せる前後の工程とつないで初めて役に立ちます。DWHの中でデータを層に分けて整える考え方はメダリオンアーキテクチャ（Bronze/Silver/Gold）の解説に、その変換をdbtで組む方法はdbtの3層構造に書いています。

毎日の処理を順番どおりに動かす仕組みはオーケストレーションツールの選び方で、数字が合わないときに気づく仕組みはデータ品質ツールの選び方で扱っています。

よくある質問（FAQ）

3つのうち、迷ったらどれから試せばよいですか?

データがすでにGoogle Cloudにあるなら、BigQueryから試します。AWSやAzureが中心で、SQLとBIが主な用途ならSnowflakeです。機械学習を加工から学習まで通して回す計画があるならDatabricksも候補に入れます。自社の代表的なデータを使い、1つの分析領域で1か月動かして、数字と請求額を確かめてから決めます。

従量課金だと、費用が青天井になりませんか?

歯止めを最初に設定すれば防げます。BigQueryでは、クエリごとの課金の上限と、1日の処理量の上限を設定できます。上限を超えたクエリは課金されずに失敗します。Snowflakeでは、ウェアハウスの自動停止を短くし、用途ごとにウェアハウスを分けます。そのうえで、毎月の利用内訳を見る担当者を1人決めておきます。

BigQueryでLIMITを付ければ、費用は下がりますか?

クラスタリングしていない表では、LIMITを付けても読み込む量は変わらず、費用も下がりません。費用を下げるには、必要な列だけを選ぶこと、パーティション列で期間を絞ることが効きます。実行前に処理量の見積もりを見る習慣も、あわせて付けておきます。

Snowflakeの見積もりで、エディションは何を見ればよいですか?

使いたい機能がどのエディションに含まれるかを確かめます。たとえば、負荷に応じて計算資源を自動で増やすマルチクラスタはEnterprise Editionの機能です。タイムトラベルの保持期間も、Standard Editionは1日まで、Enterprise Edition以上は永続的なテーブルで最大90日までです。クレジットの単価もエディションで変わります。

オンプレのDWHから一度に全部移したほうが、早く終わりませんか?

一度に移すと、旧環境の業務を止めずに数字を照合する作業が膨らみ、かえって長引きます。1つの分析領域を選び、旧環境と並べて1か月動かして、同じ数字が出ることと請求額を確かめます。その実績をもとに次の領域を決めると、予算の説明もしやすくなります。

出典

3社の見積もりが横に並べられず予算を出せないなら、自社の実際のクエリ量で試算をそろえるところから一緒に整理します。初回相談（30分・無料）で一緒に整理できます。