AIエージェントの土台になるセマンティックレイヤー｜指標定義を一箇所に

先週いちばん予約が多かった都市は？ ——社内のデータに自然言語で答えるAIアシスタントに、こんな問いを投げたとします。

返ってきた数字が、財務部の見ている数字と微妙に食い違う。

どちらが正しいのか、その場では誰も即答できません。エージェントが賢くなればこの問題は消える、と思いたくなります。

けれど、原因はモデルの能力ではありません。組織の中で指標の定義がバラバラだからです。

この記事では、AIエージェントが正しく答えるための土台になるセマンティックレイヤー（semantic layer）という考え方を、歴史と実務の両面から掘り下げます。何を、どう定義し、どこから手をつければいいのか。

順番に見ていきましょう。

なぜエージェントの答えはブレるのか

まず症状を正確に捉えます。同じ質問を二人の担当者にしても、返ってくる数字が違う。

これは多くの組織で日常的に起きています。

売上、アクティブユーザー、解約率。こうした基本指標ですら、部署ごとに計算式が違うのです。

原因は主に三つの揺れにあります。タイムゾーン（どの時刻でその日を区切るか）、フィルタ（返金やテスト注文を除くか）、集計方法（重複をどう数えるか）。

この三つがズレるだけで、同じ売上でも別の数字になります。

データアナリストのBenn Stancilは2021年に、この問題の核心を一言で表現しました。指標を定義する中央のリポジトリが存在しない、という指摘です。

定義がツールごとに散らばり、誰かが作った隠れたダッシュボードに埋もれ、監督のないまま何度も作り直される。だから同じ指標が、場所によって違う顔をするのです。

人間だけの時代でも、これは厄介な問題でした。会議のたびに数字のすり合わせに時間を取られた経験は、あなたにもあるはずです。

AIエージェントは、この混乱を一気に増幅します。人間なら「その数字、財務の定義と違うよね」と気づけますが、エージェントはテーブルに書かれた数字をそのまま正解として提示してしまうからです。

つまりエージェントは、組織の定義の曖昧さを、機械の速度で拡散する装置になりうる。ここが出発点です。

症状の一次事例——Airbnbが直面した信頼の崩壊

この問題が具体的にどう組織を蝕むのか。民泊プラットフォームのAirbnbが自社の技術ブログで語った事例が、教科書のようにわかりやすいです。

きっかけは、まさに冒頭のような問いでした。経営陣が先週いちばん予約が多かった都市を尋ねると、データサイエンスチームと財務チームが、微妙に違うテーブル・違う定義・違うロジックで、食い違う答えを返したのです。

問題はそこで終わりませんでした。食い違いが積み重なるうち、データサイエンティスト自身が自分の出す数字を疑いはじめ、やがて意思決定者のデータへの信頼が崩れていった、とブログは明かしています。

数字が信じられなくなると、組織は勘と声の大きさで動きはじめます。せっかくのデータ基盤が、意思決定の足を引っ張る存在に変わる。

これが定義の分散が招く最悪の結末です。

Airbnbが出した答えが、指標は一度定義し、どこでも使う（define metrics once, use them everywhere）という思想でした。同社はMinervaという仕組みを作り、指標・ディメンション・メタデータをGitHubの中央リポジトリで一元管理しています。

その規模は、公式ブログの時点で12,000を超える指標、4,000のディメンション、200を超えるデータ生産者に及びます。数字は今後も変わっていくでしょうが、桁感が問題の深刻さを物語ります。

ここで大事なのは、これが巨大企業だけの話ではない、ということです。指標が三つ以上あり、部署が二つ以上あれば、規模を小さくした同じ問題が必ず起きています。

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

では解決策の中心にある概念を、丁寧に定義します。セマンティックレイヤーとは、データベースのテーブルやカラムを、ビジネス上の意味を持つ指標や切り口にマッピングし、SQLを隠して一貫した定義を配る中間層のことです。

平たく言えば、生のデータベースと、それを使う人・ツール・エージェントのあいだに置く翻訳と統一のための一枚です。ここで有効予約とは何かを一度決めれば、あとは全員がその定義を共有できます。

この考え方には長い系譜があります。最初に商業的に成功したセマンティックレイヤーは、BIの草分けであるBusinessObjectsが1990年代に商用化したUniverse（ユニバース）だとされています。

Universeは、SQLを知らない業務担当者が、ビジネスの言葉でデータを問い合わせられるようにした発明でした。技術の詳細を隠し、意味の層を提供する。

この発想が、以後すべての土台になります。

2010年代に入ると、LookerがLookMLという言語で、この意味の層をコードとしてバージョン管理する流れを作りました。定義をファイルに書き、変更履歴を残し、レビューを通す。

ソフトウェア開発の作法が指標定義に持ち込まれたのです。

2020年代には、Benn Stancilが提唱したメトリクスレイヤー（metrics layer）の議論を経て、特定のBIツールに縛られないヘッドレスな形へと進化しました。そして今、AIエージェントがその定義を読む時代が来ています。

系譜を一本の線で描くと、Universe から LookML、メトリクスレイヤー、そしてAI時代へと、隠す対象は変わらず、読み手だけが人間から機械へ移ってきた、と整理できます。

何を、どう定義するのか

概念がわかったところで、実装の話に進みます。セマンティックレイヤーを実装する代表的な仕組みのひとつが、データ変換ツールdbtの提供するdbt Semantic Layerと、その中核エンジンMetricFlowです。

その設計思想を公式ドキュメントはこう説明します。指標の定義をBI層からモデリング層に移すことで、たとえ使うツールが違っても、各部門が同じ定義で作業していると確信できる、と。

肝は移す場所です。ダッシュボードの中に定義を書くのをやめ、データの手前の一箇所に集める。

dbtで定義を変えれば、呼び出し先すべてに自動で反映されます。

MetricFlowでは、意味の層をYAMLというテキスト形式で組み立てます。構成要素は四つに整理されており、この四層を理解すると定義作業の全体像が見えます。

要素	意味	例
entities	テーブル同士をつなぐ結合キー	予約ID、ユーザーID
dimensions	分析の切り口	都市、流入元、日付
measures	計算の素になる集計	予約件数、金額の合計
metrics	業務で使う最終指標	有効予約数、解約率

言葉だけでは掴みづらいので、実際の指標定義がどんな形になるか、擬似的な例を挙げます。有効予約数という一つの指標を、迷いなく確定させるとこうなります。

指標: 有効予約数 (valid_bookings)
  説明: 返金・キャンセルを除いた確定予約の件数
  対象テーブル: fct_bookings
  集計(measure): count_distinct(booking_id)
  フィルタ: status = 'confirmed' AND is_refunded = false
  タイムゾーン: Asia/Tokyo
  切り口(dimensions): 都市 / 流入元 / デバイス / 日付

注目してほしいのは、揺れの原因になっていた三つが全部そこに書いてあることです。タイムゾーン、フィルタ、集計方法。

これらが定義の中で固定されるから、誰が呼んでも同じ数字になります。

さらに現代のセマンティックレイヤーは、指標だけでなくジョインパス（どのテーブルをどう結合するか）とアクセス規則（誰がどのデータを見てよいか）も定義に含めます。ここが後で効いてきます。

指標をどう決めるか自体に迷うなら、その手前に組織の合意形成があります。定義を揃える営みそのものについては、KPIの定義を組織で揃えるで扱っています。

text-to-SQLではなく「名前で選ばせる」

さて、いよいよAIエージェントとの接続です。ここに、この記事でいちばん伝えたい設計判断があります。

エージェントにデータを扱わせる方法は、大きく二つに分かれます。ひとつは、質問を受けるたびにエージェント自身にSQLを書かせるtext-to-SQL方式。

もうひとつは、定義済みの指標を名前で選ばせる方式です。

一見、前者のほうが賢く柔軟に見えます。けれど、セマンティックレイヤーを扱うCubeの2026年の解説は、この方式が抱える構造的な弱点を鋭く突いています。

ordersというテーブル名だけを見ても、エージェントにはrevenueが総額なのか純額なのか、税込みか、返金を除くのかが分かりません。だから毎回、推測で計算してしまう。

ジョインパスが曖昧なら、エージェントは黙って二重計上します。しかも間違いを間違いと言わず、もっともらしい数字を返してくる。

アクセス制御も、SQLを書かせるだけでは効きません。正しいクエリと、他テナントのデータを漏らす危険なクエリを、SQLの見た目だけで見分けるのは難しいからです。

だからこそ設計の結論はこうなります。エージェントはロジックを書くのではなく、定義済みのものから選ぶ（selects from it）。

翻訳の自由をエージェントから取り上げ、認証済みの指標カタログの中だけで動かすのです。

この二つの方式の違いを、観点ごとに並べると輪郭がはっきりします。

観点	毎回SQLを書かせる	定義済み指標を選ばせる
定義の一致	質問ごとに推測でブレる	名前が同じなら常に同じ
二重計上	曖昧なジョインで起きうる	定義済みパスで防げる
アクセス制御	SQLだけでは効きにくい	指標に権限を紐づけられる
再現性	同じ問いで答えが変わる	同じ問いに同じ答え

このカタログをエージェントに渡す共通の受け口として、2026年時点で標準になりつつあるのがMCP（Model Context Protocol）です。AIが外部のデータや道具に接続するための共通インターフェースだと考えてください。

エージェントはMCPサーバーに、いま使える指標は何かを問い合わせます。すると、認証済みのmeasureとdimensionのカタログが返る。

エージェントはその中から選ぶだけです。

自由に書かせないことは、エージェントを弱くする話ではありません。むしろ暴走を防ぐガードレールになります。

この観点はAIエージェントのガードレール設計で掘り下げています。

どこから始めるか——小さく一箇所に確定する

理屈はわかった、でもうちには12,000の指標を管理する体力はない。そう感じたなら、それが正しい反応です。

始め方は、Airbnbほどの規模を目指すことではありません。全社で食い違っている数個のコア指標から着手するのが定石です。

多くの組織で最初に揉めるのは、売上、アクティブユーザー、解約率あたりです。この二つか三つを、まず一箇所に確定させる。

それだけで、会議のすり合わせ時間が目に見えて減ります。

進め方は、いまBIツールやダッシュボードの中に埋まっている定義を掘り起こし、モデリング層に引っ越すこと。Airbnbやdbtの一度定義してどこでも使うを、指標を数個だけ選んで小さく再現するイメージです。

最初の一歩を、三つの動きに分けて整理します。順番も大切です。

コア指標を選ぶ：部署間で答えが割れる二〜三個に絞る。最初から全部を狙わない。
揺れを固定する：タイムゾーン・フィルタ・集計方法を明文化し、モデリング層に一本化する。
呼び出しを移す：BIもアプリもエージェントも、その一箇所を参照する形に順に切り替える。

ここで見落としてはいけないのが、上流の計測の正しさです。セマンティックレイヤーはあくまで、集まったデータに一貫した意味を与える層。

素材となるサイト上の行動データが歪んでいれば、いくら定義を揃えても答えは合いません。

たとえば、Cookieに頼らず匿名の行動を正確に測るStrideのような計測層は、この土台の一部を担います。MCPに対応しているため、ClaudeのようなAIから自然言語でサイトの分析を呼び出すこともできます。

ただし、これはあくまで数ある構成要素のひとつにすぎません。

計測の土台をどう組むかという広い視点は、GTMのデータ基盤をつくるでまとめています。あわせて読むと、意味の層と計測の層の役割分担が見えてくるはずです。

まとめ——定義を資産として持つということ

最後に、この記事の学びを整理します。エージェントの答えがブレるのは、能力ではなく定義の分散が原因でした。

セマンティックレイヤーは、その分散を一箇所に集めて解く仕組みです。Universeから始まり、LookML、メトリクスレイヤーを経て、いまAIエージェントの土台になっています。

設計の急所は、たった一行に凝縮できます。エージェントにSQLを書かせず、定義済みの指標を名前で選ばせる。

これで、同じ問いには同じ答えが返る世界が実現します。

そして始め方は、大きく構えないこと。揉めている数個の指標を、揺れごと一箇所に確定させる。

ここが最初の投資対効果がいちばん高い場所です。

一段深い示唆を、最後にひとつ。指標の定義は、これまで人間の頭や暗黙知の中にありました。

エージェントの時代は、その暗黙知を明文化してテキストにし、資産として持つことを組織に要求します。

言い換えれば、AIに答えさせる準備とは、モデルを選ぶことではなく、自社の言葉の定義を書き下すことなのです。それは地味で、しかし最も効く投資かもしれません。

参考にした一次情報・公式ドキュメントは以下の通りです。