「AWS上のRedshiftが月150万近く出ていて、GCP側に寄せてBigQueryに移せば下がるのか」。そんな相談を月に何件かいただきます。
DWHからDWHへの移行は、基幹DBからの移行と違ってテーブル構造はほぼ写せます。ただし、Redshift固有のDISTKEY・SORTKEY・SUPER型・Spectrum・Materialized Viewに合わせて組んできた設計が、丸ごと乗り換え対象になります。SQL方言差も「ほぼ同じ」のはずが、本番切替の直前で数十本のクエリが落ちる、という話は珍しくありません。移行判断で最初に必要なのは、今のRedshiftで何をやっているかの棚卸しです。
そこで本記事では、Amazon RedshiftからBigQueryへの移行費用と工程、SQL方言差、判断基準、失敗パターンを、稟議とベンダー選定にそのまま使える形で整理しました。Redshiftそのものの料金体系はすでにAmazon Redshiftとは？料金体系と費用相場を解説で扱っているので、こちらは「移行するか・どう移すか」の実務判断に軸足を置いています。
2024年ごろまでは、日本国内でRedshiftからBigQueryへ乗り換える相談は限定的でした。2026年に入って相談量が増えており、背景には3つの要因があります。
1つ目は Redshift Serverless移行後のコスト予測しにくさ疲れ です。プロビジョンドのRA3から新しいServerlessに切り替えた企業で、ワークロードのピークが読めずRPU課金が想定の1.5〜2倍に跳ねる事例が出ています。BigQueryのEditions＋スロット予約は月額を固定でき、CFO稟議で「上限が読める」ことが強い動機になっています。
2つ目は GA4・広告データ・Vertex AIとの直結メリット です。マーケティング側でGA4のBigQueryエクスポートを標準機能で使い、広告データはAds Data Hubから直接BigQueryに入り、機械学習はVertex AI／BigQuery MLで完結する構成がGoogle Cloud側で年々厚くなっています。データの入口と出口がGCPに寄っている企業ほど、RedshiftをETLで挟む合理性が薄れてきています。
3つ目は 移行ツールの成熟 です。BigQuery Data Transfer ServiceのAmazon Redshiftコネクタは公式GAで、増分転送・自動スキーマ検出・VPCピアリング経由の閉域接続まで公式サポートされています（Google Cloud公式ドキュメント）。加えてBatch SQL Translatorが方言変換を自動化するようになり、以前は数百万円かかった移行工数の下地が数十万円レンジまで下がっています。
RedshiftからBigQueryへデータを流す方法は、大きく3つに分けられます。「どれか1つ」ではなく、テーブル特性ごとに割り当てる視点が実務的です。
1つ目：BigQuery Data Transfer Service（Redshiftコネクタ）。本命の方式です。GUI設定でスケジュール転送を組み、増分転送、自動スキーマ検出、VPCピアリング経由の閉域接続まで公式サポートされます。内部ではUNLOAD → S3 → GCSの経路を自動で組んでくれるので、初期構築が短く、大半のテーブル移行はこの方式でカバーできます。
2つ目：Redshift UNLOAD → S3 → Cloud Storage → BigQuery LOAD。一括ダンプ用途で有効な方式です。数十TBを一発で移す初期移行や、履歴データのアーカイブ移行で使います。ParquetまたはCSVで出力し、Storage Transfer ServiceでGCSに寄せてからLOADするのが定石で、実装がシンプルで運用コストが安い一方、CDC（変更データキャプチャ）は自作になるため、初期移行後の継続同期には向きません。
3つ目：TROCCO・Fivetran・Airbyte等のELTツール経由。複雑なソースが混在する場合や、Redshiftと同時に他のSaaS（Salesforce、kintone、広告APIなど）もBigQueryに移す場合に選択肢に入ります。ツール選定はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較を参考にしてください。
判断の基本は、Redshiftを完全に置き換える計画なら1つ目のBigQuery Data Transfer Serviceを本命に、初期の一括移行だけ2つ目のUNLOAD方式を組み合わせるのが効率的です。3つ目のELTツールは、RedshiftとBigQueryの並行運用期間を短くしたい場合や、他のSaaS連携も同じツールでまとめたい場合に有利になります。
RedshiftとBigQueryはどちらもANSI SQLベースですが、細かな方言差があります。ここを見落とすと、並行運用開始時に「クエリの2〜3割が動かない」状態に陥ります。代表的な差分を並べます。
| 分類 | Redshift | BigQuery | 対応方針 |
|---|---|---|---|
| 半構造化型 | SUPER型 + PartiQL（data.field） | JSON型 or STRUCT型（JSON_VALUE(data, "$.field")） | 動的スキーマはJSON、固定スキーマはSTRUCTに寄せる。既存クエリは書き直し |
| 分散/ソート | DISTKEY / SORTKEY | PARTITION BY / CLUSTER BY | 日付キーはパーティション、結合キーはクラスタリングに変換 |
| タイムスタンプ | TIMESTAMPTZ（マイクロ秒） | TIMESTAMP（マイクロ秒、UTC固定） | セッションのタイムゾーンではなくUTC前提で書き直す |
| 文字列連結 | パイプ2つ（||）演算子 | CONCAT() 関数（パイプ2つ非対応） | 正規表現置換で一括変換 |
| DATE_TRUNC | date_trunc('month', col) | DATE_TRUNC(col, MONTH) | 引数順が逆。単位は文字列 → 定数 |
| 配列展開 | 独自関数（super配列＋PartiQL） | UNNEST() | 集計クエリはほぼ全てテスト対象 |
| Materialized View | 自動更新（AUTO REFRESH） | Materialized View（一部制約あり） | 集計クエリの複雑度によっては通常テーブル＋スケジュールに再設計 |
| ストアド/UDF | PL/pgSQL・Python UDF | JavaScript UDF・Remote Functions（Cloud Functions） | 移植コストが高い箇所。dbtやscheduled queryに寄せられないか先に検討 |
Batch SQL Translator（BigQuery公式）を使うと、上記のうち構文レベルで機械変換できる項目は自動で書き換わります。SUPER型のパス表現やストアドプロシージャなどセマンティクス寄りの差分は手作業になるため、対象クエリのうち何割が自動変換で済むかを事前に見積もっておくと工程が読みやすくなります。
規模別の目安を並べます。実際の見積りは対象テーブル数・SUPER型やストアドの依存度・並行運用の長さ・エグレス転送量で変動します。
| 規模 | 初期プロジェクト費用 | 期間 | 月額運用費（切替後） |
|---|---|---|---|
| 小規模（1TB・数十テーブル） | 300万〜700万円 | 1〜2ヶ月 | 月5万〜20万円 |
| 標準（10TB・数百テーブル） | 1,000万〜2,000万円 | 3〜4ヶ月 | 月20万〜60万円 |
| 大規模（100TB・複雑ETL構成） | 3,500万〜6,000万円 | 6〜9ヶ月 | 月80万〜200万円 |
内訳の目安（10TB標準ケース）:
工程は4フェーズに分かれます。
「AWS上のRedshiftから乗り換えたい」という要望があっても、全ケースで移行が正解になるわけではありません。判断基準を分けて並べます。
移行を進めやすいケース:
踏みとどまるべきケース:
判断に迷う場合、まずはRedshiftワークロードの棚卸しとBigQuery側での費用シミュレーションを1〜2週間で実施し、投資回収の見込みを月額差分で数字にしてから稟議に上げるのが実務的です。
移行プロジェクトで実際によく詰まる論点を列挙します。ベンダー選定と稟議の前にこの粒度で決めておくと、後戻りが少なくなります。
発注前に決めておく5項目:
現場でよく見る失敗パターン:
Redshift → BigQueryの移行は、DWH同士でスキーマ互換性が高いぶん「動く」ように見えて、SUPER型・DISTKEY・タイムスタンプ処理といったRedshift固有設計への依存度で、実際の工数が大きく振れます。
初手は Redshiftワークロードの棚卸し と BigQuery側の費用シミュレーション です。これを1〜2週間で終わらせ、投資回収の見込みを月額差分で数字にしてから稟議に上げるのが、意思決定の遠回りを避ける近道になります。
DWH同士の別方向（SnowflakeからBigQuery）を検討している場合は、SnowflakeからBigQueryへの移行手順と費用｜SQL方言差と失敗パターン【2026年版】で同じフレームで整理しています。Redshiftそのものの料金構造はAmazon Redshiftとは？料金体系と費用相場を解説を参照してください。
株式会社Evastでは、Redshift→BigQueryの棚卸しから移行計画策定、Data Transfer Serviceの構築、SQL書き換え、並行運用、切替までを一貫して支援しています。
このようなお悩みがあれば、お気軽にご相談ください。棚卸しと費用シミュレーションから、切替後の運用最適化まで伴走します。
データ基盤BigQueryのパーティションとクラスタリングは、設定手順は簡単でも「どの列を選ぶか」の判断ミスで数十倍のスキャン量になり、月次の請求書ショックを招きます。パーティション3種の使い分け、クラスタリング列の選び方、現場でよくある設計ミス5つ、既存テーブルへの後付け手順、require_partition_filterでの事故防止まで、スキャン量を9割減らすためのテーブル設計の型を整理した2026年版です。
データ基盤DWH（データウェアハウス）の料金を、クエリ・ストレージ・付随コストの3要素に分解して整理します。BigQuery・Snowflake・Redshiftの2026年時点の主要単価、小・中・大規模の月額試算シミュレーション、DWH本体だけでは足りない全体費用の見積もり、実績が想定を30〜50%上回る典型3パターン、発注前にベンダーへ確認したいチェックリストまで、費用の全体像を意思決定できる形でまとめました。
データ基盤クラウドDWHはBigQuery・Snowflake・Redshiftで課金モデルが違い、同じ処理でも月額が2〜3倍ぶれます。3社の料金体系と月額シミュレーション（100GB/1TB/10TB）、ワークロード別の噛み合わせと選び方を発注担当目線で整理。
