なぜdbtで中間集計するのか

AIエージェントにソースデータを直接クエリさせると、集計ロジックの解釈が毎回ブレて回答が安定せず、クエリ・トークンのコストも膨らみます。本資料では、正しい集計ロジックを前もって適用する「中間集計」の必要性と、その実装をStored Procedure等の自前実装ではなくdbtで標準化すべき理由（開発・テスト・レビュー・ドキュメントの4つの課題と解決策）を解説します。さらに、dbt MCP Server / Agents Schema / dbt Stateを活用したAI-Readyなデータ基盤への道のりを紹介します。

Transcript

1. Cross Data Platforms Meetup #3 ── dbtとの併用 なぜdbtで中間集計するのか 信頼できるデータを、コスト効率よくAIに使わせるために
2. 自己紹介 @myshmeh Partner Solutions Architect, dbt Labs スライド作りすぎました。急げ！ 2
3. データ基盤がAI-Readyであるには、いくつか条件がありそう 条件 1 条件 2 条件 3 データが正確である データの意味が明記さ れている 低コストで扱える ⽰唆出しの基礎はデータ。⼟台が 不正確なら、どんな分析も信頼で きない。 カラムとビジネス⽤語の対応や品 質の明記がなければ、AIは⼀般的 な推測で進めてしまう。 エージェントは⼈間より⼤量にク エリしうる。クエリとトークンの コストが論点になる。
4. AI-Readyまでの道のりは、段階に分けて考えることができる STAGE 3 AI-Ready 条件2 データの意味 STAGE 2 信頼できるデータ 条件3 低コスト 信頼できるデータを、MCP・Semantic Layer・Stateでコスト効率よくAI活 ⽤。ROIのあうエージェントへ。 条件1 データが正確 STAGE 1 ⾃前実装の中間集計 中間集計の開発プラクティスをdbtで標 準化。 Stored Procedure等で⾃前実装。開発 が遅く、データ・ドキュメント品質が 低い。 AI Maturity →
5. 今日お話したいこと : データ基盤が AIReadyであるために、なぜ dbtは有用なのか？ 1 なぜ中間集計なのか 2 なぜdbtなのか 3 結論 + おまけ ‒ Open Data Infrastructureとは
6. 01 なぜ中間集計なのか
7. ソースデータだけで、エージェントは正しく集計できるか？ 「できるかもしれないし、できないかもしれない」 LLMは確率的な挙動により、毎回異なるクエリを構築するから
8. 「⽉ごと・商品ごとの売上」への回答は毎回変わる ⽰唆を信⽤できない上、信⽤できるまで対話を重ねるとクエリ・トークンのコストが膨らむ
9. 中間集計で、正しい集計ロジックを前もって適⽤しておく では、中間集計さえしていれば良いのか？ ── 細かい実装⽅法は、何でも良いのだろうか？
10. 02 なぜdbtなのか ⾃前実装の課題を整理し、dbtがどう解決するかを⾒る
11. §02 なぜdbtなのか STAGE 3 1 AI-Ready ⾃前実装の課題 STAGE 2 2 dbtによる開発プラクティス標準化 信頼できる データ STAGE 1 ⾃前実装の 中間集計 3 AI-Readyに向けて
12. ⾃前実装の課題 ── Stored Procedureの例 開発 テスト コードが複雑で、限られた⼈しか書けない 画⼀したテスト⼿法がない 各DWHのDDLを理解している⼈は少ない。特に増分更新のロ ジックは難解になりやすい。 テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
13. テストがない ── エラー原因の特定に時間がかかる 実際に使われるまで違和感に気づけず、エラー原因の特定に時間がかかる
14. ⾃前実装の課題 ── Stored Procedureの例 開発 テスト コードが複雑で、限られた⼈しか書けない 画⼀したテスト⼿法がない 各DWHのDDLを理解している⼈は少ない。特に増分更新のロ ジックは難解になりやすい。 テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
15. 実⾏順序は⼿作業 ── 変更の反映漏れがデータ障害に リファクタ・追加開発のたびに、実⾏順序管理でヒューマンエラーが起きかねない
16. ⾃前実装の課題 ── Stored Procedureの例 開発 テスト コードが複雑で、限られた⼈しか書けない 画⼀したテスト⼿法がない 各DWHのDDLを理解している⼈は少ない。特に増分更新のロ ジックは難解になりやすい。 テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
17. ⾃前実装の課題 ── Stored Procedureの例 開発 テスト コードが複雑で、限られた⼈しか書けない 画⼀したテスト⼿法がない 各DWHのDDLを理解している⼈は少ない。特に増分更新のロ ジックは難解になりやすい。 テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。 データが信頼できず、データドリブンな意思決定が進まない
18. §02 なぜdbtなのか STAGE 3 1 AI-Ready ⾃前実装の課題 STAGE 2 2 dbtによる開発プラクティス標準化 信頼できる データ STAGE 1 ⾃前実装の 中間集計 3 AI-Readyに向けて
19. dbtは、DWHの⽣データを分析⽤に加⼯するためのフレームワーク
20. dbt Labsは、セルフホスト・マネージド版の両製品を提供している dbt platform MANAGED・有料 Self-hosted製品の上に、統合開発環境・CI/CD・Semantic Layer・ マルチプロジェクト管理等の機能を提供 dbt Fusion SELF-HOSTED・無料 Coreの機能に加え、⽂法・意味チェック、カラムレベルリネージ等の SQL解析機能を提供 dbt Core SELF-HOSTED・無料 OSS。モデル定義・テスト・リネージなどの基本機能を提供
21. dbtは、⾃前実装の各課題をどう解決するか？ 開発 テスト コードが複雑で、限られた⼈しか書けない 画⼀したテスト⼿法がない 各DWHのDDLを理解している⼈は少ない。特に増分更新のロ ジックは難解になりやすい。 テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
22. dbtは、⾃前実装の各課題をどう解決するか？ 開発 テスト コードが複雑で、限られた⼈しか書けない 画⼀したテスト⼿法がない 各DWHのDDLを理解している⼈は少ない。特に増分更新のロ ジックは難解になりやすい。 テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
23. dbtは、簡単なSQL SELECT文で変換ロジックを定義できる コンパイル mart_customer_revenue.sql DDL 実行リクエスト DWH 23
24. 自動でモデルリネージを構築するため、変更時の影響範囲が特定しやすい 作成 mart_customer_revenue.sql ref()により、依存先モデルを特定 モデル間の依存関係図 （モデルリネージ） 24
25. dbtは、⾃前実装の各課題をどう解決するか？ 開発 テスト シンプルなSELECT⽂でモデル定義 画⼀したテスト⼿法がない アナリスト含む⾮技術者も参加でき、デリバリーが速くなる テストなしでは、実際に使われるまで違和感に気づけない。 エラー原因の特定も困難。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
26. dbtでのテスト dbtではテストが容易に導入できる各種フレームワークを用意 Generic Data Tests Unit Tests Singular Data Tests not_null、unique、許容 値、参照整合性の検証であれ ば、モデルのymlに １〜２行追記するのみ ダミーの入出力値を設定して ロジックを検証する ユニットテストも容易に導入 可能 モデルのロジックやデータの 検証には、”tests”ディレク トリに、成功時に0行になる sqlファイルを置くのみ 26
27. dbtは、⾃前実装の各課題をどう解決するか？ 開発 テスト シンプルなSELECT⽂でモデル定義 モデル毎のテストを宣⾔的に定義 アナリスト含む⾮技術者も参加でき、デリバリーが速くなる データ・ロジックの両⾯からデータ品質を担保できる。 デプロイ前にエラー検知し、原因を特定しやすい。 レビュー・デプロイ ドキュメント レビューなしに定義が変わり、実⾏順序は⼿作業 整合性を継続的に担保できない バージョン管理されない。リファクタ時に順序変更を反映し 忘れ、データ障害の危険。 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
28. dbtはコードファーストなため、Gitでバージョン管理ができる Data Warehouse dbt + Git レビューされ、 承認されたコードのみが 次に環境に反映される 複数人の 並行開発が可能 feature_2 branch feature_1 branch main branch prod 知らない間にロジックが変わっていた。。というアクシデントを防げる！ 28
29. モデルリネージに基づきモデル作成されるため、手作業の実行順序管理が不要にな る！ fct_ordersと全上流モデルを実行 fct_orders周辺のリネージ図 自動で実行順序を解決 29
30. dbtは、⾃前実装の各課題をどう解決するか？ 開発 テスト シンプルなSELECT⽂でモデル定義 モデル毎のテストを宣⾔的に定義 アナリスト含む⾮技術者も参加でき、デリバリーが速くなる データ・ロジックの両⾯からデータ品質を担保できる。 デプロイ前にエラー検知し、原因を特定しやすい。 レビュー・デプロイ ドキュメント Gitによるバージョン管理、実⾏順序の⾃動解決 整合性を継続的に担保できない 意図しない変更・反映漏れによるデータ障害を防げる 結果、誰も読まなくなり、集計知識の属⼈化から抜けられな い。
31. YAMLファイルにモデル・カラム情報を記載できる モデルの説明 カラムの説明 カラムのテスト mart_customer_revenue.yml 31
32. dbt Catalogにモデル・カラム情報が反映される モデル説明 カラム説明 カラムのテスト テスト結果一覧 32
33. dbtは、フレームワークとして開発⼯程を標準化し、開発障壁を下げ・データ障害を 最⼩化する。結果、データが信頼できるようになる！ 開発 テスト シンプルなSELECT⽂でモデル定義 モデル毎のテストを宣⾔的に定義 アナリスト含む⾮技術者も開発に参加でき、デリバリーが速 くなる データ・ロジックの両⾯からデータ品質を担保できる。 デプロイ前にエラー検知し、原因を特定しやすい。 レビュー・デプロイ ドキュメント Gitによるバージョン管理、実⾏順序の⾃動解決 モデルのドキュメントをコードから⾃動⽣成 意図しない変更・反映漏れによるデータ障害を防げる 整合性が保たれ、集計知識の属⼈化から抜けられる データの信頼は確保した。では、AIエージェントにとっての意味の理解とコスト効率は？
34. §02 なぜdbtなのか STAGE 3 1 AI-Ready ⾃前実装の課題 STAGE 2 2 dbtによる開発プラクティス標準化 信頼できる データ STAGE 1 ⾃前実装の 中間集計 3 AI-Readyに向けて
35. どうしたらROIの合うAIエージェントをローンチできるか？ データの意味 課題 1 課題 2 エージェントは、データの成り⽴ちを理解していない エージェントは、ビジネス指標とデータの対応 を理解 していない どのソースから、どんな加⼯を経て作られたデータなのか 「売上」と⾔ったとき、どのモデルのどの集計を指すのか コスト効率 課題 3 モデル作成は、効率的に⾏われているか？ ⼩さな変更ひとつで、パイプライン全体が再構築していないか？
36. The dbt MCP Server 構造的なコンテキストを AIエージェントにもたらす標準として LLM & AI orchestration Data & AI platform dbt Structured Context Layer ✅ Safe agentic data development dbt MCP Server ✅ Trusted conversational analytics ✅ - Models - Docs - Freshness - Metrics - Lineage - Ownership Cost-efficient AI
37. Agents Schema: DWHに置く、オープンソースの AIコンテキスト標準 ✓ どのDWHでも対応 ✓ オープンソース , ユーザ 所有のスキーマ ✓ DWHの権限管理機能を用 いたガバナンス Agents Schema は、セマンティックモデル、ビジネスドキュメントを SQL テーブルとして保存し、オープンソースの GitHub Actions を通じて公開します。現在ご利用いただけます！
38. dbt State：変更されたモデルだけをビルド データとコードの変更を検出してビルドすべきモデルを自動的に判断し、残りはスキップ コストを最適化 ：上流で変更されたものだけをビルドし、鮮度SLA（サー ビスレベルアグリーメント）を順守することで、平均30%のコンピューティ ングコストを削減* 自由に実行 ：実行回数を制限する必要がなくなり、ビジネスの必要に応 じてスケジュールしてデータをより新鮮に保ち、高価なミスや破壊的な変 更を恐れることなく迅速に反復処理が可能 データ変更なし 再利用モデル STG 中間層 ソース Model Model src_orders stg_orders int_orders ソース古い モデル再利用 モデル再利用 マート Model cust_orders モデルビルド済み 複雑性を軽減： カスタムワークフローや手動オーケストレーションを排除 し、dbt Stateをオンにするだけでビルドが可能 どこでも実行可能 – dbt Coreのプラグインとして、またはdbt platform で利用できるため、dbtを実行する場所に関係なくコストを最適化し、時 間を節約 STG マート ソース Model Model src_customers stg_customers dim_customers ソース新鮮 データ変更あり モデルビルド済み モデルビルド済み ビルド済みモデル 対応dbt：dbt platform、Fusion（v2.0）、dbt Core 1.12、 dbt Core 1.71.11（要プラグイン） *平均30%のコンピューティングコスト削減はデザインパートナーの結果に基づくも のです。個々の削減額は、プロジェクトの構成とワークロードによって異なります。
39. 03 結論
40. Q. データ基盤がAI-Readyであるために、なぜdbtは有⽤なのか？ A. 信頼できるデータ・意味を、コスト効率良く提供でき るから 1 開発プラクティスの標準化で、デリバリーが速くなり、異常は使われる前に検知できる。 だから データが信頼できる。 2 MCPサーバ/Agents Schemaを通じてデータの意味を構造的に提供、dbt Stateで無駄なモ デル作成を省く。だから コスト効率良くAI活⽤できる。 → dbtで、AI-Readyな中間集計を始めてみませんか？
41. APPENDIX おまけ ‒ Open Data Infrastructureとは
42. Fivetran + dbt Labs の目指す Open Data Infrastructure 柔軟なストレージ＋コンピュート あらゆるクラウド・コンピュート・LLMに対応 信頼性の高いデータ移動 あらゆるデータを確実に収集 豊富なメタデータとコンテキスト エージェントのための追跡可能な情報 スケーラブルなインフラ エージェントのスケールに対応