dbtとは｜データ変換(ELT)の仕組み・使い方・案件単価

dbtとELTの基本

結論：dbtは、DWHにロード済みのデータをSQLで整えるための「変換層」のオープンソースツールです。抽出・ロードは行わず、変換（Transform）に責務を絞ります。

従来のETLとELTの違い

以前のデータ基盤では、抽出→変換→ロード（ETL）を専用のETLサーバー上でおこなうのが定番でした。近年はDWHの計算力が伸びたため、先にロードしてからDWH内でSQL変換する「ELT」が主流になっています。dbtはこのELTの「T」を担うプレイヤーです。

DWHが高速化した現在は、変換をDWH内で回すELT側にコスト面・運用面の利点が集まっています。一言でいうと、dbtは「DWH上のデータ変換をSQLで管理し、テストや依存関係も一緒に扱えるツール」です。

dbtが解決する3つの課題

• SQLの属人化：ノートブックや個別スクリプトに散らばりがちな変換ロジックを、モデル（.sqlファイル）として1箇所に集約します

• テスト不在：not_null／unique／accepted_values／relationshipsなどの基本テストを宣言的に書けます

• 依存関係の把握困難：ref関数で下流モデルが上流を参照する形にすると、依存グラフを自動生成できます

一次情報はdbt公式ドキュメントを参照してください。

ミニFAQ：ELTかETLか迷ったら？

Q. まだETLツールを使っている場合、dbtに移行するべき？

A. DWHがBigQuery／Snowflake／Redshift／Databricksなどスケールする列指向DWHであれば、ELT＋dbtに寄せる選択が現実的です。オンプレDBのバッチ変換や、DWH側の計算コストが割高な構成では、既存のETLを残すほうが安全な場合もあります。

dbtの中核仕組み

結論：dbtの中身は「SQLファイル＋YAML定義＋Jinjaテンプレート」の3点セットです。特別なDSLを覚える必要はなく、SQL力があれば入りやすい構造です。

モデルとref関数

モデルはSELECT文を書いた.sqlファイルです。上流モデルはref('stg_orders')の形で指定し、テーブル名を直接書きません。これにより開発／本番のスキーマ切り替えや、依存グラフの自動生成が可能になります。

たとえばcustomers.sqlをmodelsフォルダ配下に置き、本文に「SELECT ... FROM {{ ref('stg_customers') }}」と書くことで、モデル名だけで上流を参照できます。テーブル名のハードコードを避けられる点がdbtの中核です。

マテリアライゼーションの選択

table／view／incremental／ephemeralの4種類から、モデルごとに実体化方式を選びます。特にインクリメンタルは、大規模テーブルの差分更新でコストを大きく下げられる要のオプションです。

テスト・ドキュメント・系譜（Lineage）

• テスト：YAMLでテストを宣言できます（記法はバージョン差があるため、実装時は公式ドキュメントで確認してください）。カスタムテストはSQLで書けます

• ドキュメント：dbt docs generateでHTMLサイトを生成できます。カラム説明を書けばドキュメント化しやすく、必要に応じてホスティングして共有できます

• 系譜：モデル間の依存グラフが画面上で可視化されます

「モデル・テスト・ドキュメント・系譜」を同じリポジトリで一体化できることが、dbtが定番になった最大の理由です。

Jinjaマクロと再利用

Jinja記法で条件分岐・繰り返し・共通関数（マクロ）が書けます。SQL方言の吸収や、日付範囲パラメータの共通化に強く、コード重複を減らせます。

ミニFAQ：どこまで書けばdbtらしい？

Q. とりあえずSQLをファイル化しただけ、はdbt導入と言える？

A. ref関数とtests設定が入り、dbt buildで回っている状態が最低ラインです。ファイル分割だけでは学習コストの割にリターンが薄くなります。

dbt Coreとdbt Cloudの違い

結論：dbt Coreはローカル／自前サーバーで動かすOSS版。dbt Cloudは公式マネージドで、Web IDE・スケジューラ・ホスト型ドキュメントが付いた有料SaaSです。

機能と課金の比較

最新の価格・プランはdbt Cloud公式を確認してください。プラン改定が入る領域のため、断定的な金額は避けます。

個人・チームでの選び方

• 個人学習・OSSで完結させたい：dbt Coreで十分。VS Code＋Gitで運用できます

• 少人数チームで運用工数を減らしたい：dbt Cloudでスケジューラ・IDE込みに寄せる選択が現実的

• 既存のAirflow／ワークフロー基盤がある：dbt Coreを差し込み、Airflow側でスケジュールする分担が組みやすい

Airflowを既に運用しているなら、Apache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価側でオーケストレーションの前提を確認しておくと選定が早くなります。

対応するデータウェアハウス

結論：dbtは主要DWHに対応。SQL方言はアダプタが吸収するため、DWH間の学習コストは相対的に低めです。

対応が広い代わりに、コスト特性・パフォーマンスチューニングはDWHごとに異なります。それぞれの詳細は下記の記事で整理しています。

• BigQueryとは？特徴・できること・データ分析案件の単価をフリーランス視点で解説

• Snowflakeとは？データクラウドの特徴・BigQueryとの違い・案件動向をフリーランス視点で解説

• Amazon Redshiftとは｜BigQueryとの違い・案件単価を解説

• Databricksとは｜レイクハウスの仕組み・Snowflakeとの違い・案件単価

Postgres／DuckDBなどOSSも対応しており、学習環境では手元のPostgresやDuckDBで試すのが始めやすい選択肢です。

導入の流れ（dbt Core）

結論：Python環境にdbt-coreと各DWH向けアダプタをインストールし、dbt initでひな型を作る、が一般的な始め方です。

インストールと初期化

1. Python仮想環境を作成（python -m venvなどを推奨）

2. pip install dbt-core dbt-bigquery のようにDWH向けアダプタを合わせて導入（Snowflakeやredshiftは対応アダプタ名に置き換え）

3. dbt init プロジェクト名 でひな型を生成

4. profiles.yml（ユーザーホーム直下の.dbtフォルダに置く）にDWH接続情報を書く

最初のモデル実行

• modelsフォルダ配下の.sqlファイルが最初のモデル

• dbt runでDWH上にテーブル／ビューが作られる

• dbt testでスキーマテストを実行

• dbt docs generate と dbt docs serve でドキュメントUIを起動

ここまでで、モデル・テスト・ドキュメントがひととおり動く状態になります。詳細な公式チュートリアルはdbt Learnに整理されています。

実案件で必要になる周辺整備

• CI：Pull Requestで「dbt build --select state:modified」を回す

• 本番実行：Airflow・dbt Cloud・GitHub Actionsなどでスケジュール

• 監査：dbt-artifactsやelementaryで結果をDWH側に貯める

これらは初日から全部やる必要はなく、モデル数が増えたタイミングで順に足していく方針が現実的です。

Airflowなどオーケストレータとの棲み分け

結論：dbtは変換層に専念し、抽出・ロード・スケジューリング・再試行はオーケストレータ側が担う責務分担が主流です。

「T」に責務を絞る意味

dbtは自身でジョブを起こしたり外部APIを叩いたりしません。DWHへ既に入っているデータをSQLで整えることに集中します。逆に言えば、以下は別ツールが担当します。

• 抽出（E）／ロード（L）：Fivetran／Airbyte／自作Lambda等

• オーケストレーション：Airflow／Dagster／Prefect／dbt Cloudスケジューラ

• 通知・監視：Slack通知／Datadog／CloudWatch

Airflow側の詳細はApache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価で整理しています。あわせて確認するとオーケストレーションと変換層の関係が立体的に見えます。

実務パターン

短く言うと、dbtは「データを変換するツール」、Airflowは「処理全体を順番に実行・監視するツール」です。両者は競合というより補完関係で使われることが多く、Airflow＋dbtの組み合わせでよく見る構成は次の通りです。

1. Fivetran／AirbyteでRaw層にロード

2. AirflowのDAGが dbt build --select tag:daily をトリガ

3. 失敗時はAirflow側が再試行・Slack通知

4. 成功後、BIツール（Looker／Metabase等）が最新テーブルを参照

「dbtが変換、Airflowが指揮者」という役割分担を意識すると設計が破綻しにくくなります。

フリーランスdbt案件の傾向と単価

結論：dbt単体案件は少なく、「データ基盤構築・移行」の一部としてdbtを担当する募集が中心です。データエンジニア・アナリティクスエンジニア枠での参画が実務的な入り口になります。

求められるスキル

• SQL（ウィンドウ関数・パフォーマンスチューニングまで）

• 対象DWH（BigQuery／Snowflake／Redshift／Databricks等）1つ以上の実務

• Git・CI／CDの運用経験

• Airflow／dbt Cloudなどオーケストレータのいずれかを経験

• ドメイン理解（売上・在庫・広告など、対象領域のデータモデリング勘）

dbtの操作自体は数日で慣れます。求められる主戦力はSQL力とデータモデリング設計で、dbtは「その表現手段」の位置づけです。

単価の目安

首都圏中心の主要フリーランスエージェント数社の公開案件（週4〜5日・準委任・フルリモート中心）を確認すると、データエンジニア／アナリティクスエンジニア枠は月75〜110万円のレンジが目立ちます（2026年時点での観測ベース）。dbt「も」触る条件が付く案件は、この帯の中〜高位に寄る傾向があります。まずは公開案件ベースの目安で、非公開案件は個別条件で上振れするケースがあります。

上記は「実務経験3年以上のデータ基盤エンジニア（SQL・DWHの本番運用経験あり）」を想定した目安です。SQL・DWHの実務経験が浅い場合はレンジ下限、あるいはBIエンジニア寄りの案件から入るのが現実的です。

自分の経験値でどのくらいの単価が狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

関連するキャリア設計・案件探しは以下も参考になります。

• データエンジニアとは？仕事内容・年収・将来性をわかりやすく解説

• データエンジニアの年収は？単価相場からフリーランスの報酬まで解説

• フリーランスデータエンジニアになるには？案件の探し方と必要スキルを解説

ミニFAQ：dbt未経験でも案件に入れる？

Q. dbt実務経験なし、SQL・BigQuery経験ありは受かる？

A. データエンジニア／BIエンジニア枠で受かるケースがあります。dbt自体は入場後にキャッチアップできる範囲と見られやすく、SQL・DWH経験が土台として評価されます。ただし「dbt導入責任者」枠は既にdbt実務がある人が優先されがちです。

dbt導入でよくある失敗と対策

結論：構文の話より、モデル設計・テスト・コスト管理でつまずくケースが多く見られます。

モデルを大きく作りすぎる

• 症状：1つの.sqlが数百行、変更のたびに影響範囲が読めない

• 対策：staging → intermediate → martの3層で分ける。staging層は「1ソース1モデル」、mart層はビジネス指標単位まで抽象化

テストを書かないまま本番に載せる

• 症状：Raw側の変更で下流が壊れ、BIダッシュボードが誤った数字を返す

• 対策：主キー相当の列には、原則としてuniqueとnot_nullを入れる。ここを押さえるだけでも初期事故は大幅に減ります

インクリメンタルの誤設計でコストが跳ねる

• 症状：フルリフレッシュ相当のスキャンが毎回走り、DWH料金が想定を大きく超える

• 対策：代表的には is_incremental 判定や unique_key の設定を使います。パーティション／クラスタリングは対象DWHのベストプラクティスに従い、merge条件やスキャン範囲を最初に設計する

依存の循環・命名の混乱

• 症状：ref関数が絡み合い、影響範囲の追跡が難しくなる

• 対策：命名規約（stg_／int_／fct_／dim_）を最初に決める。命名だけで層が判別できる状態を維持する

dbt導入・運用チェックリスト

案件参画時・自己プロジェクト立ち上げ時に確認すると事故が減る観点をまとめます。

• Raw層とdbt側のスキーマが分離されているか

• modelsフォルダが3層構造（staging／intermediate／marts）で命名規約が明確か

• 主要ファクトテーブルにテスト（unique／not_null）が入っているか

• インクリメンタルモデルにunique_keyとis_incrementalのガードが入っているか

• dbt docsのカラム説明が主要モデルで埋まっているか

• CIで dbt build --select state:modified+ が回っているか

• Airflow／dbt Cloudの失敗通知がSlack等に届く設定か

• 本番実行のログ・成果物（manifest.json等）が保管されているか

まとめ

dbtは、DWH内SQL変換に責務を絞ることで、テスト・ドキュメント・依存管理を一気に底上げする変換層ツールです。ETL全部を置き換えるものではなく、Airflow等のオーケストレータと組み合わせて基盤全体を成立させる位置づけになります。

要点を最後にまとめます。

• dbtは「T」だけを担う変換層。抽出／ロード／スケジュールは別ツールが担当する

• モデル（SQL）＋YAML定義＋Jinjaで、テスト・ドキュメント・系譜が一体化する

• dbt Coreは無償で自前運用、dbt CloudはWeb IDE・スケジューラ込みのSaaS

• 対応DWH（BigQuery／Snowflake／Redshift／Databricks／Postgres）ごとに設計上の勘所は残る

• フリーランス案件は「dbtも触るデータエンジニア／アナリティクスエンジニア枠」で参画するのが主流

次のアクションとしては、Postgres／DuckDBで手を動かしてref関数とテストの体感を得たうえで、対象DWHのアダプタを追加する流れが最短です。公式のdbt Learnで無料コースが公開されているため、実装しながら公式リファレンスに立ち戻る学習が効率的です。