基幹DB→BigQuery移行の費用と手順｜Oracle・SQL Server【2026年版】

「Oracleで20年動いている基幹DBを、そろそろBigQueryに寄せたい。ただ費用と工程がまったく読めない」。そんな相談を月に何件かいただきます。

基幹システムからDWHへの移行は、単なるデータのコピーではありません。テーブル数百本のうち分析で本当に使うのは一部で、その一部にビジネスロジックがビュー・ストアドプロシージャ・夜間バッチジョブとして分散して埋め込まれています。どこまで移せば分析が回るか、どこは基幹DB側に残すか、この線引きから始めないと、見積もりの前提が揃いません。

そこで本記事では、OracleやSQL Serverなどのオンプレ基幹DBを BigQuery に移行する際の、費用と工程の相場を、稟議とベンダー選定にそのまま使える形で整理しました。BigQueryそのものの費用構造はすでにBigQuery導入ガイド｜手順・料金・無料枠・費用相場【2026年版】で扱っているので、こちらは基幹DBからの移行に固有の判断と、落とし穴の避け方に軸足を置いています。

なぜ基幹DB→BigQuery の見積もりは幅が大きくなるのか

同じ「オンプレDBをBigQueryへ」という発注でも、見積もりが数百万円から数千万円まで開くことがあります。ベンダーが手を抜いているのではなく、前提が違うので幅が広がっているのが実情です。

見積もりを動かす要因は、大きく3つに整理できます。

1つ目は 対象テーブルとロジックの範囲 です。基幹DBには数百本のテーブルがあっても、経営会議のダッシュボードで使うのは20〜30本、業務レポートで使うのを合わせても100本以下、というケースが多くあります。ここで「全部移す」と「使う分だけ移す」では、工数が3〜5倍動きます。さらに、テーブルの中には SELECT 用のビューや、夜間バッチで作られる集計テーブルが含まれ、これを再現するには元のSQL・ストアド・バッチジョブを読み解いてBigQuery側（例えばdbtで）に書き直す必要があります。この「ロジック移植」がプロジェクトのコストのかなりの部分を占めます。

2つ目は 連携方式の選択 です。日次で回すバッチ連携なら、既存の夜間ジョブと同じサイクルに合わせてスケジュール実行するだけで済み、費用も抑えられます。一方、業務担当者が「在庫や受注をほぼリアルタイムに追いたい」と要望を出すと、CDC（変更データキャプチャ、Datastream 等）を組む必要があり、初期構築費と運用費の両方が跳ねます。この判断を要件定義でしないまま「とりあえずリアルタイム」と決めると、費用が想定の2倍以上になることがあります。

3つ目は 並行運用と切替の設計 です。基幹DBは止められないので、移行後もしばらくは既存DBとBigQueryの両方に同じデータが流れる並行運用期間を設けます。この期間を1ヶ月で切り上げるのか、3ヶ月かけて数字を突合するのか、切替後の既存DBはいつ止めるのか、で運用費と検証工数が変わります。並行運用の設計は見積もり書ではあまり表に出てこない部分ですが、実際の総費用に大きく効きます。

「移行費用が知りたい」という段階では、この3点の前提を先に決めてしまうのが、見積もりの精度を上げる近道です。ベンダーに一気に見積依頼を投げる前に、社内で「どこまで移すか」「どのくらいの鮮度が要るか」「並行期間はどれくらい取れるか」の粗いラインを決めておくと、比較可能な見積もりが返ってきます。

移行対象データベースの3タイプと難易度

基幹DBといっても、対象システムの種類によって移行の難しさが変わります。代表的な3タイプを整理します。

もっとも多いのが1行目の商用RDB（OracleとSQL Server）です。Google Cloud には SQL Server 用の BigQuery Data Transfer Service や、Oracle からの CDC を扱う Datastream など、公式に用意された連携経路があります。ツール的な難易度は高くありません。ただし、Oracle特有の PL/SQL で書かれた業務ロジックや、SQL Server のビュー・SSISパッケージに埋め込まれた集計処理は、そのままBigQueryでは動きません。ここを dbt などのモダンな変換基盤に書き直す作業が、実際の工数の中心になります。

2行目のOSS系（PostgreSQL / MySQL）は、Datastreamの標準サポート対象で、連携そのものは短期間で立ち上がります。癖が少ないぶん、費用も抑えやすい部類です。ただし、テーブル数が数百本規模になれば、対象を絞る作業や品質検証の工数は商用RDBと同じくらい発生します。

3行目のメインフレームや独自DBは、直接連携できるSaaSが限られます。多くの場合、いったんファイルエクスポート（CSVや固定長）を Cloud Storage に置き、そこから BigQuery に取り込む中継設計が必要になります。文字コード変換（Shift_JIS→UTF-8）や桁数の丸めなど、地味だが手戻りが多い工程が挟まるため、他のタイプより1.5〜2倍の期間を見込みます。老朽化した独自DBが対象の場合は、移行ではなく「刻んで抜き出す」実装になることも珍しくありません。

自社のDBがどれに当たるかを最初に確認し、それに応じたベンダーの実績を見ておくと、選定の失敗が減ります。特に3タイプ目のメインフレーム移行実績は、ベンダーによって大きな差があります。

3つの連携方式：一括バッチ・スケジュールバッチ・CDC

基幹DBからBigQueryへデータを流す方式は、大きく3つに分けられます。「どれを選ぶか」ではなく「テーブルごとにどれを割り当てるか」の視点が実務的です。

一括バッチ（フルロード） は、対象テーブルを丸ごとエクスポートして、BigQuery側で毎回テーブルを置き換える方式です。マスタ系（商品マスタ、取引先マスタ、社員マスタなど）で、日次に一度上書きすれば足りるテーブルに向いています。実装がもっともシンプルで、費用も安く済みます。数百MB〜数GBのマスタなら、毎日フルロードしても大きな問題は起きません。

スケジュールバッチ（差分連携） は、前回連携以降に更新されたレコードだけをBigQueryに追記する方式です。トランザクション系（受注、売上、在庫移動など）で、レコード数が多く毎回フルロードすると転送量が跳ねるテーブルに向いています。更新日時カラムやシーケンスIDを使って差分を抽出するのが定番で、troccoやEmbulk、Airflow経由のカスタム実装で扱います。ツール選定はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較を参考にしてください。

CDC（Change Data Capture、Datastream等） は、DBのトランザクションログを読み取って、変更をほぼリアルタイムでBigQueryに反映する方式です。「在庫を分単位で追いたい」「業務データが更新された瞬間にダッシュボードに出したい」ケースで真価を発揮します。Google CloudのDatastreamがOracle・PostgreSQL・MySQL・SQL Serverに公式対応しており、構成は比較的シンプルです。

ただしCDCには費用面の落とし穴があります。Datastreamの料金は変更データ量に対する従量課金なので、更新頻度が高いテーブルを全て対象にすると、月額が想定の数倍に膨らむことがあります。実際の現場でも、更新頻度の高いログ系テーブルをCDC対象から外しただけで、月額を予算内に戻せた例があります。CDCを組む場合は、対象テーブルを「行数」ではなく「更新頻度×行数」で評価して絞ることが必須です。

3方式の使い分けの目安は次の通りです。

「全テーブル一律にCDC」ではなく、「マスタは一括、トランザクションは差分、要リアルタイムだけCDC」のハイブリッドが、費用対効果としては最適解です。CDCとバッチの概念的な違いを詳しく知りたい場合はデータパイプラインとは？ETLとの違いと仕組みを図解で解説を参考にしてください。

費用の内訳と相場：初期・月額・移行専用工数

基幹DBからBigQueryへの移行費用は、大きく「初期プロジェクト費」と「移行後の月額運用費」に分かれます。それぞれの相場を並べます。

初期プロジェクト費（一度きり）

移行後の月額運用費

数字を見ると、初期のプロジェクト費が総額のかなりを占めることが分かります。この構造上、「まず対象を絞って初期を軽くする」が費用を抑えるいちばん効く判断です。全テーブル移行ではなく「経営会議で毎月見ている数字を作るテーブルだけ」に絞れば、初期を300万〜500万円台に収めることも可能で、成果を出してから次のフェーズで対象を広げるほうが総額も安くなります。

費用全体の設計思想と、稟議に使う投資対効果の組み立て方はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説、期間・工程の詳細はデータ基盤構築の期間はどのくらい？規模別・工程別スケジュールの目安にまとめています。BigQuery自体のランニングコスト最適化はBigQueryの料金を最適化する12の実務テクニックを参考にしてください。

標準的な移行プロジェクトの工程（3〜6ヶ月）

対象10〜30テーブル・数百GB規模の標準的な移行を想定した、3〜6ヶ月の工程を並べます。ここが読めていないベンダーからの見積もりは、要注意です。

工程で見落とされがちなのが、データ検証と並行運用の合計で2〜3ヶ月を確保する点です。この期間を圧縮すると、切替後に業務部門から「先月と数字が違う」という指摘が出て、原因調査に追われる展開になります。並行運用中に一度でも数字が合わないと、その後の信頼回復に想像以上の工数がかかるため、最初から余裕を持って設計するほうが結局は速いです。

移行プロジェクトも、いきなり本番投入せず段階的に価値を確認するのが定石です。PoCの進め方はデータ基盤PoCの進め方｜5ステップ・成功基準・費用相場【2026年版】にまとめています。

よくある落とし穴と発注前チェックリスト

基幹DB→BigQueryの移行で、実際に起きる失敗パターンを整理します。発注前に自社に当てはまるものが無いか、確認しておくと初期投資が塩漬けになるリスクを下げられます。

1つ目：全テーブル一括移行を狙う。基幹DBに数百本テーブルがあると「せっかくならまとめて」と考えがちですが、分析で使わないテーブルまで対象にすると工数と費用が数倍になります。まず「経営ダッシュボードで使う数字を作る20〜30テーブル」に絞り、成果を出してから広げる順序が、総額でも定着でも有利です。

2つ目：ビジネスロジック移植の工数を見落とす。テーブル移行だけを見積もると安く見えますが、実際には夜間バッチやストアドプロシージャで作られている集計テーブルの再現に、パイプライン構築と同じくらいの工数がかかります。要件定義の段階で「BigQuery側でどの集計を再現するか」を確定させないと、後で数百万円の追加見積もりが発生します。

3つ目：全部CDCで組んでしまう。「せっかく移行するならリアルタイムに」の判断は、月額を数倍にする最大の要因です。業務側の要求鮮度を必ずヒアリングし、日次で十分なテーブルはバッチに割り当てる設計が費用対効果としては最適解です。

4つ目：文字コード・タイムゾーンの検証を後回しにする。Shift_JISで長年運用されてきたDBをUTF-8のBigQueryに移すと、絵文字や環境依存文字で文字化けが発生します。タイムゾーンも、JSTのままCSV出力するか、UTCで揃えるかを最初に決めないと、集計結果がずれます。この工程は要件定義とパイプライン構築の間に必ず挟むべきです。

5つ目：並行運用期間を1ヶ月未満に圧縮する。「早く既存DBを止めたい」という要望はよく出ますが、並行運用を短くすると、切替後に業務部門から数字違いの指摘が出て信頼を失います。最低1ヶ月、理想は2〜3ヶ月の並行運用を確保する設計にしてください。

6つ目：業務側のオーナーを立てないまま情シスだけで進める。移行後のダッシュボードを実際に見るのは業務部門です。数字の意味と用途を業務側と合意しないまま進めると、切替後に「使わないダッシュボードが並ぶ」状態になります。プロジェクト開始時点で、経理・営業・製造など主要部門から1名ずつオーナーを立てるほうが定着します。

移行プロジェクト特有ではない、データ基盤構築全般の失敗パターンはデータ基盤構築でよくある失敗と発注前チェックリストにまとめています。既存のExcel運用からBigQueryへ移す観点はExcel運用からデータ基盤へ移行する判断基準と費用感を参考にしてください。

内製と外注の分担：どこを外に、どこを内に

基幹DB移行はプロジェクト規模が大きく、社内リソースだけでは通常回りません。一方で、全部外注し続けると運用の自走力が育たず、追加開発のたびに費用がかさみます。実務的な分担の目安を並べます。

• 要件定義・対象範囲の合意（0〜1ヶ月）は社内主導＋外部支援：業務部門との合意形成は社内でしかできない。外部はテンプレートと過去事例を提供する役割
• パイプライン構築・ロジック移植（1〜4ヶ月）は外注寄り：Datastream/dbtの実装スキルは専門性が高く、社内で内製化を試みると学習コストで工数が倍以上になる
• データ検証・並行運用（4〜6ヶ月）は社内主導＋外部支援：数字の突合は業務部門にしかできない。外部は差異の原因追跡を手伝う
• 切替後の日常運用（6ヶ月〜）は内製寄り：BIツールでの集計追加、簡単なSQL修正は社内で回す。中規模の改修は都度外注に戻す変動費に

この分担の勘どころは、外注が入っている期間中に、社内担当者がSQL・BigQuery・dbtの基礎を触れる状態に上げておくことです。ここが抜けると、外注が終わった瞬間に「誰も触れないデータ基盤」になり、追加費用が青天井になります。

内製と外注の詳しい判断基準はデータ基盤は内製と外注どっち？判断基準とハイブリッドの進め方、公開後の運用体制の設計はデータ基盤の運用・保守｜体制と工数、コスト削減の実務にまとめています。

まずは対象棚卸しから始める

基幹DB→BigQueryの移行は、いきなり全社統合を狙うより、経営会議で見ている20〜30テーブルに絞って半年で成果を出すほうが、総額も定着率も良くなります。500万〜1,500万円の初期投資で、以降は月10万〜50万円のレンジで運用できる規模なので、稟議のハードルも投資対効果で説明可能な水準です。

Evastでは、OracleやSQL ServerからBigQueryへの移行プロジェクトを、対象棚卸しから並行運用まで一気通貫で支援しています。既存DBのテーブル数と対象システムを伺えれば、初期プロジェクト費と月額のオーダー感、3〜6ヶ月の工程の初稿までは無料でお出しできます。「そもそもうちの基幹DBが移行に向いているのか」の壁打ちからでも構いません。

→ データ基盤構築サービスを見る → 無料相談を申し込む