セマンティックレイヤーとは――部門でずれるKPI定義を一つにする

同じ「売上高」なのに、営業会議、経営会議、マーケティングのレポートで数字が違う。その原因は、データソースの違いだけではありません。受注と請求のどちらを採用するか、取消をいつ反映するか、通貨をどのレートで換算するか、どの組織階層で集計するかが、レポートごとに実装されているためです。

セマンティックレイヤーは、データを利用者にとって意味のある業務用語、指標、分析軸として提供する層です。単に計算式を共通化するだけでなく、定義、粒度、関係、権限、責任者、変更履歴を管理することで、複数のBIや分析用途から再利用できる「指標の共通基盤」を作ります。

セマンティックレイヤーとは

Microsoft Fabricの公式文書では、セマンティックモデルを、分析対象領域をメトリクスや業務利用者に分かりやすい表現で記述する論理モデルとして説明しています。典型的には、売上や在庫などの事実を表すファクト、顧客・商品・組織・日付などの分析軸を表すディメンション、両者の関係、メジャーと呼ばれる計算済み指標で構成されます。

利用者は、物理テーブル名や複雑な結合、レポートごとの計算式を意識せず、「売上高」「粗利率」「顧客」「事業部」「会計月」という業務の言葉で分析できます。一つの共有モデルを複数レポートから利用すれば、同じ定義を再実装する回数を減らせます。

なぜ部門・レポートごとにKPIがずれるのか

数値差を調べる際は、計算式だけでなく、粒度、時点、対象範囲、変換、権限を追跡します。調査の詳しい進め方は、BIの数字が合わない原因――データリネージュで根拠を追跡するで解説しています。

セマンティックレイヤーに含める要素

メジャーとKPI

売上高、在庫回転率、商談転換率などの計算ロジックに、表示形式、単位、対象・除外条件、時間集計のルールを持たせます。比率や残高は単純合計できないため、分子・分母や時点の扱いも定義します。

ディメンションと階層

顧客、商品、組織、地域、日付など、フィルターや集計に使う共通の分析軸です。「商品→カテゴリ→事業」のような階層とコード体系を整え、異なるファクトが同じ軸で比較できるようにします。

関係と粒度

どのファクトがどのディメンションにつながり、1行が何を表すかを明示します。曖昧な多対多関係や双方向フィルターを安易に増やすと、利用者が予期しない集計結果になり得ます。

業務用語と説明

表示名、定義、計算根拠、利用上の注意、データ責任者、更新時刻、品質状態を利用者が確認できるようにします。物理メタデータだけでなく、Business Glossaryと接続することが重要です。

セキュリティ

組織や担当範囲に応じた行レベル、機密項目に対する列レベルの制御を設計します。レポートで列を非表示にするだけでは保護にならない場合があるため、モデルまたは基盤側で権限を適用します。

セマンティックレイヤーだけでは解決できないこと

セマンティックレイヤーは重要ですが、万能ではありません。ソースデータの欠損や重複、マスターの不統一、履歴不足を、見せ方だけで根本解決することはできません。また、同じ名称の指標について部門間の目的が本当に異なる場合、無理に一つの式へ統合するのも適切ではありません。

その場合は、全社共通指標と部門固有指標を分け、名称で区別し、相互の関係を説明します。下層のDWH・レイクハウスに必要な統合と品質管理は、DWH・データレイク・レイクハウスの選定およびDWH要件定義チェックリストと合わせて検討してください。

KPIを統一する7つの設計ステップ

1．優先する意思決定を選ぶ

全指標を一度に統一せず、経営会議、営業管理、需給計画など、影響が大きく数値差が問題になっている意思決定から始めます。レポート一覧ではなく、誰がどの判断に使うかを明確にします。

2．KPI定義カードを作る

各指標について、名称、目的、業務定義、計算式、粒度、期間、対象・除外、単位・通貨、ソース、更新頻度、品質ルール、責任者、承認者、改定日を一枚にまとめます。正常・境界・例外の計算例も残すと、実装と受入テストが一致します。

3．共通ディメンションと論理モデルを設計する

顧客、商品、組織、時間などを複数指標で再利用できる形にし、業務用語を論理データモデルへ対応づけます。ソース固有コードの変換と履歴方式も決めます。

4．共有モデルとして実装する

指標を個々のレポートへ埋め込まず、認定された共有セマンティックモデルから利用できるようにします。用途やセキュリティ境界が大きく異なる場合は、単一の巨大モデルにせず、共通コアと領域モデルへ分けます。

5．照合と利用者受入テストを行う

ソース、DWH、セマンティックモデル、主要レポートの各段階で、代表期間・組織・商品を照合します。既存レポートとの差が出た場合は、新旧どちらが正しいかを業務責任者が判断し、差異理由を記録します。

6．認定・発見・利用ルールを整える

Microsoft Power BIには、組織が品質基準を満たしたコンテンツを認定し、信頼できるモデルを見つけやすくする仕組みがあります。製品を問わず、「推奨」「認定」「廃止予定」などの状態、利用条件、問い合わせ先をカタログで示します。

7．変更管理を運用する

KPIは組織再編、会計方針、商品体系、業務プロセスの変更で変わります。変更申請、業務承認、影響分析、テスト、通知、施行日、旧定義の保存を手順化し、下流レポートの影響をリネージュで確認します。

指標ガバナンスの役割分担

運営体制についてはBI CoEの作り方、利用者の自由度との両立についてはセルフサービスBIのガバナンスもご覧ください。

EAとDMBOKから見た位置づけ

EAでは、KPIは単なるBI項目ではなく、戦略・事業能力・業務プロセスの成果を測る情報です。ビジネスアーキテクチャの目的と指標をデータアーキテクチャの業務用語・論理データモデルへつなぎ、アプリケーションアーキテクチャで生成元と利用先を、技術アーキテクチャで実行基盤を整理します。これにより、システム変更が経営指標へ与える影響を追跡できます。

DMBOKの観点では、セマンティックレイヤーはデータモデリング、メタデータ、DWH／BI、マスターデータ、データ品質、セキュリティ、ガバナンスの交点です。ツール導入だけでなく、定義する人、承認する人、品質を監視する人を設計して初めて、企業の共通言語として機能します。

導入前の最終チェックリスト

• 優先KPIが具体的な意思決定と結びついている
• 名称、式、粒度、期間、対象・除外、単位が定義されている
• 正常・境界・例外の計算例がある
• 共通ディメンションと履歴方式が決まっている
• 業務責任者、技術責任者、承認者が決まっている
• 権限適用後の見え方をテストしている
• 認定モデルと個人・部門モデルを区別できる
• 変更時の影響分析、通知、旧定義保存の手順がある

まとめ

セマンティックレイヤーの目的は、レポートを作りやすくすることだけではありません。戦略と業務に基づくKPIを、共通ディメンション、業務用語、権限、責任、変更管理と一体で提供し、数値を信頼して意思決定できる状態を作ることです。Version株式会社では、EAとDMBOKをベースに、指標棚卸し、論理データモデル、セマンティックレイヤー、BIガバナンスを一貫して設計します。部門間の数値差やモデル乱立でお困りの場合は、お問い合わせください。

BI／DWHテーマクラスター：BI要件定義 ／ 経営ダッシュボード ／ セルフサービスBI統制 ／ DWH・データレイク・レイクハウス ／ DWH要件定義 ／ セマンティックレイヤー ／ BI数値不一致とリネージュ ／ レガシーDWH刷新 ／ BI CoE ／ DWH受入テスト