オントロジー入門 2026 ─ 哲学・Palantir・GraphRAG までの全体像

一般 Semantic Layer の世界 ─ Cube / dbt SL / Looker / Unity Catalog / OSI

2026/05/04

第6章: 一般 Semantic Layer の世界 ─ Cube / dbt SL / Looker / Unity Catalog / OSI

一般 Semantic Layer 6製品比較と Open Semantic Interchange

第5章で Palantir の Semantic / Kinetic / Dynamic 3層モデルを見た。本章では「Semantic Layer」のもうひとつの文脈 ─ BI / アナリティクス系の一般 Semantic Layerを整理する。同じ言葉でも目的と読者が違うため、Palantir 文脈と混同しないことが大切。

一般 Semantic Layer とは何か

BI / アナリティクスの世界で「Semantic Layer」と呼ぶときは、ほぼ次を指す：

メトリクスとディメンションを一元定義し、各 BI ツールが同じ数字を返すようにする層

「一元定義」が肝。同じ「Revenue」を Tableau と Looker と Power BI と Excel が違う計算式で出していた、というのが従来の悲劇。これを1か所で定義 → どの BI ツールから引いても同じ数字にするのが Semantic Layer の使命。

graph TB
    DW[(Data Warehouse<br/>Snowflake / BigQuery / Redshift)]
    SL[Semantic Layer<br/>メトリクス + ディメンション一元定義]
    DW --> SL
    SL --> T[Tableau]
    SL --> L[Looker]
    SL --> P[Power BI]
    SL --> M[Mode]
    SL --> E[Excel]
    SL --> AI[AI Agent / LLM]
    style SL fill:#1a2030,stroke:#4cc9f0

これがHeadless BI（後述）の発想。

Palantir Semantic Layer との軸の違い

第5章の予告通り、Palantir と一般 Semantic Layer は軸が違う。

軸	Palantir Semantic Layer	一般 Semantic Layer
主役	エンティティ（Aircraft、Customer、Order）	メトリクス（Revenue、ARR、DAU）
単位	Object Type、Link Type	measure、dimension
利用者	業務オペレーション、現場ユーザー	アナリスト、ビジネスユーザー
Action	含む（Action Type）	含まない（読み取り専用）
Permission	Ontology に統合	DWH や BI 側に依存
主目的	業務を動かす	数字を揃える

両者は競合しない。むしろ補完関係。同じ組織で「Palantir Ontology で業務を動かしながら、dbt Semantic Layer で経営数値を揃える」という併用も増えている。

主要製品 7 つを比較する

graph TB
    SL((Semantic Layer<br/>製品))
    SL --> Looker[Looker LookML<br/>BI-native]
    SL --> dbtSL[dbt Semantic Layer<br/>MetricFlow ベース]
    SL --> Cube[Cube.dev<br/>Universal API]
    SL --> AtScale[AtScale<br/>Headless BI]
    SL --> Fabric[Microsoft Fabric<br/>semantic model]
    SL --> Databricks[Databricks<br/>Unity Catalog Metric Views]
    SL --> Custom[自社実装<br/>YAML + 簡易API]
    style Looker fill:#1a2030,stroke:#ff4d6d
    style dbtSL fill:#1a2030,stroke:#ff6b35
    style Cube fill:#1a2030,stroke:#b794f4
    style AtScale fill:#1a2030,stroke:#4cc9f0
    style Fabric fill:#1a2030,stroke:#00d9c0
    style Databricks fill:#1a2030,stroke:#7c8db5

順に見ていく。

1. Looker LookML（Google Cloud）

項目	内容
性質	BI-native（Looker 専用）
定義言語	LookML（独自 DSL）
構成要素	`view`（テーブル相当）/ `explore`（JOIN グループ）/ `measure`（メトリクス）/ `dimension`（属性）
強み	LookML 自体が成熟、コードレビュー文化、Looker UI と密結合
弱み	Looker 以外で native 消費できない（API 経由で出すことは可）

view: orders {
  sql_table_name: analytics.orders ;;

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
  }
  dimension: order_date {
    type: time
    sql: ${TABLE}.order_date ;;
  }
}

Google Cloud 配下でも、Looker は依然として大企業 BI の主軸の1つ。

2. dbt Semantic Layer（MetricFlow）

項目	内容
性質	Transformation-layer 系
定義言語	YAML、dbt project に同居
構成要素	`semantic_model`（テーブル相当）/ `measure` / `dimension` / `entity`
強み	Git 管理、CI/CD と相性◎、dbt エコシステムを活かせる
弱み	dbt Cloud 課金（OSS は MetricFlow 単体）

semantic_models:
  - name: orders
    model: ref('orders')
    entities:
      - name: order_id
        type: primary
    measures:
      - name: total_revenue
        agg: sum
        expr: amount
    dimensions:
      - name: order_date
        type: time

★ 2025-10 Fivetran と dbt Labs が全株式合併で、モダンデータスタックの中核として再編フェーズに入っている。

3. Cube.dev

項目	内容
性質	Definition + Serving（API 含む）
定義言語	YAML / JavaScript
提供 API	REST、GraphQL、SQL、MDX、DAX を同時提供
強み	Embedded analytics、複数 API で多様なクライアント対応、AI API + MCP 統合
弱み	別レイヤを増やす運用負担

「1つの定義から REST も GraphQL も SQL もすべて出せる」のが Cube の特徴。LLM 時代に MCP サーバとして Semantic Layer を公開する文脈で再注目されている。

4. AtScale

項目	内容
性質	Universal / Headless BI
強み	aggregate awareness（自動 rollup）、複数 BI ツール対応、エンタープライズ寄り
主用途	大規模 BI 統合、レガシー OLAP 置き換え

「Aggregate awareness」とは「BI ツールが日次集計を要求 → 既に作ってある月次集計テーブルから引く」という最適化。これは大規模 BI で効く。

5. Microsoft Fabric semantic model

項目	内容
性質	Platform-native（Microsoft Fabric 配下）
強み	Power BI と密結合、Direct Lake、XMLA エンドポイント、Copilot 連携
弱み	Microsoft スタック前提

Power BI を主要 BI とする組織には圧倒的に魅力的。

6. Databricks Unity Catalog Metric Views（2025 GA）

項目	内容
性質	Lakehouse-native
GA	2025
強み	measure と dimension の分離、AI/BI Dashboards・Genie・Notebooks・SQL から共通参照
弱み	Databricks 前提

-- 概念的なイメージ
CREATE METRIC VIEW sales_metrics
AS SELECT
  customer_id AS dimension,
  SUM(amount) AS total_revenue MEASURE
FROM analytics.sales;

Databricks が「Lakehouse の上に Semantic Layer を乗せる」戦略を本格化させた象徴。

7. 自社実装（YAML + 簡易API）

スタートアップや小規模組織では、簡易な YAML + 自社の BI APIで十分なケースも多い。OSI（後述）の登場で、この自社実装も標準仕様に乗せやすくなった。

Headless BI ─ アーキテクチャ哲学

「メトリクス定義は Head（UI）と分離し、再利用可能に」という発想を Headless BI と呼ぶ。

graph TB
    subgraph 従来型 BI
        T1[Tableau]
        L1[Looker]
        P1[Power BI]
        T1 -.->|独自定義| DW1[(DWH)]
        L1 -.->|独自定義| DW1
        P1 -.->|独自定義| DW1
    end
    subgraph Headless BI
        SL[Semantic Layer<br/>共通定義]
        T2[Tableau]
        L2[Looker]
        P2[Power BI]
        AI[AI Agent]
        SL --> T2
        SL --> L2
        SL --> P2
        SL --> AI
        SL --> DW2[(DWH)]
    end
    style SL fill:#1a2030,stroke:#4cc9f0

従来型では3つの BI がそれぞれ独自にメトリクスを定義し、結果が食い違っていた。Headless BI では1つの Semantic Layer に集約し、各 BI ツールはそこから引くだけ。

これは2020年代前半にCube.dev / AtScale が提唱し、2024-2026 でメインストリームになった。

★ Open Semantic Interchange（OSI、2025-09 立ち上げ）

業界最大級の動き。「define once, use everywhere」を目指すvendor-neutral な YAML 仕様。

立ち上げ参加企業

ロール	企業
創立メンバー（2025-09）	Snowflake / Salesforce / dbt Labs / BlackRock / RelationalAI
後参加	AtScale / Cube / Databricks / Atlan / DataHub / Collibra

仕様の特徴

MetricFlow ベースの YAML（dbt 生まれ）
Apache 2.0 ライセンス
公式サイト：open-semantic-interchange.org
2026-01 Spec 公開

なぜ重要か

graph LR
    Org[Org の Semantic Layer 定義]
    Org -->|YAML を export| OSI[OSI 仕様]
    OSI --> S[Snowflake Cortex]
    OSI --> D[Databricks]
    OSI --> dbt[dbt SL]
    OSI --> Cube[Cube.dev]
    OSI --> AT[AtScale]
    OSI --> AI[AI Agent / MCP]
    style OSI fill:#1a2030,stroke:#b794f4

Semantic Layer の定義をベンダー間で持ち運べる。これにより：

ベンダーロックインが緩和される
LLM Agent が「組織のメトリクス定義」を標準フォーマットで取得できる
BI 移行のコストが激減する

★ ただし、Palantir は OSI に参加していない。Palantir は自社 Ontology の優位性を維持する戦略。**「BI 系は OSI で標準化、業務オペレーション系は Palantir」**という二極化が起きつつある。

標準化のもう一方 ─ ISO GQL

第3章で扱った **GQL（ISO/IEC 39075:2024、2024-04）**もこの文脈で重要。

標準	対象	立ち位置
ISO GQL	Property Graph のクエリ言語	Cypher / PGQL の統一
Open Semantic Interchange	Semantic Layer の定義 YAML	dbt MetricFlow ベース
W3C SPARQL	RDF/Triplestore のクエリ	OWL/RDF 系の主流

「意味と構造の標準化が同時進行」と「はじめに」で書いたのは、これらが2024-2026 で揃った異例の状況を指す。

製品選定のフロー

flowchart TB
    Q[要件] --> Q1{主要 BI は?}
    Q1 -- Looker --> Looker[Looker LookML]
    Q1 -- Power BI --> Fabric[Microsoft Fabric]
    Q1 -- 複数 BI --> Q2{dbt 中心?}
    Q1 -- Databricks 中心 --> UC[Unity Catalog Metric Views]
    Q2 -- Yes --> dbt[dbt Semantic Layer]
    Q2 -- No / Embedded --> Cube[Cube.dev]
    Q --> Q3{Palantir Foundry あり?}
    Q3 -- Yes --> Combo[Palantir Ontology + dbt SL 併用]

ざっくりの判断軸：

Looker 中心 → LookML（既に持っているなら継続）
Power BI 中心 + Microsoft 365 → Fabric semantic model
dbt + 複数 BI → dbt Semantic Layer（OSI の主流仕様）
Embedded analytics / API 多様性 → Cube.dev
Databricks Lakehouse → Unity Catalog Metric Views
エンタープライズ大規模 → AtScale（Aggregate Awareness）
業務オペレーション → Palantir Ontology（別軸）

LLM 時代との接続

Semantic Layer は LLM 時代に新たな役割を担う：

graph TB
    LLM[LLM Agent]
    LLM -->|MCP 経由| SL[Semantic Layer]
    SL --> M[メトリクス定義]
    SL --> D[ディメンション定義]
    SL --> Q[クエリ生成]
    Q --> DW[(DWH)]
    DW --> Result[結果]
    Result --> LLM
    style LLM fill:#1a2030,stroke:#b794f4
    style SL fill:#1a2030,stroke:#4cc9f0

「LLM Agent が SQL を書く」のではなく「Semantic Layer に自然言語で問い合わせ → Semantic Layer が SQL を生成」する設計。これにより：

LLM が組織の正しいメトリクス定義を使う
計算誤りや独自解釈が減る
ガバナンスが Semantic Layer に集約される

Cube AI API、dbt Semantic Layer の MCP 対応、Snowflake Cortex Analyst はすべてこの設計の現出。

一般 Semantic Layer と Palantir、改めて整理

quadrantChart
    title Semantic Layer の位置マップ
    x-axis "メトリクス中心" --> "エンティティ中心"
    y-axis "BI 向け" --> "業務オペレーション向け"
    quadrant-1 業務 + エンティティ
    quadrant-2 BI + エンティティ
    quadrant-3 BI + メトリクス
    quadrant-4 業務 + メトリクス
    Looker LookML: [0.15, 0.2]
    dbt SL: [0.2, 0.25]
    Cube: [0.25, 0.3]
    AtScale: [0.2, 0.15]
    UC Metric Views: [0.25, 0.2]
    Fabric: [0.2, 0.25]
    Palantir Ontology: [0.85, 0.85]
    Stardog: [0.7, 0.7]
    Neo4j: [0.6, 0.6]

「どの製品が正解」ではなく「何を解きたいか」で選ぶ。同じ組織で複数を併用しても問題ない。

本章の要点

#	要点
1	一般 Semantic Layer はメトリクスとディメンションを一元定義して BI 各種を揃える層
2	Palantir Semantic Layer はエンティティ中心、一般はメトリクス中心 ─ 軸が違うが補完関係
3	主要製品 7 つ：Looker LookML / dbt SL / Cube / AtScale / Fabric / Unity Catalog Metric Views / 自社実装
4	Headless BI はメトリクス定義を Head と分離する設計哲学
5	Open Semantic Interchange（2025-09 立ち上げ、2026-01 spec 公開）で業界標準化が進行。Palantir は不参加
6	ISO GQL + OSI + W3C SPARQL で意味と構造の標準化が同時進行
7	LLM 時代の Semantic Layer の役割：LLM が SQL を書くのではなく、Semantic Layer に自然言語で問い合わせる
8	製品選定は「主要 BI」「dbt 中心か」「Palantir 併用か」で判断

効いている根本原理

本章は 原理1（共通言語） と 原理4（LLM 時代の橋渡し） が中心だった。Semantic Layer は組織内のメトリクスを共通言語化し、その上で LLM Agent との接点を作る。Palantir Ontology との「軸の違い」を理解することで、両者を併用する設計が可能になる。

ここまでで第2部「現代のオントロジー基盤」は完了だ。次の第3部から LLM 時代のオントロジー ─ GraphRAG とエージェント ─ に入る。