「AWS上のSnowflakeが月200万近く出ていて、GCP側に寄せてBigQueryに移せば下がるのか」。そんな相談を月に何件かいただきます。
DWHからDWHへの移行は、基幹DBからの移行と違ってテーブル構造はほぼ写せます。ただし、Snowflake固有のTime Travel・VARIANT・Secure Data Sharing・仮想ウェアハウス運用に合わせて組んできた設計が、丸ごと乗り換え対象になります。SQL方言差も「ほぼ同じ」のはずが、本番切替の直前で数十本のクエリが落ちる、という話は珍しくありません。移行判断で最初に必要なのは、今のSnowflakeで何をやっているかの棚卸しです。
そこで本記事では、SnowflakeからBigQueryへの移行費用と工程、SQL方言差、判断基準、失敗パターンを、稟議とベンダー選定にそのまま使える形で整理しました。両DWHの機能比較はすでにSnowflakeとBigQuery比較｜コスト・性能・機能の違いと選び方【2026年版】で扱っているので、こちらは「移行するか・どう移すか」の実務判断に軸足を置いています。
2024年ごろまでは、日本国内でSnowflakeからBigQueryへ乗り換える相談は少数派でした。2026年に入って相談量が明らかに増えており、背景には3つの要因があります。
1つ目は On-demand課金の予測しにくさ疲れ です。Snowflakeの仮想ウェアハウスは秒単位の従量課金で自由度が高い一方、担当者が入れ替わったりダッシュボードが増えたりすると、月額が想定の1.5〜2倍に跳ねる事例が繰り返し起きます。BigQueryのEditions＋スロット予約は月額を固定できるため、CFO稟議で「上限が読める」ことが強い動機になっています。
2つ目は GA4・Ads・Vertex AIとの直結メリット です。マーケティング側でGA4のBigQueryエクスポートを標準機能で使い、広告データはAds Data Hubから直接BigQueryに入り、機械学習はVertex AI／BigQuery MLで完結する構成がGoogle Cloud側で年々厚くなっています。データの入口と出口が同じクラウドに寄っている企業ほど、SnowflakeをETLで挟む合理性が薄れてきています。
3つ目は 移行ツールの成熟 です。2026年前半にBigQuery Data Transfer ServiceのSnowflakeコネクタが正式提供に昇格し、増分転送・自動スキーマ検出・Private connectivityが公式サポートされました（Google Cloud公式ドキュメント）。加えてBatch SQL Translatorが方言変換を自動化するようになり、以前は数百万円かかった移行工数の下地が数十万円レンジまで下がっています。
Snowflakeから BigQueryへデータを流す方法は、大きく3つに分けられます。「どれか1つ」ではなく、テーブル特性ごとに割り当てる視点が実務的です。
1つ目：BigQuery Data Transfer Service（Snowflakeコネクタ）。2026年前半に正式提供に昇格した本命の方式です。GUI設定でスケジュール転送を組み、増分転送、自動スキーマ検出、Private Service Connect経由の閉域接続まで公式サポートされます。初期構築が短く、大半のテーブル移行はこの方式でカバーできます。
2つ目：Snowflake COPY INTO → Cloud Storage → BigQuery LOAD。一括ダンプ用途で有効な方式です。数十TBを一発で移す初期移行や、履歴データのアーカイブ移行で使います。実装がシンプルで運用コストが安い一方、CDC（変更データキャプチャ）は自作になるため、初期移行後の継続同期には向きません。
3つ目：trocco・Fivetran・Striim等のELTツール経由。複雑なソースが混在する場合や、Snowflakeと同時に他のSaaS（Salesforce、kintone等）もBigQueryに移す場合に選択肢に入ります。ツール選定はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較を参考にしてください。
判断の基本は、Snowflakeを完全に置き換える計画なら1つ目のBigQuery Data Transfer Serviceを本命に、初期の一括移行だけ2つ目のCOPY INTO方式を組み合わせるのが効率的です。3つ目のELTツールは、SnowflakeとBigQueryの並行運用期間を短くしたい場合や、他のSaaS連携も同じツールでまとめたい場合に有利になります。
SnowflakeとBigQueryはどちらもANSI SQLベースですが、細かな方言差があります。ここを見落とすと、並行運用開始時に「クエリの2〜3割が動かない」状態に陥ります。代表的な差分を並べます。
| 領域 | Snowflake | BigQuery | 移行時の注意 |
|---|---|---|---|
| 半構造化型 | VARIANT | JSON または STRUCT | 比較演算・パスアクセスの書き方が異なる |
| 半構造化展開 | LATERAL FLATTEN(input => col) | UNNEST(col) WITH OFFSET | 展開後のカラム参照方法が変わる |
| Time Travel | 最大90日（Enterprise以上） | 最大7日、テーブルスナップショットで長期化 | 90日保持要件がある場合は運用設計を作り直す |
| MERGE | WHEN NOT MATCHED BY SOURCE 対応 | WHEN NOT MATCHED BY SOURCE 対応 | DELETE句の書き方と挙動差で個別テストが必要 |
| 配列インデックス | 範囲外は NULL | 範囲外はエラー、SAFE_OFFSET で回避 | 既存クエリに SAFE_OFFSET への置換が必要 |
| SESSION_USER | ユーザー名 | メールアドレス | 権限比較ロジックは修正必須 |
| データ型 | TIMESTAMP_NTZ / TZ / LTZ | DATETIME / TIMESTAMP | タイムゾーン仕様の差でずれが出る |
| 数値精度 | NUMBER(38,37) まで | NUMERIC(38,9) / BIGNUMERIC | 高精度小数の丸めルールに注意 |
方言差の変換は、Google CloudのBatch SQL Translatorで自動処理できる部分と、手作業が必要な部分に分かれます。VARIANT→JSONやSAFE_OFFSETの機械的な置換は自動化が効きますが、Time Travelのように設計思想そのものが違う項目は人間の判断が必要です。
実務では、既存Snowflakeのクエリログを1週間ぶんエクスポートして、実際に走っているSQLの上位80%をBatch SQL Translatorに投げるところから始めます。この段階で「自動変換で通ったもの／手直しが必要なもの／設計変更が必要なもの」の3層に分類できると、以降の見積もりが一気に精度を上げます。
Snowflake→BigQuery移行の費用は、規模とSnowflake固有機能の依存度で大きく変わります。日本国内での実務相場を、標準的な10TB規模のケースで並べます。
初期プロジェクト費（一度きり）
| 費目 | 相場 | 補足 |
|---|---|---|
| 対象棚卸し・SQL方言差分抽出 | 200万〜400万円 | 既存Snowflakeのクエリログ調査、方言差の分類、Time Travel等の代替設計 |
| データ移行パイプライン構築 | 300万〜700万円 | BigQuery Data Transfer Service設定、COPY INTO方式との使い分け実装 |
| SQLクエリ・dbtモデル移植 | 300万〜800万円 | ダッシュボード用SQL、集計モデル、UDF、ストアドプロシージャの書き換え |
| 品質検証・並行運用 | 200万〜400万円 | 数字合わせ、業務部門との突合、切替リハーサル |
| プロジェクト管理・ドキュメント | 200万〜300万円 | 3〜4ヶ月間のPM工数、運用引き継ぎ資料 |
| 初期合計 | 1,200万〜2,500万円 | 10TB・数百テーブル前後の標準ケース。100TB超なら6,000万円+ |
移行後の月額運用費
| 費目 | 相場 | 補足 |
|---|---|---|
| BigQuery利用料（クエリ・ストレージ） | 10万〜40万円 | On-demand $6.25/TiBスキャン、Editionsは$0.04/slot-hour〜 |
| データ連携ツール（利用時） | 3万〜15万円 | trocco・Fivetranを併用する場合 |
| パイプライン運用保守 | 5万〜20万円 | 月次レビュー、追加テーブル対応、障害対応 |
| 月額合計 | 月20万〜60万円 | 3年運用で総額700万〜2,200万円のオーダー |
なお上記のレンジは、Evastで支援した案件の実績と国内SIer相場観からの目安です。要件次第で上下しますので、具体的な見積もりは対象棚卸しの後に確定させるのが現実的です。
費用の内訳を見ると、初期の「SQLクエリ・dbtモデル移植」が総額の3割前後を占めるのが特徴です。Snowflake側で夜間バッチや複雑な集計をSQLで書き溜めてきた企業ほど、この費目が跳ねます。事前に「業務で使っているのは上位2割のSQL」に絞り込む棚卸しをしておくと、初期費用を数百万円単位で削れます。
BigQuery側のコスト最適化の詳細はBigQueryのコスト最適化｜料金体系と実務テクニック、両DWHの料金比較はクラウドデータウェアハウス比較｜BigQuery・Snowflake・Redshiftの費用と選び方【2026年版】にまとめています。
標準工程（3〜4ヶ月）
| フェーズ | 期間 | 主なアウトプット |
|---|---|---|
| 対象棚卸し・方言差分抽出 | 3〜4週間 | 移行対象テーブル・SQL一覧、方言差分の3層分類、Time Travel代替設計 |
| 環境準備・スキーマ移行 | 2〜3週間 | BigQuery環境、Data Transfer Service設定、テーブルスキーマ移行 |
| データ移行・SQL移植 | 4〜6週間 | 全テーブルの初期投入、dbtモデル・BIクエリの書き換え |
| 並行運用・数字突合 | 3〜4週間 | Snowflake／BigQuery両方に流し、業務部門と数字を突合 |
| 切替・Snowflake停止 | 1〜2週間 | 分析用途をBigQueryに切替、Snowflake契約の縮小・停止手続き |
基幹DBからのオンプレ移行と比べて、DWH同士でスキーマ互換性が高いぶん、工程が全体で1〜2ヶ月短くなります。ただし「動く」ように見えて数字がずれる、というDWH間移行特有の落とし穴があるため、並行運用の期間は圧縮しないほうが安全です。
Snowflake→BigQueryは「安くなるから」だけで判断すると、移行後にかえって使いにくくなる例があります。実務の判断基準を並べます。
移行が向くケース
移行に踏みとどまるべきケース
判断で難しいのは、上のリストで「向く／踏みとどまる」の両方に当てはまるハイブリッド構成です。この場合は、まず新規のダッシュボード用途からBigQueryに寄せ、既存のSnowflake資産は残す共存構成で1年運用し、コスト差と学習曲線を実データで確認してから完全移行を判断する順序が現実的です。
BigQueryそのものの機能理解はBigQueryとは？できること・料金・他DWHとの違いをわかりやすく解説、Snowflake側の機能整理はSnowflakeとは？クラウドDWHの特徴と導入メリットを解説を参考にしてください。
Snowflake→BigQuery移行で、実際に起きる失敗パターンを整理します。発注前に自社で1つずつ確認しておくと、初期投資の塩漬けを避けられます。
1つ目：Snowflake感覚のスキャン量でBigQueryを回す。SnowflakeはVWの稼働時間課金なので、SELECT * を投げてもコストが体感で見えません。同じ感覚でBigQueryのOn-demandを使うと、$6.25/TiBスキャン課金がまともに乗り、月額が想定の3〜5倍になります。移行と同時に、パーティション設計とクラスタリング設計を組み直す前提で見積もる必要があります。
2つ目：On-demandを継続選択してEditionsへの切替を検討しない。中〜大規模ワークロードでOn-demandを回し続けると、Snowflake時代より高くつくケースがあります。3ヶ月ぶんの実データが溜まった時点で、必ずEditions＋スロット予約への切替シミュレーションを行ってください。
3つ目：SQL方言差の検証を1週間で切り上げる。既存クエリを全件Batch SQL Translatorに通して「変換率9割」の数字を見て安心すると、残りの1割で本番ダッシュボードが落ちます。方言差の検証は、上位80%のクエリを人間が目視で追う工程を必ず挟むのが安全策です。
4つ目：Time Travelの利用パターンを移行前に洗い出さない。Snowflake側で監査・障害調査に90日のTime Travelを使っていた場合、BigQueryの7日制限に切り替わった瞬間に業務が回らなくなります。移行前にテーブルスナップショットの自動化設計を組み込んでおいてください。
5つ目：並行運用を2週間で切り上げる。「早くSnowflake契約を止めたい」の判断で並行運用を短くすると、切替後に業務部門から数字違いの指摘が出て信頼を失います。DWH同士でスキーマ互換性が高いぶん「動く」ように見える罠があるので、最低1ヶ月、理想は2ヶ月の並行運用を確保してください。
6つ目：Snowflakeのdbtモデル資産を全部書き直す。Snowflake向けに書かれたdbtモデルは、ref()とプロファイル設定の変更で大半がそのまま動きます。全部ゼロから書き直す前提で見積もると、300万円単位で工数が膨らみます。方言差が出る部分だけをピンポイントで直す進め方が実務的です。
移行プロジェクト特有ではない、データ基盤構築全般の失敗パターンはデータ基盤構築でよくある失敗と発注前チェックリスト、基幹DBからのオンプレ移行の観点は基幹DB→BigQuery移行の費用と手順｜Oracle・SQL Server【2026年版】にまとめています。
Snowflake→BigQueryの移行は、いきなり全ワークロードを一括で切り替えるより、既存Snowflakeのクエリログ棚卸しから始めて、上位2割の実利用SQLに絞り込んでから設計する順序が、総額と定着率の両面で有利です。10TB規模で1,200万〜2,500万円の初期投資、月20万〜60万円の運用費というレンジに収まれば、3年で移行TCOを吸収できる規模の月額差が出るケースが多くあります。
Evastでは、Snowflakeのクエリログ棚卸しからBigQuery Data Transfer Serviceでの並行稼働、SQL方言差の移植、切替リハーサルまで、Snowflake→BigQuery移行を一気通貫で支援しています。現在のSnowflake月額とテーブル数、主要ダッシュボードの本数を伺えれば、初期プロジェクト費と3〜4ヶ月の工程の初稿、切替後の月額試算までは無料でお出しできます。「そもそもうちのSnowflake構成が移行に向いているのか」の壁打ちからでも構いません。
データ基盤DWH（データウェアハウス）の料金を、クエリ・ストレージ・付随コストの3要素に分解して整理します。BigQuery・Snowflake・Redshiftの2026年時点の主要単価、小・中・大規模の月額試算シミュレーション、DWH本体だけでは足りない全体費用の見積もり、実績が想定を30〜50%上回る典型3パターン、発注前にベンダーへ確認したいチェックリストまで、費用の全体像を意思決定できる形でまとめました。
データ基盤モダンデータスタックは2026年も主流だが、Fivetran＋Snowflake＋dbt＋Lookerのフル構成は月146万円超の重装備。中堅の現実解はBigQuery＋TROCCO＋dbt Coreで月20〜80万円に収まる。5層構成・費用差・Agentic Data Stackへの移行を実装現場から整理。
データ基盤クラウドDWHはBigQuery・Snowflake・Redshiftで課金モデルが違い、同じ処理でも月額が2〜3倍ぶれます。3社の料金体系と月額シミュレーション（100GB/1TB/10TB）、ワークロード別の噛み合わせと選び方を発注担当目線で整理。
