【ITニュース解説】Is Your Text-to-SQL Agent Just a Fancy Way to Drop Your Production Tables?

Text-to-SQLエージェントは、私たちが普段使う言葉で質問するだけで、自動的にデータベースから情報を引き出すためのSQLクエリを生成してくれる便利なツールである。これにより、SQLの専門知識がなくても誰でも簡単にデータにアクセスできるため、多くの企業で注目を集めている。しかし、この技術には大きな落とし穴があり、安易に導入すると、企業にとって計り知れないリスクをもたらす可能性がある。

最も危険なのは、「LLM（大規模言語モデル）ベースのText-to-SQLエージェントは賢いから、機密情報とそうでない情報の区別を理解しているだろう」という誤解である。実際には、LLMはその区別を理解しておらず、そもそも関心も持たない。LLMは与えられた情報と指示に基づいてSQLを生成するだけで、そのSQLがどのような影響をもたらすかまでは判断できないのだ。たとえば、顧客の個人情報が含まれるテーブルにLLMがアクセスできる設定になっていると、ユーザーが単純な質問をしただけでも、意図せず機密情報が漏洩するようなSQLが生成されかねない。実際に、LLMが機密データが含まれるテーブルを結合しようとする例が報告されており、厳重なデータベース権限がなければ情報が漏洩していたとされている。

多くの導入事例やチュートリアルでは、いかに正しいSQLを生成させるかに焦点を当てがちである。プロンプトエンジニアリングと呼ばれる、LLMへの指示の出し方を工夫する手法や、スキーマ定義をLLMに学習させる方法などが議論される。しかし、これは根本的な解決策ではない。LLMをデータベースに対する「権限のあるユーザー」として扱うと、まるで高速なSQLインジェクション攻撃のように、意図しない破壊的な操作が行われる危険性が高まる。例えば、データベース全体のスキーマ情報をLLMに丸ごと渡すと、ユーザーが「ユーザー数を教えて」と尋ねただけで、LLMがデータベース全体の情報を取得しようとし、システムをダウン寸前に追い込むようなクエリを生成することもある。これは、LLMに家全体の地図を渡しておきながら、機密データのある部屋の鍵をかけていない状態と同じである。ユーザーが「顧客Xに関する全情報を探して」と言えば、LLMは鍵のかかっていない部屋に迷わず入ってしまうだろう。

このようなリスクを防ぐためには、LLMを信頼せず、「信用できないユーザー」として扱い、データベース側で厳重なセキュリティ対策を講じることが不可欠である。

最初の重要な対策は、「ビューベースのゲートキーパーパターン」を導入することである。LLMエージェントがデータベースの基盤となるテーブル（生のデータが保存されている場所）に直接アクセスするのを絶対に禁止する。代わりに、エージェント専用の「AI-Consumption」というスキーマ（データベース内の領域）を作成し、そこに「ビュー」と呼ばれる仮想的なテーブルを定義する。このビューには、LLMエージェントが必要とする最低限のデータとカラムのみを含め、機密情報や不必要なカラムは一切含めないようにする。さらに、データへのアクセス期間を制限するフィルターをかけることも有効である。例えば、過去1ヶ月間の取引データだけをビューに含めることで、LLMがそれ以前のデータにアクセスするのを防ぐ。これにより、LLMが顧客の社会保障番号などの機密情報を参照しようとしても、その情報自体がビューには存在しないため、物理的にアクセスできない状態になる。LLMに機密情報を「無視させる」ことを期待するのではなく、データベース側が「提供しない」ようにすることが重要なのだ。

次に、「ミドルウェア層でのサーキットブレーカー」を導入する。LLMは、データベースのパフォーマンスを考慮せずに、膨大なデータを取得しようとする「暴走クエリ」を生成することがある。例えば、「平均取引額を教えて」という質問に対して、5千万行ものデータをすべてメモリに読み込もうとするクエリを生成する可能性がある。これを防ぐため、LLMエージェントが生成したSQLクエリが実際にデータベースで実行される直前で、そのクエリをチェックする中間層（ミドルウェア）を設ける。この中間層で、データベースを破壊する可能性のある「DROP」「TRUNCATE」「ALTER」「DELETE」といった危険なキーワードが含まれていないかを検査し、もし見つかればクエリの実行を阻止する。また、データ取得件数を制限する「LIMIT」句が欠けているクエリには、自動的に「LIMIT 100」のような制限を追加し、過剰なデータ取得を防ぐ。これは一見すると地味な対策に見えるかもしれないが、運用環境でデータベースの破壊やパフォーマンス低下を防ぐための非常に重要な防衛策である。さらに、実行されたクエリにはエージェントを特定できる「QUERY_TAG」を付与しておくことで、万が一問題が発生した場合に、どのエージェントが原因で発生したかをすぐに特定できるようになる。

3つ目の対策として、「セマンティックプロキシ層」の構築がある。LLMにデータベースの全てのスキーマ定義（テーブル名、カラム名、データ型など）を直接渡すと、情報量が多すぎてLLMが混乱し、「幻覚」（ハルシネーション）と呼ばれる誤ったSQLを生成する原因となる。また、LLMが処理できる情報量（コンテキストウィンドウ）にも限りがある。これを避けるため、LLMとデータベースの間に「セマンティックプロキシ」と呼ばれる翻訳層を設ける。このプロキシは、データベースのスキーマを人間が理解しやすい言葉で記述した「マニフェストファイル」（YAMLやJSON形式など）を持っている。例えば、データベース内の「amount_usd」というカラムを、LLMには「total_revenue（総収益）」というエイリアスで提示する。LLMは「total_revenue」という言葉を使ってクエリを生成し、プロキシがそれを実際のカラム名「amount_usd」に変換してからデータベースに渡す。この仕組みにより、データベースのカラム名が変更されても、マニフェストファイルを更新するだけで済み、LLMエージェント側の設定を変更する必要がなくなる。データベースの内部構造とエージェントの処理が分離されることで、柔軟性と保守性が向上する。

これらの対策を導入することには、いくつかの懸念が考えられる。 「LLMの能力を制限することになるのではないか？」という意見に対しては、それは「機能」であって「欠陥」ではないと筆者は反論している。特に金融サービスなど機密性の高い業界では、異なる種類の機密データを安易に結合することは、規制違反につながる可能性がある。もしエージェントがアクセスできる範囲外の複雑な質問に答える必要があるなら、それはLLMに任せるのではなく、人間が慎重に定義・管理されたデータプロダクトとして提供されるべきである。エージェントは、アクセス権がない情報については「情報にアクセスできません」と正直に答えるべきである。

「これらのビューやマニフェストファイルの維持コストが高いのではないか？」という意見もある。dbtやCubeといったセマンティックレイヤーを既に活用している企業であれば、その恩恵を最大限に活かすべきであるが、これらのツールは主に人間のアナリストのために設計されている。LLMはテーブルが作成された背景やビジネス上の意味合いを理解できないため、既存のセマンティックレイヤーをそのままLLMに投入するだけでは不十分である。LLM向けに最適化された、より厳選されたデータモデルのサブセットを別途構築する必要がある。

「LLMが構文的には正しいが、論理的に間違ったSQLを生成したらどうするのか？」という最も難しい問題もある。例えば、合計すべきでないカラムを合計してしまうようなケースである。これに対する解決策は、「ヒューマン・イン・ザ・ループ」（人間の介入）検証である。データを参照するだけのシンプルなクエリであればそのまま実行してもよいが、機密性の高いメトリクスに対する複雑な集計クエリなど、ビジネスに大きな影響を与える可能性のあるクエリが生成された場合は、LLMに直接実行させず、人間が生成されたSQLを確認し、「承認」ボタンをクリックして初めて実行されるような仕組みを導入する。これは、企業の重要な指標（KPI）に誤りが生じるリスクを避けるための重要なセーフティネットである。

結論として、Text-to-SQLエージェントを安全に利用するためには、LLMを「信用できないユーザー」として扱うことが大前提である。LLMを「賢く」しようとすることに注力するのではなく、データベース側を「愚かにする」、つまりシンプルに、厳密な制約を設け、定義された安全な範囲外の操作を一切実行できないようにすることが重要である。ミドルウェア、プロキシ、そしてビュー層といった厳重な「フェンス」を構築する準備ができていないのであれば、LLMエージェントを実運用環境に展開すべきではない。それまでは、安全な「遊び場」の中でテストを続けるべきだということを忘れてはならない。