Skip to content
Published on

Semantic Layer・Metrics Store・Reverse ETL 完全ガイド: dbt・Cube・Looker・Hightouch・Census、データ活性化 (2025)

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
シェア
Authors

Season 5 Ep 5 — Ep 4 がパイプラインのエンジニアリングだったなら、Ep 5 は「データの意味を一度だけ定義する」という古い約束の 2025 年版。

プロローグ — 「なぜ売上がチームごとに違う数字になるのか?」

2015 年に多くの企業が経験した古典的な混乱:

  • 財務チーム: 「今月の売上は 10 億」
  • マーケティング: 「今月の売上は 11.5 億」
  • セールス: 「今月の売上は 9.7 億」

同じデータ、違う数字。理由は:

  • 返金の処理方法
  • 税込みかどうか
  • 通貨換算の基準日
  • 認識時点 (注文時 vs 入金時)

各チームが自分の SQL を直接書くため定義が分かれる。Semantic Layer はこの問題を「指標定義を一箇所に」集めて解決しようとする試みだ。

第 1 章 · Semantic Layer の歴史

1.1 第 1 世代: BI 内部の定義

  • Business Objects、Cognos、MicroStrategy (1990s–2000s)
  • 各 BI ツールの内部に定義 → ベンダーロックイン

1.2 第 2 世代: Looker の LookML (2013–)

  • LookML でコード化された指標定義
  • Git 管理、再利用
  • 欠点: Looker 専用

1.3 第 3 世代: Headless / Open Semantic Layer (2020–)

  • BI から独立した別レイヤー
  • dbt Semantic Layer / MetricFlow (2022)
  • Cube (2019–)
  • Transform(2021、→ dbt が 2022 年に買収)
  • AtScale(エンタープライズ)

1.4 なぜ今また注目されるのか

  • データスタックの断片化 → 指標の重複が深刻化
  • AI・チャットボットがデータをクエリ → 自然言語→指標 のマッピングが必要
  • Headless BI の台頭

第 2 章 · Semantic Layer の構成

2.1 コアエンティティ

  • Entity: ビジネス上の実体 (注文・顧客・製品)
  • Dimension: 属性 (国・カテゴリ・日付)
  • Measure: 生の数値 (金額・数量)
  • Metric: 測定可能な指標 (売上・ユーザー数・転換率)

2.2 リレーションとジョイン

  • エンティティ間のリレーションを宣言
  • ジョイン経路を自動生成
  • 指標を照会するとき内部で適切なジョインを実行

2.3 フィルター・パラメータ

  • 期間・国・製品などのフィルターを標準化
  • ユーザー別権限 (Row-level security)
  • 比較 (YoY、MoM) 計算を内蔵

2.4 例 (dbt Semantic Layer / MetricFlow)

semantic_models:
  - name: orders
    model: ref('fact_orders')
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    measures:
      - name: total_amount
        agg: sum
        expr: amount_krw
    dimensions:
      - name: order_date
        type: time
        type_params: {time_granularity: day}

metrics:
  - name: gross_revenue
    type: simple
    type_params:
      measure: total_amount

→ API 呼び出し: metric('gross_revenue', filters=..., group_by=['order_date'])

第 3 章 · dbt Semantic Layer / MetricFlow

3.1 背景

  • 2021 年 Transform 創業 (Nick Handel、元 Airbnb 実験チーム)
  • 2022 年 dbt が Transform を買収
  • MetricFlow が dbt Semantic Layer のクエリエンジン

3.2 構造

  • dbt モデルの上に semantic model・metrics を定義
  • dbt Cloud が API サービスを提供
  • BI・ノートブック・AI が API 呼び出しで指標を照会

3.3 強み

  • dbt 親和的、既存プロジェクトを拡張
  • オープン標準 (GraphQL・JDBC)
  • 2024–2025 年に主要 BI と統合 (Tableau・Hex・Mode など)

3.4 限界

  • dbt Cloud に依存 (セルフホスティングの選択肢は成熟途上)
  • 複雑なジョイン・測定は今も SQL を直接書くほうが有利

第 4 章 · Cube — 「開発者向け Semantic Layer」

4.1 アイデンティティ

  • 2019 年 Cube Dev
  • オープンソース + Cube Cloud
  • データアプリ・Headless BI 向け API

4.2 特徴

  • YAML/JS/Python でデータモデルを定義
  • REST/GraphQL/SQL API
  • ダッシュボードを自分で作る開発者・プロダクトに適する

4.3 例

cube(`Orders`, {
  sql: `SELECT * FROM fact_orders`,
  measures: {
    revenue: { sql: 'amount_krw', type: 'sum' },
    count: { type: 'count' }
  },
  dimensions: {
    orderDate: { sql: 'order_date', type: 'time' },
    country: { sql: 'country', type: 'string' }
  }
});

4.4 使いどころ

  • 埋め込み分析 (顧客にダッシュボードを提供)
  • カスタムデータアプリ
  • AI チャットボットの指標照会バックエンド

第 5 章 · Looker・LookML — 「エンタープライズのクラシック」

5.1 アイデンティティ

  • 2013 年 Looker → 2019 年 Google が買収
  • LookML: 指標定義の DSL
  • Google Cloud 統合、Looker Studio と結合

5.2 強み

  • 業界で最も検証された LookML
  • 巨大な企業リファレンス
  • 2024–2025 年の Gemini 統合で自然言語クエリ

5.3 限界

  • Looker の外で LookML を再利用しにくい
  • コスト・ロックイン

5.4 2025 年の戦略

  • dbt Semantic Layer と LookML を併用
  • BigQuery 中心の企業は Looker + Gemini がデフォルト

第 6 章 · その他の主要ツール

6.1 AtScale

  • エンタープライズ Semantic Layer の専門
  • 大規模 MDX/XMLA (Excel・Power BI) 互換
  • 金融・保険の大企業に強み

6.2 Lightdash

  • オープンソース Headless BI + dbt Semantic
  • Looker の代替として注目
  • 2024–2025 年に急成長

6.3 Transform (dbt)

  • 買収後 dbt Semantic Layer に吸収

6.4 Metabase・Superset

  • BI ツール自体に一部 Semantic Layer 機能を内蔵
  • dbt Semantic Layer 連携を拡大

6.5 Thought Spot

  • 自然言語検索 BI
  • 2024–2025 年の LLM・AI 統合で先頭

第 7 章 · Metrics Store パターン

7.1 コンセプト

  • 会社の指標の単一ストア
  • 定義・バージョン・オーナー・関連ダッシュボード
  • 「指標カタログ」

7.2 構成

  • Metric catalog: 名前・説明・数式
  • Governance: 承認・変更・deprecation
  • API: BI・ノートブック・AI が照会
  • Lineage: 指標がどのデータから来たか

7.3 例

  • Airbnb Minerva (社内システム、公開論文あり)
  • Uber uMetric
  • LinkedIn Datahub metrics
  • dbt Semantic Layer を外部で標準化

7.4 効果

  • チーム間で指標が一致
  • 監査・規制への対応
  • AI の自然言語質問の正確性が上がる

第 8 章 · Headless BI

8.1 アイデンティティ

  • クエリ・指標エンジン ↔ フロントエンド UI の分離
  • フロントはアプリ・ダッシュボード・AI チャネルが自由に
  • Semantic Layer が API として提供

8.2 メリット

  • マルチ UI (ウェブ・モバイル・Slack・音声)
  • 既存 BI からの移行が容易
  • AI 統合がしやすい

8.3 ツール

  • dbt Semantic Layer + Hex/Mode/Tableau
  • Cube + カスタムウェブ
  • Lightdash + dbt
  • Metabase + dbt Semantic Layer

8.4 限界

  • UX カスタムのコスト
  • 保守が分散

第 9 章 · Reverse ETL — 「データを運用に戻す」

9.1 なぜ必要か

  • Warehouse に貴重な顧客・行動データ
  • Salesforce/HubSpot/Marketo には無い
  • エンジニアが API を接続 → 時間・コスト・信頼性の問題

→ Reverse ETL: Warehouse → 運用 SaaS へデータを同期

9.2 主要ツール

  • Hightouch: 2020 年、業界のリーダー
  • Census: 2018 年、もう一方のリーダー
  • Grouparoo(現在は Airbyte の一部)
  • RudderStack(CDP + Reverse ETL)
  • Workato(一般的な iPaaS + データ)

9.3 パターン

  1. dbt で顧客セグメントモデルを構築
  2. Reverse ETL が Warehouse から読み Salesforce/HubSpot/Intercom へプッシュ
  3. セールス・マーケティングがすぐにセグメントを活用

9.4 事例

  • Intercom に顧客 LTV を注入 → 会話の優先順位付け
  • Salesforce に Health score を注入 → Churn 対応
  • Marketo に利用量ベースのセグメント → キャンペーン

9.5 データ活性化 (Data Activation)

  • 分析にとどまらず 運用アクション をトリガーする
  • CDP (Customer Data Platform) と一部競合・一部補完
  • 2025 年のモダンデータスタックを完成させるピース

第 10 章 · AI・LLM と Semantic Layer

10.1 なぜ AI が Semantic Layer を必要とするのか

  • LLM が自然言語の質問を SQL に変えようとするとき 指標定義が必要
  • 「うちの売上は?」の答えは会社ごとに違う
  • LLM が raw テーブルに直接アクセスするとハルシネーション・誤りのリスク

10.2 「Text-to-SQL」vs「Text-to-Metric」

  • Text-to-SQL: 会社スキーマを元に SQL を生成 → 指標が食い違うリスク
  • Text-to-Metric: Semantic Layer API を呼び出す → 定義された指標だけを返す → 安全

10.3 事例

  • dbt Semantic Layer + GPT/Claude/Gemini で自然言語 BI
  • Cube + カスタムチャットボット
  • ThoughtSpot AI・Looker Gemini はネイティブ

10.4 品質管理

  • 指標定義の標準化が必須
  • 権限・監査は Semantic Layer で中央管理
  • AI に直接 SQL を書かせないほうが安全

10.5 2025 年の方向

  • Headless BI + AI = 「すべてのチームが自然言語でデータと対話」
  • Semantic Layer が AI の 安全なデータアクセス層 になる

第 11 章 · Data Activation 実戦シナリオ 3 つ

11.1 コマース — パーソナライズ推薦

  • Warehouse: 顧客の行動・購買履歴 → ML モデルで推薦スコア
  • Reverse ETL: スコア → Braze/Iterable/Salesforce Marketing Cloud
  • 結果: パーソナライズされたプッシュ/メールの自動化

11.2 B2B SaaS — Product-led Sales

  • Warehouse: プロダクト利用量・機能 adoption の指標
  • Reverse ETL: 指標 → Salesforce
  • AE は「自分の顧客の中でアップグレード可能性が高い人」をすぐ確認

11.3 フィンテック — Risk scoring

  • Warehouse: 取引パターン・リスクスコア
  • Reverse ETL: スコア → カスタマーサポートツール (Zendesk/Intercom)
  • CS 担当が VIP・リスク顧客の応対時にコンテキストを確保

第 12 章 · 韓国企業の成熟度

12.1 現状

  • 大企業・IT: Looker・Tableau・Superset が混在、Semantic Layer の導入は初期
  • スタートアップ: dbt + Metabase/Superset の組み合わせがよくある
  • Toss・Coupang・Danggeun・Kakao: 社内 Metrics Store 構築の事例
  • Reverse ETL: Hightouch・Census が 2024 年に急拡大

12.2 導入パターン

  1. dbt + 標準指標のドキュメント化
  2. Metabase/Superset で指標を露出
  3. dbt Semantic Layer / Cube を実験
  4. 特定のチームから Reverse ETL で運用と連携
  5. 全社 Metrics Store + AI 接続

12.3 考慮事項

  • 韓国語のビジネス用語の定義
  • 税金・為替・会計ポリシーのカスタム
  • セキュリティ・権限体系 (職級・部署ベース)
  • 監査・規制要件の反映

第 13 章 · アンチパターン 10 選

13.1 Semantic Layer なしで AI を直結

指標のハルシネーション・一貫性の崩壊。

13.2 LookML だけに依存

他の BI・AI チャネルと断絶。

13.3 指標オーナーが不明

変更責任の空白。

13.4 Deprecation なしの変更

消費者のダッシュボードが壊れる。

13.5 Reverse ETL の経路が乱立

Warehouse から数十本の同期パイプライン、管理不能。

13.6 Reverse ETL にリアルタイムを期待

ほとんどは分–時間単位、「リアルタイム」ではない。

13.7 Metric のバージョンなしで運用

過去のレポートを再現できない。

13.8 指標を Superset/Metabase にだけ定義

Semantic Layer の独立がない → 他ツールと分断。

13.9 自然言語 BI の整合性検証が不足

AI の回答をそのまま信じる → 誤った意思決定。

13.10 チームごとに自前の SQL で指標を計算

振り出しに戻る。

第 14 章 · チェックリスト — Semantic Layer・Reverse ETL 12 項目

  • コア指標カタログのドキュメント化 (オーナー・定義・SLA)
  • Semantic Layer 導入候補 (dbt/Cube/Looker) の評価
  • BI・AI チャネルの統合計画
  • 指標のバージョン・deprecation プロセス
  • 権限・Row-level security
  • 系譜 (Lineage) と監査
  • Reverse ETL ツールの選定とパイプラインカタログ
  • 運用システム (Salesforce・HubSpot など) のマッピング
  • データ活性化 ROI の測定
  • AI/LLM の自然言語アクセス統制
  • 失敗・アラートへの対応体制
  • ユーザー教育・オンボーディング

第 15 章 · 次回予告 — Season 5 Ep 6:「Feature Store と Vector・Graph・時系列 DB の融合」

Semantic Layer が BI の言語層なら、Feature Store は ML の言語層。そして 2025 年のデータ DB はベクター・グラフ・時系列が融合しつつある。

  • Feature Store の再定義 (Feast/Tecton)
  • Online-Offline skew の管理
  • リアルタイム Feature Pipeline
  • Vector DB の地形 (Pinecone/Weaviate/Milvus/Chroma/LanceDB)
  • マルチモーダル埋め込みの保存
  • Graph DB (Neo4j/NebulaGraph/Dgraph) とナレッジグラフ
  • 時系列 DB (InfluxDB/TimescaleDB/VictoriaMetrics)
  • 2025 年「Unified DB」の登場
  • AI・ML ワークロードが DB 地形に与えた衝撃
  • 韓国企業の選択

「モデルよりデータ、データよりフィーチャー」が 2025 年の ML の知恵。

次の記事で会おう。

要約: Semantic Layer は「指標定義は一度、すべてのチャネルで再利用」という古い約束の 2025 年版。dbt Semantic Layer・Cube・Looker・Lightdash・AtScale がそれぞれポジションを取り、Reverse ETL (Hightouch・Census) が Warehouse のデータを運用ツールへ戻して Data Activation を完成させる。AI・LLM の時代には Semantic Layer が 安全なデータアクセス層 へ格上げされ、Text-to-SQL の代わりに Text-to-Metric が推奨される。韓国企業は dbt + Metabase/Superset + Hightouch/Census の組み合わせで急速に追い上げており、Toss・Coupang・Kakao のように社内 Metrics Store を構築した事例が広がっている。「データの意味を語る層」はもはや贅沢ではなく、AI 時代のインフラだ。

Discuss on Twitter • View on GitHub