売上を計算するSQLがBI、個人のメモ、定期バッチに散らばり、返品の扱いを直すたびに複数箇所を修正する。dbtはこの苦しさを減らす道具ですが、『入れればデータ連携も品質も全部解決する』と期待すると役割を見誤ります。
結論としてdbtは、DWH内のデータ変換をSQL中心のコードとして作り、依存関係、テスト、文書、実行を管理する仕組みです。データをShopifyから取得する機能や、事業上の正しい売上定義を自動で決める機能ではありません。SQLの再利用とレビューが必要になったときに価値が出ます。
最初に結論
dbtはELTのTransformを担い、SELECT文で定義したmodelをDWH上のテーブルやビューとして構築します。refで依存関係を結び、data testで前提を検査し、documentationで列の意味を共有します。まず重複している重要SQLを一つ移し、検証してから広げるのが安全です。
この記事のポイント
- ・dbtの中心はDWH内のSQL変換であり、抽出・格納やBIそのものではない
- ・model、source、refによって変換の依存関係を明示し、順番を管理する
- ・テストはデータの前提違反を検知するが、事業定義の正しさを自動で保証しない
- ・staging→intermediate→martsに分けると、元仕様と事業ロジックを整理しやすい
対象：SQLは使えるがdbtは初めての分析担当者、データエンジニア、データ基盤責任者
1. dbtはELTのTを管理する
dbt公式ドキュメントでは、データ実務者が分析コードをソフトウェアのように変換、テスト、デプロイ、文書化できる仕組みとして説明されています。すでにBigQueryなどへ格納されたデータに対し、SQLのSELECT文を書き、結果をテーブルやビューとして構築します。計算は主に接続先のデータプラットフォームで行われます。
たとえばraw_ordersからキャンセルを除き、タイムゾーンを揃えたstg_ordersを作り、返金を反映したordersを作り、顧客別LTVを持つcustomer_martを作ります。各段階をファイルとして管理すれば、変更理由をレビューし、同じ入力から再実行できます。BIごとに別の売上計算を持つ状態を減らせます。
| 仕事 | dbtが担うか | 主な手段 |
|---|---|---|
| APIからデータを取得 | 原則として別の仕組み | 連携サービス・自作パイプライン |
| DWH内でSQL変換 | 中心機能 | model、SQL、materialization |
| 依存順に実行 | 担う | ref、DAG、job |
| データ前提を検査 | 担う | data test、unit test |
| ダッシュボード表示 | 別の仕組み | BI・分析アプリ |
| 指標の意味を決定 | 人が決め、dbtに実装 | 合意・定義・レビュー |
2. model・source・ref・test・docsを理解する
modelは多くの場合、一つのSELECT文を持つSQLファイルです。sourceは連携された元テーブルを宣言し、refは別のmodelを参照します。dbtはrefから依存関係を作り、上流から順に実行します。この関係はDAGとして可視化でき、売上の変更がどの顧客マートへ影響するかを追いやすくなります。
data testは、注文IDが一意、顧客IDがNULLではない、statusが許可値に含まれる、注文明細が存在する、といった前提をSQLで検査します。documentationにはモデルや列の説明を記載します。テスト結果と文書は、作っただけでは運用になりません。失敗通知、担当者、修正期限、定義変更時のレビューを決めます。
- model：SQLで定義する変換後のデータセット
- source：DWHへ取り込まれた上流データの宣言
- ref：別モデルへの参照と実行順の依存関係
- data test：一意性、非NULL、許可値、関係などデータ前提の検査
- documentation：モデル・列・定義・所有者を共有する説明
3. staging・intermediate・martsに分ける
dbt Labsのベストプラクティスでは、プロジェクトをstaging、intermediate、martsなどの層で整理する考え方が示されています。stagingは元データの名前や型を整え、intermediateは複雑な結合や再利用する途中計算、martsは売上、顧客、商品など業務で直接使うデータを提供します。
この分割は絶対的な正解ではありません。SQLが数本しかないうちに細かな層を増やすと、移動するだけで理解しにくくなります。反対に、一つの巨大SQLで取得元の補正、返品計算、顧客集計まで行うと変更影響を追えません。各層の責任を一文で説明できる最小構成から始めます。
| 層 | 役割 | ECの例 |
|---|---|---|
| staging | 元サービスごとの型・名前・重複を整理 | stg_shopify__orders |
| intermediate | 結合や再利用する途中ロジック | int_orders_with_refunds |
| marts | 業務概念ごとに利用しやすく提供 | fct_orders、dim_customers |
4. EC売上モデルを作る最小例
最初にShopifyのorders、order_lines、refundsをsourceとして宣言します。stagingでIDや時刻を揃え、テスト注文を除外します。intermediateで注文と返金を注文ID単位に結び、martsで純売上、注文数、初回注文日、顧客別累計売上を作ります。BIはこのmartsだけを読めば、共通の返品ルールを再利用できます。
ここで重要なのはSQLの技巧より定義です。純売上に税と送料を含むか、部分返金は返金日と注文日のどちらへ計上するか、ゲスト注文を同一顧客へ統合するかを事業側と決めます。定義をdocumentationへ書き、既存レポートと日次件数・金額を照合します。差異を無理にゼロにせず、理由と許容範囲を残します。
- sourceを宣言する：元テーブル、更新時刻、責任者を明示する。
- stagingで整える：命名、型、時刻、重複、テストデータを統一する。
- 事業ロジックを分ける：返金や顧客統合を再利用できる中間モデルへ切り出す。
- martsを公開する：BI利用者が理解できる注文・顧客モデルを提供する。
- テストと照合を自動化する：一意性、非NULL、件数、金額差を継続的に確認する。
5. テストは何を保証し、何を保証しないか
data testは、データが宣言した条件を満たすかを検査します。注文IDの重複や参照先のない顧客IDを早く見つけるのに有効です。unit testは小さな入力と期待出力を用意し、複雑なSQLロジックを変更前に確かめる用途があります。Pull Requestで変更モデルと下流を実行すれば、本番反映前に影響を検出しやすくなります。
しかし『売上には送料を含めるべきか』のような業務判断はテストだけでは決まりません。間違った定義を期待値として書けばテストは通ります。また全行検査が高コストになる場合は、対象期間や重要度を考える必要があります。重大度に応じて警告と失敗を分け、失敗したまま公開するか停止するかを運用ルールにします。
6. dbtが向く組織・まだ早い組織
dbtが向くのは、DWHがあり、SQL変換が複数あり、複数人でレビューしたい組織です。同じ指標を繰り返し計算する、変更影響が分からない、SQLの実行順を手で管理する、品質問題を公開後に知る、といった症状が導入理由になります。GitとSQLの基本を学ぶ時間、実行環境、障害対応の担当も必要です。
まだデータが表計算一枚だけ、定例SQLがほとんどない、DWHへ安定してデータが届かない場合は、先にデータ取得と重要指標の定義を整えるほうが効果的です。dbt Cloudなどのプラットフォームとdbt Core系の利用形態・機能・サポートは変化するため、導入時は公式の最新情報を比較します。
| 状況 | 判断 |
|---|---|
| 同じSQLがBIや担当者ごとに重複 | 小さなdbtプロジェクトで集約を検討 |
| DWHへの連携が不安定 | 取得・監視を先に安定させる |
| SQLを複数人で変更 | Git、レビュー、テストと相性がよい |
| 表計算だけで目的を満たす | 運用負担を増やさず現行を改善 |
| 業務定義の責任者がいない | ツール導入前に合意と所有者を決める |
7. 最初のプロジェクトを失敗させない順序
最初は経営KPIすべてではなく、利用頻度が高く、既存SQLが理解できる一つのモデルを選びます。sourceを宣言し、staging、marts、数個の重要テスト、列説明を作ります。既存レポートと並行稼働し、日付ごとの件数と金額を比較して、定義差を関係者と確認します。
安定後に実行スケジュール、失敗通知、Pull Requestのレビュー、開発と本番の分離を整えます。モデル命名、層、テスト、文書のルールは短いREADMEに残し、例外を増やしすぎません。利用者から『どの数字を信じればよいか迷わなくなった』と確認できてから、次の領域へ広げます。
- 価値が明確な一つの重要SQLを選ぶ
- 元データと結果の件数・金額を日付別に照合する
- 重大な前提だけをテストし、失敗通知と担当者を決める
- 定義と列説明を利用者の言葉で文書化する
- レビューとデプロイが安定してから対象モデルを増やす
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- What is dbt? — dbt Labs（最終確認：2026-08-07）：dbtの役割、開発ワークフロー、主要概念を参照。
- How we structure our dbt projects — dbt Labs（最終確認：2026-08-07）：staging・intermediate・martsの構成原則を参照。
- Data tests — dbt Labs（最終確認：2026-08-07）：データテストの定義、種類、利用方法を参照。
- Document your models — dbt Labs（最終確認：2026-08-07）：モデル・列の文書化と共有機能を参照。
よくある質問
dbtはデータ連携ツールですか？
主な役割はDWHへ格納済みのデータ変換です。SaaSや業務DBからデータを取得・ロードする処理は、通常、連携サービスや別のパイプラインが担います。
dbtを使うにはPythonが必要ですか？
分析モデルの中心はSQLとYAMLで始められます。ただし環境構築、パッケージ、CI、拡張機能の運用ではコマンドラインやソフトウェア開発の基礎が役立ちます。
dbtのテストでデータ品質は保証できますか？
宣言した前提違反は検知できますが、定義そのものの妥当性や取得漏れを自動では保証しません。元システムとの件数・金額照合、所有者、通知、復旧手順と組み合わせてください。
まとめと次の一歩
dbtが解決するのはデータ取得ではなく、散らばった変換SQLを依存関係のある変更可能な資産へ変える問題です。モデルを小さく分け、テストと文書を同じ変更に含めることで、売上定義の修正をレビューし、影響先へ一貫して届けられます。