はじめに
「セマンティックレイヤー」と「メトリックビュー」。Databricksを触っていると両方の用語が出てきますが、この2つの関係性を明確に説明できるでしょうか？
本記事では、セマンティックレイヤーの概念を整理したうえで、Databricksが提供する Unity Catalog Business Semantics とその中核機能である メトリックビュー（Metric Views） について解説します。
セマンティックレイヤーとは
一言でいうと
セマンティックレイヤーとは、ビジネス用語の定義と、その定義によるデータ取得を一体化する仕組みです。
もう少し詳しく
多くの組織で「売上」という言葉は日常的に使われていますが、実際にデータを取得しようとすると、以下のような問題に直面します。
- 部門Aは「税込・返品含む」で売上を計算している
- 部門Bは「税抜・返品除外」で売上を計算している
- どちらが正しいか誰も把握していない
「では、用語集を作って定義を統一しよう」と考えるかもしれません。しかし、Excelの用語集やWikiに定義を書いても、実際のダッシュボードやSQLクエリに反映される保証はありません。定義と実装が分離しているため、時間が経つにつれて乖離していきます。
セマンティックレイヤーはこの問題を、「定義」と「実行」を同じ場所に置く ことで解決します。「売上＝SUM(税抜価格) WHERE ステータス != '返品'」という計算ロジックをセマンティックレイヤーに一度定義すれば、ダッシュボード、自然言語クエリ、AIエージェントなど、どこからアクセスしても同じ計算結果が返ります。
「ビジネス用語の定義を揃える」だけならドキュメントでもできます。セマンティックレイヤーの本質は、揃えた定義でそのままデータを取得できる（＝定義と実行が一体化している）点にあります。
セマンティックレイヤーがない世界 vs ある世界
| 観点 | セマンティックレイヤーなし | セマンティックレイヤーあり |
|---|---|---|
| 指標の定義 | 各ダッシュボード・SQLに分散 | 一箇所で一元管理 |
| 定義の整合性 | 時間とともに乖離する | 常に同じ定義が適用される |
| ビジネスユーザーのアクセス | SQLを書くか、誰かに依頼する | ビジネス用語で直接問い合わせ可能 |
| AIの精度 | 生テーブルから推測するため不正確 | 定義済みの指標を参照するため正確 |
Databricksにおけるセマンティックレイヤー：Unity Catalog Business Semantics
Databricksでは、このセマンティックレイヤーの考え方を Unity Catalog Business Semantics としてプラットフォームにネイティブ統合しています。
特徴的なのは、従来のセマンティックレイヤーがBI（ダッシュボード・レポート）向けだったのに対し、Databricksは 人間（BIユーザー）とAI（エージェント）の両方が同じ定義を参照する共通基盤 として設計している点です。
主な構成要素
Unity Catalog Business Semanticsは、以下の要素で構成されています。
| 構成要素 | 役割 |
|---|---|
| メトリックビュー | ビジネス指標をYAMLで定義し、SQLでクエリ可能なビューとして公開 |
| Unity Catalogガバナンス | リネージ、アクセス制御、利用状況のインサイト |
| Certification（認定） | 公式指標として認定し、信頼できるデータの発見を促進 |
| Genie Space | 自然言語でメトリックビューを問い合わせるインターフェース |
| AI/BI ダッシュボード | メトリックビューの指標をドラッグ&ドロップで可視化 |
セマンティックレイヤーは「概念・アーキテクチャ」であり、メトリックビューはその概念をDatabricks上で実装するための「具体的な機能」です。つまり メトリックビュー ⊂ セマンティックレイヤー という包含関係にあります。
メトリックビューとは
メトリックビューは、Unity Catalog Business Semanticsの中核機能で、ビジネス指標をYAMLで宣言的に定義し、SQLでクエリ可能なビューとして公開するもの です。
通常のデータベースビュー（CREATE VIEW）と似ていますが、ビジネスメタデータやセマンティクス情報が付与されている点が大きく異なります。
YAML定義の例
以下は、注文データに対するメトリックビューの定義例です。
version: 1.1
source: samples.tpch.orders
comment: 売上分析用のメトリックビュー
dimensions:
- name: order_date
expr: o_orderdate
comment: 注文日
display_name: 注文日
format:
type: date
date_format: year_month_day
synonyms:
- 受注日
- オーダー日
- name: customer_segment
expr: |
CASE
WHEN o_totalprice > 100000 THEN 'Enterprise'
WHEN o_totalprice > 10000 THEN 'Mid-market'
ELSE 'SMB'
END
comment: 注文金額に基づく顧客分類
display_name: 顧客セグメント
synonyms:
- セグメント
- 顧客ランク
measures:
- name: total_revenue
expr: SUM(o_totalprice)
comment: 全注文の合計売上
display_name: 合計売上
format:
type: currency
currency_code: JPY
synonyms:
- 売上
- 売上合計
- 総売上
- name: order_count
expr: COUNT(1)
comment: 注文件数
display_name: 注文件数
synonyms:
- 注文数
- オーダー数
この定義には、以下の要素が含まれています。
- dimensions（ディメンション）: 分析の切り口（日付、セグメントなど）
- measures（メジャー）: 集計指標（合計売上、注文件数など）
- synonyms（シノニム）: 同義語。Genieが自然言語を正しく解釈するためのコンテキスト
- display_name: BIツールやダッシュボードでの表示名
- format: 通貨・日付などの表示フォーマット
メトリックビューの特徴
自動マテリアライズ: 頻繁に使われるクエリはDatabricksが自動的にプリコンピュートし、最適なマテリアライズドビューにルーティングします。データパイプラインの手動管理が不要です。
AIコンテキストとしての活用: シノニムやコメント、表示名などのメタデータは、Genieやその他のAIエージェントがユーザーの自然言語クエリを正確なSQLに変換するためのコンテキストとして機能します。
オープンなアクセス: REST、ODBC、JDBC、Python、Go、Node.jsなど複数のインターフェースからSQLでクエリ可能です。
セマンティックレイヤーとメトリックビューの違い（まとめ）
| 観点 | セマンティックレイヤー | メトリックビュー |
|---|---|---|
| 抽象度 | 概念・アーキテクチャ | 具体的な実装・オブジェクト |
| スコープ | ガバナンス、認定、AI連携、BIツール統合を含む全体 | 指標定義（ディメンション・メジャー・メタデータ） |
| ベンダー依存 | dbt、Looker、AtScaleなど各社が独自に実現 | Databricks Unity Catalog固有の機能 |
| 例え | 設計思想・設計図 | その思想を実現するための中核部品 |
実際の活用イメージ
ビジネスユーザー
Genie Spaceを通じて「先月の関東エリアの売上は？」のように自然言語で問い合わせると、Genieがメトリックビューのシノニムやメジャー定義を参照して正しいSQLを生成・実行します。SQLを書く必要はありません。
データエンジニア / アナリティクスエンジニア
メトリックビューをYAMLで定義・管理し、Gitでバージョン管理します。指標の計算ロジックを変更する場合はYAMLを更新するだけで、Genie、ダッシュボード、AIエージェントなどすべての消費先に一括で反映されます。
AIエージェント / アプリケーション開発者
REST APIやPython SDKを通じてメトリックビューにアクセスし、エージェントが自律的にデータを取得・分析するワークフローを構築できます。指標の定義をセマンティックレイヤーから取得することで、定義の不整合を防げます。
おわりに
セマンティックレイヤーは「データの意味をビジネス用語で定義し、一元管理する」というアーキテクチャの考え方であり、メトリックビューはDatabricksがその考え方を具体化した中核機能です。
Databricksの特徴的なアプローチは、セマンティックレイヤーを BI用途だけでなくAIエージェントとの共通基盤 として位置づけている点にあります。LLMが正確にデータを扱うには、テーブル名やカラム名だけでは不十分で、「この数値は何を意味するか」「どう集計すべきか」というビジネスコンテキストが不可欠です。メトリックビューのシノニムや表示名は、まさにそのコンテキストを提供するための仕組みです。
「指標を一度定義すれば、人間（BI）もAI（エージェント）も同じ真実を参照する」 ― これがDatabricksのセマンティックレイヤーが目指す世界です。