dbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方【2026年版】

dbt（data build tool）は、データウェアハウスに取り込み済みの生データを、SELECT文だけで分析用のテーブルへ組み替えるツールです。抽出も転送も担当せず、ELTのうちT（変換）だけに守備範囲を絞っている点が、従来のETLツールとの決定的な差になります。この記事では、ref()による依存解決とDAG自動生成という中核の仕組み、GUI型ETLツールや手組みSQLバッチからの移行判断、2026年8月時点の料金レンジ、そして自社データ基盤へ組み込むときに内製と受託開発のどちらへ倒すかまでを整理しました。導入すると損をする規模の条件も、逃げずに書きます。

まとめ：dbtを採用すべきデータ基盤の条件と見送る判断の分かれ目

dbtが効くのは、変換ロジックが増え続ける基盤です。目安として、分析用テーブルが30本を超え、集計定義の修正が月に数回発生し、SQLを書ける人が2人以上いる。この3つが揃ったところから、依存関係の自動解決とテストの恩恵が手間を上回ります。逆に、テーブルが数本でスケジュール実行も日次1回なら、DWHのスケジュールドクエリで十分足ります。

提供形態は2つあります。オープンソースの dbt Core（Apache 2.0）を自前のCI基盤で回すか、dbt platform（旧dbt Cloud）のマネージド環境を使うか。2026年6月のバージョン2.0以降、Rust実装のFusionエンジンが既定の実行環境となり、Core側でも中核機能を無償で使える範囲が広がりました。有料プランへ移る分岐点は人数ではなくモデルビルド数で、無料のDeveloperプランは月3,000ビルドが上限になります。

導入の実務でつまずくのは、ツールの操作ではなくレイヤ構成と命名規則の設計です。ここを決めずにモデルを書き始めた基盤は、半年後に「どのテーブルが正なのか分からない」状態へ戻ります。設計だけ外部に入れて運用は内製、という切り分けが現実的な着地点になりやすい。

dbtがELTのTを担う仕組みとSQLモデル中心の変換設計の考え方

dbtを理解する早道は、担当しない範囲を先に把握することです。データの抽出も、DWHへの転送も、ワークフロー全体のスケジューリングも、dbtの仕事ではありません。

変換処理をDWH内で完結させるELT前提の役割分担と適用範囲

従来のETLは、抽出したデータを専用サーバーへ運び、そこで変換してからDWHへ書き戻す構造でした。dbtが前提に置くELTでは順序が入れ替わり、生データをDWHへ先に載せてから、DWHの計算資源で変換します。ETLとELTの違いと選定の考え方を整理した記事も併せて読むと、この順序変更が何を意味するかが掴めるはずです。

dbtが発行するのは、実体としてはCREATE TABLE ASやCREATE VIEW ASのSQLにすぎません。変換の計算はすべてSnowflakeやBigQueryの側で走ります。だからdbt自体は軽く、専用の実行基盤を持つ必要がない。裏を返すと、DWHに載っていないデータは一切扱えず、APIからの取得やファイル転送は別のツールが要ります。

SELECT文とrefによる依存解決とDAG自動生成の仕組み

dbtのモデルは、1ファイル＝1つのSELECT文です。テーブル名を直書きせず、ref('stg_orders')のように他モデルを参照すると、dbtが参照関係を読み取って実行順序を自動で決めます。人が「先にこれ、次にこれ」と順番を書く必要がない。

この参照グラフはDAG（有向非巡回グラフ）として保持され、dbt runを叩けば依存順に一括実行されます。上流モデルの列名を変えたとき、影響を受ける下流モデルがどれかも同じグラフから辿れる。手組みのSQLバッチでいちばん壊れやすい「どのクエリがどのクエリに依存しているか」という暗黙知を、コードそのものから機械的に復元できる点が中核の価値になります。

テスト・ドキュメント・履歴管理をSQL資産に付ける設計思想と管理条件

dbtはモデルに対して、一意性・NULL不許容・参照整合性・許容値といったテストをYAMLで宣言できます。dbt testを実行すると各テストがSQLへ展開され、違反行が1件でもあれば失敗として返る。データ品質の検査を、SQL資産と同じリポジトリに置ける構造です。

ドキュメントも同様にモデル定義から生成され、列の説明と依存グラフをブラウザで辿れる形になります。すべてがGit管理下のテキストなので、変更はプルリクエストのレビュー対象になり、いつ誰がどの集計定義を変えたかが履歴として残る。ソフトウェア開発の運用習慣を、そのままデータ変換へ持ち込む設計と言えます。

ETLツールや手組みSQLとdbtの違いと運用コストの境界条件

比較対象は3つあります。GUI型のETLツール、自前で書いたSQLバッチ、そして抽出・ロード専用のSaaS。それぞれ競合するのか補完するのかが違います。

GUI型ETLツールとの違いはコードレビューと差分管理の可否

GUI型ETLツールは、画面上でコンポーネントを線でつないで変換フローを組みます。作り始めは速い。問題は変更が積み上がったときで、誰がどこを直したかがGUIの内部表現に埋もれ、差分レビューが実質できなくなります。

選定の分かれ目は、変換ロジックの改修頻度に置くと判断が安定します。年に数回しか触らないフローならGUIのままでよく、月次で定義が動く指標を抱えているならコード管理へ寄せた方が総コストは下がる。

手組みSQLバッチから移行する判断基準はモデル数と改修頻度の2軸

多くの現場の出発点は、cronで叩くSQLファイル群です。これが破綻するのは、テーブル数ではなく依存の深さが増えたとき。5階層の中間テーブルを挟むようになると、実行順序の管理と再実行範囲の特定が人力では追いつかなくなります。

移行を検討する目安は、分析用テーブル30本前後、または依存が3階層を超えたあたり。この規模を下回るなら、移行工数のほうが高くつきます。既存のSQLはSELECT文の部分をほぼそのまま持ち込めるため、移行作業の実体はテーブル名をref()へ書き換える機械的な置換と、レイヤ構成の再設計になります。

Fivetranなど抽出・ロード側ツールとの守備範囲の切り分け

FivetranやAirbyteは、SaaSやデータベースからデータを引き抜いてDWHへ載せるまでを担います。dbtとは競合せず、前工程として組み合わせるのが標準的な構成です。FivetranのELT構成とMAR課金の仕組みを押さえておくと、どこまでを製品に任せ、どこからをSQLで書くかの線引きがしやすくなります。

なお、この2製品は2026年6月1日に企業として統合されました。ただし製品としての守備範囲は分かれたままで、抽出・ロードとT（変換）は別レイヤとして選定してよい。組み合わせるツールを1社に寄せるかどうかは、契約と請求の都合で決める話になります。

dbt Core・dbt platformの提供形態と2026年の料金体系

費用を見積もる前に、無料で使える範囲がどこまでかを正確に押さえます。2026年8月時点の公式pricingページで実測した数字を基準にしました。

無料のDeveloperプランで足りる規模と有料化の分岐点となるモデルビルド数

課金の単位は座席数ではなくモデルビルド数です。ここを取り違えると見積りが大きく外れます。

月3,000ビルドがどれくらいかを実務感覚に直すと、モデル50本を日次1回まわして月1,500ビルド。ここに開発中の試行実行が乗るので、モデル50本前後が無料枠のおおよその上限になります。100本を超えるか、時間単位のスケジュール実行を始めた時点でStarter以上へ移る計算です。オープンソースの dbt Core を自前のCI基盤で回すなら、このビルド数上限そのものが存在しません。

Fusionエンジン標準化で変わった実行環境と対応DWHの確認点

2026年8月12日更新の公式ドキュメントでは、Fusionエンジンが dbt をインストールしたときの既定の実行体験として案内されています。Rustで書き直された実行エンジンで、Apache 2.0ライセンスの dbt Core 2.0 ランタイム上に構築されている。無償で使え、一部機能は無料プランのアカウントでサインインすると解放されます。

注意点は対応アダプタです。同ドキュメントが挙げるのは Snowflake・Databricks・BigQuery・Redshift の4つ。PostgreSQLやその他のデータベースを変換先に使っている基盤では、Fusionの対象外となるため事前の確認が要ります。DWHの選定がまだ固まっていない段階なら、この4製品のいずれかに寄せておくと後の選択肢が広く残ります。

Fivetranとの合併がオープンソース継続に与える影響と確認点

2025年10月13日に発表された全株式交換方式の合併は、2026年6月1日に完了しました。CEOはFivetran側の George Fraser、Presidentに dbt Labs 創業者の Tristan Handy が就き、統合後の利用規模は10万を超えるデータチームとされています。

技術選定の観点で確認すべきは、オープンソースが続くかどうかの1点に尽きます。公式プレスリリースは、dbt Core v2.0 と Fusion エンジンを Apache 2.0 でオープンソース化し、コア言語機能とウェアハウスアダプタの全機能へ無償でアクセスできると明記しました。ライセンス上、dbt Core を自前運用する構成が塞がれる状況ではない。とはいえ単一ベンダーへの依存度は上がったので、変換ロジックをSQLとYAMLというテキスト資産として保つ運用は続けておくのが安全です。

データ基盤へdbtを組み込む導入手順と内製・外注を判断する基準

ここからは、実際に入れると決めた場合の話です。手順そのものは軽く、難所は設計判断の側に寄っています。

初期導入で最初に決めるべきはレイヤ構成と命名規則・テスト方針

接続設定を書いてdbt runが通るまでは半日で届きます。そのあとに効いてくるのが、モデルを何層に分けるかという設計です。標準は3層構成で、生データをほぼそのまま整形するstaging層、業務エンティティ単位に組み直すintermediate層、BIツールが直接参照するmarts層に分けます。dbt三層構造でmarts層が最終データ整備を担う原則に、各層の責務の切り方を実装レベルでまとめてあります。

同時に決めるのが命名規則とテスト方針です。stg_やfct_といった接頭辞を最初に固定しておかないと、モデルが100本を超えたところで検索が効かなくなる。テストは全モデルに網羅的にかけず、marts層の主キー一意性とNULL不許容から始めて、障害が起きた箇所に足していく運用が続きます。

社内内製に向く条件と受託開発へ切り出す条件の具体的な分かれ目

内製で回せるのは、SQLを日常的に書く担当が2人以上いて、Gitでのレビュー運用が既に定着している組織です。この2条件が揃っているなら、外部に頼むのは初期のレイヤ設計レビューだけで足ります。

切り出しを勧めるのは、SQLを書けるのが1人だけの場合。属人化した状態でモデルが増えると、その1人が離れた瞬間に誰も触れない基盤が残ります。DWHの選定から入る、既存のETLツールから移行する、複数の業務システムを横断して指標を統一する。このいずれかを含むなら、設計フェーズは外部の手を入れた方が結果的に安く付きます。当社ではデータ分析基盤構築・MLOps構築支援として、レイヤ設計から運用移管までを請けています。基盤全体の構成要素と費用感はデータ分析基盤の構成要素と内製・外注の判断基準にまとめました。

dbtを採用しない方が早い基盤規模とデータ更新頻度の具体条件

入れない方がよい場面を、条件付きで言い切ります。第一に、分析用テーブルが10本未満で依存が2階層以内の基盤。この規模ではDAGの自動解決が解く問題がそもそも存在せず、YAMLとプロジェクト構造の学習コストだけが残ります。BigQueryのスケジュールドクエリやSnowflakeのタスクで足ります。

第二に、秒単位・分単位のストリーミング処理が主目的の場合。dbtはバッチ変換のツールで、マイクロバッチでも数分間隔が現実的な下限になります。リアルタイム性が要件なら、DWH側のストリーミング取り込みや専用の処理基盤を先に検討する方が筋が通る。第三に、変換対象がDWHの外にあるファイルやAPIのままで、まだDWHへ載っていない場合。この状態でdbtを検討しても、着手すべきは抽出・ロード層の整備です。

導入後につまずく運用課題とチーム体制の実務的な対処と改善条件

半年から1年運用したチームが共通して当たる壁が2つあります。実行時間の膨張と、権限設計の曖昧さです。

モデル数増加で実行時間が伸びたときの分割と選択実行の設計判断

モデルが数百本規模になると、全件実行が数時間かかるようになります。対処は2段階。まずdbt build --selectによる選択実行で、変更したモデルとその下流だけを回す運用へ切り替える。次に、テーブルを毎回作り直すのをやめ、差分だけを追記するincrementalマテリアライゼーションへ、行数の多いモデルから順に移します。

それでも足りない規模では、プロジェクト自体の分割が視野に入ります。部門ごとにリポジトリを分けたうえで、モデル間の参照は保ちたい。この要求に応える手段をdbt-loomによるdbt Coreマルチプロジェクト管理で扱っています。ただし分割は運用の複雑さと引き換えなので、選択実行とincremental化を先に試し切ってからにしてください。

データアナリストとエンジニアの権限分離とレビュー運用の設計方針

dbtはSQLさえ書ければ誰でもモデルを追加できます。この敷居の低さが、そのまま統制の課題になる。marts層に部門ごとの似て非なる売上定義が並び、どれが正なのか分からなくなるパターンが典型です。

実務で効いたのは、層ごとにレビュー要件を変える運用でした。staging層とintermediate層はアナリストが自由に追加してよく、marts層への追加・変更だけはデータエンジニアのレビューを必須にする。全部を厳格にすると開発が止まり、全部を自由にすると定義が割れます。境界を1本引くだけで、速度と統制の両方が保てる。加えて、marts層のモデルには必ず所有者を記述しておくと、定義の疑義が出たときの照会先が明確になります。

よくある質問

dbtの検討段階で問い合わせの多い論点を、5つに絞って回答します。

dbtは無料で使えますか？

使えます。オープンソースの dbt Core は Apache 2.0 ライセンスで公開されており、自前のCI基盤やサーバー上で実行する限り費用は発生しません。マネージド環境の dbt platform を使う場合も、Developerプランなら無料で1シート・月3,000モデルビルド・1プロジェクトまで利用できます（2026年8月時点の公式pricing）。有料化の目安は座席数ではなくモデルビルド数で、モデル100本規模や時間単位の実行を始めると1人あたり月100ドルのStarter以上が必要になります。

dbt CoreとdbtCloud（dbt platform）はどちらを選ぶべきですか？

すでにGitHub ActionsなどのCI基盤が社内にあり、運用できる人がいるなら dbt Core で足ります。スケジューラ・IDE・ドキュメントホスティング・権限管理を自前で用意したくない場合が dbt platform の出番です。判断材料は費用よりも運用工数で、CI基盤の保守を誰が担うかを先に決めると答えが出ます。なお2026年6月のバージョン2.0以降はRust実装のFusionエンジンが両者の共通基盤となり、実行性能の面での差は縮まりました。

dbtを使うにはPythonの知識が必要ですか？

基本的な変換処理はSELECT文とYAMLだけで書けるため、Pythonの知識がなくても運用できます。必要になるのはインストール時のpipコマンド程度です。ただし、条件分岐やループを含む動的なSQLを生成する場面では、テンプレート言語のJinjaを書くことになります。Jinjaの構文はPythonに似ていますが別物なので、Pythonそのものの学習は前提になりません。機械学習の前処理をモデルとして書くPythonモデル機能もありますが、対応DWHが限られます。

既存のETLツールから移行する場合の工数はどれくらいですか？

変換ロジックの本数に比例します。SQLベースで書かれた変換であれば、SELECT文をほぼそのまま持ち込めるため、モデル50本規模で1〜2か月が目安になります。GUI型ETLツールからの移行はフロー定義をSQLへ書き起こす作業が加わるため、同じ本数でも1.5倍から2倍を見込んでください。工数の大半を占めるのは移行作業そのものではなく、レイヤ構成と命名規則を決め直す設計フェーズです。

dbtでデータの取り込み（Extract・Load）もできますか？

できません。dbtはDWHに既に存在するデータを変換する役割に限定されており、外部システムからのデータ取得や転送は担当外です。SaaSやデータベースからの取り込みには Fivetran・Airbyte・trocco などの専用ツール、あるいは自前のスクリプトを組み合わせます。この分担は仕様上の制約というより設計思想で、各レイヤを疎結合に保つことで取り込み側の変更が変換ロジックに波及しない構造になっています。

関連記事

• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：dbtが前提とするELTへの移行を、ツール選定の観点から整理しています。
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：dbtの変換先となるDWHをどう置くかの前段になります。
• データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説：dbtのテストをさらに前段の契約で補強する方法を扱っています。
• リバースETLとは？同期モードと差分検出の仕組み・API制約から実装判断を解説：dbtで整えたデータを業務システムへ戻す後段の工程です。
• dbt-loomが解決するdbt Coreマルチプロジェクト管理の構造的課題：モデルが増えてプロジェクト分割を検討する段階の選択肢です。