NL2SQL とは何ですか?また、どのように機能しますか?

NL2SQL は、自然言語での質問を、リレーショナル ベースで実行できる SQL クエリに自動変換することを指します。フリー テキストで応答する一般的なチャットボットとは異なり、NL2SQL システムは、実際のデータに対して実行され、検証可能な結果を​​ 1 行ずつ返す構造化アーティファクト SQL を生成します。

「text-to-SQL」という用語は、自然言語処理の学術研究に由来しています。 「NL2SQL」は、製品および技術文書の面で最もよく使用される略語です。どちらも同じ問題、つまり日常言語で尋ねられる質問と SQL エンジンが期待する正確な構文の間のギャップを埋めることを指します。

NL2SQL は、広義のデータベースに接続された会話型エージェントとは区別されます。 1 つ目は、読み取り可能で監査可能なクエリを生成します。 2 つ目は、必ずしも一意で検査可能な SQL を生成せずに、複数のツール呼び出し (検索、計算、書き込み) を連鎖させることができます。適切に設計された NL2SQL システムは、この意図的に制限されたスコープ (変換、検証、実行、結果の返し) 内に留まります。

信頼性の高い NL2SQL パイプラインは、プロバイダーに関係なく、常に同じシーケンスに従います。質問は言語モデルを通過し、生成された SQL は実行前ではなく実行後に検証されます。 aura-aiサービスコードで検証された Aurabase 実装では、抽象的な説明ではなく、具体的なルールを使用してこれらの各ステップを示しています。

1.実際のベースの回路図とともにご質問を承ります

システムは、自然言語での質問を、クエリされたデータベースのスキーマ (テーブル名、列、タイプ) に関連付けます。このパターンは、呼び出し元が提供する説明からではなく、実際の根拠の内省から得られるものでなければなりません。顧客が宣言したスキーマを受け入れる実装では、存在しないテーブルに関する質問や、プロジェクト間の分離の回避への扉が開かれます。 Aurabase エンジンは、リクエストで送信された schema フィールドを暗黙的に無視するのではなく、明示的に拒否 (400 エラー) します。

2.LLM が候補 SQL を生成します

言語モデルはプロンプトで質問とスキーマを受け取り、短い説明とともに候補 SQL クエリを生成します。 Aurabase は、OpenAI、Anthropic (Claude)、Gemini の 3 つのプロバイダーを専用のネイティブ クライアントと同等に扱います。この SQL 候補は、現段階では単なる提案であり、直接実行されることはありません。

3.候補 SQL は実行後ではなく実行前に検証されます。

これは、本格的な NL2SQL システムと、単純な LLM 呼び出しとその後の単純な実行を区別するステップです。生成された SQL は、キーワード検索によって検査されるのではなく、構文ツリー (AST) に解析されますが、これは簡単にバイパスされます。 sqlparserライブラリを使用した Aurabase 実装では、単純な SELECT クエリのみが許可されます。CTE/WITH、サブクエリ、UNION、ウィンドウ関数およびロック句 (FOR UPDATE) は明示的に拒否され、10 個の関数のホワイトリスト外の SQL 関数 (count、 sum、 avg、 min、 max、 lower、 upper、 coalesce、 date_trunc、 now)。

4.コミットされたクエリは行キャップを使用して実行されます

Validated SQL receives an LIMIT if it does not already have one: 100 lines by default with Aurabase, 1000 maximum, both values configurable on the server side. A request beyond the cap is explicitly denied rather than silently reduced. The response indicates whether this LIMIT was added by the server, so the caller knows if the SQL executed differs from that produced by the model.

-- 質問: 「プレミアム顧客の今月の注文は何件ありますか?」
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- サーバーによって追加されましたが、生成された SQL にはありません

The full detail of this pipeline, with each HTTP call and each JSON response, is covered in our step-by-step tutorial for building an NL2SQL endpoint on Postgres.

NL2SQL は、あらゆる場所で手書きの SQL を置き換えることを目的としたものではありません。 SQL を知らない人、または単純なクエリの時間を節約したい人からの、その場限りの 1 回限りの質問など、特定の範囲をカバーしています。

• 非技術者によるダッシュボードのアドホックな探索 (サポート、製品、管理)。
• 考えられるすべての質問に対して専用の API ルートを作成することなく、データベースにクエリを実行する機能のラピッド プロトタイピング。
• 限定的な分析セルフサービス: エンド ユーザーにデータベースへの直接アクセスを許可せずに、カウント、フィルター、単純な集計を行います。

質問がこの範囲を超える場合は、手書きの SQL が望ましいままです。上記のような AST 検証済みの実装では、セキュリティ上の理由から、CTE、サブクエリ、およびウィンドウ関数が構造上除外されています。これらの構造、コホート、高度な時間ウィンドウ処理を構造的に必要とする分析は、NL2SQL を経由せず、直接コーディングされます。これは受け入れられた妥協であり、生成される SQL の完全性よりもシステムのセキュリティが優先されます。

NL2SQL 実装では 3 つのリスクが系統的に再発し、システムの成熟度に応じて対応が異なります。

プロンプトまたは質問による SQL インジェクション

質問自体に「前のステートメントを無視して...」というインジェクション試行が含まれている場合、LLM を操作して悪意のある SQL を生成する可能性があります。防御策は、プロンプトを信頼することではなく、要求された内容とは関係なく生成された SQL を検証することです (まさに上記のパイプラインのステップ 3)。このトピックは専用の扱いに値します。正確な攻撃ベクトルと対策については、SQL インジェクションに対する NL2SQL の保護 を参照してください。

存在しないテーブルまたは列の幻覚

モデルは、特に大規模なスキーマや文書化が不十分なスキーマでは、実際のスキーマには存在しない、もっともらしいテーブル名または列名を作成する可能性があります。生成された SQL を実際のデータベース スキーマに照らして検証する実装では、生の SQL エラーをユーザーに返すのではなく、明示的なメッセージでクエリを拒否し、実際に使用可能なテーブルをリストします。

モデル呼び出しのコストとレイテンシ

NL2SQL の各質問は、SQL の実行時間に加えて、独自のコストと待ち時間を伴う言語モデルの呼び出しをトリガーします。 NL2SQL が反復的な質問のデフォルト層として機能する場合、このコストは急速に増加します。毎回再変換するのではなく、標準レポートとしてキャッシュまたは公開する方が有益です。

2 つのアーキテクチャは同様の目に見える結果を生成しますが、保証は大きく異なります。ネイティブ NL2SQL は、生成、検証、実行を、プロジェクトのスキーマとアクセス権をすでに知っているバックエンド層に直接統合します。これは、Aurabase について上で説明したロジックであり、aura-ai サービスはインフラストラクチャとスキーマ分離を残りのバックエンドと共有します。

アセンブルされた NL2SQL は、汎用 LLM サービス、データベースへのコネクタ、および独自の検証層を組み合わせたものです。このアプローチの安全性を妨げるものは何もありませんが、すべての保証、サーバー側でのイントロスペクトされたスキーマ、AST 検証、行キャップ、分離テナントは、プラットフォームによって提供されるのではなく、これらのブリックをまとめるチームによって実装および維持される必要があります。

NL2SQL ツールの状況 (ネイティブとアセンブル、オープン ソースと商用) は、 NL2SQL 2026 ツールの比較で詳細に比較されています。

NL2SQL と RAG (検索拡張生成) は、データベースに接続された LLM に依存しているため、混同されることが多い 2 つの異なる質問に答えます。

NL2SQL は、構造化データとリレーショナル データを対象とします。つまり、自然に SELECT、 GROUP BY、集計に変換される、いつ、いくつ、どのような割合の質問を対象とします。 RAG は、ドキュメント、メモ、サポート チケットなどの非構造化コンテンツを対象としています。回答はテーブルの行に収まりませんが、モデルにコンテキストで与える前に、意味的類似性、pgvector でのベクトル検索、HNSW インデックスによって関連する文章を見つける必要があります。

The two capabilities can coexist in the same project and combine in an agent who chooses one or the other depending on the question asked. The Aurabase native AI pillar details how the two mechanisms work together, and our RAG pipeline guide on pgvector covers the implementation of the second.