社内でChatGPTに「先週の売上は？」と聞いた回答と、ダッシュボードの数字が食い違う。営業本部長が経理部長に確認したら、また別の数字が出てくる。ここ1年、こうしたご相談が急に増えました。
原因の多くはAIの精度ではなく、「売上」という言葉の定義が社内で揃っていないことにあります。受注ベースか入金ベースか、税抜きか税込みか、返品を含むか。人間のアナリストなら「これは税抜きですよね」と聞き返せますが、生成AIは聞き返さずに推測で答えます。
この「同じ数字でもチームで結果が違う」という古典的な問題は、生成AIの普及で一気に顕在化しました。そして解決策として注目度が急上昇しているのが、セマンティックレイヤー（意味の層）です。ガートナーは2026年の予測で、2030年までにこの層はデータ基盤やセキュリティと並ぶ必須インフラになると明言しています。
何が変わったのか、どんな仕組みで、どう入れれば失敗しないのか。国内外の最新の動向と実装の現場感を、順に整理します。
まず、なぜ2025〜2026年にかけて業界の話題が集中しているのかを、数字で確認します。
自然言語でDWH（データウェアハウス、分析用にデータを集約して保管する基盤）に問いかける仕組みは、この2年で一気に普及しました。BigQueryのGemini in BigQuery、Snowflake Cortex、Databricks Genie、Microsoft Fabric Copilot。どのDWHにもチャットで質問できる窓口が付き、社内でも試したチームが多いのではないでしょうか。
そこで露呈したのが、AIが生成するSQLの品質問題です。dbt Labsが2026年に公開したベンチマークでは、生のText-to-SQL（自然言語からSQLを直接生成する方式）の正答率は**約10〜51%だったのに対し、セマンティックレイヤー経由では90〜100%**まで跳ね上がりました。差の要因の大半は、指標定義や結合条件をAIが推測してしまうことにあります。
4,602件のText-to-SQLエラーを分析した2025年の学術研究「NL2SQL-Bugs」でも、実行失敗のうち80%以上が「スキーマ関連のハルシネーション」、つまり存在しない列名や誤った結合を生成した結果でした。
調査会社ガートナーは、2026年のデータ&アナリティクス予測（2026年3月）で、次のように示しています。
「AIエージェントをDWHに繋いで自然言語で答えさせる」だけでは早晩壁にぶつかる、その手前に共通の意味定義を置け、というのがガートナーの主張です。
2025年後半から2026年にかけて、Snowflake・dbt Labs・Databricksが中心となって **Open Semantic Interchange（OSI）**という標準化イニシアチブが立ち上がり、CubeやAtScaleもYAMLの定義形式を寄せる動きを見せています。特定ベンダーに閉じた仕様ではなく、ツールをまたいで持ち運びできる状態が近づいています。
流行りものではなく、業界全体が「共通の意味定義がないとAIの時代は前に進まない」という認識で足並みを揃え始めた、と読むのが正確です。この2025〜2026年にかけての変化は、モダンデータスタック（MDS）の中に「セマンティックレイヤー」「オブザーバビリティ」「AI/MCP接続」という新しい3層が第一級市民として組み込まれた再編でもあります。全体像はモダンデータスタックとは？2026年の構成例と費用で整理しています。
用語だけ聞くと抽象的なので、位置と役割から押さえます。
セマンティックレイヤーは、BigQuery や Snowflake といったDWHと、それを利用するBI・AI・社内アプリの間に挟む**「用語の公式辞書」**です。「売上」「受注件数」「粗利率」といった指標の計算式や、それを切る次元（日付・部署・商品カテゴリ）を、YAMLなどのコードで1度だけ定義します。
利用側（BIツール、AIエージェント、社内アプリ、Jupyter Notebook）は、生SQLを書く代わりに「売上を月別に、部署ごとに」といった指標名と次元の組み合わせで問い合わせます。裏でセマンティックレイヤーが決定的なSQLに翻訳し、DWHに投げ、結果を返します。
上の図のように、DWHには手を入れずに、その上に薄い「意味の層」を置いてすべての利用側に配信する、というイメージが近いです。
役割は大きく3つに整理できます。
ダッシュボードの中でも、AIチャットでも、社内アプリのAPIでも、同じ定義と同じ権限で数字が返る状態を作る。これが、セマンティックレイヤーが引き受ける仕事です。
AI活用の前提となるデータ整備の全体像は、なぜAI時代にこそデータ基盤が必要か｜生成AIが失敗する理由で整理しています。あわせて読むと、この層がなぜ「AI-readyなデータ」の要になるかが把握できます。
「うちのBIには計算メジャーの機能がある。それとは何が違うのか」という問いは、実際によくいただきます。ここは押さえておきたい点です。
TableauやPower BI、Lookerには、指標や次元を定義する機能が古くからあります。Lookerの「LookML」は、この分野の元祖にあたる仕組みです。ただし、そこで定義した指標は各BIツールの中に閉じます。
Tableauで「受注ベースの売上」を定義しても、Power BIから同じ定義は参照できません。AIエージェントや社内アプリからも直接呼べません。結果として、複数BIを併用している組織では、同じ指標を各BIで再定義することになります。定義がツール間でズレて、**「BIをまたぐと数字が違う」**問題が生じる典型例です。
対して2020年代に伸びてきたのが、UIを持たないHeadless型のセマンティックレイヤーです。dbt Semantic Layer、Cube、AtScaleがこの系統です。
上の図のように、Headless型は「1つの定義を、SQL/GraphQL/REST/MCPといった複数のAPIで配信する」ことに特化しています。BIツールを乗り換えても定義は再利用でき、AIエージェントも同じ定義に基づいて数値を取得できます。定義はYAMLなどのテキストで書き、Gitで管理してPRレビューを回せます。
2025年以降の潮流は、明確にHeadless側にあります。BI閉じの定義を否定するというより、「AIやアプリも呼び出す時代には、BIの外に定義を出す必要が増えた」という位置づけです。従来のBIツールとの比較や選び方は、Power BI・Tableau・Lookerを徹底比較｜3大BIツールの選び方でも整理しています。
具体的にYAMLで何を書くのかを、代表的な要素で押さえます。
上の図で示した6つが、dbt Semantic LayerでもCubeでも共通する骨格です。個別に見ます。
なおDimensionsの「商品カテゴリ」「チャネル」といった項目名は、社内で用語がぶれやすい部分でもあります。データカタログで全社共通の用語集を先に整えておくと、複数チームでYAMLを書いても定義がずれにくくなります。
書き方の雰囲気を示すと、dbt Semantic Layerでは次のようなYAMLで指標を定義します。
semantic_models:
- name: orders
model: ref('fct_orders')
entities:
- name: order_id
type: primary
- name: customer_id
type: foreign
dimensions:
- name: order_date
type: time
- name: sales_channel
type: categorical
metrics:
- name: net_revenue
label: 税抜き売上
type: simple
type_params:
measure: order_amount_ex_taxこのYAMLを1度書けば、BIからも、AIエージェントからも、社内アプリからも、net_revenue という同じ指標を同じ計算で呼び出せます。dbtのモデル管理そのものについては、dbtとは？データ変換をコード管理するツールの仕組みを解説で解説しています。
セマンティックレイヤーが特に効くのが、生成AIとの連携です。ここは冒頭の数値（AIの回答精度80%改善）に直結する話です。
自然言語でDWHに問いかける最も素朴な方式は、AIに生SQLを組み立てさせる直接Text-to-SQLです。GeminiやClaudeがDWHのスキーマを見て「たぶんこう書けばよい」とSQLを生成します。
上の図のように、この経路ではLLMが「売上とは何か」「どの列を使うか」「どこでJOINするか」をすべて推測します。列名を微妙に間違えたり、返品を除外し忘れたり、部署でズレる定義のうち一方を採用してしまったり。実行に失敗すれば気付けますが、実行に成功して「それらしい違う数字」を返すのが一番厄介です。
同じ質問を、セマンティックレイヤー経由に切り替えるとどうなるか。LLMは「どの指標を、どの次元で切るか」を選ぶだけになり、SQLはセマンティックレイヤーが決定的に生成します。指標と次元は事前にYAMLで定義済みなので、推測が入る余地がありません。
先ほど触れたdbtの2026年ベンチマーク（正答率10〜51% → 90〜100%）は、この経路の切り替えで得られる差です。
実装パターンは2種類あります。
Google Cloudは、Looker MCP Server経由でGeminiに問い合わせると、LLM単独時と比べて自然言語誤解の頻度が約2/3に減ったと報告しています（Google Cloud Blog、2025年）。
「RAG（検索拡張生成）とセマンティックレイヤーはどう使い分けるのか」もよく聞かれます。
答えは補完関係です。RAGは非構造データ（社内ドキュメント、契約書、議事録）から関連情報を検索して渡す仕組みです。セマンティックレイヤーは構造化された数値・KPIに対する問い合わせを担います。「うちの就業規則で在宅勤務は何日まで？」はRAG、「先週の関東エリアの粗利率は？」はセマンティックレイヤー、という切り分けが素直です。
RAGの仕組みと実装で必要なデータ基盤要件は、RAGとは？企業の社内データをAIに使わせる仕組みと作り方で詳しく整理しています。
代表的な選択肢を、ざっくりの位置づけで整理します。
| プロダクト | 提供元 | 位置づけ | 強み |
|---|---|---|---|
| dbt Semantic Layer | dbt Labs | Headless、Git/YAML中心 | dbt Coreとの一体運用、コード管理、2025年末にMetricFlowがOSS化 |
| Cube | Cube.dev | Headless、API/アプリ中心 | OSS版あり、AI API（Cube AI API）でRAG組込機能を内包、キャッシュが強い |
| Looker（LookML） | Google Cloud | BI付き | 元祖の設計思想、Gemini in Lookerでの自然言語対応、Looker MCP Server |
| Power BI Semantic Model | Microsoft | BI付き（旧Dataset） | Fabric F2 SKU（月額約$262）で利用可、Copilot連携 |
| AtScale | AtScale | Headless、DWH非依存 | 2025年GigaOm Radarでリーダー評価、大規模組織で採用多め |
| MicroStrategy ONE | MicroStrategy | BI付き、Semantic Graph | AtScaleと統合可能、既存MicroStrategy顧客向け |
選定の考え方は、「既存の資産に寄せる」が現実的です。
日本国内での採用状況の定量データは公開ソースが乏しく、体感ではPower BI SemanticとLookMLが多数、dbt Semantic LayerとCubeが技術志向の組織で急速に採用が伸びている、という肌感です。TVer社のアドテク基盤ではdbt Platformが本番採用されており（TVer Tech Blog、2025年）、genda社ではCubeを社内プロダクトに組み込んだ事例が公開されています（Zenn、2025年）。
DWH側の選定はSnowflakeとBigQueryの違いを徹底比較｜選定基準3つで、Snowflakeの位置づけはSnowflakeとは？特徴・料金体系・BigQueryとの違いを解説で整理しています。
最後に、実際に入れるときの流れと、現場で見かける失敗を整理します。
コアKPI 10〜20指標に絞ってYAML定義から始めるのが、失敗しにくい進め方です。
実装期間は、コアKPIに絞れば1〜3か月が現実的な目安です。100指標を超える規模だと、6〜12か月の中期プロジェクトになります。
現場でよく見る失敗は、大きく3つに集約されます。
Evastの現場では：セマンティックレイヤーの導入相談を受けるとき、最初にお聞きするのは「今、部署で数字が割れて困っている指標はありますか」です。ここに具体名が挙がる組織は導入がスムーズで、「特に困っていない」組織は現時点では時期尚早のことも多い。困りごとを起点にすると、レビュー体制も自然と回り始めます。
導入前の準備として、社内で使われている指標定義の棚卸しと、DWHへのデータ集約が済んでいることが前提です。まだ集約段階なら、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説やデータ基盤構築の費用相場｜内訳・見積もりの取り方・コスト削減のポイントを先に参照してください。
セマンティックレイヤーは、DWHと利用側の間に置く「用語の公式辞書」です。「売上とは何か」を1度だけ定義し、BIからもAIからもアプリからも同じ数字が返る状態を作ります。
生成AIが自然言語でDWHに問い合わせる時代になり、「指標定義が揺れると、AIが自信満々で違う数字を返す」問題が一気に顕在化しました。ガートナーは2030年までにこの層が必須インフラになると予測し、Snowflake・dbt Labs・Databricksを中心に定義形式の標準化も進んでいます。
導入は、争いのある指標10〜20個からコード（YAML）で定義し、BI・AI・アプリ横断で同じ数字を返す状態を作るのが最短ルートです。DWHがまだ整っていない段階では、まず集約と加工（dbtなど）を進めるほうが優先されます。
Evastでは、BigQuery・Snowflake・dbtを軸としたデータ基盤の構築から、セマンティックレイヤーの設計・導入、AI活用の連携までを一貫して支援しています。「AIとダッシュボードで数字が違う」「社内チャットボットが変な数値を返す」といった具体の困りごとから、データ基盤構築サービスやお問い合わせでご相談ください。
データ基盤生成AIで成果が出ない原因はモデルではなくデータです。ガートナー調査では63%が「AI向けデータ整備の手法なし」と回答。AI-readyデータの5条件、BI用整備との違い、MCP時代の接続口、3〜6か月で最初の成果を出す段階的な進め方を、発注・社内推進に使える形で整理します。
データ基盤モダンデータスタックは2026年も主流だが、Fivetran＋Snowflake＋dbt＋Lookerのフル構成は月146万円超の重装備。中堅の現実解はBigQuery＋TROCCO＋dbt Coreで月20〜80万円に収まる。5層構成・費用差・Agentic Data Stackへの移行を実装現場から整理。
データ基盤保険業界のデータ活用が進まない本質は「契約が数十年続く時系列」「代理店・銀行窓販・Webのチャネル分断」「FISC安全対策基準＋要配慮個人情報の同意設計」の3つ。BigQuery・Snowflake・Databricksの使い分け、損害率・継続率・不正検知など5つの効くユースケース、初期800万〜2,500万円の中堅保険会社向け現実解と、4〜8週間で立ち上げる進め方を整理しました。