dbt metrics 実務ガイド: 指標の定義と利用を“壊れない”形で設計する

指標は最終成果物ではなく、意思決定のための契約です。定義場所と計算方法がブレると、BIの数字がツールごとにズレます。本稿では、dbtにおける指標定義の選択肢を、モデルによる集約とSemantic Layerによる統一定義の両面から整理します。

dbt公式の機能はバージョンで変遷があります。特に旧来のmetricsリソースは非推奨方向で、現在はdbt CloudのSemantic Layer（MetricFlowベース）が推奨です。資格対策では、安定して問われやすい概念（粒度、テスト、系譜、ガバナンス）に軸足を置きつつ、新旧の位置づけを押さえておきましょう。

指標をどこで定義するか: モデル vs Semantic Layer

dbtでの指標の置き場所は、大きく2つに分かれます。ひとつは集約済みのマートモデルを作る方式、もうひとつはSemantic Layerでmeasureとmetricを宣言して下流ツールから呼び出す方式です。前者はどのDWHでも動く普遍性、後者は定義の一元化と接続先での再利用性に強みがあります。

現場では、まず事実テーブルとディメンションの正規化、時間粒度の統一、フィルタ条件の合意を済ませてから、どちらの方式を選ぶかを決めるのが堅実です。

• モデル方式: fct_ / dim_ を整備し、必要な集約ビューをdbtモデルとして提供
• Semantic Layer方式: measures・dimensions・metricsをYAMLで宣言し、ツール横断で再利用
• どちらでも共通: 粒度、フィルタの既定、null/重複の扱い、テストの自動化
• データプラットフォーム非依存性を優先するならモデル方式、組織横断の定義一元化を優先するならSemantic Layer

指標の系譜と利用の流れ

モデルで指標を表現する: 安定・移植性重視の作り方

マート層で事実テーブルを整備し、AOVやCVRなどの指標をビュー/テーブルとして提供する方法です。どのDWHでも使え、dbt Coreのみで完結するため、試験でも本流として問われやすいです。

ポイントは一貫した粒度管理と、集約ロジックの再利用です。たとえば日次・週次・月次と3つ作るのではなく、最小粒度（日次）を基本に、下流でロールアップ可能な形に保ちます。

• 粒度の明示: date_day, customer_id などを主キーに含める
• フィルタの既定値は列として持つよりも、ビュー層で統一的に適用
• 重複行・遅延到着の扱いをstgで潰す（surrogate key、windowで最新行など）
• tests: unique, not_null, accepted_values を必ず用意
• exposuresでダッシュボード依存関係を可視化して監視対象にする

Semantic Layerで指標を定義する: 再利用性と一貫性の最大化

dbt CloudのSemantic Layer（MetricFlowベース）では、semantic_modelsでエンティティ・ディメンション・メジャーを宣言し、metricsで指標を組み立てます。BIやノートブックがこの層を経由することで、ツール間の指標不一致を防げます。

仕様やキーワードはバージョンで更新されることがあるため、実装前に公式ドキュメントを確認してください。概念としては、measure（集計対象の定義）とmetric（利用者向けのビジネス指標）を分離し、time grainやディメンション、フィルタの既定を明示します。

• measureは集計方法（sum, count, avg など）と式を定義
• metricはmeasureを参照し、必要に応じてratioや派生計算を宣言
• time_granularityや既定フィルタをmetric側に持たせると誤用を防止
• 接続済みBIから同一API経由で取得することで数値の一貫性を担保

Semantic Layerの例: semantic_models と metrics のYAML

semantic_models:
  - name: orders
    model: ref('fct_orders')
    entities:
      - name: order
        type: primary
        expr: order_id
      - name: customer
        type: foreign
        expr: customer_id
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: channel
        type: categorical
    measures:
      - name: orders
        agg: count
      - name: gross_revenue
        agg: sum
        expr: gross_amount

metrics:
  - name: total_revenue
    type: simple
    label: Total Revenue
    type_params:
      measure: gross_revenue
  - name: aov
    type: ratio
    label: Average Order Value
    type_params:
      numerator: gross_revenue
      denominator: orders
    filter: channel != 'internal'
    time_granularity: day

粒度・テスト・ガバナンス: 壊れない指標の作法

壊れない指標は、粒度の明示、入力データ品質の担保、そしてドキュメントの3点で決まります。特に日付とエンティティの組で一意になるかを最初に確認し、nullや遅延到着を想定した設計にします。

テストはstgとmartsの両方に配置します。stgではスキーマ整合と重複排除、martsではキーの一意性、結合の完全性、受け入れ値の検証を行います。Semantic Layerを使う場合でも、土台のモデルテストは省略しません。

• 粒度: 最小粒度で保持し、必要に応じてロールアップ
• フィルタ: ビジネス合意済みの既定フィルタを定義。除外条件は明文化
• null/遅延: 既定値の扱いと更新戦略（スナップショット/増分）を決める
• テスト: unique, not_null, relationships, accepted_values を必須化
• ドキュメント: 指標の定義根拠、分子・分母、例外事項をdocsで公開

指標の利用: BI・ノートブック・アプリからの呼び出し

モデル方式では、集約ビューをBIが直接参照します。Semantic Layer方式では、対応コネクタやAPIを介してmetricを指定して取得します。どちらでも、権限設計とキャッシュ戦略を合わせて考えておくとパフォーマンスが安定します。

ダッシュボードはexposuresでdbtプロジェクトに登録し、上流変更の影響を可視化します。リリース前に該当exposureに対するデータ検証を自動実行すると、指標の破壊的変更を早期に検知できます。

• BI接続: モデル方式はビュー/テーブル参照、Semantic Layerはコネクタ/API参照
• 権限: 最小権限のロールで読み取りを付与。Semantic Layer経由時はCloud側の権限も確認
• キャッシュ: 時系列指標は日次リフレッシュのウィンドウを短くしすぎない
• exposures: type=dashboard の依存関係で影響範囲を追跡
• SLA: 更新頻度と遅延の許容範囲をダッシュボードに明記

試験対策の要点: ひっかけ回避の観点整理

Analytics Engineer試験では、定義の一貫性とデータ品質に関する原則が狙われます。具体プロダクトの細部仕様は変わる可能性があるため、概念の優先順位で判断できるようにしておきましょう。

ひっかけとして多いのは、BIツールごとの計算フィールド乱立や、粒度の不一致による比率の誤差です。分母・分子が同じフィルタと粒度で計算されているかを常に確認します。

• 指標はビジネス定義の契約。定義場所の一元化が最優先
• 粒度が合わない集約の比率は誤差を生む。先に正しい粒度へ揃える
• testsとdocsは合格の定番論点。examplesやaccepted_valuesを活用
• exposuresで下流の可視化を管理し、変更の影響を追跡
• Semantic Layerは概念把握が重要。measureとmetricの役割分担を説明できること

問題で確認

よくある質問