社内DBに「先月の売上トップ10は？」と日本語で聞くと、SQLに変換して答えてくれる。そんなText-to-SQL（自然言語をSQLクエリに変換する仕組み）を自社システムに組み込もうとしている開発者・PMに向けた内容です。
導入検討時に「要は翻訳機能でしょう」という理解で進めると、思わぬデータ事故につながる可能性があります。なぜ単純な翻訳では済まないのか、内部で何が起きているのかを整理しました。
Text-to-SQLは「翻訳」ではなく6段階のパイプライン
Text-to-SQLは、英語や日本語の自然言語をGoogle翻訳のようにSQLへ1対1変換する仕組みだと誤解されがちです。
実際には内部で6つの工程が順番に実行され、どの工程も単独で失敗しうる構造になっています。「Nolanが2010年以降に監督した映画は？」という問いを例に見ていきます。
- 意図分類（Intent Classification）: ユーザーが求める回答の型を判定します。「どの映画」なら文字列のリストであり、件数や真偽値ではありません
- エンティティ認識（Entity Recognition）: 「Nolan」「2010」のような固有名詞・数値を抽出します
- 関係抽出（Relation Extraction）: 「監督した」が Nolan と映画を DIRECTED という関係で結びつけることを特定します
- 条件変換（Functional Filtering）: 「以降」という前置詞を
year > 2010のような演算子に変換します - スキーマリンキング（Schema Linking）: 抽象的な概念を実際のテーブル・カラムに対応付けます
- SQL生成: ここまでの意図・エンティティ・関係・条件・スキーマパスを組み立てて実行可能なSQL文にします
この整理を支えるのが、自然言語処理の分野でよく使われる3つの用語の切り分けです。
NLP（Natural Language Processing、自然言語処理）は要約や感情分析まで含む広い道具箱全体を指します。
NLU（Natural Language Understanding、自然言語理解）は「この文は何を意味するか」を解く中間層です。
NLQ（Natural Language Query、自然言語クエリ）はその応用の一つで、質問文をデータベースへの実行可能なクエリに変換する機能に限定されます。
Text-to-SQLはNLQの具体的な実装の一つ、と捉えると立ち位置が整理しやすくなります。
最難関はスキーマリンキング、グラフの最短経路問題として解く
この6工程の中で最もつまずきやすいのがスキーマリンキングです。「Nolan」という単語を directors.name に結びつけるべきで、actors.name や movies.title ではない、とどう判断するのでしょうか。
仕組みとしては、自然言語の各単語とDBスキーマの各テーブル・カラムをすべてノード（グラフ上の点）として扱います。そのうえで、単語とスキーマ要素の間に辺（エッジ）を張り、意味的なもっともらしさに応じてコスト（重み）を設定します。
たとえば「Nolan」というノードから見ると、directors.name へのエッジは文脈上「監督した」という動詞があるため低コストです。actors.name へのエッジは、この文脈で演技をしている記述がないため高コストになります。movies.title へのエッジは、人名を映画タイトル欄に当てはめることになるため、事実上採用されないほど高コストに設定されます。
このグラフ全体に対して、ダイクストラ法のような最短経路アルゴリズムを実行し、累積コストが最も低い経路を採用します。これはカーナビが最短ルートを探すのと同じ発想の応用です。
ここでのポイントは、「確信度」が曖昧な感覚値ではなく数値として計算される点です。
既存の業務DBに組み込む前の比較観点
エンタープライズの業務システムでは、すでにBIツールのダッシュボードやレポートクエリが整備されている場合が多くあります。Text-to-SQLはその代替ではなく、アドホックな問い合わせの窓口として位置づけるのが現実的です。
比較の軸を整理すると、既存の固定レポートとText-to-SQLには明確な役割分担があります。
| 観点 | 固定レポート/BI | Text-to-SQL |
|---|---|---|
| クエリの正確性 | 開発者がレビュー済みで安定 | スキーマリンキングの精度に依存 |
| 対応できる質問の幅 | 事前定義された範囲のみ | 未定義の自由な質問に対応可能 |
| 曖昧さへの対処 | 発生しない(固定クエリのため) | 確認プロンプトの設計が必須 |
| 導入負荷 | 要件定義とクエリ実装が中心 | スキーマ情報の整備・メタデータ管理が中心 |
この表からわかる通り、Text-to-SQLの導入負荷は「クエリをどう作るか」ではなく「スキーマ情報をどう整備するか」に重心が移ります。テーブル名・カラム名が業務用語と乖離している既存システムほど、スキーマリンキングの難易度が上がる点に注意が必要です。
既存システムで確認すべきポイント
Text-to-SQLの導入を検討する際、技術選定の前に確認しておきたい項目を整理します。
- カラム名の可読性:
col_42のような無意味な命名が残っていないか、既存テーブル定義を棚卸しします - 同義語・類似エンティティの衝突:
directorとproducerのように意味が近いカラムが複数テーブルに存在しないか確認します - 曖昧時のフォールバック設計: 確信度が低い場合に即実行せず、確認を返す設計になっているかベンダーやOSSのドキュメントで確認します
- テストデータでの検証: 本番相当のスキーマ複雑度を持つステージング環境で、意図的に曖昧な質問文を投げて挙動を確認します
- 監査ログの有無: 生成されたSQLとその確信度スコアを記録し、後から誤判定を追跡できるかを確認します
特に既存の基幹システムやレガシーDBにText-to-SQLを後付けする場合、テーブル設計そのものがスキーマリンキングの精度を左右します。導入前にメタデータ（カラムの意味・単位・関連キー）を整備するドキュメント作業が、実装作業そのものより重要になる場面も出てきます。
まとめ
Text-to-SQLは単純な言語変換ではなく、意図分類からSQL生成まで6段階を経る多段パイプラインです。
中でもスキーマリンキングは、単語とDB要素の対応関係をグラフの最短経路問題として解く、計算コストを伴う工程です。
導入を検討するなら、まずは自社DBのカラム命名の可読性と、曖昧な質問に対する確認プロンプトの有無をチェックしてみてください。
既存の固定レポートとの役割分担を明確にしたうえで、ステージング環境で曖昧な質問文を実際に投げてみる、という小さな検証から始めるのが現実的な一歩になります。