dbt project を安全に運用する

Stage 5 — 第3章（Capstone） | dbt入門カリキュラム 推定学習時間：50〜60分 | 難易度：★★★★☆

この章で学ぶこと

ここまで analytics_mcp/dbt/dsplayground/ の staging → intermediate → mart → test → macro → snapshot → exposure を追ってきました。 最終章では 運用スキーマ、GitHub Actions、docs artifact の境界を学び、トラック全体を 1 枚の地図 に収めます。

コードは実行しません。warehouse 資格情報も扱いません。 データマネジメント入門 と データアナリティクス入門 で学んだ「信頼できる数字の仕組み」が、dbt プロジェクトで どう実装されているか を振り返ります。

この章を終えると、こんなことができるようになります：

• analytics と analytics_ci の役割分担を説明できる
• dbt docs が 公開 Pages ではなく CI artifact である理由を説明できる
• 主要 caveats（membership proxy、latest-state accuracy、anon キー）を 一覧で 説明できる
• Stage 1〜5 の学習経路を自分の言葉で要約できる

本番 schema と CI schema

dbt プロジェクトをチームで運用するとき、本番 BI が読む schema と PR 検証用 schema は分けます。

PR 上の実験的 SQL が 本番ダッシュボードを壊さない ためです。 レイク・DWH・マート の「分析環境分離」と同型です。

CI パイプライン

典型的な CI ジョブは次を一括実行します。

1. dbt build（run + test）
2. schema tests（YAML の data_tests）
3. singular tests（tests/*.sql）
4. dbt docs generate（lineage 含む）

secrets（warehouse 接続情報）は repo 設定にのみ置き、カリキュラムや公開ドキュメントには載せません。 CI ログと artifact 名を知っていれば、マージ前に品質ゲートが走っている ことを確認できます。

dbt docs と artifact 配布

dbt docs generate は、モデル SQL・列メタデータ・lineage・exposure まで含む 内部向けドキュメント を生成します。

公開 Web（GitHub Pages 等）に載せない理由は、公開範囲の最小化 です。

社内利用者は CI artifact から index.html を開き、lineage グラフ で exposure まで追います。 ガバナンス実践 の考え方と一致します。

テスト戦略の全体像

テストは ドキュメント でもあります。 品質 6 軸 の「完全性・一意性」を CI で自動化したイメージです。

宣言的契約（schema test）と手続き的断言（singular test）を CI 上の dbt build で回す——これが dbt プロジェクトの標準的な品質モデルです。

2 つの schema

DBT_USER は read-only on public + write on 対象 schema のみ（README 参照）。

PR 時に mart を build する schema として CI 専用 schema を使うことで、本番 analytics を守ります。

GitHub Actions

dbt-daily.yml（本番）

• DBT_SCHEMA=analytics
• dbt build — run + test
• docs artifact 保存

dbt-ci.yml（検証）

• DBT_SCHEMA=analytics_ci
• push / PR で dbt build + test + docs generate
• 本番 Metabase は更新しない

会議前チェックリスト（Capstone）

DS Playground analytics を 会議で使う前 に確認する caveats 一覧です。 分析前チェックリスト を dbt 版として使えます。

トラック全体の学習経路（Capstone 図）

Stage 別ふりかえり

Stage 1 — なぜ dbt か

Supabase = ソース正本、dbt = transform SSOT、Metabase = 利用面。 再現可能な pre-monetization monitoring が目的（overview.md）。

Stage 2 — 信頼の土台

Thin staging、schema/singular test、seed catalog。 データ品質チェック SQL の upstream。

Stage 3 — コア mart

• int_user_activity_events — Learning Action SSOT
• Membership / conversion — terms proxy と転換率 caveats
• Active user — faithful DAU + status 分割
• Incremental — 14 日 lookback 教学例

Stage 4 — セグメントと研究

• Monetization status — free / premium / former_premium
• Engagement — tier + 分布 mart + anon 境界
• Survey — goal share + multi-select unnest
• Content quality — seed 分母 + outlier フラグ

Stage 5 — 再利用と運用

• safe_ratio — 比率 SSOT
• Snapshot + exposure — 履歴と dashboard lineage
• CI / docs — 本番を守る build 規律

次の学習ステップ

体系コラム：カリキュラム上の位置づけ

まとめ

dbt 入門は「SQL を書く教程」ではなく、DS Playground の analytics 定義を読み解き、会議で数字を説明できる状態 を目指しました。 transform・テスト・lineage・CI が一体になって初めて 信頼できるデータ になります。

関連教材

• トラック起点: なぜ dbt Core か
• 横断（DM）: データマネジメント入門
• 横断（Analytics）: データアナリティクス入門
• リポジトリ: analytics_mcp/dbt/dsplayground/models/overview.md

確認問題

問題 1

Pull Request 時に mart を build する schema として 一般的に望ましい のはどれですか。

A. OLTP の public スキーマ
B. CI 専用 schema（例: analytics_ci）
C. 本番 analytics schema を常に上書き
D. アプリ認証 schema

正解: B

解説: CI は専用 schema で検証し、本番 schema を守ります。

問題 2

dbt docs を内部 artifact のみで配布する 主な理由 はどれですか。

A. dbt が HTML を生成できないから
B. 内部 SQL・schema・lineage などを公開 Web に載せないため
C. BI ツールが docs を読めないから
D. OLTP のポリシーで禁止されているから

正解: B

問題 3（Capstone 総合）

dbt プロジェクト全体の設計思想として 最も central な考え方はどれですか。

A. BI ダッシュボード JSON
B. intermediate 層で指標定義を SSOT 化し、marts は BI 向けに grain を固定する
C. GitHub Actions YAML のみ
D. OLTP テーブルを mart から直接読む

正解: B

解説: Transform の責務は 定義の固定（intermediate） と 問いへの回答（marts） の分離です。

問題 4（Capstone 総合）

このトラックで繰り返し登場する 品質ゲート の組み合わせとして最も適切なのはどれですか。

A. BI 上の目視のみ
B. schema tests（YAML）+ singular tests（SQL）+ CI 上の dbt build
C. seed ファイルの手動コピーのみ
D. macro のコメントアウト

正解: B

解説: 宣言的契約と手続き的断言を CI で回すのが、dbt プロジェクトの標準的な品質モデルです。

用語メモ（トラック総括）