「今月の売上はいくらか」という問いに、営業部と経理部と経営企画部が別々の数字を出す。よくある話であり、たいていは誰も間違っていない。返品を引くか、内部取引を除くか、計上を受注日で見るか検収日で見るか。定義が違うだけで、それぞれの部署の中では正しい。
これまでは、会議で数字が合わないたびに人間が擦り合わせて済ませてきた。しかしAIが社内データに問い合わせを始めた時点で、この方式は限界を迎える。AIは擦り合わせをしない。定義が無ければ、その場でもっともらしい定義を発明して、自信のある数字を返す。
セマンティックレイヤーは、この問題に構造で答える層である。
この記事の対象読者
- BIツールのダッシュボードごとに数字が違う状態を解消したいデータ基盤担当者
- 社内データにAIで問い合わせる仕組みを検討していて、精度の担保方法を探している方
- dbtやメトリクスストアの導入を検討している分析基盤チーム
- 「AIに聞けば分かる」と言われた数字の信頼性をどう担保するか問われている責任者
セマンティックレイヤーとは
セマンティックレイヤーは、業務上の指標の定義を1箇所に集約し、そこを経由してのみデータを参照させる層である。
データウェアハウスのテーブルと、利用者（人間もAIも）の間に挟まる。利用者は「売上」「解約率」「稼働率」といった業務の言葉で問い合わせ、レイヤーがそれを正しいSQLに変換する。
構成要素は概ね4つに整理できる。
| 要素 | 意味 | 例 |
|---|---|---|
| ディメンション | 集計の切り口 | 期間、地域、商品カテゴリ、顧客セグメント |
| メジャー | 集計対象の生の値 | 受注金額、返品金額、稼働時間 |
| メトリクス | 業務指標としての定義 | 売上＝受注金額−返品金額（検収日基準、内部取引除く） |
| 結合関係 | テーブル間の正しい繋ぎ方 | 顧客と注文の結合キー、多重計上を防ぐ粒度 |
価値の中心はメトリクスにある。 「売上」という語が何を指すのかを1箇所で決め、その定義を全員が使う。定義を変えるときも1箇所を変えれば全体に反映される。
何が解決されるか
- 同じ問いに同じ数字が返る。 部署ごとのSQLが増えても定義は増えない
- 定義の変更が追跡できる。 指標定義がコードとしてレビュー・履歴管理の対象になる
- 結合の間違いが構造的に防げる。 多重計上のような、SQLを書くたびに再発する事故を1度で潰せる
なぜ2026年に重要度が上がったのか
セマンティックレイヤー自体は新しい概念ではない。BIツールの内部には以前から似た仕組みがあった。状況が変わったのは、AIがデータに直接問い合わせるようになったからである。
人間のアナリストであれば、出てきた数字に違和感があれば止まる。「この数字はおかしい」と気づき、定義を確認しに行く。AIはそれをしない。スキーマから読み取れる範囲で、もっともらしいSQLを書いて、確信を持って結果を返す。
実測されている差
dbt Labsが2026年に公開したベンチマークは、この差を数字で示している。保険業のデータセット（15テーブル）に対して11問を各20回実行したものである。
下表は同じモデリング済みデータに対して、AIにSQLを書かせた場合と、セマンティックレイヤーを経由させた場合を比べたものだ。データは同一で、違いはインターフェースだけである。
| モデル | text-to-SQL | セマンティックレイヤー経由 |
|---|---|---|
| Claude Sonnet 4.6 | 90.0% | 98.2% |
| GPT-5.3 Codex | 84.1% | 100.0% |
同じデータを与えても、AIにSQLを書かせる方式は84〜90%で頭打ちになる。 構文は正しいが意味が違うSQLを書いてしまう領域が残るためである。なおベンチマークにはモデリングを施さない生スキーマの構成も含まれており、そちらの正答率はさらに低い。
数字より重要なのは、失敗の質が違うこと
このベンチマークの核心は正答率ではない。失敗したときに何が起きるかが、2つの方式で決定的に違うという点である。
- text-to-SQLの失敗：もっともらしい間違った数字が返る。エラーは出ない
- セマンティックレイヤーの失敗：「その質問には答えられない」というエラーが返る
前者は沈黙して間違える。後者は声を上げて止まる。取締役会資料・監査対応・全社KPIダッシュボードのように、間違いが下流に流れると取り返しがつかない用途では、この違いがすべてである。
10%の誤答率が問題なのではない。その10%がどれなのか分からないまま流通することが問題なのだ。
この数字の限界も書いておく
11問・15テーブルという小規模なベンチマークである。自社のデータで同じ差が出る保証はない。またセマンティックレイヤー側の高い数値は、dbtのベストプラクティスに沿ってきちんとモデリングされた状態での結果であり、雑に定義を並べただけでは再現しない。
この数字は「セマンティックレイヤーを入れれば精度が上がる」という主張の根拠ではなく、「定義の層を作り込めば失敗の出方を制御できる」という主張の根拠として読むべきである。
導入の順序
一度に全社の指標を定義しようとすると、まず終わらない。実務で機能する順序は次のとおりである。
1. 数字が割れている指標から始める
すべての指標を定義する必要はない。会議で毎回議論になる指標が、最初に定義すべき指標である。 通常は5〜10個で足りる。
2. 定義の「決裁者」を決める
技術的な作業より難しいのはここである。「売上とは何か」を最終的に決めるのは誰か。データ基盤チームではなく業務部門であるべきだが、その合意が取れていないまま実装に入ると、レイヤーの中に複数定義が並ぶ結果になる。
セマンティックレイヤーの導入は、技術プロジェクトではなくガバナンスの合意形成である。 ここを飛ばすと、定義が1箇所に集まっただけで統一はされない状態になる。
3. 既存のBIダッシュボードを1つ移す
新規の分析から始めず、すでに使われているダッシュボードを1つ選んでレイヤー経由に置き換える。既存の数字と一致するかで、定義が正しいかを検証できる。一致しない場合、その差分こそが今まで放置されていた定義のズレである。
4. AI経由の問い合わせを繋ぐ
ここまで来て初めて、AIに触らせる。順序を逆にしない。 定義が固まっていない状態でAIを繋ぐと、AIが出した数字の検証にかかる工数のほうが大きくなる。
5. カバー範囲外の扱いを決めておく
セマンティックレイヤーは定義された指標しか答えられない。カバー範囲外の探索的な問いをどう扱うかを決めておく必要がある。 実務では「重要な数字はレイヤー経由、探索と発見は生データへの直接問い合わせ」という併用が現実的である。両者を使い分けること自体を設計に含める。
オントロジーとの関係
セマンティックレイヤーとオントロジーは重なる部分があるが、射程が違う。
セマンティックレイヤーは「読む」ための層である。 指標定義を統一し、正しい集計結果を返すことに焦点がある。
一方、企業向けオントロジーはこれに加えて「動かす」ための層を持つ。データの意味だけでなく、そのデータに対して実行できる操作までを型として定義する。AIエージェントに業務そのものを実行させたい場合、この射程が必要になる。
先にセマンティックレイヤー、必要になったらオントロジーへという順序が実務的である。指標定義すら揃っていない状態でオントロジーの構築に着手しても、土台が無い。
オントロジーの詳細はオントロジーとは？AI時代のデータ活用を変える意味の地図で扱っている。
失敗パターン
定義の決裁者を決めずに始める。 前述のとおり最大の失敗要因である。技術で解決できない。
全指標を一度に定義しようとする。 完成しないまま推進力が尽きる。割れている指標から始める。
既存ダッシュボードとの突き合わせを飛ばす。 検証手段を持たないまま本番に載せると、間違った定義が「公式の数字」として固定される。
AIを先に繋ぐ。 定義が無い状態でAIに問い合わせさせ、出てきた数字の検証で疲弊する。
カバー範囲外の問いを想定していない。 レイヤーが答えられない問いが来たとき、利用者が勝手に生SQLへ戻る。併用のルールを設計に含めておく。
FAQ
Q1. BIツールの内部にある定義機能と何が違うのか？
機能としては近いが、BIツール内の定義はそのツールの中でしか効かない。別のBIツール、Excel、AIエージェントからの問い合わせには適用されない。セマンティックレイヤーはツールの外側に置き、すべての利用経路が同じ定義を通るようにするものである。
Q2. dbtを使っていないと導入できないか？
できる。dbtは選択肢の1つであり、他にもメトリクスストアやセマンティックレイヤー製品がある。重要なのは製品選定ではなく、指標定義を1箇所に集約してコードとして管理する運用が回るかどうかである。
Q3. 精度が98%あればAIに任せてよいか？
用途による。残り2%がどれか分からないことが問題なので、間違いが下流に流れると取り返しがつかない用途（取締役会資料、監査、外部公表数値）では、AIの出力をそのまま採用しない前提を残す。セマンティックレイヤーの利点は、答えられない問いに対して沈黙せずエラーを返すことであり、それは人間の確認ポイントを作れるという意味である。
Q4. 導入にどれくらいかかるか？
指標5〜10個の初期導入であれば、定義の合意が取れていれば数週間の作業である。時間がかかるのはほぼ合意形成の側で、実装ではない。 「売上の定義を決める会議」が何回必要かで期間が決まる。
Q5. 定義を変えたいとき、過去の数字はどうなるのか？
定義変更は過去の集計結果も変える。定義をコードとして履歴管理し、いつ何が変わったかを追跡できる状態にしておくことが前提になる。過去との比較が必要な指標は、旧定義を別メトリクスとして残す運用もある。
Q6. 小さな会社でも必要か？
指標定義が割れていないなら不要である。判断は規模ではない。同じ問いに違う数字が出ているかで決める。出ていないなら、まだ要らない。出ているなら、規模に関わらず問題は既に発生している。
Q7. AIエージェントに業務を実行させたい場合もセマンティックレイヤーで足りるか？
読み取りだけなら足りる。データを更新したり、業務上のアクションを起こさせたい場合は射程が足りない。 その場合はオントロジー側の設計が必要になる。
次に読むべき記事
- オントロジーとは？AI時代のデータ活用を変える意味の地図 — 「動かす」層まで含めた意味の設計
- Company Brain（カンパニーブレイン）とは？企業のAI知識基盤 — 全社の知識基盤としての全体像
- ハーネスエンジニアリングとは？エージェント品質の決め手 — AIの出力を検収する仕組み側の設計
- AIアセスメントとは？業務棚卸しと投資対効果の設計 — どの業務から着手するかの判断
まとめ
- セマンティックレイヤーは、指標の定義を1箇所に集約し、そこを経由してのみデータを参照させる層である
- 重要度が上がったのはAIが直接データに問い合わせるようになったから。人間と違い、AIは定義の違和感で立ち止まらない
- dbt Labsの2026年ベンチマークでは、同じモデリング済みデータに対してAIにSQLを書かせると84〜90%で頭打ちになるのに対し、セマンティックレイヤー経由は98〜100%だった
- 数字より重要なのは失敗の質である。 text-to-SQLは沈黙して間違え、セマンティックレイヤーは声を上げて止まる。間違いが下流に流れる用途ではこの差がすべて
- ただしこのベンチマークは11問・15テーブルの小規模なもので、高い数値はきちんとモデリングされた前提のものである
- 導入順序は「割れている指標から → 定義の決裁者を決める → 既存ダッシュボードで検証 → AIを繋ぐ」。技術プロジェクトではなくガバナンスの合意形成である
- 読むだけならセマンティックレイヤー、業務を動かすならオントロジー。先に前者、必要になったら後者
FDXのデータ基盤支援
FDXはAX（AI Transformation）の実装パートナーとして、指標定義の棚卸しから、セマンティックレイヤーの設計、AIからの問い合わせ経路の構築までを支援する。
「AIに社内データを触らせたいが、出てきた数字を信じてよいか分からない」という段階であれば、まず割れている指標を洗い出すところから着手するのが早い。業務とデータの棚卸しはAX診断で扱っている。
出典・参考文献
- dbt Labs Developer Blog「Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update」（ACME Insuranceデータセット15テーブル・11問を各20回実行。4構成を検証しており、本記事が引いた数値はモデリング済みデータに対する text-to-SQL と Modeled Semantic Layer の比較。Claude Sonnet 4.6は90.0%/98.2%、GPT-5.3 Codexは84.1%/100.0%。失敗の質の違いに関する記述を含む）
- 上記ベンチマークの原型データセットはdata.worldのJuan Sequedaらが作成したもの