意味層 vs Text-to-SQL — 2026 ベンチマーク（dbt）¶

作成日: 2026-08-12 出典 / きっかけ: dbt Developer Hub "Semantic Layer vs Text-to-SQL: 2026 Benchmark Update" 関連: aiエージェント時代のデータ基盤論争_意味層は要るか_整理 / 意味層_enforced_cube_dbt_looker_整理 / dbt_analytics_engineerからcontext_engineerへ_構造化文脈層_整理 / オントロジーと知識グラフ_理論から本番_nebulagraph_整理 / クラシル_データ基盤2人運用_data_owner_tier_ai_agent_整理

0. 要点（3行）¶

論点は「精度」ではなく「壊れ方」。text-to-SQL も意味層も動くし価値を出すが、失敗の仕方が根本的に違う。text-to-SQL は「もっともらしいが微妙に間違った答え」を黙って返す（silent error）。意味層は答えられないとき明示的にエラーを返す（fails loudly）。取締役会・監査・KPI に出す数字ではこの非対称性が全て。
2026 の実測: モデルは 2023 から劇的に上達し、text-to-SQL の全体精度は 32.7% → 64.5% とほぼ倍増。だが意味層の範囲内の質問では両モデルが 100% に達し、精度クリティカル用途では意味層が依然優位（MetricFlow が決定的に SQL 生成し、LLM の仕事を「意味分解」だけに縮める）。
意外な発見: 推論努力（reasoning effort）を上げても精度は上がらずレイテンシだけ増える（GPT xhigh 20秒 vs high 8秒）。Sonnet 4.6 > Opus 4.6、でかいモデル≠最良。構造化データのタスクでは「大きさ」より「決定的な足場」が効く。結論は "vs" ではなく「両方を用途で使い分け」。cf. aiエージェント時代のデータ基盤論争_意味層は要るか_整理

※ 出典は dbt 自身（意味層を売る側）だが、ベンチは再現可能なOSS（dbt-labs/dbt-llm-sl-bench）として公開され、text-to-SQL の改善も正当に評価している。モデル名は記事準拠（2026 時点）。

1. 2つのアプローチ — 同じ「NL→SQL」でも壊れ方が違う¶

自然言語から SQL を作る道は2つ:

	Text-to-SQL	Semantic Layer（意味層 / オントロジー駆動）
やり方	スキーマ情報（表名・列名・関係）を LLM に渡し、毎回ゼロから SQL を書かせる	業務ロジックを構造化オントロジーに符号化し、LLM は意味分解だけ。SQL 生成はエンジンが決定的に行う
LLM が推論するもの	構造的な手がかりだけから意味を推測	メトリクス／ディメンションの選択のみ
壊れ方	もっともらしく微妙に間違う（silent）	答えられない＝明示エラー（loud）

2. Text-to-SQL の失敗モード（silent error が肝）¶

不正な JOIN — どの表をどう繋ぐかを誤る
意味的曖昧性 — 列が実際に何を意味するか取り違える
サイレントエラー — 実行は成功するのに結果が微妙に間違う（一番危険）
非一貫性 — 同じ質問が run ごとに違う「それっぽい数字」を返す
スキーマのスケール限界 — データが大きいと全スキーマを context に載せるのが非現実的

3. Semantic Layer の仕組み（dbt Semantic Layer / MetricFlow）¶

構造化オントロジーを定義: メトリクス（業務指標）／ディメンション（属性）／エンティティ（業務オブジェクト）／それらの関係。
LLM の仕事を「意味分解」に縮める: 自然言語を「正しいメトリクス＋ディメンション」に分解するだけ。JOIN や集計は MetricFlow エンジンが決定的に生成。LLM は不正な JOIN や誤集計をそもそも作れない。
決定性の保証: LLM が正しいメトリクス／ディメンションを選べば、クエリは正しいことが保証される。run ごとに違う数字が出ることはない。ロジックはコード化され決定的。

トレードオフ: - カバレッジ制約: モデル化済みデータの範囲内しか答えられない。 - 失敗は明示的: 答えられない＝エラーメッセージ（間違ったデータではない）。

[Text-to-SQL]  NL → LLM が丸ごとSQLを書く      → 実行成功でも silent に誤りうる
[Semantic Layer] NL → LLM は metric/dimension を選ぶだけ → MetricFlow が決定的にSQL生成
                      選択が正しければ結果は保証／範囲外は loud にエラー

4. 2026 ベンチマーク結果¶

ベンチ条件: ACME Insurance（15 テーブル）、11 問 × 各 20 run。

4-1. モデル化後（3モデル追加後・modeled data）の TL;DR¶

モデル	手法	精度
claude-sonnet-4-6	Text-to-SQL	90.0%
claude-sonnet-4-6	Semantic Layer	98.2%
gpt-5.3-codex	Text-to-SQL	84.1%
gpt-5.3-codex	Semantic Layer	100.0%

4-2. 2023 vs 2026（全体像）¶

指標	T2SQL 2023(GPT-4)	T2SQL Sonnet4.6	T2SQL GPT-5.3	SL 2023	SL Sonnet4.6	SL GPT-5.3
SL 範囲内	26.9%	62.5%	51.2%	83.1%	100.0%	100.0%
SL 範囲外	48.3%	70.0%	100.0%	0.0%	0.0%	0.0%
全体	32.7%	64.5%	64.5%	60.5%	72.7%	72.7%

4-3. 主要な発見¶

Text-to-SQL の全体精度はほぼ倍増（32.7% → 64.5%、2023→2026）。
Sonnet 4.6 と GPT-5.3 Codex はほぼ同等（両手法とも）。
意味層の範囲内なら両モデルとも 100%。2023 は稀に誤り（正しいデータ・誤ディメンション）があったが解消。
範囲外は意味層では答えられない（追加モデリングが要る）。決定的な違い＝SL はエラーを返す／T2SQL はもっともらしい誤答を返す。

5. 意外な発見 — 「大きいモデル」でも「考えさせる」でもない¶

16 通り（Opus 4.6 / Sonnet 4.6 / GPT-5.3 / GPT-5.2 × 推論レベル）を検証:

意味層クエリではモデル選択がほとんど効かない — 大半が推論努力に関係なく 100%。
推論努力を上げても精度は上がらず、レイテンシだけ激増 — GPT xhigh = 20秒/クエリ、high = 8秒/クエリで精度差は無意味。
驚き: Sonnet 4.6 が Opus 4.6 を上回る／GPT-5.3 Codex ≒ GPT-5.2／最大モデル ≠ 最良モデル（構造化データタスクでは）。

含意: 意味層で足場を固めれば、安いモデル・低い推論努力で十分。コスト最適化の観点でも意味層が効く。cf. dbt_analytics_engineerからcontext_engineerへ_構造化文脈層_整理（文脈を SSoT 化してトークンを減らす話と地続き）

6. 最小モデリングの効果 — 3モデルで両方が改善¶

「11 問全部をカバーする最小モデリングは？」→ わずか 3 つの新規 dbt モデル（正規化テーブルを JOIN し、対応する semantic model を作る。手書きコード不要・LLM 生成）。
結果、text-to-SQL も意味層も両方改善（§4-1）。
教訓: 良いモデリングは両アプローチを等しく助ける。「意味層 vs T2SQL」以前に、モデリング（意味の整備）そのものが効く。

7. 使い分け＆ハイブリッド¶

意味層を使う: 精度クリティカル（取締役会資料・監査・OKR/KPI・週次レポート）／多数テーブル（本ベンチは15+）／複雑・雑然データ／保証された正しさが要る／エンタープライズ（ガバナンス・監査可能性）。

Text-to-SQL を使う: アドホック探索（単発質問・データ発見・プロトタイピング）／小さいデータ（スキーマが prompt に収まる）／カバレッジ > 確実性／素早い試作（モデリング不要）。

推奨ハイブリッド:

1. まず意味層で答えられるか確認
2. 無理なら → 軽微なモデリング追加で埋まるか評価
3. それも非現実的なら → スキーマ context 付き text-to-SQL にフォールバック

この流れは dbt の answering-natural-language-questions-with-dbt スキルに実装されている。

8. 核心 — failure mode の非対称性（まとめ）¶

アプローチ	失敗の型	本番リスク
Text-to-SQL	もっともらしい誤答	CRITICAL — silent error
Semantic Layer	明示的なエラーメッセージ	LOW — loud に失敗する

状況	推奨	理由
数字が意思決定・監査・KPI に乗る	意味層	silent error を出さない。決定的
単発の探索・試作	Text-to-SQL	カバレッジ優先、モデリング不要
多テーブル・複雑・雑然	意味層（＋最小モデリング）	決定性が効く。3モデルで両者改善
コスト/レイテンシが気になる	意味層＋安いモデル・低努力	推論努力は精度に効かずレイテンシだけ増える
範囲外の質問が来る	T2SQL フォールバック	意味層は範囲外を答えない（が、それは安全側）

一言で: モデルは SQL を書くのが劇的に上手くなった。それでも 「決定的な生成＋loud な失敗」を持つ意味層が、精度クリティカル用途では依然優位。答えは「text-to-SQL か意味層か」ではなく「用途で両方」。そしてどちらもモデリング（意味の整備）が土台。

参考リンク¶

原典: dbt "Semantic Layer vs Text-to-SQL: 2026 Benchmark Update" — https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026
再現可能ベンチ（OSS） — https://github.com/dbt-labs/dbt-llm-sl-bench ／結果サイト: https://dbt-labs.github.io/dbt-llm-sl-bench/
dbt agent skills（意味層セットアップ・NL質問応答） — https://github.com/dbt-labs/dbt-agent-skills
dbt MCP Server（意味層をエージェントに公開） — https://docs.getdbt.com/docs/dbt-ai/about-mcp

作成: 2026-08-12 ／最終更新: 2026-08-12