AI活用を見据えたdbt Core導入事例

参考になった

レビュー投稿日の情報になります

株式会社ニーリー / 清水光司

最終更新日2025/07/29投稿日2025/07/30

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

dbt Core

データモデリング、ドキュメント化

10名以下

2025年5月

B to B

B to C

利用プラン	dbt Core
利用機能	データモデリング、ドキュメント化
ツールの利用規模	10名以下
ツールの利用開始時期	2025年5月
事業形態	B to B B to C

アーキテクチャ

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

PdMやビジネスチームがデータ分析を行える状態にするためには、Viewやデータマートの整備が急務でした。なぜなら、当時は下記のような課題があり、データへのアクセシビリティが低い状態であったためです。

既存ツールの機能不全: BIツールとして利用しているRedashのLoad Schema機能がロード対象オブジェクト数の多いデータ基盤に対して機能しなくなり、テーブル名やカラム名を参照できない状態でした。
**使いにくいデータカタログ: ** 既存のテーブル定義ドキュメントは検索性が悪く、更新漏れもあるため信頼性が低く、また「どのテーブルがどんなカラムを持っているか」は問題なく検索できますが、「このカラムはどのテーブルに含まれているか」が把握しづらい作りになっていました。これにより、SQLクエリを作成するにあたって基本的な情報を把握するのにも時間がかかっていました。

どのような状態を目指していたか

上記課題を解決するため、以下の状態を目指していました。

データアクセシビリティの向上: 分析用のデータマート・Viewを整備し、Analyticsチームをはじめとする社内のデータ利活用者が必要なデータにすぐにアクセスできる状態
信頼できるデータカタログの構築: データマート・Viewの定義や、それらのソースとなる既存テーブルの情報を一元的に管理・参照できるデータカタログが整備されている状態
効率的な開発フローの実現: 今後のAI活用（自然言語からSQL生成など）には、分析用データマートの整備とデータカタログが不可欠であるため、これらを効率的に開発できる状態

上記の状態を目指してまずはdbt Coreを試したところ、求めている状態を目指すのに必要十分であったため、本格的に導入を開始しました。

導入の成果

導入して2ヶ月が経過した現在地について、まずチーム外の状況としてはPdMやマーケティングチームなどデータ分析に特に関心が高い利活用者にデータマートやデータカタログを利用してもらえるようになってきた状態です。具体的には、データカタログをAIにインプットすることでAI活用して実用的な分析用のSQLを作成できるようになったり、幾つものテーブル結合が必要な分析用の基礎となるデータマートを作成し、それを元に分析タスク自体は利活用者側が自身で進められるようになったりしつつあります。

一方でAnalayticsチーム内ではSQLを作成する際にデータカタログを活用したり、dbtのリポジトリをGemini CLIに読ませて自然言語からSQLの骨組みをスピーディに生成したり、データモデルをコードベースで管理し始めたことでAIを活用できる環境が整いつつあります。

導入に向けた社内への説明

上長・チームへの説明

Viewやデータマートを整備しなければならないという課題についてはdbtを試してみる以前から共有できていたこと、dbt CoreについてはOSSのため費用発生がなかったことから、課題解決のための手段としてまずはやってみようという形で、特に説明は発生しませんでした。

活用方法

よく使う機能

データモデリング機能

dbtの中核である、SQLを使って宣言的にデータモデルを定義・構築する機能です。このプロジェクトでは、dbtのモデリング機能を最大限に活用し、再利用性とメンテナンス性の高いデータ変換パイプラインを構築しています。

特徴：階層的なデータモデリングの実践

このプロジェクトでは、データ変換のプロセスをbase, intermediate, martsという3つのレイヤー（階層）に分割するアプローチを採用しています。

base層: データソースからロードした生データをクレンジングし、カラム名の変更やデータ型のキャストなど、基本的な整形のみを行います。これにより、元のデータソースの変更に強い、安定した土台を築きます。
intermediate層: base層のモデルを複数組み合わせ、複雑なビジネスロジックや変換処理を集約します。例えば、複数テーブルのJOINや、ウィンドウ関数を用いた集計などがこの層で行われます。ロジックをintermediate層にまとめることで、marts層のモデルがシンプルになり、再利用性も高まります。
marts層: intermediate層のモデルをさらに組み合わせて、BIツールでの可視化やデータ分析で最終的に利用される「データマート」を作成します。分析の目的に応じて、必要なデータを集約したワイドテーブルなどを構築します。

このように、dbtのref()関数を使ってモデル間の依存関係を定義し、処理を段階的に積み上げていくことで、複雑なデータパイプラインを非常に見通し良く管理できます。

ドキュメント化機能

dbtは、作成したデータモデルに関するドキュメントを自動生成し、データカタログとして共有する強力な機能を備えています。

特徴：ドキュメントの一元管理と自動公開

このプロジェクトでは、dbtのドキュメント機能を以下のように活用しています。

descriptionの記述: モデルやカラムの定義ファイル（.yml）に、descriptionキーを使って説明文を記述します。これにより、「このモデルは何を表しているのか」「このカラムには何が入っているのか」といったメタデータがコードと共に管理されます。
dbt docs generate: 上記のdescriptionや、モデル間の依存関係、定義されたテスト内容を元に、dbt docs generateコマンド一つで網羅的なデータカタログサイト（HTML）を生成できます。
persist_docs: dbt_project.ymlでこの設定を有効にすると、.ymlに記述した説明文が、dbt run実行時にBigQueryなどのデータウェアハウスのテーブル・カラムコメントにも反映されます。これにより、仮に将来的にはGoogle Cloud上のデータカタログツールを使うことになったとしても、dbtで管理しているメタデータを活用することができます。
CI/CDによる自動公開: さらに、GitHub Actionsを利用して、コードが更新されるたびにdbt docs generateを実行し、生成されたデータカタログを自動でS3にデプロイする仕組みを構築しています。これにより、関係者はいつでも最新のドキュメントにWebブラウザからアクセスできます。

データモデルという「コード」と、その説明である「ドキュメント」をdbtで一元管理し、常に最新の状態を保つことで、属人化を防ぎ、組織全体のデータ活用を促進します。

ツールの良い点

SQL中心で学習コストが低い

データ分析に関わる多くの人が慣れ親しんでいるSQLをそのまま使えるのが最大のメリットだと思います。複雑なプログラミング言語を習得することなく、Analyticsチームにいるメンバーであればソフトウェアエンジニアリングのベストプラクティス（バージョン管理、テスト、ドキュメンテーション）を取り入れられます。

データ品質を担保するテスト機能

not_nullやuniqueといった汎用テストから、SQLでビジネスロジックを記述するカスタムテストまで、データに対するテストを定義・実行できます。これにより、データの品質と信頼性を継続的かつ体系的に担保できるため、プロジェクトとしてテスト実装方針(本プロジェクトでは未定で、これから定める予定)を決めておけば、検算のプロセスを改善できそうです。(例えば行数確認、case文のチェックなどはテストで定義できるため、検算用のクエリを作ってそれをレビューしてもらうなどは不要)

ドキュメントの自動生成と一元管理

モデルやカラムの定義ファイル（.yml）にdescriptionを記述するだけで、データリネージ（データの依存関係）を含む網羅的なドキュメントサイトを自動生成できます。 DBやDWHに存在している情報は以下のコマンドにより定義ファイルを生成できるため、不足している情報を補うだけでメタデータを管理できます。(事前にcodegenをpackages.ymlに記載した上でdbt deps実行が必要)

モデル定義ファイルの生成

dbt -q run-operation generate_model_yaml --args '{ "model_names": ["<モデル名>"] }' > models/marts/<モデル名>.yml

ソース定義ファイルの生成

dbt -q run-operation generate_source --args '{"schema_name": "<データセット名>", "table_names": ["<テーブル名>"], "generate_columns": true, "include_data_types": true}'

上記コマンドで出力できるyamlファイルと、既存のテーブル定義ドキュメントを構造化したcsvファイルを用いて、生成AIにテーブルやカラムのdescriptionを埋めさせるような効率化をしています。

さらにpersist_docs機能で、その説明をBigQueryなどのDWHのメタデータにも反映可能です。これにより、データがブラックボックス化するのを防ぎ、属人性を排除します。

ref()とsource()による再利用性と保守性の向上

モデル間の依存関係をref()関数で定義することで、物理的なテーブル名（例：my_project.my_dataset.my_table）をハードコーディングする必要がなくなります。これにより、環境の切り替え（開発/本番）が容易になり、データリネージが自動で追跡されるため、保守性が劇的に向上します。

Jinjaマクロによる高度な抽象化

SQLにプログラミング言語の要素（変数、forループ、if文など）を持ち込めるJinjaテンプレートエンジンが組み込まれています。これにより、繰り返し発生するSQLパターンをマクロとして抽象化（DRY: Don't Repeat Yourself）でき、コードの再利用性を高め、冗長な記述を減らすことができます。弊社のdbtプロジェクトでは永続UDFの管理にもマクロを利用しています。

オープンソースであり、エコシステムが豊富

dbt Core自体は無料で利用できます。また、CLIツールであるため、様々な外部ツールと柔軟に連携可能です。このプロジェクトでも、GitHub ActionsでCI/CDを構築し、TROCCOでジョブのスケジューリングを行うなど、既存のワークフローにスムーズに組み込めています。

ツールの課題点

実行スケジューリング機能の不在

dbt Coreは、あくまでデータ変換処理を実行するためのCLIツールであり、単体では「毎日午前5時に実行する」といったスケジューリング機能を持っていません。そのため、(dbt Cloudを利用しない前提で)実際の運用するとなるとAirflow, Dagster, Google Cloud Composerといったワークフローエンジンや、このプロジェクトで採用しているTROCCOのような外部のスケジュール機能を持つツールが別途必要になります。弊社では既にデータ転送ツールおよびワークフロー管理ツールとしてTROCCOを利用しており、この課題はすぐにクリアになりました。

今後の展望

dbtによるデータ基盤の整備は少しずつではありますが成果を上げつつあります。これまでSQLにほとんど触れてこなかった社員が自ら分析を始める事例が生まれているほか、Analyticsチームへのアドホックな分析依頼に対しても、dbtリポジトリとAIを連携させることで高精度なSQLを即座に生成できた事例もあります。

この成功の鍵は、dbtがデータモデルをコードとして管理できる点にあり、これがAIへの高品質なインプットを可能にする基盤となっています。

今後の展望としては、この「データモデル × AI」の連携をさらに深化させ、将来的には既存のBIツールに蓄積されたクエリも組み合わせることで、専門知識の有無にかかわらず、全ての社員がデータを自在に活用できる「データ活用の民主化」を推し進めていきたいと考えています。

株式会社ニーリー / 清水光司