LASSIC Media らしくメディア
セマンティックレイヤー導入を外注で進める進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 部署ごとに「売上」「アクティブ数」の定義がずれる問題と、セマンティックレイヤーが担う役割を整理します。
- dbt Semantic Layer・Cube・LookMLという代表的な選択肢の考え方の違いを、優劣を断定せずに紹介します。
- 外注でセマンティックレイヤー導入を進める場合の委託範囲と、発注前に準備すべき情報をまとめます。
目次
指標定義のズレ — BIツールごとに数字が変わる問題
セマンティックレイヤー（メトリクスレイヤー）とは、売上やアクティブ数といった経営指標（メトリクス）の定義をコードとして一元管理し、複数のBIツールやSQLクエリから同じ数字を参照できるようにする中間層を指します。
BIツールを複数導入している企業では、部署ごとに「売上」の集計条件が違う状態が起こりやすくなります。営業部門は契約ベースで売上を集計し、経理部門は請求確定ベースで集計するといった違いが典型例です。
同じ「売上」という言葉でも、集計元のテーブル・フィルタ条件・期間の切り方がツールごとに個別実装されていると、会議で異なる数字が並んで議論が止まる事態につながります。dbtが提唱する「Define metrics once. Use them everywhere.（メトリクスは一度定義し、あらゆる場所で使う）」という考え方*1は、こうした状態を防ぐための設計思想です。
セマンティックレイヤーを導入する狙いは、指標の定義をBIツール側の個別設定ではなくデータ基盤側のコードに集約し、どのツールから見ても同じ計算ロジックが適用される状態を作ることにあります。ダッシュボードを作り直すたびに集計条件を再定義する手間も減らせます。
メトリクス・アクセス制御・キャッシュ — セマンティックレイヤーの役割
セマンティックレイヤーが担う役割は、大きく4つに整理できます。Cube（分析基盤向けのセマンティックレイヤー製品）の公式ドキュメントでは、データモデリング・アクセス制御・キャッシュ・APIの4本柱で構成されると説明されています*2。
第一に、メトリクスとディメンションの定義です。Cubeの用語では、売上や訪問数のような数量データを「measures（メジャー）」、都道府県や商品名のような分類データを「dimensions（ディメンション）」と呼びます*2。この2種類を組み合わせることで、集計の単位と切り口を一箇所で定義できます。
第二に、データ同士の結合（ジョイン）の定義です。売上テーブルと顧客テーブルをどう結合するかをセマンティックレイヤー側に記述しておくと、BIツール側では結合方法を意識せずに指標を参照できます。
第三に、アクセス制御です。誰がどの指標・どのデータ行を参照できるかをセマンティックレイヤー側で管理し、BIツールやSQLクライアントごとに個別設定する手間を減らします。
第四に、キャッシュです。dbt Semantic Layerには、よく使われるクエリの結果を宣言的にキャッシュする仕組みがあり、パフォーマンス向上とクエリ計算量の削減につながるとされています*1。BIダッシュボードを開くたびに集計処理が走る構成と比べ、応答が安定しやすくなります。
これら4つの機能を一箇所に集約することで、BIツール・SQLクライアント・場合によってはAIエージェントからも、同じ定義に基づいた指標を参照できる状態を作れます*2。
dbt・Cube・LookMLの考え方の違い
セマンティックレイヤーを実現する製品・機能はいくつか存在します。ここでは代表的な3つの考え方の違いを、優劣を断定せずに整理します。
dbt Semantic Layerは、dbt（データ変換のコード管理ツール）のモデリングレイヤー上にメトリクス定義を配置する方式です。MetricFlowというクエリエンジンを介して、YAMLファイルで意味モデル（semantic models）とメトリクスを記述します*1。dbtで既にデータ変換パイプラインを組んでいる企業であれば、変換ロジックとメトリクス定義を同じリポジトリで一体管理しやすい構成です。
Cubeは、データベースとBIツールの間に独立したセマンティックレイヤー層を置く製品です。「cubes」という単位でテーブルと結合関係を整理し、その上に「views」を重ねてエンドユーザー向けの公開範囲を絞り込む構成を取ります*2。SQL（PostgreSQL互換）・REST・GraphQLなど複数のAPIで指標を公開できる点が特徴です*2。特定のBIツールに依存せず、複数のフロントエンドから同じ指標を参照したい場合に選択肢となります。
LookMLは、Google Cloudの分析プラットフォームであるLooker専用のモデリング言語です。公式ドキュメントでは「Lookerでセマンティックデータモデルを作成するために使われる言語」と説明されています*3。ディメンション・集計・計算・データ間の関係性をLookMLで記述すると、Lookerがそのコードを再利用してSQLクエリを都度生成する仕組みです*3。Lookerをすでに標準BIとして採用している企業であれば、追加の基盤を持たずにセマンティックレイヤーの機能を使える点が特徴です。
3製品はいずれも「メトリクスをコードで定義し、複数の参照先で使い回す」という目的は共通していますが、dbtは変換パイプラインとの一体運用、Cubeはツール非依存の独立層、LookMLはLooker専用という前提が異なります。既存のデータ基盤構成（dbtを使っているか、BIツールを1つに統一しているか等）によって適した選択肢が変わるため、自社構成を踏まえた比較検討が必要です。
| 選択肢 | 位置づけ | 前提となる環境 |
|---|---|---|
| dbt Semantic Layer | dbtのモデリングレイヤー上でメトリクスをYAML定義。 MetricFlowで問い合わせを処理します*1。 |
dbtで変換パイプラインを既に運用している構成 |
| Cube | データベースとBIツールの間に独立層を配置。 SQL・REST・GraphQLで指標を公開します*2。 |
複数のBIツール・アプリから同じ指標を参照したい構成 |
| LookML | Looker専用のモデリング言語。 ディメンション・計算をLooker内で定義します*3。 |
Lookerを標準BIとして採用済みの構成 |
導入の進め方と外注の委託範囲
セマンティックレイヤーの導入を外注で進める場合、進め方は概ね4段階に整理できます。まず現状の指標定義を洗い出す工程です。各部署・各BIツールで「売上」「アクティブ数」等の主要指標がどう集計されているかを突き合わせ、ズレのある箇所を特定します。
次に、統一後のメトリクス定義を設計する工程に入ります。どの粒度（日次・月次など）でどの条件を含めるかを、業務部門と合意した上でコード化します。この工程は業務知識とデータモデリングの両方が必要になるため、外注先には自社の業務用語の理解を求める場面が出てきます。
三段階目は、選定した製品（dbt Semantic Layer・Cube・LookML等）への実装です。既存のデータウェアハウスやBIツールとの接続設定、アクセス制御の設計、キャッシュ方針の設計を含みます。
四段階目は、既存のBIダッシュボードをセマンティックレイヤー経由の参照に切り替える移行作業です。ダッシュボードごとに参照先を切り替え、旧ロジックとの計算結果の差異を検証しながら進めます。
外注に委託する範囲は、企業のデータ基盤の成熟度によって変わります。データウェアハウスやBIツールの選定・接続がすでに完了している企業では、メトリクス定義の設計と実装工程だけを委託範囲にできます。一方、データ基盤そのものが未整備な企業では、基盤構築からセマンティックレイヤー実装までを一括で委託する形になり、委託範囲が広がる分だけ検討すべき論点も増えます。
発注前に準備する情報と必要スキル
セマンティックレイヤー導入を内製で行う場合、データモデリング・SQL・利用予定のBIツールへの理解に加え、業務部門と指標定義を合意形成する調整力が必要になります。定義を誤ると、全社のダッシュボードが誤った数字を表示し続けるリスクがあるため、設計段階の検証を軽視できません。
特に注意すべきは、指標定義の統一作業そのものが持つ難しさです。部署間で異なる集計ロジックのどちらを「正」とするかは技術的な判断だけでは決まらず、業務側の合意形成に時間を要します。この調整を外部の技術者だけで完結させることは難しく、発注側の業務部門の参加が前提になります。
外注先に依頼する際は、発注前に以下の情報を整理しておくと、要件のすり合わせがスムーズになります。
- 現在使用しているデータウェアハウス・BIツールの種類と接続方法
- 統一したい主要指標のリストと、現状の部署別の集計ロジックの違い
- 指標へのアクセス権限を分ける必要がある部署・役職の範囲
- 既存ダッシュボードの本数と、移行を優先すべきダッシュボードの範囲
専門パートナーに依頼した場合は、複数製品の比較検討・既存データ基盤との接続検証・移行時の計算結果差異の検証を、業務側の合意形成と並行して進められる点が内製との違いになります。内製で同じ工程を担う場合は、データモデリング担当者と業務部門の調整役を並行して確保する体制設計が必要です。
まとめ：セマンティックレイヤー導入の3つの判断軸
本稿では、部署ごとの指標定義のズレを解消するセマンティックレイヤーの役割と、導入の進め方・外注の委託範囲を整理しました。要点を3つに集約すると次の通りです。第一に、セマンティックレイヤーはメトリクス・ディメンションの定義とアクセス制御・キャッシュを一元管理し、複数のツールから同じ数字を参照できるようにする層だという点です。第二に、dbt Semantic Layer・Cube・LookMLはいずれも目的は共通しつつ、既存のデータ基盤構成によって適する選択肢が変わる点です。第三に、外注の委託範囲はデータ基盤の成熟度に応じて変わり、指標定義の合意形成には業務部門の参加が前提になる点です。
よくある質問
セマンティックレイヤーとデータカタログはどう違いますか。
データカタログはデータの在庫（どのテーブルにどの列があるか）を整理する仕組みで、セマンティックレイヤーは指標の計算ロジック（売上をどう集計するか）を統一する仕組みです。両者は目的が異なり、データカタログで整備した情報を土台に、セマンティックレイヤーで指標定義を組み立てる関係になります。
既存のBIダッシュボードはすべて作り直しが必要ですか。
既存のダッシュボードを一度に作り直す必要はありません。参照先をセマンティックレイヤー経由に切り替える移行作業を、優先度の高いダッシュボードから段階的に進める進め方が一般的です。移行時は旧ロジックとの計算結果の差異を検証しながら切り替えます。
dbtを使っていない場合、dbt Semantic Layerは使えませんか。
dbt Semantic Layerはdbtのモデリングレイヤー上に構築される機能のため、前提としてdbtでの変換パイプライン運用が必要です*1。dbtを使っていない場合は、独立したセマンティックレイヤー層を持つCubeや、利用中のBIツールが提供するモデリング機能（LookMLなど）が選択肢になります。
指標定義の統一にはどのくらいの部署の関与が必要ですか。
統一対象とする指標を実際に使っている部署すべての関与が必要です。技術的な実装だけでは指標定義のズレは解消できず、どの集計ロジックを正とするかについて業務部門間の合意形成を要するためです。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：dbt Labs, Inc.「dbt Semantic Layer」公式製品ページおよびドキュメント（https://www.getdbt.com/product/semantic-layer、https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl）（2026年時点）
- *2 出典：Cube Dev, Inc.「Data Modeling Overview」Cube公式ドキュメント（https://docs.cube.dev/docs/data-modeling/overview）（2026年時点）
- *3 出典：Google Cloud「What is LookML」Looker公式ドキュメント（https://docs.cloud.google.com/looker/docs/what-is-lookml）（2026年時点）
