業務のAI化データ基盤 — 「意味を強制するか、豊かに供給するか」¶

一言で: エージェントに業務データを生のまま渡すのは全社が否定する。本当の争点は「渡す前に、意味を enforced（強制） するか advisory（豊かに供給） するか」であり、正解は組織規模×問いの多様性で変わる。契約のスコープ（読み取り→意味→操作）を上げるほど強力になるが、完成形（Palantir）は重さとロックインを同時に背負う。

論点マップ¶

問い	対立軸	現在地（私の理解）
エージェントに何を渡すか	生テーブル vs 意味の足場	生テーブル直渡し（素の Text-to-SQL）は全社が否定。何らかの足場が要る、が共通了解
足場をどう効かせるか	enforced（強制）vs advisory（供給）	強制=意味層（クエリが必ずそこを通る／生 SQL を書かせない）、供給=AI-Ready data（豊かな grounding＋ガードレール）。組織規模で最適が動く
意味層は必須か	要る派 vs 要らない派	Gartner/dbt/Cube は必須寄り、月1万件運用の実務家は「定型は意味層・深掘りは AI-Ready」。両者は留保で握れる
どこまで契約化するか	読み取り契約 vs 操作契約	読み取り固定（Sansan）は内製の現実解、操作まで契約（Palantir）は完成形だが重い
完成形を買うか	買う（Palantir）vs 内製	完成度と重さ・ロックイン・常駐人材依存は同じコインの裏表

知見の整理¶

1. 全社の共通了解 —「生テーブル直渡しはダメ」¶

意味層要る派（Gartner: MCP だけに頼る agentic 分析の60%が2028年までに失敗／dbt ベンチ: Text-to-SQL 単体 64.5% → 意味層カバー範囲 ~100%）も、要らない派（AI-Ready data 派）も、「生スキーマをそのままエージェントに渡す素の Text-to-SQL はダメ」では一致している。争うのは足場の効かせ方だけ。

2. 足場の3層（下から積み上がる）¶

flowchart TD
  Raw["生テーブルを直接渡す<br>素の Text-to-SQL"]
  Floor["最低ライン<br>何らかの意味の足場が要る"]
  Adv["advisory 供給<br>AI-Ready data + ガードレール<br>信頼度スコア / SQL引用 / 計算前提の明示"]
  Enf["enforced 強制<br>意味層 = 定義を名前で選ぶ / 生SQLを書かない<br>compile-time 統治"]
  Onto["オントロジー + Action<br>意味 + 操作 + 権限を契約化<br>完成形だが重い"]
  Raw -->|"全社が否定"| Floor
  Floor --> Adv
  Floor --> Enf
  Adv --> Onto
  Enf --> Onto

advisory（供給）: 認証済みベーステーブル＋ビジネスオントロジー＋業務ルール辞書＋お手本＋評価ハーネス、にガードレール（信頼度・SQL 引用・計算前提）を添える。生 SQL は許すが、失敗しないほど基盤を耕す
enforced（強制）: エージェントは定義を書かず選ぶ。売上=どの JOIN か・粒度・権限を毎回モデルに再推測させない。行/ロール権限はクエリの作られ方に組み込む（事後フィルタでない）
オントロジー: 意味層＋実体の同定（Identity）＋関係（Relationships）＋操作（Action）。意味層 ⊂ オントロジー

3. enforced か advisory か —「意味層は要るか」論争¶

要る派の芯: メトリクスの作り方を固定しないと、同じ問いがセッションごとに違う数字を出す。統一定義がモデル進化だけでは埋まらない差を埋める
要らない派の芯: 意味層は「事前にモデル化した範囲の問い」しか答えられない（dbt 自身が認める限界）。深掘り分析には AI-Ready data の方が効く
握りどころ: 定型質問中心・小組織 → 意味層で十分。深掘りが常態・大組織 → AI-Ready data。まず意味層で始め、天井に当たったら grounding を厚くする移行経路

4. 契約のスコープと各社の位置¶

同じ「セマンティックレイヤー」を掲げても、実装は enforced ↔ advisory に大きく散る。生 SQL を書くか（＝足場が効いているか）が見分け方。

社 / 製品	足場の作り方	軸上の位置
Cube / dbt SL / LookML	メトリクス定義を強制（生 SQL を書かせない）	enforced 意味層（本命の型）
タイミー	dbt＋Looker(LookML) を経由	enforced 意味層寄り
メルカリ Socrates	Basic Tables＋全カラム description を CI 必須＋カタログ＋Agent-as-Judge	advisory grounding（厚い）
カンム Synapse	業務コンテキストを MCP に注入するのみ	足場が薄い（advisory 未満）
LayerX	メタデータ整備＋設計思想の言語化	grounding 構築中
10X	data contract＋dbt-osmosis でカタログ	足場の下地（契約・メタデータ）
Sansan DataBridge	人・組織データの読み取り契約（正本は持たない）	前段（データ自体を整える／読み取り契約）
Palantir Foundry	意味層＋オントロジー＋Action	完成形（操作まで契約・重い）

5. 完成形（Palantir）の代償¶

Ontology が enforced（意味も操作も権限も強制）だからこそ強く、その強制を成立させるオントロジー構築・保守が重く・抜けにくく・人依存になる。W3C/OWL 非準拠でオントロジーをエクスポートできず移行が高コスト（構造的ロックイン）、OWL 的な論理推論はしない（関係は明示モデル必須）、価格は Compute/Storage/Ontology の3軸従量。完成度と重さは分離できない — だから内製各社は「操作まで契約」を避け、読み取り契約や意味層で止めて自社所有・作り直せる軽さを買っている。

6. 全社共通の宿題 — 評価系¶

足場（意味層／grounding）を整えても、エージェントの回答の妥当性を測る評価系は別問題として全社が直面。メルカリは Agent-as-Judge、カンムは Text-to-SQL の Execution Accuracy、タイミーは評価環境が積み残し。足場はクエリの正しさを保証するが「そのクエリを選んだ判断」の妥当性は保証しない。

主要ソース¶

作成: 2026-07-24 ／最終更新: 2026-07-24