Text-to-SQLは、自然言語の質問をSQLクエリへ変換する——「昨年の売上トップ10は？」→ SELECT … ORDER BY … LIMIT 10——NLPタスクです。RAGがPDFや社内文書を検索するのに対し、Text-to-SQLは表形式のデータベースに直接問い合わせる橋。本記事はSQL方言の細部より、「なぜ翻訳タスクとして整理されるか」に焦点を当てます。
試験で問われる見方
Text-to-SQL単独の定義問題はまだ少ないですが、自然言語→別形式への変換として押さえます。Seq2Seqは入力系列を出力系列へ変換する枠組み（G-255）——Text-to-SQLは文→SQL文という具体例です。
生成AIの文脈では、LLMがテキストを生成する能力（TF-0178）を、実行可能なクエリに向けるタスクとして理解します。誤答では、Text-to-SQL＝RAG、Text-to-SQL＝ベクトルDB——などのすり替えに注意します。
演習で確認する
G検定：G-255（Seq2Seq）、TF-126（NLP）、TF-174（RAGとの区別）、TF-172（ハルシネーション）
生成AIパスポート：TF-0178（テキスト生成）、TF-0108（Transformer）
入出力の形
Text-to-SQLはT5のText-to-Text思想に近い——入力も出力もテキスト——タスクです。ただし出力のSQLは、データベースエンジンが実行する命令でもあります。
| 側 | 例 | 特徴 |
|---|---|---|
| 入力 | 「東京都の顧客数を教えて」 | 話し言葉・ビジネス質問 |
| 出力 | SELECT COUNT(*) FROM customers WHERE prefecture = '東京都' | 構文規則のあるSQL |
| 結果 | 数値・表・グラフ用データ | DB実行後にユーザーへ返す |
機械翻訳（G-340）が言語A→言語Bなら、Text-to-SQLは自然言語→問い合わせ言語（SQL）——どちらも「別形式の系列へ変換」という整理が試験でも使えます。
スキーマを渡す理由
SQLを正しく書くには、どのテーブルにどの列があるか——スキーマ（schema）——の情報が不可欠です。「売上」が sales.amount なのか orders.total なのか、モデルは推測しかねません。
- テーブル名・列名 — モデルへの入力にスキーマ定義を含める
- 外部キー — JOIN先の関係を示す
- 値の例 — 「東京都」が
prefecture列かregion列かの手がかり
RAGがチャンク化した文書を検索するのに対し、Text-to-SQLはメタデータ（スキーマ）＋質問をモデルに渡す——データの渡し方が違います。
典型的な処理の流れ
- 質問受付 — ユーザーが自然言語で質問
- スキーマ付与 — 対象DBのテーブル・列情報をプロンプトに含める
- SQL生成 — LLMや専用モデルがSQL文字列を出力
- 検証 — 構文チェック、読み取り専用制限、権限確認
- 実行・整形 — DBでクエリを走らせ、結果を表や自然言語で返す
実務では「生成して即実行」ではなく、人間の確認やサンドボックスを挟むことが多い——生成AIの出力をそのまま信頼しない設計です（TF-172のハルシネーション文脈）。
RAG・ベクトルDBとの違い
| 観点 | Text-to-SQL | RAG |
|---|---|---|
| データ | リレーショナルDBの表 | 文書・PDF・Webページ |
| アクセス | SQLで集計・JOIN・フィルタ | 埋め込み検索で関連チャンク取得 |
| 出力の型 | 実行可能なクエリ | 参照付きの自然言語回答 |
| 得意 | 「売上合計」「件数ランキング」 | 「規程の第3条に何と書いてあるか」 |
| 試験 | 系列変換・NLPタスク | TF-174の検索拡張生成 |
両方とも生成AIのビジネス活用として語られますが、構造化データへの問い合わせか非構造化文書の検索補強か——目的が異なります。併用する製品もあります。
誤ったSQLのリスク
自然言語の翻訳ミスと違い、SQLの誤りはデータを壊す可能性があります。読み取り専用の SELECT 以外に、誤って DELETE や UPDATE を生成したら致命的です。
- 列名の取り違え 似た名前の列をJOINし、集計がずれる——結果はもっともらしいが誤り（ハルシネーションに近い）
-
条件の欠落
WHEREが抜け全件集計——数値は出るが質問意図と不一致 - 権限外の参照 個人情報テーブルへのアクセス——ガバナンス上の問題
試験では実装詳部より、「生成テキストをそのまま実行しない」という運用上の注意が、生成AIリテラシーとして押さえ目標です。
すり替えに注意
| 誤った説明 | 正しい理解 |
|---|---|
| Text-to-SQL＝RAG | SQL生成 vs 文書検索拡張（TF-174） |
| Text-to-SQL＝ベクトルDB | タスク vs 埋め込み保存の基盤 |
| Text-to-SQL＝CNN | NLPの系列変換 vs 画像の畳み込み |
| Text-to-SQL＝SQLエンジンそのもの | クエリを生成するタスク vs 実行するDB |
| 生成SQLは常に正確 | 検証・権限制御が必要（TF-172） |
| Text-to-SQL＝Text-to-Image | SQL文生成 vs 画像生成。Text-to-○は別タスク |
よくある質問
Text-to-SQLとは何ですか？
ユーザーが日本語や英語などの自然言語で書いた質問（例：「昨年の売上トップ10の商品は？」）を、データベースに投げるSQL文（SELECT文など）へ変換するタスクです。SQLを書けない人でも表形式データに問い合わせできるようにするのが目的です。
Text-to-SQLとRAGは同じですか？
同じではありません。RAGは文書を検索してLLMの回答に参照させる仕組みです。Text-to-SQLはリレーショナルデータベースなどの構造化データに対し、SQLクエリを生成して集計・抽出するタスクです。データの形（非構造化文書 vs 表）とアクセス手段（検索 vs SQL）が異なります。
Text-to-SQLは畳み込みニューラルネットワークですか？
いいえ。Text-to-SQLは自然言語をSQL文へ変換するNLPタスクです。実装にはTransformerベースのLLMやSeq2Seqモデルが使われることがありますが、タスクそのものは画像の畳み込みとは無関係です。