セマンティックレイヤーとは｜AIエージェント活用に不可欠な「意味の定義」を理解する

AIエージェントの導入検討に入ると、データ整備に関する用語が一気に増えます。

データカタログ、メタデータ管理、データガバナンス。

そのなかで「セマンティックレイヤー」は、データ整備関連などで繰り返し登場するわりに、他の概念との違いが掴みにくい用語の一つではないかと思います。

「データカタログとは何が違うのか」「メタデータ管理の話と同じなのか」という疑問を持ったまま読み飛ばしている方も少なくないはずです。

本記事では、セマンティックレイヤーの定義と、構成する要素を整理します。

そのうえで、混同しやすい概念との違い、データ整備全体のなかでの位置づけ、この層がないとAIエージェント活用で何が起きるか、提供のされ方の種類、そして実際にどこから手をつけるかを解説します。

セマンティックレイヤーとは、数値の意味と計算のしかたを決めておく層

そもそもセマンティックとは

セマンティック（semantic）は「意味に関する」という意味の英語です。

たとえば、家計簿にその月の食費として80,000円と記録されていたとします。
数字は読めますが、この80,000円が何を数えたものかは、これだけでは分かりません。

外食は入っているのか。お酒は食費に含めたのか。家族全員分なのか、書いた人の分だけなのか。

書いた本人は分かっているので、わざわざ書き足しません。
ところが別の人がこの家計簿を見て「食費が多い」と判断すると、数えている中身が食い違ったまま話が進みます。

この「80,000円が何を数えたものか」にあたる情報を、書いた人の記憶に置いたままにせず、データのそばに書き出しておく。
これを社内のデータに対して行うのが、セマンティックレイヤーです。

セマンティックレイヤーの定義

セマンティックレイヤーとは、社内の数値の意味と計算のしかたを1か所で決めておく層です。

データベースやデータウェアハウス（分析のためにデータを集めておく専用のデータベース）に入っている実際のデータと、それを見るBIツールやAIとのあいだに位置します。

BIツールやAIは、データベースのテーブルに直接アクセスする代わりに、このセマンティックレイヤーを通してデータを参照します。
結果として、誰が・何のツールで照会しても、同じ定義に基づく一貫した数値が返ってきます。

なぜセマンティックレイヤーが必要になるのか

たとえば社内に「売上」のデータがあるとします。

実際のデータベースでは、売上に関する数値は複数のテーブルに分かれて格納されています。
受注テーブル、請求テーブル、入金テーブル。 「月次売上」を集計しようとしたとき、どのテーブルの、どの列を、どの条件で合算するかは、SQL（データベースからデータを取り出すための言語）のクエリとして都度定義する必要があります。

ここで問題になるのは、同じ「月次売上」という言葉を使っていても、営業部門と経理部門でその計算方法が異なるケースが少なくないことです。

営業部門は受注ベースで計算し、経理部門は請求ベースで計算する。
どちらも「月次売上」と呼んでいるにもかかわらず、数字が一致しません。

あると現場で何が変わるのか

セマンティックレイヤーがあれば、この2つは別の指標として定義されます。

「月次売上（営業ベース）は受注テーブルのamount列を当月分で集計したもの」「月次売上（経理ベース）は請求テーブルのamount列を当月分で集計したもの」と、明確に分けて定義しておきます。

数字が食い違った際、どちらが正しいかを部門間で確かめる代わりに、定義を1か所見に行けば、2つが別の指標であることと、それぞれの計算のしかたが分かるようになります。

BIの時代からAIエージェントの時代へ

BIツールの中に閉じていた意味の定義を、外に出す

セマンティックレイヤーが最初に注目されたのは、BIツールの普及期です。

2000年代から2010年代にかけてTableau、Looker、Power BIといったツールが広がるなかで、「SQLを書けないビジネスユーザーでもデータを自由に分析したい」というニーズが高まりました。セマンティックレイヤーは、この問題を解決する仕組みとして位置づけられていました。

このころ、指標の定義はBIツールの中に置かれていました。
データを見るのはBIツールを開く人で、その人に届けば足りていたためです。

2025年以降、状況は変わりつつあります。

AIエージェントが社内のデータを参照して質問に回答したり、データに基づいた業務判断を補助したりする場面が増えています。

この場合、データを参照し分析しているのは人間ではなくAIです。

AIエージェントは、BIツールの画面を通らずにデータを取りに行きます。
定義がBIツールの中にしか無ければ、AIはその定義を読まないため、同じ会社の中で、人が見る数字とAIが返す数字が別々の計算から出てくることになります。

意味の定義をBIツールの外に出す必要が出てきたのは、この理由によります。

自然言語で聞かれたとき、AIは何を手がかりに答えているのか

AIエージェントに「今月の営業成績を教えて」と聞いたとき、AIはデータベースにSQLを発行するか、APIを通じてデータを取得します。

セマンティックレイヤーがなければ、AIはテーブルの構造とカラム名だけを手がかりにデータを解釈することになります。

テーブル名が tbl_sales_01、カラム名が amt_1 のようなシステム的な命名だと、AIがその意味を正しく推定できる保証はありません。

セマンティックレイヤーを通して「月次売上＝受注テーブルのamount列を当月1日〜末日で集計したもの」という定義を参照できると、AIが意味を取り違えるリスクが下がります。

セマンティックレイヤーの役割は「人間がSQLを書かずにデータを見られるようにする」から、「AIがデータの意味を正しく理解できるようにする」へと拡張されています。

セマンティックレイヤーを構成する要素

この層に何が書かれているのかは、製品の仕様に具体的に表れています。

データ基盤構築ツールを提供している主要な会社が公開している仕様をいくつか並べると、呼び名は違っても、指標にあたるもの、集計の切り口にあたるもの、テーブルの結合にあたるものの3つは、どの製品にも共通して出てきます（（出典: Semantic models | dbt、Data modeling | Cube、What is LookML? | Looker）。

この3つに、実務で必要になる用語集と権限を加えた5つが、この層に書かれている中身です。

指標（メトリクス）の定義と計算のしかた

中心にあるのが指標です。
月次売上、解約率、平均単価のように、業務の状態を1つの数字で表したものを指します。

ここで決めるのは、その数字をどのデータから、どの条件で、どう計算するかです。
合計なのか、件数なのか、平均なのか。キャンセルになった受注のように、除外する条件はあるか。

指標は、単純な集計だけではありません。
2つの指標の割り算として比率を定義したり、売上から原価を引いて粗利を出すように指標同士の計算で新しい指標を作ったりする形も、定義として持てます。

実際の定義は、次のようなテキストファイルとして書かれます。

models:
  - name: orders
    semantic_model:
      enabled: true
    metrics:
      - name: monthly_revenue_sales
        label: 月次売上（営業ベース）
        description: 受注ベースで集計した月次の売上
        type: simple
        agg: sum
        expr: order_amount

label が画面に表示される名前、agg: sum が合計で計算すること、expr: order_amount がどの列を合計するかを指しています。
社内で「月次売上（営業ベース）」と呼んでいる数字の正体は、この十数行です。

集計の切り口（ディメンション）と集計の単位

ディメンションは、指標を分解して見るときの切り口です。

地域別、商品別、担当者別、月別といった単位を指します。
指標が「いくつか」を表すのに対して、ディメンションは「何ごとに見るか」を決めます。

あわせて決めるのが、どの単位でまとめるかです。
同じ「売上」でも、日単位で見るのか、月単位で見るのかで数字は変わります。

この単位が決まっていないと、「今月の売上」と聞かれたAIが、締め日をまたいだ範囲で集計したり、経理の月次と1日ずれた範囲を返したりします。

テーブルの結合ルール

売上を担当者別に見るには、受注テーブルと社員テーブルをつなぐ必要があります。
この、どのテーブルとどのテーブルを、どの列でつなぐかという取り決めが結合ルール（JOIN）です。

dbtでは、テーブルをつなぐための列を種別つきで登録し、その情報をもとに結合の処理が組み立てられます。Lookerでは、どのテーブルがどう関係するかをLookMLに記述します。

ここが決まっていないと、同じ「売上」でも、つなぎ方によって数字が変わります。
1件の受注が複数の明細を持つときに、つなぎ方を誤れば同じ金額が二重に計上されます。

用語集とメタデータ

指標名やディメンション名に、業務での呼び名と説明を添える部分です。
「ARR」と書かれた指標が社内で何を指すのか、「粗利」に何が含まれているのか。
定義そのものではなく、定義を人が読んで理解するための情報にあたります。

ここはデータカタログと守備範囲が重なります。
データカタログ側で管理している説明情報を、セマンティックレイヤーの指標定義に紐づけて使う形が一般的です。

権限とアクセス制御

誰がどの数字を見てよいかの制御です。
Power BIには行レベルセキュリティという仕組みがあり、営業担当者には自分が担当する地域の行だけが見える、といった制御ができます（出典: Semantic models in the Power BI service | Microsoft）。

AIエージェントを使い始めると、この要素の重みが変わります。
人がBIツールを開くときは、見られる範囲がツールの権限設定で決まっていました。

AIエージェントは質問に答えるために広い範囲のデータを取りに行くため、指標の定義と一緒に「この数字は誰に返してよいか」を持たせておかないと、権限の外側の数字が回答に混ざります。

セマンティックレイヤーと混同しやすい概念との違い

セマンティックレイヤーと混同されやすい概念が4つあります。
データカタログ、メタデータ管理、オントロジー、コンテキストレイヤーです。

データカタログとの違い

データカタログは、社内にどんなデータがどこに存在するかを一覧・検索できるようにする「索引」の仕組みです。

「顧客テーブルはこのデータベースのこのスキーマにあり、所有者はマーケティング部門、最終更新は○月○日」といった情報を管理します。

データカタログは「データの所在と管理情報」を扱いますが、そのデータを使ってビジネス指標をどう計算するかまでは定義しません。

詳しい内容はデータカタログとはで解説しています。

メタデータ管理との違い

メタデータ管理は、データの属性情報を体系的に管理する取り組みです。

テーブルの列が「文字列型か数値型か」「NULLを許容するか」「どのパイプラインで更新されるか」といった技術的な属性情報と、「このデータの業務上の意味」「だれが責任者か」といった業務的な属性情報の両方を対象とします。

メタデータ管理はデータカタログの機能として提供されることも多く、対象範囲はセマンティックレイヤーよりも広い一方で、ビジネス指標の計算のしかたは含みません。

メタデータはデータの「説明」であり、セマンティックレイヤーはデータの「計算の定義」です。

オントロジーとの違い

オントロジーは、ある領域の概念と概念のつながりを形式的に定義した取り決めです。

「顧客は注文を持つ」「注文は商品を含む」のように、業務に登場するものが何を指し、何とどうつながるかを決めます。

セマンティックレイヤーとの違いは、対象が関係か計算かという点にあります。
オントロジーが決めるのは「受注は1つの顧客に紐づく」という型と型のつながりです。

セマンティックレイヤーが定めるのは「今期の受注金額とは、受注日が今期に入る受注の、値引き後の金額を合計した数字」という計算のしかたです。

なお、製品によっては、オントロジーにあたる機能をセマンティックレイヤーと呼んでいる場合があります。ベンダーの資料を読み比べるときは、その製品が何を指してその語を使っているかを確かめる必要があります。

オントロジー側の詳細はオントロジーとはで解説しています。

コンテキストレイヤーとの違い

セマンティックレイヤーはもともと、BIツールがデータを読むための層として語られてきた用語です。
AIエージェントが社内データを読むようになってから、これと近い意味で使われる語として、コンテキストレイヤーが登場しています。

セマンティックレイヤーが「この数値の意味は何か」という問いに答える層であるのに対して、コンテキストレイヤーが回答するのは、それに加えて「いつ、どのルールで、誰がこの数値を使えるのか」「この回答はどのデータからどう生成されたのか」「過去に同じ問いにどう答えたか」といった、より広い問いです。

コンテキストレイヤーはセマンティックレイヤーを包含した存在で、より広い意味を含めてBIツールやAIエージェントに届ける役割を担っています。

5つの概念を一覧で整理する

データカタログ、メタデータ管理、オントロジーの3つとセマンティックレイヤーは、補完関係にあります。

データカタログは「見つける」、メタデータ管理は「説明する」、セマンティックレイヤーは「定義して使えるようにする」という役割分担です。

セマンティックレイヤーがないとAIエージェント活用で何が起きるか

ここで、セマンティックレイヤーが整備されていない状態でAIエージェントを導入すると、具体的にどんな問題が起きるのかを見ていきます。

AIエージェント活用の現場で繰り返し見られるケースを整理します。

同じ質問に違う数字が返る

営業担当者がAIエージェントに「今月の売上はいくら？」と聞いたとき、AIが受注テーブルを参照する場合と請求テーブルを参照する場合があります。

セマンティックレイヤーで「営業向け月次売上＝受注ベースでこう集計する」と定義されていれば、いつ誰が聞いても同じ数値が返ります。

定義がなければ、AIはテーブルの構造やカラム名から推測して回答するため、参照先が安定しません。

営業部門のAIエージェントが返した「月次売上1億2,000万円」と、経理部門のAIエージェントが返した「月次売上1億500万円」が一致しなければ、利用者はAIの回答を信用しなくなります。

原因はAIのモデル性能ではなく、参照先のデータ定義が統一されていないことですが、こうした食い違いが数回起きるだけで、現場のAI活用は急速に停滞するかと思います。

AIが集計の前提を取り違える

参照先が合っていても、集計の前提が食い違えば数字はずれます。

税抜で集計するのか税込なのか。キャンセルになった受注を含めるのか。締め日が月末なのか20日なのか。返品や値引きをどの時点で反映するのか。
人が集計するときは、こうした前提を経験で補っています。明文化されていないため、AIには渡っていません。

前提が渡っていないAIは、その場で妥当に見える解釈を選びます。
1件の受注に複数の明細がある場合に、明細ごとに金額を数えて合計を膨らませる、といった間違いも起こります。回答は断定的な形で返ってくるため、受け取る側は前提のずれに気づきません。

定義の食い違いを、毎回人が埋めることになる

定義が置かれていないと、その代わりを人が務めることになります。

AIに質問するたびに「売上は受注ベースで、キャンセル分は除いて」と前提を添えて聞く、という形です。
前提を知っている人が毎回書き足しているあいだ、定義はその人の頭の中にあり、組織には置かれていません。

同じことが、データソースを増やすときにも起きます。
セマンティックレイヤーが存在しない環境では、新しいSaaSやシステムのデータをAIエージェントの参照先に加えるたびに、接続設定やプロンプトの調整を個別に行う必要があります。

セマンティックレイヤーがあれば、新しいデータソースの指標定義をセマンティック層に追加するだけで、既存のAIエージェントからも一貫した形で参照できるようになります。
データソースが増えるほど、この運用負荷の差は広がっていきます。

AIエージェントの導入を検討するのであれば、データ側の数値の意味の定義をどう整備するかを議論に含める必要があるかと思います。

データ整備全体のなかでのセマンティックレイヤーの位置づけ

データ基盤からAIエージェントまでの4つの層

データ整備の全体像を層構造として整理すると、セマンティックレイヤーがどこに位置するかが見えやすくなります。

最下層にあるのが物理データ層です。
業務システム（ERP、CRM、SFAなど）やSaaSが日々生成するデータが、それぞれのデータベースに格納されています。
多くの企業では、これらのデータはシステムごとに分散した状態にあります。

その上に位置するのが統合・変換層です。
分散したデータをデータウェアハウスやデータレイク（構造化・非構造化を問わずデータを1か所に蓄積する保管領域）に集約し、分析可能な形に加工する層です。 各システムからデータを抽出し、変換し、格納する処理を担うデータ変換ツールが、この層で機能します。

セマンティック層は、統合・変換層と消費層の間に位置します。
統合されたデータに対して意味と計算のしかたを定義する層であり、「月次売上はこう計算する」「解約率はこの条件で求める」といったビジネス指標の定義がここで一元管理されます。

最上層が消費層です。
BIツール、ダッシュボード、AIエージェント、業務アプリケーションなどが、セマンティック層を通じてデータを参照し、レポートやAIの回答として出力します。

この全体像のなかでセマンティックレイヤーが果たす役割は、統合・変換層で整えたデータに数値の意味を付与し、消費層の利用者（人間であれAIであれ）が一貫した定義でデータを使えるようにすることです。

どの整備が先で、どれが後か

層の順に並べると、下から順に完成させていくように見えます。
実際の進め方は、そこまで直線的ではありません。

順序として動かせないのは、意味の取り決めが計算の定義より先に来るという点です。
「受注」が何を指すかが部門ごとに違う状態で計算のしかただけを決めても、違うものを合計した数字が並びます。何を何と呼ぶかを揃えることが、指標を定義する前提になります。

一方で、全社のデータを統合し終えてからでないとセマンティックレイヤーに手を付けられない、という順序ではありません。
1つの部門の、1つの業務システムのデータだけを対象にしても、そこで使う指標の定義は決められます。

統合を進める過程では「この2つのテーブルの売上は同じものか」という問いが出てくるため、指標の定義づくりは統合作業と並行して進むことになります。

セマンティックレイヤーの種類と提供形態

セマンティックレイヤーは、単体の製品として売られているとは限りません。
定義をどこに置くかによって、大きく3つの形に分かれます。

BIツールに組み込まれている型

BIツールの中に、指標とディメンションを定義する機能が備わっている形です。
Power BIのセマンティックモデルや、LookerのLookMLがこれにあたります。

分析の画面と定義の管理が近いため、定義を確認しながら分析を進められます。
すでにBIツールを導入している企業であれば、追加の製品を入れずに始められる点も現実的です。

制約は、定義がそのBIツールの中に置かれることです。
別のツールやAIエージェントから同じ定義を参照するには、それぞれの側で作り直すか、連携の仕組みを別に用意することになります。

BIツールから独立している型（ヘッドレス）

定義をBIツールの外に置き、複数のツールから参照させる形です。
dbt Semantic LayerやCubeがこの型にあたります。

dbtの説明では、指標の定義をBIツールではなくデータのモデリング層に置き、APIを通じて下流のツールに配る構成をとります。定義を変更すると、その指標を使っている場所に反映される構成です（出典: dbt Semantic Layer | dbt）。

BIツールとAIエージェントの両方から同じ数字を参照させたい場合は、この型が前提になります。一方で、データの変換処理を管理する仕組みを社内に持っていることが導入の条件になるため、着手のハードルはBI組み込み型より高くなります。

データ仮想化と一体になっている型

データを1か所に移さないまま、複数のデータソースを1つのビューとして見せる仕組みに、意味の定義を載せた形です。Denodoがこの型にあたります。

Denodoは、分析ツールごとに意味を定義すると定義が重複し、管理の手間が増えるという課題に対して、データの意味を1か所に集約する構成を挙げています（出典: Universal Semantic Layer | Denodo）。

データを物理的に集約しきれない事情がある場合、たとえば基幹システムのデータを動かせない場合に選択肢になります。

3つの型の比較

AIエージェントからの利用を前提にするのであれば、定義がBIツールの中で閉じていない形、つまり独立型かデータ仮想化型のどちらかに寄せる判断になります。

どこから手をつけるか

導入の5ステップ

提供形態の話が続いたので製品の選定から入るように見えますが、実際に着手すると、製品を選ぶ前に決めることのほうが多くなります。

1. 数字が合わない指標を1つ選ぶ
全社の指標を一度に定義しようとすると、決めごとの量で止まります。
部門間で数字が合わず、毎回確認が発生している指標を1つ選びます。
売上、稼働率、解約率のように、会議で数字の出どころが問われる指標が候補になります。

2. その数字の計算のしかたを、決められる人と合意する
どのテーブルの、どの列を、どの条件で集計するか。締め日、税の扱い、除外する条件まで決めます。
ここで必要なのはツールではなく、その指標の定義を決める権限を持つ人の合意です。
営業ベースと経理ベースのように2つ必要であれば、別々の指標として2つ定義します。

3. 決めた内容を文書に書き出す
合意した内容を、人が読める形のテキストとして書き出します。
この段階では専用の製品は必要ありません。
当社でも、Googleドライブ上に構築したデータレイクハウスのなかで、「この数値の定義は何か」といったAIに渡す前提情報を、専用の層を立てずにmarkdownとして記述しています（参考: Googleドライブでデータレイクハウスを構築した記録）。

4. AIとBIから、その文書を参照させる
書き出した定義を、AIエージェントが参照する場所に置きます。
先ほどの検証でAIの正答率を押し上げたのも、4KB程度の文書です。
製品を導入するかどうかは、この段階で参照のされ方を見てから判断できます。

5. 使われ方を見て、指標を足す
実際に質問が飛んでくる指標から順に定義を足していきます。
質問が来ない指標を先に定義しても、使われないまま古くなります。

運用に乗せるために決めておくこと

定義は、一度書いて終わりにはなりません。事業の形が変わると、指標の定義も変わります。

決めておく必要があるのは、まず定義を変更できる人です。
誰でも書き換えられる状態にすると、部門ごとの都合で定義が分岐していきます。
指標ごとに、変更を決められる人を1人決めます。

次に、変更をどう知らせるかです。
指標の定義が変わると、その指標を使っているダッシュボードとAIの回答が同時に変わります。
変更前に、その指標を見ている部門へ知らせる手順を決めておきます。

そして、権限の扱いです。
定義が増えるほど、誰がどの数字を見てよいかの判断が細かくなります。
指標を定義するときに、その数字を返してよい範囲もあわせて決めておくと、後からの整理が要らなくなります。

セマンティックレイヤーの理解がデータ整備の議論を変える

セマンティックレイヤーは、データに「ビジネス上の数値の意味」を定義する層です。

データカタログが「どこに何があるか」を管理し、メタデータ管理が「データの属性」を説明するのに対して、セマンティックレイヤーは「そのデータをどう計算してビジネス指標にするか」を定義します。

AIエージェントの時代に入り、この意味の定義層の重要性は高まっています。

人間がBIツールで分析するときは、暗黙の前提知識で補えていた「このテーブルのこの列は営業ベースの売上を指している」という文脈を、AIには明示的に渡す必要があるためです。

データ整備関連の記事や社内の議論で「セマンティックレイヤー」という用語が出てきたとき、データカタログやメタデータ管理、オントロジーの話と混同せずに、「ビジネス指標の定義と計算ロジックを一元管理する層の話だ」と切り分けて理解できるだけで、記事の理解度が大きく変わります。

セマンティックレイヤーの位置づけを正しく押さえておくことは、データ整備全体を正しく見通すために必要な要素です。