売上や在庫の数字を見たいだけなのに、結局は分析担当やDBAに依頼しなければならない。そんな待ち時間をなくす道具として、自然言語でデータベースを叩く「Text-to-SQL」が再び注目を集めている。しかも今回は大規模言語モデル、すなわちLLM（Large Language Model）が加わり、AWSやSnowflakeまで公式機能として前面に押し出し始めた。では、SQLを知らない現場ユーザーがそのまま頼って良い段階に来たのだろうか？情報を追ってみると、まず恩恵を受けるのは一般社員より分析者やDBAであり、最大の壁は構文生成ではなく「質問の意味を正しく定義すること」に残っていることが見えてくる。

AD

SQL生成ではなく「意味の翻訳層」として売り出されている

2026年4月7日付のAWS公式ブログは、Amazon Bedrockを使ったText-to-SQL構成を公開し、自然文の業務質問をSQLへ変換して結果まで返す流れを紹介した。そこでは単にSQL文字列を生成するだけでなく、実行結果を自然文で要約し、業務ユーザーが「数時間ではなく数秒で」答えを得られると訴求しており、自然言語クエリをSQLの代替UIとして再び押し出す動きが広がっている。ただし各社の公開資料を読み比べると、本当に力を入れているのは生成モデルそのものより、質問とスキーマの間をつなぐ意味付けの層だと分かる。

Snowflakeの公式ドキュメントは、その方向性をかなり明快に書いている。Cortex Analystでは、自然言語質問の精度を上げるためにsemantic modelやsemantic viewを用い、業務用語と物理スキーマを対応付ける。たとえば利用者が「先月の売上高」と聞いても、実データ側では列名が略称だったり、売上の定義が純売上か総売上かで異なったりする。Snowflakeはここをメタデータで埋める設計を採り、Cortex Analystがその定義を読んで物理テーブル向けSQLを生成すると説明している。自然言語から直接正解SQLをひねり出す魔法より、用語辞書と結合規則を整える地味な作業こそが精度を左右するわけだ。

この方針はAWS側の実装例でも確認できる。Amazon Bedrockの公式ユーザーガイドでは、構造化データ検索で TEXT_TO_SQL モードを指定して自然言語をSQLへ変換できる一方、ブログ記事ではアーキテクチャ、実装戦略、運用時の学びを詳しく述べている。LLMをつなげば完成する機能ではなく、対象スキーマの探索、権限、結果整形、失敗時の再試行まで含めたシステム設計が前提だ。Text-to-SQLが製品化フェーズへ入ったのは事実だが、製品化されたのは「限定された業務文脈で意味を矯正するパイプライン」である。

ボトルネックはSQL文法にない――76%の壁を作っているのは質問の曖昧さだ

BIRD（BIg Bench for LaRge-scale Database Grounded Text-to-SQL Evaluation）の原論文は、Text-to-SQLを小規模な学術課題から現実寄りの評価へ引き戻した。そこで測ろうとしたのは、単純な構文一致ではなく、大規模データベースをまたいで自然言語の質問を正しく解釈し、実行可能なSQLへ落とせるかどうかだった。著者らは課題として、汚れたデータ値、外部知識、SQL効率を挙げている。つまり難しさの中心は、SQLの文法暗記より業務文脈の読み取りに近い。

そのBIRDは、12,751件の質問とSQLのペア、95の大規模データベース、総計33.4GB、37分野を含む。2023年時点で有力モデルの実行精度は人間の92.96%に遠く及ばず、ChatGPT相当でも40.08%だった。その後の改善は急速だったが、2026年4月23日時点のBIRD公式リーダーボードでも、公開上位の一角であるAskData + GPT-4oはテストスコア76.31にとどまる。The Register記事が触れた「約82%」という数字は別設定や別評価の文脈を含んでいる可能性が高く、BIRD公式リーダーボードの現行値では76.31が確認できる。

2026年3月公開の論文「ReViSQL: Achieving Human-Level Text-to-SQL」は、複雑な推論パイプラインを積むほど精度が上がるとは限らないと示した。著者らはBIRD-Verifiedとして2,500件の検証済みText-to-SQLデータを整備し、その一部では61.1%に誤りが見つかったと述べる。データ修正だけで単発生成の精度が8.2〜13.9ポイント改善したという結果は重い。モデルを巨大化する前に、教師データや評価セットの品質が精度の天井を決めていたからだ。

University of Torontoの教授であるNick Koudas氏は、自然言語からSQLへの変換には、まず質問をデータベースのスキーマへ対応付け、次にSQLを生成する二段階が必要だと説明している。しかも企業ごとの独自スキーマや社内用語は事前学習済みLLMの外側にあるため、そのままでは高精度になりにくい。人間から見れば「売上」「顧客」「解約」は日常語でも、社内システムでは集計範囲や結合先が別物という場面が珍しくない。76%という数字は、SQL構文の不得手さより前に、質問の定義そのものが揺れる現実を反映した値と読んだ方が実態に一致する。

AD

必要なのは全自動化より、問い返せるインターフェース設計

NAACL 2025のPRACTIQは、既存のText-to-SQL研究が「答えられる明確な質問」へ寄りすぎていたと指摘し、曖昧または回答不能な質問を含む会話型データセットを構築した。そこでは最初の質問に対し、システムが確認質問を返し、利用者が補足し、その後にSQLを出す4ターン構成をとる。現実の業務質問が最初から完全に定義されているケースは少なく、「今期の主要顧客の失注理由を出して」といった曖昧表現をほどく工程が必要だからだ。ベンチマークを作る段階で問い返しを組み込んだこと自体、研究の重心が構文生成から対話設計へ移ったことを示している。

EMNLP 2023の「Interactive Text-to-SQL Generation via Editable Step-by-Step Explanations」も同じ方向を示した。この研究は、非専門家が誤ったSQLを直接読むのではなく、段階的な説明を編集してクエリを修正できる仕組みを提案している。24人のユーザー調査を含む評価では、こうした対話的修正が既存手法より良い結果を出した。生成AIのUIがチャット窓1つで済む時代に逆行するようでいて、実運用では「説明可能な途中表現」を挟む方が安全性も修正効率も高い。

The Register記事でもKoudas氏は、LLMが不確実なトークンを検知した際に「こちらの意味か、あちらの意味か」と利用者へ問い返す仕組みの必要性を語っていた。この発想はPRACTIQや対話的編集の流れと一致する。企業が本当に欲しいのは、100回に1回の派手なデモ成功ではなく、意味が曖昧なときに無理に答えず確認へ回る挙動だ。誤ったSQLが実行エラーで止まるならまだ救いがあるが、構文的には正しく意味的には誤ったSQLが通ると、現場は間違いに気づきにくい。

現場導入で先に変わるのは一般社員ではなく、分析者とDBAの働き方

The Register記事でKoudas氏は、返ってきたSQLの妥当性を判断し、必要なら直せる人にとっては生産性向上ツールになると述べた。AWSのガイドやSnowflakeのドキュメントも、実質的にはそうした使い方を前提にしている。スキーマ定義、セマンティックモデル整備、実行権限、監視を理解する人が周辺にいて初めて、自然言語DBは安全に回り始める。まず仕事の中身が変わるのは、SQLをまったく知らない一般社員ではなく、生成結果を監査できる分析担当者とDBAだ。

Snowflakeがsemantic modelとsemantic viewを前面に出し、AWSが運用込みのアーキテクチャを紹介している事実は、導入作業の中心がモデル選定ではないことを示している。社内用語の辞書を作り、曖昧な質問に確認を返し、結果を監査できる経路を残す。この3工程は地味だが、ここを飛ばすと76.31という公開精度で社内意思決定を回すことになる。社内データの意味をモデリングできる人材を抱えられるかどうかが、自然言語クエリが実用ツールになるかデモ止まりで終わるかの分水嶺になる。

Sources