dbt Semantic Layer vs. Text-to-SQL：2026年ベンチマーク最新版

LLMを使ってデータから答えを得る方法は、大きく2つあります。モデルに直接SQLを生成させるか、dbt Semantic Layerのような構造化されたオントロジーを通じてクエリさせるか、です。どちらも実際のビジネス現場で成果を上げています。ただし、失敗の仕方はまったく異なります。どちらを選ぶかを判断するうえで本当に重要なのは、この違いを理解することです。

2023年に私たちは両アプローチを比較したベンチマークを実施し、Semantic Layerが大差で勝利しました。しかし2023年は、LLMの時間軸でいえば約1,000万年前に相当します。モデルのSQLを書く能力は劇的に向上しました。そこで、その差が縮まったかどうかを確かめるべく、最新世代のモデルでベンチマークを再実施しました。

TL;DR

• Text-to-SQLの精度は大幅に上がっています。GPT-4世代から現在への改善は目覚ましいものがあります。
• よくモデリングされたSemantic Layerの対応範囲内では、正答率が100%に近いかそれに達しています。決定論的なクエリ生成により、LLMが微妙にずれた結果を出してしまうことがありません。
• データモデリングの品質は、どちらのアプローチにとっても非常に重要です。 生テーブルの上に最小限のモデリングを加えるだけで、結果は全体的に改善されました。
• 推奨： アドホックな分析や小規模データセットにはText-to-SQL。精度が求められる大規模・複雑・整備されていないエンタープライズ用途にはSemantic Layerを推奨します。

数値は今後も改善し続けるでしょうが、根底にある原則は変わらないと考えています。ベンチマーク自体を試したい方、詳細なデータやコストを確認したい方はリポジトリをご覧ください。それ以外の方は、方法論の詳細や学んだことについて、このまま読み進めてください。

2つのアプローチの仕組み

本題の数値に入る前に、それぞれのアプローチの仕組みをおさらいしておきましょう。

Text-to-SQLはシンプルなアプローチです。LLMにスキーマ情報を渡し、自然言語の質問に答えるSQLクエリを生成させます。テーブル名・カラム名・関係性といった構造的な手がかりからデータのセマンティクスを推測し、毎回ゼロからクエリを組み立てます。データさえあればどんな質問にも対応できる柔軟性がある一方で、脆弱さも持ち合わせています。テーブルの結合を誤ったり、カラムの意味を誤解したり、実行はできても誤った結果を返すクエリを生成してしまうことがあります。質問と生成されたSQLの間には、何のガードレールもありません。

dbt Semantic Layerのようなオントロジー駆動のアプローチは、まったく異なる方法で動作します。LLMに生のSQLを書かせるのではなく、ビジネスロジックを組み込んだ構造化されたオントロジー（メトリクス、ディメンション、エンティティ、およびそれらの関係性）をあらかじめ定義します。LLMの仕事は、自然言語の質問を適切なメトリクスとディメンションの組み合わせに落とし込むことだけです。実際のクエリ生成はMetricFlowが決定論的に行うため、LLMが誤った結合や不正確な集計を生み出すことはありません。正しいメトリクスとディメンションが選ばれれば、クエリの正確性は保証されます。さらに重要なのは、実行するたびに微妙に異なる「それらしい数値」が出てくることもないという点です。ロジックはコードとして定義されており、常に同じ結果を返します。ただしトレードオフもあります。対応できるのは、あらかじめモデリングされた範囲内の質問に限られます。

どちらにも存在価値があります。では、それぞれどこで力を発揮し、どこでつまずくのか？実際に検証しました。

ベンチマーク

Juan Sequeda氏らがdata.worldで開発したACMEインシュアランスベンチマークを使用しました。実世界の分析的な問題を模倣した、適度な複雑さを持つデータセットです。11の質問を複数のLLMで各20回実行しました。

テストした構成は4つです：

1. Text-to-SQL：エージェントがスキーマ情報をもとにゼロからクエリを作成
2. 最小限のdbt Semantic Layer：元の（高度に正規化された）テーブルの上に構築した軽量なdbtプロジェクト
3. モデリング済みdbt Semantic Layer：dbtのベストプラクティスに沿って再構築したプロジェクト
4. モデリング済みデータへのText-to-SQL：ゼロからクエリを作成しますが、上記で作成した新しいモデルにアクセスできる状態

dbtユーザーにとって最も実態に近い比較は、モデリング済みプロジェクトでのText-to-SQL対Semantic Layerです。ひとつ注意点として、Text-to-SQLを機能させるためにスキーマ全体をコンテキストとして読み込みましたが、これは大規模なデータセットでは現実的ではありません。数値を読む際にはこの点を頭に置いてください。

どのモデルを使うべきか（思ったよりも差はない）

フルベンチマークの前に、まずモデルの選択やReasoningレベルが結果に意味のある差をもたらすかどうかを確認しました。

Opus 4.6、Sonnet 4.6、GPT-5.3 Codex、GPT-5.2（GPT-5.4はAPI経由でまだ利用不可）を、複数のReasoningレベルでテストしました。Anthropicのモデルはlowからmax、OpenAIのモデルはnoneからxhighまでです。Semantic Layer経由で回答できる質問について、16通りの組み合わせの結果は以下のとおりです：

結論から言えば、Semantic Layerのクエリについてはほとんど関係ありません。ほとんどのモデルがReasoningの設定によらず100%かそれに近い正答率を達成しています。タスクが十分に具体的でコンテキストも明確なため、Reasoningトークンを増やしても効果が出ないのです。

Reasoningレベルを上げて変わるのは速度だけで、しかも遅くなる方向です。GPTモデルでxhighを使うと1クエリあたり平均20秒以上かかりましたが、highでは8秒で、精度の改善は見られませんでした。Anthropicのモデルでは、Reasoningレベルは結果にもレイテンシーにも影響しませんでした。

いくつかの想定外の結果もありました：

• Sonnet 4.6がOpus 4.6を上回った（今回のユースケースでは）
• GPT-5.3 CodexとGPT-5.2はほぼ同等の結果
• 大きいモデルが構造化データタスクに最適とは限らない

これをふまえ、フルベンチマークはSonnet 4.6とGPT-5.3 Codexをデフォルトのレベルで実施しました。

本題：2023年対2026年

LLMはデータに関する質問に、2年前より上手く答えられるようになっているのでしょうか？

答えはYESです。 GPT-4（2023年11月）とGPT-5.3 Codex・Sonnet 4.6（2026年2月/3月）で、同じ11問を各20回実行して比較しました。2年前は一貫性のなかった問題も含め、両手法ともに100%正解できる問題が増えています。

以下は、MetricFlowにとってエンティティホップが多すぎるかどうかで分類した内訳です：

注目すべき点は以下のとおりです：

• Text-to-SQLの正答率がほぼ倍増し、32.7%から64.5%へ向上しました。 大幅な改善です。
• Sonnet 4.6とGPT-5.3 Codexは両手法でほぼ同じ結果でした： SLの正答率は同一、Text-to-SQLの全体正答率も同一（どちらも64.5%）。
• Semantic Layerの対応範囲内の問題については、両モデルとも100%正解しています。 以前は、データは正しいのにモデルが期待するディメンションを選ばないという誤答が1〜2件発生することがありましたが、今はそれもなくなりました。
• 2023年にSemantic Layerで回答できなかった問題は、追加モデリングなしには今も回答できません。 ただし、ここに大きな違いがあります。Semantic Layerは「回答できない」と明示します。誤ったデータを返すことはありません。 Text-to-SQLは平然と誤った数値を返します。

これが本番環境で最も重要な違いです。Text-to-SQLでは、失敗は「もっともらしいが誤った回答」として現れます。Semantic Layerでは、失敗は「エラーメッセージ」として現れます。 取締役会資料、監査対応、社内KPIダッシュボードなど、精度が問われる場面ではこの差が決定的です。

少しモデリングを加えるとどうなるか

一部の問題がSemantic Layer経由で回答できなかったのは、元のスキーマが第三正規形で高度に正規化されており、MetricFlowには多すぎるエンティティホップが必要だったためです。そこでひとつの問いを立てました。このギャップを埋めるために、最低限どれだけのモデリングが必要なのか？

LLMに対して、11問すべてをSemantic Layer経由で回答できるようにするための最小限のdbtモデルを作成するよう指示しました。結果として、コードを一切書かずに、いくつかのテーブルを結合して対応するセマンティックモデルを含む3つの新しいモデルが作成されました。

変更をgitにプッシュするとSemantic Layerが自動的に更新され、ベンチマークを再実施しました。Text-to-SQLのテストでも、新しいテーブルと関係性を含むDDLコンテキストを更新しています。

結果は一目瞭然です。 たった3つのモデルを追加するだけで、Semantic Layerはベンチマークの全問に回答できるようになりました。また、Text-to-SQLの精度も向上し、モデリングの改善が両方のアプローチに効果をもたらすことが改めて確認されました。

（GPT-5.2でも実施しましたが、結果は著しく弱く、Text-to-SQLの正答率はGPT-5.3 Codexの84.1%に対して68%にとどまりました。）

どちらを使うべきか

答えはText-to-SQL対Semantic Layerという二択ではありません。用途に応じて両方を使うことです。

複数のテーブルが関わる場合（今回のベンチマークでは15テーブル）、Semantic Layerを使うことで決定論性が加わり、正答率が劇的に向上します。Semantic Layerが答えられる問題は正確に答え、答えられない場合はそう伝えます。誤ったデータを黙って返すことはありません。

Text-to-SQLはより柔軟で、データが存在する限りどんな質問にも対応できます。ただしその柔軟性には代償が伴います。もっともらしく、しかし誤った答えを返すことがあるのです。なお、生テーブルの上にモデリングを加えることで、両方のアプローチの精度が改善されました。

私たちの考え方は以下のとおりです：

• 精度が重要な場面（取締役会資料、監査、OKR、KPI、週次レポートなど）： Semantic Layerを設定し、LLMを接続する。
• アドホックな探索（一度きりの質問、データディスカバリー、プロトタイピングなど）： まずSemantic Layerで答えられるか試す。できなければ、軽微なモデリング変更でギャップを埋められるか検討する。それでも難しければ、できる限り多くのスキーマコンテキストを持たせてText-to-SQLで対応する。

これはまさに、dbt agent skillsで推奨しているアプローチです。

試してみる・データを詳しく見る

フルベンチマークはオープンソースで、誰でも再現できます。元のノートブック+CSVの構成から、LLMとのやり取りにPydantic AI、結果の保存にDuckDBを使ったPythonライブラリへと移行しました。

• 自分のデータでベンチマークを試す： dbt-labs/dbt-llm-sl-bench
• コストとレイテンシーを確認する： フルベンチマークデータ
• 独自のSemantic Layerをセットアップする： dbt agent skillsを使ってAIに構築・設定してもらう
• 質問や発見を共有する： dbt Community Slack の #tools-dbt-mcp へ