LLM SQL生成、AWS実装の注意点

大規模言語モデル（LLM）にSQLを生成させ、データベースのクエリを自動化する「Text-to-SQL」の実装が企業システムで広がりつつある。しかし、本番環境で安定稼働させるには、データベースの選定から権限設定、スキーマ情報の管理に至るまで、考慮すべき技術的課題が少なくない。

2026年7月5日、Qiitaに公開された記事「LLMにSQLを生成・実行させる際に注意したこと※AWS編」では、AWS環境でLLMとデータベースを連携させる際の具体的な注意点がまとめられている。著者はJAWSミートでの登壇内容を基に、検証と構築を通じて得た実践的な知見を公開した。本稿では、同記事の内容を基に、Text-to-SQL導入時にエンジニアが押さえるべきポイントを整理する。

DB選定の二択

Text-to-SQLのバックエンドに使用するデータベースの選択は、システム全体の成否を左右する。AWS環境では、Amazon Aurora（RDS）とAmazon Redshiftの二択が主流となる。選定の指針は、生成されるSQLの性質とワークロードの種類に依存する。

Redshiftが適しているのは、GROUP BYやJOINを多用する分析クエリが中心となるケースだ。列指向ストレージによる集計パフォーマンスが求められる場面で真価を発揮する。また、Redshift Serverlessはアイドル時に完全停止が可能であり、利用していない時間帯のコストを限りなくゼロに近づけられる点も、検討材料となる。

一方、Auroraが適するのは、ユーザーが「このレコードを更新して」のような更新系の操作をLLMに実行させたい場合や、テーブル数が非常に多く、リレーションが複雑な正規化されたOLTPスキーマが存在する場合だ。PostgreSQLやMySQLの標準構文に厳密に準拠したい場合もAuroraが選択肢となる。

Redshiftの方言

RedshiftはPostgreSQLをベースとしているが、サポートされていないPostgreSQL機能が複数存在する。LLMが一般的なPostgreSQLの知識でSQLを生成すると、LATERAL JOINやRECURSIVE CTEといった構文でエラーが発生するリスクがある。

Qiitaの記事では、LLMへのシステムプロンプトに「Redshiftを使用している。LATERAL JOINやRECURSIVE CTEは使えない」と明示することで、こうしたエラーを低減できると指摘している。データベースの方言の違いを事前にLLMに認識させることは、Text-to-SQLの精度向上において重要な要素だ。

権限設定の鉄則

LLMにデータベースアクセス権限を付与する際、必ず読み取り専用（READ ONLY）に設定すべきである。この点は、記事でも「鉄則」として強調されている。

LLMは指示に従ってSQLを生成するが、ハルシネーション（幻覚）によりDROP TABLEを実行したり、プロンプトインジェクションにより意図しないDELETEが発行されるリスクはゼロではない。実際、AIエージェントが自律的にランサムウェア攻撃を実行した事例もSysdigによって確認されており、データベースへの書き込み権限をAIに与えることの危険性は現実のものとなっている。

Redshiftの場合は、管理者ユーザーとは別に読み取り専用ユーザーを作成し、全テーブルへのSELECT権限のみを付与する。Data APIを使用する場合、execute_statementでDbUserパラメータを指定することで、この読み取り専用ユーザーとしてSQLを実行できる。DbUserを省略すると、IAMロールに紐づいた管理者権限で実行されるため、LLMが生成したDELETEやDROPがそのまま通ってしまう危険性がある。

Aurora（PostgreSQL）の場合も同様に、読み取り専用ロールとユーザーを作成し、Secrets Managerに格納した認証情報をsecretArnで指定する運用となる。Aurora（MySQL）の場合も考え方は同じで、SELECT権限のみを付与したユーザーを作成する。

スキーマの渡し方

LLMが正確なSQLを生成するには、テーブルやカラムの情報（スキーマ）が必要となる。「どのテーブル定義をどう渡すか」は、Text-to-SQLの精度を大きく左右する要素だ。

方式としては、全スキーマ投入とスキーマ検索（Schema Linking）の二つがある。全スキーマ投入は実装がシンプルでテーブル選択ミスが発生しない反面、テーブル数が多いとトークン消費が大きくなる。スキーマ検索はトークンを節約できるが、検索ミスが生じると誤ったテーブルでSQLを生成してしまうリスクがある。

テーブル数が20程度と少ない場合、全スキーマをプロンプトに含める方が精度が高いことが多い。この判断は、Text-to-SQLの標準的なベンチマークであるBIRDベンチマークの知見とも一致する。テーブル数が多く複雑なスキーマを持つシステムでは、スキーマ検索の実装が不可欠となる。

プロンプトインジェクション対策

LLMにSQLを生成させるシステムでは、プロンプトインジェクションへの対策がセキュリティ上の重要課題となる。悪意のあるユーザーが自然言語のクエリにSQLインジェクション文を埋め込むことで、LLMが危険なSQLを生成する可能性がある。

読み取り専用ユーザーの設定は、このリスクに対する最後の防御線となる。仮にLLMが危険なSQLを生成したとしても、データベース側で書き込み権限がなければ、被害は情報漏洩のリスクに限定される。データの破壊や改ざんを防ぐことができる。

また、LLMが生成したSQLをそのまま実行するのではなく、事前に構文チェックや許可リストとの照合を行うバリデーション層を設けることも、追加の防御策として有効だ。

コスト管理の視点

Text-to-SQLシステムでは、プロンプトに含めるスキーマ情報のサイズが直接コストに影響する。テーブル数が数十から数百に及ぶ大規模なデータベースでは、全スキーマを毎回プロンプトに含めるとトークン消費が膨大になる。

スキーマ検索の実装は、トークン消費の最適化とクエリ精度のトレードオフを伴う。検索の精度を高めるには、テーブルやカラムの説明文をメタデータとして充実させ、ベクトル類似検索などを用いた効率的な検索基盤が必要となる。この点は、AIエージェントのトークンコスト問題が顕在化する中で、実運用上の重要な設計判断となる。

編集部の見解

Text-to-SQLの実装は、AIと既存のデータベース資産を結びつける有力な手法として注目されている。しかし、本記事が示すように、データベースの選定から権限設定、スキーマ管理に至るまで、考慮すべき要素は多岐にわたる。特に、読み取り専用ユーザーの徹底は、AIエージェントにデータベース操作を委ねる上での最小限の安全策であり、これを怠った場合のリスクは計り知れない。今後3〜6カ月で、AWS環境におけるText-to-SQL導入事例が増加すると予想されるが、同時に権限設定の不備によるトラブルも発生する可能性が高い。セキュリティベストプラクティスの浸透が急務となる。 長期的には、LLMがデータベースのスキーマ情報を自律的に理解し、最適なクエリを生成する技術が進化することで、データ分析の民主化が加速すると見られる。ただし、そのためにはLLMのハルシネーション対策やプロンプトインジェクションへの耐性向上が不可欠だ。1〜3年のスパンでは、スキーマ検索の精度向上やコスト最適化の技術が競争領域となると言えそうだ。

参考

• LLMにSQLを生成・実行させる際に注意したこと※AWS編 - Qiita — 2026-07-05公開
• BIRD-Bench (Text-to-SQLベンチマーク) — 公式サイト