🔗 技術調査 - オントロジー Semantic Layer と dbt Semantic Layer 比較・統合戦略

背景

エンタープライズデータ統合において、ビジネス概念の定義層（Semantic Layer）を raw データの上に構築するアプローチが主流になりつつあります。この流れには大きく 2 つの方向性があります。

1. オントロジーベース: OWL/TTL によるビジネス概念の厳密な定義、SPARQL による問い合わせ
2. 製品ごとのセマンティックレイヤー: dbt・Looker・Tableau 等の各データプラットフォームが独自に提供するメトリクス定義層

両者は「ビジネス概念の定義層」という本質を共有しています。一方で、形式主義の深さ・推論能力・エコシステムの成熟度では大きく異なります。

2025-2026 年にかけて、Data Mesh（ドメイン分散所有）と Data Fabric（メタデータ自動化）の融合が進んでいます。Knowledge Graph / オントロジーが両者を統合する「意味の糊」として注目されています。

この記事では、製品ごとのセマンティックレイヤーの中から広く普及している dbt Semantic Layer を代表例として取り上げ、オントロジーベースのアプローチと詳細に比較します。その上で、Data Mesh 時代のアーキテクチャにおいてオントロジーを上位レイヤーに維持し、ネイティブインターフェースで下流ツールと接続する戦略を提案します。OWL → dbt YAML 変換のような「上位概念を下位ツールに押し込む」アプローチがアンチパターンとなる理由も検証します。

記事の構成:

関連記事:

https://zenn.dev/suwash/articles/shanai_data_ontology_seiri_20260215

https://zenn.dev/suwash/articles/semantic_arts_gist_ontorojii_taikeika_20260216

1. オントロジーベースのデータ活用アーキテクチャ

1.1 全体像

オントロジーを用いたデータ活用では、業務 DB 群の上に概念モデル（OWL オントロジー）を定義します。その概念モデルを通じてデータにアクセスします。

1.2 主要なデータフローパターン

パターン1: SPARQL 直接クエリ

• 最もシンプルな構成
• 開発者・データエンジニア向け
• ツール: Stardog Studio, GraphDB Workbench, YASGUI

パターン2: OBDA / Virtual Graph - 仮想グラフ

• 既存 RDB を SPARQL で直接問い合わせ可能にする仮想化
• 製品: Stardog Virtual Graphs, Ontop, Timbr
• 利点: ETL 不要、リアルタイム性、既存 DB への影響なし

パターン3: Semantic Layer → BI ツール

• ビジネスユーザーが慣れた BI ツールでオントロジー統合データを利用
• 製品: Timbr（SQL 互換セマンティックレイヤー）, Graphwise（PoolParty + GraphDB + BI）

パターン4: GraphRAG - 知識グラフ + 生成AI

• 非構造化データをオントロジーに基づきグラフ化し、RAG で活用
• 製品: Neo4j GraphRAG, Amazon Neptune + Bedrock, Microsoft GraphRAG

パターン5: AI Agent + Ontology

• LLM がオントロジーをスキーマとして理解し、自律的にクエリを組み立て
• 製品: Stardog Voicebox, Microsoft Fabric IQ

1.3 アプリケーション種別

1.4 代表的なプロダクトスタック

以下、各プロダクトの詳細です。

Stardog - エンタープライズ Knowledge Graph

• Virtual Graph で既存 DB に直結、ETL 不要
• Voicebox で自然言語クエリ対応
• Stardog Studio で SPARQL 開発・可視化
• BI Connector（JDBC/ODBC）で Tableau/Power BI 接続

Graphwise - PoolParty + GraphDB

• PoolParty: テキストからエンティティ抽出・分類
• GraphDB: トリプルストア + ビジュアルグラフ探索
• BI コネクタ経由で Tableau/Power BI 連携

Timbr - SQL 互換セマンティックレイヤー

• オントロジーを「SQL ビュー」として公開
• 既存の BI ツール・データ分析ツールから SQL でナレッジグラフにアクセス
• OWL クラスが「テーブル」、プロパティが「カラム」として見える
• データエンジニアの学習コスト最小

Neo4j + GraphRAG

• LPG（Labeled Property Graph）ベース、RDF インポート可能
• GraphRAG: ドキュメント → グラフ → ベクトル検索 → LLM 回答
• Bloom: ノーコードでグラフ可視化

AWS Neptune + Bedrock

• Neptune: フルマネージド RDF/SPARQL ストア
• Bedrock: LLM 連携でナレッジグラフ対話
• Glue + Lake Formation でデータガバナンス統合

Microsoft Fabric IQ

• Fabric: 統合データプラットフォーム
• IQ: 自然言語 → SQL/SPARQL 変換
• Copilot 連携でビジネスユーザーが直接データ問い合わせ

1.5 BI / 他システムへの接続方式

ビジネスユーザーが BI で活用する場合、最終的には SQL 互換のインターフェースが必要です。接続方式は 3 つに大別されます。

方式1: Semantic Layer 製品（最も実用的）

Timbr が代表格です。

ビジネスユーザーは普通の SQL を書くだけでオントロジー統合データにアクセスできます。例えば SELECT * FROM Customer WHERE region = 'APAC' で、裏側では複数 DB を横断クエリします。

方式2: トリプルストアの BI Connector

Stardog や GraphDB が提供する方式です。

方式3: ETL / 中間DB パターン（レガシー環境向け）

• 最もシンプルな構成（リアルタイム性は低く、バッチ更新）
• 既存のデータパイプラインに乗せやすい

他システムへの連携一覧

2. dbt Semantic Layer の概要

セクション 1 ではオントロジーベースのアプローチを整理しました。ここでは、製品ごとのセマンティックレイヤーの代表例として dbt Semantic Layer を概観します。

2.1 アーキテクチャ

dbt Semantic Layer は、DWH 上のデータに対してビジネスメトリクスの定義層を提供します。

2.2 定義構造

semantic_models:
  - name: customers
    description: "顧客マスタ"
    model: ref('stg_customers')
    defaults:
      agg_time_dimension: created_at

    entities:
      - name: customer_id
        type: primary
      - name: region_id
        type: foreign

    dimensions:
      - name: customer_name
        type: categorical
      - name: region
        type: categorical
      - name: created_at
        type: time

    measures:
      - name: total_revenue
        agg: sum
        expr: annual_revenue
      - name: customer_count
        agg: count_distinct
        expr: customer_id

metrics:
  - name: revenue_per_customer
    type: derived
    type_params:
      expr: total_revenue / customer_count

2.3 エコシステム

• dbt Cloud: CI/CD、バージョン管理、メトリクス API
• MetricFlow: メトリクス定義から SQL 自動生成
• BI 連携: Tableau, Power BI, Looker, Hex, Mode 等と標準統合
• dbt Mesh: チーム間でのモデル共有・ガバナンス

3. 両者の詳細比較

セクション 1・2 で整理した両者を、概念対応と本質的な違いの観点から比較します。

3.1 概念の対応関係

3.2 本質的な違い

定義の形式主義の度合い

オントロジー - OWL: 論理的形式体系です。クラス間の関係・制約を厳密に定義できます。

:Customer a owl:Class ;
    rdfs:subClassOf gist:Organization ;
    owl:disjointWith :Supplier .

:hasRegion a owl:ObjectProperty ;
    rdfs:domain :Customer ;
    rdfs:range :GeoRegion .

この定義は「顧客は組織の一種であり、サプライヤーとは重複しない」「顧客は地理的リージョンを持ち、その値は GeoRegion クラスのインスタンスに限定される」という論理的制約を表現しています。

dbt Semantic Layer: 実用寄りです。YAML で属性と集計を宣言します。

semantic_models:
  - name: customers
    entities:
      - name: customer_id
        type: primary
    dimensions:
      - name: region
        type: categorical
    measures:
      - name: lifetime_value
        agg: sum

シンプルで学習コストが低い反面、エンティティ間の論理的制約を表現する手段は限られます。

推論の有無

これが両者の最大の差です。

dbt の場合: 「顧客 A は東京に所在」のみを返します。

Ontology の場合: 推論エンジンが暗黙の関係を自動導出します。

データソースのスコープ

dbt: 単一 DWH（Snowflake/BigQuery 等）が前提です。全データを DWH に集約してから Semantic Layer を適用します。

Ontology: 複数の異種 DB を仮想統合できます。データを移動せず統合ビューを提供します（Virtual Graph）。

3.3 比較サマリ

4. Data Mesh とオントロジーの統合アーキテクチャ

セクション 3 の比較を踏まえ、両者をどう組み合わせるかを検討します。2025-2026 年の最新動向として、Data Mesh / Data Fabric / Knowledge Graph の融合が進んでいます。

4.1 大きな流れ: Data Mesh + Data Fabric + Knowledge Graph の三位一体

2026 年時点で、Data Mesh と Data Fabric は補完関係として定着しました。Gartner は一方を採用した企業が 2-3 年以内に他方も導入すると予測しています。さらに Knowledge Graph / オントロジーがその統合の「糊」として注目を集めています。

三者は異なるレイヤーの課題を解決しており、組み合わせて使うのが 2026 年の主流です。

4.2 3つの構成パターン

パターン1: Knowledge Mesh - 分散オントロジー + フェデレーテッドクエリ

各ドメインが自律的にオントロジーを所有し、共有上位オントロジーで相互運用します。データ移動なしにフェデレーテッドクエリで横断検索を実現します。

Blindata が提唱する「Knowledge Plane」がこの概念を体系化しています。オントロジーを「プロダクト」として扱い、ドメインが所有・進化させます。段階的成熟モデルとして、用語集 → タクソノミー → オントロジーの順に整備するアプローチを推奨しています。

パターン2: Semantic Data Mesh - セマンティックレイヤー統合型

Data Mesh のデータプロダクトを、セマンティックレイヤー製品で仮想統合します。OWL オントロジーで各ドメインのスキーマをマッピングし、SQL 互換で問い合わせ可能にします。

Timbr が「Semantic Data Mesh」として製品化しています。dbt との連携もサポートしています。

パターン3: 集約 + ガバナンス型 - DWH 中心のハイブリッド

Data Mesh のドメイン所有を維持しつつ、分析用に DWH へ集約します。dbt がデータ変換とセマンティックレイヤーを担います。

Thoughtworks の 2026 年レポートによると、多くの企業がこのパターンからスタートしています。中央データオフィスが「ゲートキーパー」から「センター・オブ・エクセレンス」に転換するのが成功パターンです。

4.3 2026 年の最新トレンド

5. 統合戦略の評価

セクション 4 で示した構成パターンを踏まえ、「OWL → dbt YAML 変換」という一見合理的なアプローチを検証し、推奨戦略を提示します。

5.1 OWL → dbt Semantic Layer 変換がアンチパターンである理由

両者の概念には対応関係があります（owl:Class ≒ semantic_model、owl:ObjectProperty ≒ entity 等）。技術的には OWL → dbt YAML の自動変換は可能です。しかし、これは上位レイヤーの概念を下位レイヤーに押し込む行為であり、戦略として推奨しません。

概念対応表（参考）

変換は可能ですが、以下の理由から戦略的に避けるべきです。

理由1: 上位概念の切り捨てが不可逆

オントロジーが持つ推論・仮想統合・開世界仮説は、dbt の閉世界・単一 DWH・バッチ処理モデルに変換すると不可逆的に失われます。推移的関係を recursive CTE で事前計算するのは、推論エンジンのリアルタイム導出の劣化コピーに過ぎません。

理由2: プロダクトの進化に追従できない

Stardog、Timbr、GraphDB 等のオントロジーネイティブ製品は、BI Connector や SQL 互換インターフェースをすでに備えています。これらは JDBC/ODBC 経由で Tableau や Power BI と直接接続可能であり、dbt を経由せず BI に到達できます。

さらに、Knowledge Mesh や Semantic Data Mesh のアーキテクチャが成熟するにつれ、オントロジー層がネイティブに BI・AI Agent・他システムと接続する方向に進化しています。dbt YAML に変換すると、このネイティブ統合から切り離されます。

理由3: Data Mesh / Data Fabric との不整合

Data Mesh はドメインごとの自律性と分散所有を原則とします。各ドメインがオントロジーを所有し、フェデレーテッドクエリで横断する Knowledge Mesh パターンはこの原則と整合します。一方、全ドメインのオントロジーを dbt YAML に変換して単一 DWH に集約するのは、Data Mesh の思想と矛盾します。

5.2 推奨アプローチ: オントロジーを上位レイヤーに維持する

オントロジーは意味論の定義層として上位に位置づけ、下位のツール（dbt, BI, AI）にはネイティブインターフェースで接続するのが正しい戦略です。

設計原則

1. オントロジーが Single Source of Truth: ビジネス概念の定義はすべて OWL/TTL で管理
2. ネイティブインターフェースで接続: dbt YAML への変換ではなく、BI Connector / JDBC / REST で直接接続
3. 仮想統合を優先: データは移動せず、Virtual Graph / フェデレーテッドクエリで統合
4. DWH/dbt は必要な場合のみ: 集計・バッチ処理が必要な分析ワークロードに限定して DWH を使用。dbt は「消費層のツール」であり意味論の定義層ではない
5. 段階的な成熟: 用語集 → タクソノミー → オントロジーの順に段階的に整備

dbt の正しい位置づけ

dbt は「オントロジーに代わるもの」ではなく、「オントロジーが統合したデータを消費するツールの一つ」として位置づけます。

5.3 構成パターンの選択基準

実際にはこれらを混在して運用するのが現実的です。ドメインの性質やユースケースに応じて、パターン 1-3 を使い分けます。共通するのはオントロジーを上位レイヤーに維持し、Single Source of Truth とする点です。

6. 今後の展望

セクション 5 の推奨戦略を実践するための段階的な導入アプローチと、将来の技術動向を整理します。

6.1 段階的な導入アプローチ

1. Phase 1: 用語集の整備: ドメインごとにビジネス用語を定義し、共通語彙を合意
2. Phase 2: タクソノミーの構築: 用語間の階層関係を整理し、分類体系を確立
3. Phase 3: オントロジーの定義: gist 上位オントロジーを基盤に、ドメイン拡張オントロジーを OWL/TTL で厳密に定義
4. Phase 4: 仮想統合の実現: Stardog / Timbr 等でデータソースを仮想統合し、BI / AI からネイティブ接続
5. Phase 5: Knowledge Mesh への展開: ドメインがオントロジーを「プロダクト」として所有・進化させるガバナンスモデルを確立

6.2 将来的な技術動向

まとめ

この記事では、オントロジー Semantic Layer と dbt Semantic Layer を比較し、Data Mesh 時代における統合戦略を検討しました。

両者は「ビジネス概念の定義層」という本質を共有しつつ、以下の点で本質的に異なります。

この違いから、両者の適用スコープは明確に分かれます。

OWL → dbt YAML 変換は技術的に可能ですが、推論・仮想統合・開世界仮説といった上位概念が不可逆的に失われるため、アンチパターンです。dbt Semantic Layer を複数データプロダクトの統合に使おうとするのは、スコープの越境にあたります。

推奨戦略は以下の通りです。

• オントロジーを意味論の Single Source of Truth として上位に維持し、複数データプロダクトを束ねる
• dbt Semantic Layer は単一データプロダクト内に留め、DWH 上のメトリクス集計を担う
• BI・AI 等の下流ツールには、オントロジーの BI Connector（JDBC/ODBC）で直接接続する
• バッチ集計が必要なワークロードに限り、dbt / DWH を経由する

導入にあたっては、用語集 → タクソノミー → オントロジーの順に段階的に整備します。組織の成熟度に応じて Knowledge Mesh / Semantic Data Mesh / DWH 集約型の 3 パターンを使い分けるのが現実的です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント

  • W3C OWL 2 Web Ontology Language
  • W3C R2RML: RDB to RDF Mapping Language
  • dbt Semantic Layer Documentation
  • MetricFlow Documentation
  • SAMOD - Simplified Agile Methodology for Ontology Development
  • Ontology Development 101 - Noy and McGuinness

• GitHub

  • gist GitHub Repository

• 製品・プラットフォーム

  • Semantic Arts - gist Upper Ontology
  • Stardog - Enterprise Knowledge Graph
  • Timbr - SQL Knowledge Graph
  • Ontop - Virtual Knowledge Graph
  • GraphDB by Ontotext
  • Neo4j GraphRAG

• 記事

  • Thoughtworks - The State of Data Mesh in 2026: From Hype to Hard-Won Maturity
  • Blindata - Architecting the Knowledge Plane for Humans and Agents
  • Timbr - Semantic Data Mesh for Scalable Data Management
  • Enterprise Knowledge - How a Knowledge Graph Can Accelerate Data Mesh Transformation
  • Alation - Data Fabric vs Data Mesh: 2026 Guide
  • Stardog - What is a Data Mesh: Principles and Architecture
  • Actian - Why Federated Knowledge Graphs are the Missing Link in Your AI Strategy
  • Dataversity - The Convergence of the Data Mesh and Data Fabric
  • AtScale - The State of the Semantic Layer: 2025 in Review