dbtで何が変わる？データ変換を管理する仕組みと導入の判断

dbtは、データウェアハウスに取り込んだデータを、SQLで分析しやすい形に整える「変換」の処理を管理するためのツールです。BigQueryやSnowflakeなどにデータを集めたものの、集計用のSQLが担当者のPCや管理画面のあちこちに散らばり、誰がどの数字をどう作っているのか分からなくなっている。dbtはこうした状態を立て直すためによく使われます。

dbtで何が変わるのかを一言で言えば、変換のSQLを「プログラムのソースコードと同じように」管理できるようになることです。処理の順番の自動解決、データのテスト、ドキュメントの自動生成、変更履歴の管理といった、ソフトウェア開発では当たり前の仕組みを、データの変換に持ち込めます。

一方で、dbtはデータを取り込む道具でも、グラフを描く道具でもありません。また、2025年から2026年にかけてdbtのクラウド版の名称や配布形態、ライセンスが変わっており、数年前の解説記事の説明がそのまま当てはまらない部分もあります。

この記事では、dbtがデータ基盤のどこを担うのか、導入で何が変わるのか、OSS版とクラウド版の違いと料金、導入すべきかどうかの判断基準、進め方の注意点を、発注側・導入を検討する側の目線で整理します。

dbtが担うのはELTの「T」の管理

データ基盤の処理は、元のシステムからデータを取り出す（Extract）、データウェアハウスに読み込む（Load）、分析しやすい形に変換する（Transform）の3つに分けられます。読み込んでから基盤の中で変換するELTの構成では、dbtはこのうち「T」の部分、つまりデータウェアハウスの中で行う変換を担当します。

dbtの基本的な単位は「モデル」と呼ばれるSQLファイルです。1つのモデルには1つのSELECT文を書き、dbtがそれをデータウェアハウス上のテーブルやビューとして作成します。CREATE TABLEなどの定義文や、作り直しの手順はdbtが代わりに組み立てるため、書き手は「どんなデータを作りたいか」というSELECT文に集中できます。

dbtが担わない部分も押さえておく必要があります。

処理	dbtの役割	別に用意するもの
元のシステムからの取り出しと読み込み	担わない	データ連携ツール、クラウド事業者の転送サービス、個別開発の取り込み処理
データウェアハウス内での変換	担う（モデル・テスト・ドキュメント）	実行先のデータウェアハウス
定期実行と失敗時の通知	OSS版だけでは別途用意が必要。クラウド版には機能がある	ジョブ管理の仕組み（OSS版の場合）
グラフやダッシュボードの表示	担わない	BIツール

変換の計算自体は、dbtではなくデータウェアハウスが行います。dbtはSQLを組み立てて送るだけなので、変換に使った処理量に応じたデータウェアハウスの料金は、dbtを使っても使わなくても発生します。dbtの導入費用を考えるときは、この点を混同しないようにしてください。

dbtを入れると変換の管理で何が変わるか

dbtを使わずに変換を組む場合、データウェアハウスの「スケジュールされたクエリ」機能や、BIツールの中の計算式、手作業で実行するSQLファイルなどを組み合わせることが多くなります。小さいうちはこれで回りますが、集計が数十本に増えると、次のような問題が出てきます。

• あるテーブルを直したとき、それを参照している集計がどれか分からない
• 処理の実行順を人が覚えていて、順番を間違えると古いデータで集計される
• 重複や欠損があっても、会議資料に載るまで誰も気づかない
• 指標の定義が文書に残っておらず、担当者が辞めると説明できなくなる

dbtはこれらに、それぞれ仕組みで対応します。

困りごと	dbtでの対応
依存関係と実行順が分からない	モデルの中で他のモデルをref関数で参照すると、dbtが依存関係を読み取り、正しい順番で実行する。依存関係は図（リネージ）として確認できる
データの異常に気づけない	列ごとにテストを定義できる。標準で用意されているのは、値が重複しない（unique）、空でない（not_null）、決められた値だけが入る（accepted_values）、参照先に存在する（relationships）の4種類。独自の条件はSQLで書ける
定義が文書に残らない	モデルや列の説明をコードと同じ場所に書き、ドキュメントを自動生成できる
作り方の違いを毎回書き分けている	ビュー、テーブル、差分だけを追加する増分テーブルなどの作り方（マテリアライゼーション）を設定で切り替えられる。既定はビュー
誰がいつ何を変えたか分からない	モデルはただのテキストファイルなので、Gitで変更履歴を管理し、レビューを通してから本番に反映できる

このうち効果が大きいのはテストです。たとえば「受注明細の受注番号は重複しない」「顧客コードは顧客マスタに必ず存在する」というテストを置いておけば、取り込み側で二重登録が起きたときや、マスタの登録漏れがあったときに、集計結果が使われる前に検知できます。

逆に言えば、dbtを入れてもテストやドキュメントを書かなければ、SQLの置き場所が変わっただけで終わります。導入の効果は、ツールそのものより「どこまでテストと説明を書く運用にするか」で決まります。

参考：Add data tests to your DAG／dbt Labs

参考：Materializations／dbt Labs

dbtのOSS版とクラウド版の違いと料金

dbtには、自社の環境に入れて使う配布版と、dbt Labsが提供するクラウド版があります。2026年に配布形態が変わったため、名称を整理しておきます。

長く「dbt Core」と呼ばれてきたのは、Pythonで書かれたコマンドラインのツールで、公式ドキュメントでは現在v1と表記されています。ライセンスはApache 2.0で、無料で使えます。2026年6月には、Rustで作り直したエンジンによるv2がアルファ版として公開され、2026年10月時点の公式ドキュメントでは、多くの利用者にv2を使うよう案内されています。v2には、Apache 2.0のオープンソース版（dbt Core 2.0、ドキュメント上はdbt OSS）と、それに独自機能を加えたdbt Labsの製品ライセンスの配布版があり、後者もライセンス上は無料で使えると説明されています。公式ドキュメントは、多くの利用者には後者を勧め、組織の方針で厳密なオープンソースが求められる場合などにOSS版を選ぶよう案内しています。

クラウド版は、以前は「dbt Cloud」と呼ばれていたもので、現在の公式サイトでは「dbt platform」と表記されています。ブラウザ上の開発環境、定期実行のスケジュール、変更時の自動チェック（CI）、ドキュメントの公開、監視と通知などを一つにまとめたサービスです。2026年11月時点の公式料金ページでは、次のプランが案内されています。

プラン	料金（米ドル）	主な内容
Developer	無料	開発者1人、プロジェクト1つ、成功したモデルの作成が月3,000回まで。API連携は使えない
Starter	1人あたり月100ドル	開発者5人分、月15,000回まで。リネージの確認機能、指標を定義するセマンティックレイヤー、APIが使える
Enterprise	個別見積もり	月100,000回まで、プロジェクト30まで。SSOや権限管理、複数プロジェクトの連携など
Enterprise+	個別見積もり	Enterpriseの内容に加え、閉域接続やIP制限など

Starterでは月15,000回を超えた分が従量課金の対象になります。全機能を使える14日間の無料トライアルも用意されています。料金とプランの内容は改定されることがあるため、契約前に公式ページで確認してください。

OSS版とクラウド版のどちらを選ぶかは、ライセンス費より「定期実行と監視を誰が用意するか」で考えると判断しやすくなります。

観点	配布版（OSS版など）	クラウド版（dbt platform）
ツールの費用	無料	人数と実行回数に応じて課金
定期実行・通知	ジョブ管理の仕組みやサーバーを自分で用意する	画面で設定できる
開発環境	各自のPCに環境を作る	ブラウザで開発できる
向いている体制	サーバーやCIを運用できるエンジニアがいる	SQLは書けるが、実行基盤の運用までは手が回らない

なお、対応するデータウェアハウスは、公式ドキュメントでSnowflake、BigQuery、Databricks、Amazon Redshiftなどが一般提供として案内されています。自社の基盤が対象に入っているか、使いたい機能がどの配布版・どのプランで使えるかは、導入前に必ず確認してください。

参考：dbt licensing／dbt Labs

参考：dbt Pricing／dbt Labs

dbtを導入すべきかを判断する基準

dbtは便利なツールですが、どの会社にも必要なわけではありません。変換の本数が少なく、担当者が1人で把握できている段階では、導入と学習の手間のほうが大きくなることがあります。判断の目安は次のとおりです。

状況	判断
集計用のSQLが10本未満で、担当者1人が全体を把握している	急いで入れる必要はない。データウェアハウスの定期実行機能で足りる
集計が数十本に増え、テーブル同士の参照が入り組んできた	導入を検討する時期。依存関係の自動解決とテストの効果が出やすい
複数人で変換を書き、部署によって数字が合わないことがある	導入の効果が大きい。指標の定義をコードと文書で一元化できる
BIツールの中で計算式を組んでいて、ツールごとに数字が違う	計算をデータウェアハウス側に寄せる手段としてdbtが有効
そもそもデータの取り込みが安定していない	先に取り込みを安定させる。dbtは取り込みの問題を解決しない
社内にSQLを読める人が誰もいない	dbtを入れても運用を引き継げない。外部に任せる場合も、少なくともレビューできる人を決める

判断で見落とされやすいのは、最後の項目です。dbtは「SQLを書ける人が、SQLをきちんと管理するための道具」です。SQLを書けない人が使えるようになる道具ではありません。外部の会社に構築を依頼する場合も、納品後に誰がモデルを読み、テストが落ちたときに誰が原因を調べるのかを決めておかないと、立派な仕組みだけが残って誰も触れない状態になります。

また、dbtを入れたからといってデータウェアハウスの費用が下がるわけではありません。増分テーブルを使えば毎回の全件作り直しを避けられるので処理量を減らせますが、すべてをテーブルとして毎日作り直す設定にすると、かえって処理量が増えることもあります。費用を抑えたいなら、どのモデルをどの作り方にするかを設計の段階で決めておく必要があります。

dbt導入の進め方と注意点

dbtを導入するときは、既存の集計をすべて一度に移すのではなく、重要な指標から順に移していくのが安全です。進め方の一例は次のとおりです。

1. 今ある集計SQLとその置き場所、実行のタイミング、使っている人を一覧にする
2. 経営会議で使う売上など、重要で間違いが許されない指標を1〜2個選ぶ
3. 元データを整える層、結合や計算をする層、BIツールが参照する層のようにモデルを分け、命名ルールを決める
4. 選んだ指標をdbtのモデルとして作り直し、既存の集計結果と数字が一致するかを確かめる
5. 主キーの重複、必須項目の欠損、マスタとの不整合のテストを置く
6. 定期実行と失敗時の通知を設定し、旧来の集計を止める
7. 同じ手順で対象の指標を広げる

4番目の「既存の数字と一致するか」の確認は省かないでください。作り直しの過程で、これまで気づかれていなかった集計の誤りが見つかることがあります。その場合はどちらが正しい定義かを業務側と決め、決めた内容をドキュメントに残します。

あわせて、次の点にも注意が必要です。

• テストは最初から網羅しようとせず、主キーの重複と必須項目の欠損から始める。テストが多すぎて落ち続けると、誰も見なくなる
• テストが失敗したときに、処理を止めるのか、警告だけにするのかをモデルごとに決めておく
• 個人情報を含む列を、どの層まで持ち込むかを決める。dbtのモデルとして作ったテーブルにも、元データと同じ権限管理が必要になる
• v1とv2では動作に違いがあるため、既存のプロジェクトを移行する場合は、公式の移行手順に沿って検証してから切り替える
• モデルが増えると実行時間とデータウェアハウスの費用が伸びるため、月に一度は実行時間の長いモデルを確認する

外部に依頼する場合は、成果物としてdbtのプロジェクト一式（モデル、テスト、ドキュメント）がGitのリポジトリで納品されること、命名ルールと層の分け方の説明があること、テストが失敗したときの確認手順があることを確認しておくと、納品後に自社で運用を続けやすくなります。

まとめ

dbtは、データウェアハウスの中で行う変換を、SQLのモデルとして管理するツールです。ref関数による依存関係の自動解決、テスト、ドキュメントの自動生成、Gitでの変更管理によって、集計の数が増えても「どの数字がどう作られているか」を説明できる状態を保てます。データの取り込みや表示は担わないため、連携ツールやBIツールとは別に考えます。

配布版は無料で使え、従来のdbt Core（v1）とOSS版のv2はApache 2.0です。クラウド版のdbt platformは、無料のDeveloperプランから、2026年11月時点で1人あたり月100ドルのStarterプラン、個別見積もりのEnterpriseプランまであります。どちらを選ぶかは、定期実行と監視を自分で用意できるかで決めるのが現実的です。

導入を考えるなら、まず今ある集計SQLの一覧を作り、本数、参照関係、担当者、使っている人を書き出してみてください。集計が数十本あり、複数人が触っているなら導入の効果は大きく、10本未満なら急ぐ必要はありません。導入する場合は、重要な指標1〜2個から始め、既存の数字との一致を確かめてから範囲を広げていきましょう。