「先月の売上、Tableauで320万、Lookerで315万って出てるんですけど、どっちが正しいんですか」。BIを複数のツールで併用していると、こんな問い合わせが現場から飛んできます。理由はだいたい、メトリクス（「売上」の定義）が各ツール内で別々に書かれているからです。Tableauの計算フィールド、Lookerの LookML、ダッシュボード作者の頭の中、それぞれが少しずつ違う。
セマンティックレイヤー（Semantic Layer、メトリクスレイヤーとも）は、この「メトリクス定義」をBIの外で一元管理する層です。dbt Semantic Layer・Cube・Lightdashが代表的な選択肢で、考え方も実装も少しずつ違います。3つの違いと選び方を整理します。
なぜセマンティックレイヤーが必要か
BIで困る典型的な3つの状況を挙げます。どれかに心当たりがあれば、セマンティックレイヤーが効きます。
| 困りごと | 原因 |
|---|---|
| 同じ指標の数字がツールで違う | メトリクス定義が各ツール内で別々 |
| 新しいダッシュボードを作るたびに集計ロジックを書き直す | 定義の再利用ができない |
| 分析者ごとに「正しい売上」の定義が違う | 定義の責任者が不明確 |
これらに共通するのは、「メトリクスの定義」がデータの近くに住んでいない、ことです。セマンティックレイヤーは、定義をdbtプロジェクトやセマンティックレイヤー専用のリポジトリで管理し、BIはそれを参照するだけ、という構成にします。
3つのツールの位置づけ
| dbt Semantic Layer | Cube | Lightdash | |
|---|---|---|---|
| カテゴリー | dbtと統合されたセマンティックレイヤー | 独立したセマンティックレイヤー（API・キャッシュ・BI） | セマンティックレイヤー＋BI（一体型） |
| 主な使い方 | dbt projectでメトリクスを定義し、BIから参照 | YAMLで定義、APIをBIや独自アプリで利用 | dbt projectから直接BIダッシュボードを構築 |
| OSS/SaaS | SaaS（dbt Cloud Enterprise） | OSS＋Cube Cloud | OSS＋Lightdash Cloud |
| BIとの関係 | 多くのBIから接続 | 多くのBI・独自アプリから接続 | BIも一体提供 |
| 得意領域 | dbt中心の組織で、既存BIと組み合わせ | BI以外（アプリ・AI Agent等）にもメトリクスを提供したい | 小〜中規模で、dbtからシームレスにBIまで |
3者は競合ではなく、解決する範囲が違います。「dbtに統合して既存BIで使う」のはdbt Semantic Layer、「メトリクスをAPI公開して様々な場所から使う」のはCube、「メトリクスとBIを一体運用する」のはLightdashです。
それぞれの強みと弱み
dbt Semantic Layer
dbt Labsが2023年に正式リリースしたセマンティックレイヤーで、dbtプロジェクトと一体運用できるのが最大の強みです。MetricFlowというSQL生成エンジンを使い、メトリクスの定義から実際のクエリ生成までを行います。Tableau・Hex・Modeなどの主要BIから接続できます。
強みは、dbtプロジェクトの一部として管理できること、変換ロジックとメトリクス定義が同じ場所にあること。弱みは、dbt Cloud Enterpriseが必要で、OSSとして自前運用できないことです。詳細はdbt Semantic Layer とはで扱います。
Cube
Cubeは独立したOSSセマンティックレイヤーで、APIとキャッシュを中心にしたアプローチが特徴です。BIだけでなく、Web/モバイルアプリ、AI Agent、組み込みダッシュボードなど、「データを必要とするあらゆる場所」にメトリクスを提供できます。
強みは、API ベースで使う場所を選ばないこと、キャッシュレイヤーが組み込まれていて高速なこと。弱みは、Cube独自のスキーマ定義を学ぶ必要があり、dbtとの統合は別途設定が必要なことです。詳細はCube とはで扱います。
Lightdash
Lightdashは「dbtプロジェクトから直接BIダッシュボードまで構築できる」OSSツールです。メトリクスはdbtのモデルにYAMLで定義し、Lightdashがそれを読み取ってBIとして動かします。dbtを使っているチームには、もっとも自然な導入感です。
強みは、dbtとシームレスに連動すること、OSSでセルフホストできること、BIも一体提供されること。弱みは、エンタープライズBIの機能（高度な権限管理、複数データソース等）はLooker/Tableauに譲ること、エコシステムがまだ若いことです。詳細はLightdash とはで扱います。
選定の判断軸
| 判断軸 | 選び方 |
|---|---|
| 既にTableau/Looker/PowerBI等を使っていて、メトリクス統一だけしたい | dbt Semantic Layer |
| BI以外（アプリ・AI）にもメトリクスを使いたい | Cube |
| BIごとリプレースして、dbtと一体化したい | Lightdash |
| OSSで自前運用したい | Cube・Lightdash |
| dbtを使っていない | Cubeが選択肢になる（dbt非依存） |
dbtプロジェクトとの統合
dbtを使っているチームの場合、メトリクスは「dbtモデルの上にどう乗せるか」の設計が大事になります。
| 層 | 役割 |
|---|---|
| Bronze/Silver/Gold（dbt） | データを集める・整える・配膳する |
| セマンティックレイヤー | 「売上」「アクティブユーザー数」等のメトリクスを定義 |
| BI・アプリ・API | セマンティックレイヤーを参照 |
dbtでの層分けはdbt実装ガイド、メダリオンアーキテクチャはメダリオンアーキテクチャ解説を参照してください。セマンティックレイヤーは「Goldの上に薄く乗る層」と考えると整理しやすいです。
どこから始めるか
- ステップ1：BI間で数字が割れている代表的なメトリクスを5〜10個リストアップする
- ステップ2：定義の合意を業務側と取り、文章で言語化する
- ステップ3：そのメトリクスから、選んだセマンティックレイヤーに移植する
- ステップ4：BI側を順次セマンティックレイヤー経由に切り替える
すべてのメトリクスを最初から移すのは現実的ではありません。「数字が合わなくて困っているもの」だけから始め、価値を確認してから広げます。
まとめ
- セマンティックレイヤーは「メトリクス定義をBIの外で一元管理する層」。BI間の数字割れを解く。
- dbt Semantic Layer＝dbt統合、Cube＝API公開、Lightdash＝BI一体型、と覚える。
- 選定は、既存BI継続／API公開／BIリプレースの3軸で決まる。
- dbtを使うなら、Gold層の上に薄く乗せる構成が自然。
- 導入は「数字が合わない代表メトリクス」から段階的に始める。
各ツールの詳細はdbt Semantic Layer とは・Cube とは・Lightdash とはにまとめています。セマンティックレイヤー導入の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. Lookerの LookMLもセマンティックレイヤーですよね？
A. その通りで、LookMLは事実上セマンティックレイヤーです。それがLookerの中に閉じているため、Tableau や Power BIから参照できません。LookMLで定義したメトリクスを他のツールでも使いたいという需要が、「BI非依存のセマンティックレイヤー」を生みました。Looker中心で運用しているなら、LookMLで十分というケースも多いです。
Q. セマンティックレイヤーがあれば、Goldマートは要らないですか？
A. 不要にはなりません。Goldマートは「事前集計してBIが速く読める形」、セマンティックレイヤーは「メトリクスの定義を持つ層」で役割が違います。実務では、Goldで集計したテーブルの上にセマンティックレイヤーを乗せ、メトリクス定義を統一する、という二段構えになります。Goldの設計を簡素化しすぎると、セマンティックレイヤーで複雑な集計を実行する負担が増します。
Q. メトリクスの定義は誰が責任を持つべきですか？
A. データアナリティクスエンジニア、もしくはアナリストとビジネス側の合議が一般的です。「売上」のような重要メトリクスは、業務側のオーナー（経理・営業企画等）が定義に合意し、データ側がコードに落とす、というプロセスを取ります。「ツールに任せれば自動で定義される」と思って導入すると、半年後に「結局誰も触っていない」状態になります。プロセスとガバナンスが、ツール選定と同じくらい重要です。
Q. AI Agent（自然言語で分析するツール）にもセマンティックレイヤーが必要ですか？
A. むしろAI時代こそ重要、というのが現在の業界トレンドです。LLMが「売上を見せて」と聞いて、自分でSQLを書くと、定義が組織と違うものになるリスクがあります。セマンティックレイヤーがあれば、LLMはそれを参照して定義通りのSQLを生成できます。CubeはAI Agentを意識した設計を強調しており、dbt Semantic Layerもこの方向に進化しています。