スタートアップ分析
dbtとは？SQLを資産に変える規律から読む導入判断
dbtを語る記事の多くは、資金調達や会社規模、Fivetranとの統合発表から書き始めますが、自社でdbtを導入すべきかを決める材料はそこにはありません。実務で効くのは、自社にとって最も重要な指標を計算しているSQLが、今どこにあり、誰か一人の頭の中にしか置かれていないかという1点です。会社規模や資金調達のニュースは、本記事では判断材料として扱いません。
私はdbtを、機能の束ではなく「個人のSQLをチームでレビューできる資産に変える一つの規律」として読んでいます。SQLをファイルとして置き、ref()で参照し、テストを付け、ドキュメントを添え、Gitでレビューし、依存関係をグラフで扱う。この規律に名前を付けたことが、dbt Labsの個別機能よりも大きい仕事だったというのが私の立場です。
この記事は、Fivetran、Monte Carlo、AIデータ・アナリティクス基盤の役割整理と同じ調査シリーズの一本として書いています。Fivetranを扱った記事では「データ移動のどこまでを外部に任せられるか」という責任分界を軸に読みましたが、dbtは変換工程を担うレイヤーです。同じ「責任分界」という軸を「変換ロジックの所有権」に当てはめると何が見えるかを確かめたい、というのがこの記事を書く動機です。
私自身がdbtを本番プロジェクトで運用した経験は、本記事の執筆時点ではまだありません。以下は、dbt Labs公式Developer Hub、GitHub、Fivetran/dbt Labs双方の統合発表、Forrester ConsultingのROI記事を読み込んだ範囲での判断軸であり、運用実感が得られ次第、書き直す前提で公開します。
前提：SQLの資産化と責任分界を定義する
この記事の前提
- 製品名・機能名・料金・提供範囲は契約や時期で変わるため、本文では固定の判断材料にしません。詳細は公式docsで確認してください
- 事例記事やROI記事の数値は各社固有の条件に依存する参考情報であり、再現を保証するものではありません
この先で使う2つの言葉を、反証可能な形で先に定義しておきます。
SQLの資産化 — あるSQLが「資産」になるのは、次の5条件を満たしたときだと定義します。①別のモデルからref()で参照できる、②テストが付いている、③ドキュメントが残っている、④Gitレビューの対象になっている、⑤依存関係グラフの中に位置づけられている。個人のノートブックやBIツールの裏で動いているSQLは、正しく動いていても資産ではありません。この5条件のどれか一つでも欠けていれば「資産化されていない」と反証できます。
責任分界 — 実行環境、権限、監視、CI、障害復旧のうち、どこまでを自社の運用チームが持ち、どこから製品や外部ベンダーに委ねるかの境界線です。dbt Core / dbt platformの選択も、Fivetran統合をどう読むかという実務判断も、この一本の軸で読み解けます。
dbt Labsの全体像
Modern Data Stackにおけるdbt/Fivetranの位置づけ
dbtとは何か：SQLを資産に変える規律
dbtは、もとはFishtown Analyticsという名前で始まったデータ変換ツール群です。
データチームでは、分析用のSQLが個人のノートブック、BIツール、共有フォルダ、定期実行ジョブに散らばりがちです。動いているうちは便利でも、担当者が変わった瞬間に壊れます。所在が曖昧なSQLはファイルとして管理し、追えない変更履歴はGitレビューの単位にし、属人化した品質基準はプロジェクト内のテストに置き換え、見えない依存関係はモデル同士の関係としてグラフに、揺れる用語はドキュメントやSemantic Layerに集める。dbtがやっているのは、この5つの寄せ先を1つのプロジェクト構造にまとめることです。
dbtの思想は、アナリストをフルスタックエンジニアに変えることではありません。SQLを書ける人が、ソフトウェア開発の規律を借りて、データ変換を共同管理できるようにすることです。
最小構成はこうなります。
-- models/staging/stg_orders.sql
select
id as order_id,
user_id,
order_date,
status,
total_amount
from {{ source('raw', 'orders') }}
where status != 'cancelled'
このSQLは、単なるクエリではなく「モデル」です。別のモデルからref()で参照でき、テストや説明文を付けられ、実行順序もプロジェクトから導けます。先ほど定義した5条件のうち、ref()参照とプロジェクト管理の2つを、この1ファイルだけですでに満たしています。
dbtプロジェクトで見るべき部品は5つあります。ビジネス定義がどの粒度でテーブル化されているかを示すModels、生データの由来と責任範囲を明示するSources、null・unique・accepted valuesなどの品質条件を持つTests、列やモデルの意味をレビュー可能な形で残すDocumentation、そして共通処理を使い回すMacros / Packagesです。この5つが揃って初めて、1本のSQLが資産化の5条件を満たします。
Analytics Engineeringという見方
dbt Labsが広げた言葉のひとつが、Analytics Engineeringです。データアナリストとデータエンジニアの中間にある実務を指し、ダッシュボードを作るだけでなく、指標の定義、変換ロジック、テスト、ドキュメント、レビューの流れまでを扱います。
従来の分担では、アナリストはビジネスに近い問いを持ち、エンジニアはパイプラインの信頼性を守っていました。しかし指標の意味はSQLの中にあり、SQLの品質は運用の中で壊れます。dbtはこの境界を引き直しました。変換ロジックは個人の手元ではなくリポジトリで共有し、テストは後工程で発見するのではなくモデル定義の近くに置き、ドキュメントは別管理ではなくコードと同じレビュー対象にし、BIごとに分岐していた指標定義は共有レイヤーへ寄せる。この職能は、役職名というよりも「データをプロダクトとして扱う姿勢」に近いものです。
dbt Core、dbt platform、Fusion engineを責任分界で読む
dbt Core
dbt Coreは、オープンソースのdbtプロジェクトを実行するための中核です。CLIを使い、自前の開発環境やスケジューラと組み合わせて運用できます。
Coreを選ぶときの論点は、料金ではなく責任分界です。実行環境、権限、ジョブ監視、CI、ログ保管、障害時の復旧を誰が持つのかを、導入前に決める必要があります。
dbt platform
dbt platformは、開発、実行、探索、メタデータ管理をまとめて扱う製品群です。公式Developer Hubでは、dbt Copilot、VS Code extension、Orchestrator、Insights、Canvas、Semantic Layer、Catalogなどが製品面として案内されています。機能名を覚えることよりも、チームが必要としているのがローカル開発の速度なのか、ジョブ運用なのか、指標定義の共有なのか、データ発見なのかを先に分ける方が重要です。これは責任分界を、自社で持つか製品に委ねるかという選択そのものです。
対応データ基盤や料金は、公式Supported data platformsおよびPricingページで確認してください。アダプタの対応状況もプランも時期で変わるため、本文では固定の数字を扱いません。
Fusion engine
公式docsでは、dbt Fusion engineをRustベース、dbt CoreをPythonベースのエンジンとして説明しています。バージョン管理やリリースチャネルも別途案内されています。Fusionを見るときは「速いかどうか」だけで判断せず、既存プロジェクトのパッケージ、マクロ、アダプタ、CI、開発者のローカル環境がどう変わるかまで確認する必要があります。
Fivetran統合の読み方
資本イベントは、dbtが確立した規律の価値を変えない、というのが私の立場です。Fivetran統合の発表で変わりうるのは、製品名、契約条件、提供範囲であって、SQLをref()・テスト・ドキュメント・Gitレビュー・依存グラフの上に乗せて資産化するという中核の価値そのものではありません。
Fivetranとdbt Labsは、Fivetran側の公式プレスリリースとdbt Labs側のブログで統合の意図を説明しています。発表の中心は、データ移動、変換、メタデータ、アクティベーションをひとつの基盤として扱うというものです。ただし、ユーザーが読むべきポイントは「大きな会社になるか」ではありません。実務では、次の4点に分解して確認する方が役に立ちます。
| 観点 | 確認すること |
|---|---|
| オープン性 | dbt Coreのライセンス、開発体制、コミュニティ運営がどう保たれるか |
| 責任分界 | Fivetran側の抽出・ロードとdbt側の変換で、失敗時の責任がどう分かれるか |
| メタデータ | lineage、Catalog、Semantic Layer、BI連携の情報がどこに集まるか |
| 既存運用への影響 | 契約、権限、監査ログ、CI、ジョブ監視が変わるか |
公式発表は方向性の一次情報として有用です。一方で、個別契約、提供範囲、統合作業の進み方は時期によって変わります。ロードマップを確定事実として読むのではなく、導入前チェックの入口として扱ってください。
ROI・事例の読み方
Forrester ConsultingのROI記事やJetBlueの事例記事が示す数字を、私は自社の期待効果としてそのまま移植すべきではないと考えています。理由は単純です。既存のデータ品質、ウェアハウス費用、レビュー文化、CIの成熟度、BI利用者の数が違えば、同じ施策でも効果の出方が変わるからです。
これらの資料を読む価値があるとすれば、数字そのものではなく、何が効果を生んだ構造だったかという型にあります。開発速度の数字を見るなら、自社ではPRレビューと本番反映までの待ち時間がどこで詰まっているかを問い直す。品質の数字を見るなら、壊れたデータを誰がどのタイミングで発見しているかを問い直す。ドキュメントの数字を見るなら、指標や列の意味がBI利用者まで届いているかを問い直す。オンボーディングの数字を見るなら、新メンバーがモデル構造を読めるまで何日かかるかを問い直す。コストの数字を見るなら、変換の再実行や重複テーブル、手戻りが費用を押し上げていないかを問い直す。ROI記事や事例記事は、導入稟議の結論ではなく、社内計測項目を設計するためのヒントとして読むべきです。
競合を見る前に、責務を分ける
dbtを検討すると、SQLMesh、Coalesce、Dataform、SnowflakeやDatabricksのネイティブ機能なども比較対象になります。ただし、一覧表だけで勝敗を決めると失敗しがちです。まず、データ変換基盤に求める責務を分けます。
| 責務 | 代表的な問い |
|---|---|
| 変換定義 | SQL、Python、GUIのどれを中心にするか |
| 実行 | どこでジョブを動かし、失敗時に誰が見るか |
| 品質 | テスト、契約、監視、アラートをどう設計するか |
| メタデータ | lineage、カタログ、指標定義をどこに置くか |
| 開発体験 | ローカルIDE、レビュー、CI、プレビュー環境をどう作るか |
| ガバナンス | 権限、監査、承認、データ契約をどこまで求めるか |
dbtの強みは、SQL中心のチームがコードレビューとテストを持ち込みやすいことです。一方、GUI中心のチーム、ウェアハウス内蔵機能で完結したいチーム、Python変換が多いチームでは、別の選択肢が合うこともあります。
競合比較
導入を判断する：小さく始めるための具体チェック
最初に決めるべきなのは、どのテーブルをdbtで作るかです。生データのコピー、ステージング、中間モデル、マート、指標定義を一気にdbtへ寄せると、初期プロジェクトが読みにくくなります。おすすめは、既に重要だが壊れやすい指標を1つ選び、その上流だけを小さく移すことです。
命名はstg_、int_、fct_、dim_のような規則そのものが正解ではありません。大切なのは、チーム内で「このモデルはどの層か」がすぐ分かることです。テストは最初からすべてを網羅する必要はなく、次の条件を優先します。
| 条件 | 例 |
|---|---|
| 主キー | unique、not_null |
| 重要な状態値 | accepted_values |
| 参照関係 | relationships |
| 数値の異常 | カスタムテストや監視ツールと連携 |
ドキュメントは列説明を全部埋めるより、ビジネス指標、集計粒度、更新頻度、利用上の注意を優先する方が実務では役に立ちます。そしてdbtの価値は、SQLをレビュー可能にするところにあります。PRで何を検証するか、どのモデルだけを実行するか、本番反映前に誰が承認するかを、CIの設計として先に決めておいてください。
既存の重要指標を1つ選び、上流SQLの所在と責任者を書き出すところから始め、dbtのquickstartでmodels、sources、tests、docsの関係を確かめ、公式docsでFusion engine、Semantic Layer、Catalog、Orchestratorの役割を確認する。Fivetranを併用している場合は、統合発表が契約・監査・運用に与える影響も合わせて確認します。これが、上で定義した責任分界を自社の言葉で埋める作業です。
dbt Labsの成長タイムライン
結び：資本イベントで変わるもの、変わらないもの
ここまでの材料を、変わりやすさで並べ直します。
製品名、価格帯、機能の統廃合、Fivetranとの契約・統合の進み方は、資本イベントや時期で変わります。公式Developer Hubに並ぶ製品名も、今後さらに変わっていくでしょう。一方、SQLをref()で参照し、テストとドキュメントを添え、Gitレビューにかけ、依存グラフの上に置くという規律そのものは、会社がどう変わっても価値を失いません。dbt Labsが広げたのは機能ではなく、この規律を「個人の持ち物」から「チームの資産」に変える型です。
私が次に確かめたいのは、この型を実際に1つのプロジェクトで動かしたときに、どこで摩擦が起きるかです。
関連記事
参考リソース
dbt Labs公式
製品docs
Fivetran統合発表
- Fivetran and dbt Labs Unite to Set the Standard for Open Data Infrastructure
- dbt Labs + Fivetran: Open data Infrastructure for analytics and AI
事例・投資対効果
- The return on investment of dbt Cloud
- JetBlue eliminates data engineering bottlenecks with dbt
- Analytics Engineering Guide
本記事はネクサフローのAI研究シリーズの一部です。
