はじめに
ChatGPTやGitHub Copilotなどの生成AIを活用してSQL文を自動生成する機会が増えています。AIは複雑なクエリを数秒で記述できるため開発効率が向上しますが、出力されたSQLをそのまま本番環境で実行すると、パフォーマンス低下やセキュリティ上の深刻な脆さが生じるリスクがあります。
この記事では、AIが生成したSQLに潜む代表的な「性能・セキュリティ上の落とし穴」を具体例とともに解説し、実務で安全に運用するための確認チェックリストとプロンプトテンプレートを提供します。
対象読者・前提条件
- AIツールを利用してSQLを作成・レビューしているエンジニア
- リレーショナルデータベース（RDBMS）の実務経験がある方
- 特定のRDBMS（PostgreSQL, MySQL等）に依存しない一般原則を中心に解説します（実行時には利用するRDBMSの最新仕様を確認してください）。
AI生成SQLに潜む代表的なアンチパターン
1. セキュリティの落とし穴：文字列結合によるSQLインジェクション
AIにプログラムコード内でのSQL作成を指示すると、プレースホルダー（バインド変数）を使わずに文字列結合（f-stringや動的生成）を行ったコードを出力することがあります。
悪い例（文字列結合）
# 独自実装例：ユーザー入力を直接組み込んでいる（SQLインジェクションのリスクあり）
user_input = get_user_input()
query = f"SELECT id, username, email FROM users WHERE status = 'active' AND username = '{user_input}'"
cursor.execute(query)
良い例（プレースホルダーの利用）
# プレースホルダーを利用してパラメタライズドクエリを実行する
user_input = get_user_input()
query = "SELECT id, username, email FROM users WHERE status = %s AND username = %s"
cursor.execute(query, ('active', user_input))
対策: AIにコード文脈でのSQLを生成させる場合は、必ず「バインド変数（プレースホルダー）形式で出力すること」をプロンプトで明確に指定します。
2. 性能上の落とし穴：インデックスが無効化される関数や演算
AIはデータモデルや既存インデックスの情報を知らないため、検索条件の列に対して関数を適用したり、暗黙の型変換を引き起こすSQLを生成しがちです。
悪い例（列に対する関数適用）
-- createdAt列にインデックスがあってもフルテーブルスキャンが発生する可能性がある
SELECT order_id, total_amount
FROM orders
WHERE DATE(created_at) = '2023-10-01';
良い例（範囲検索への書き換え）
-- 列に対して関数を適用せず、SARGable（Search Argument Able）なクエリにする
SELECT order_id, total_amount
FROM orders
WHERE created_at >= '2023-10-01 00:00:00'
AND created_at < '2023-10-02 00:00:00';
3. リソース枯渇の落とし穴：不要な全件取得とサブクエリの多用
AIは要求を満たす最小限のロジックを作成するため、大規模データでのスケーラビリティを考慮しないクエリ（SELECT * の使用や、巨大なテーブルに対する非効率な IN (SELECT ...) など）を出力することがあります。
比較表：AI生成クエリの傾向と改善方針
| 項目 | AIが出力しがちなパターン | 実務でのリスク | 推奨される対策 |
|---|---|---|---|
| 取得カラム | SELECT * |
不要なI/O・メモリ圧迫 | 必要なカラムのみ明示的に指定 |
| 結合・絞り込み | 大規模テーブルに対する IN (SELECT ...)
|
実行計画によって処理が低速化 |
EXISTS や JOIN 構造への書き換え |
| ページネーション |
OFFSET 100000 のような深限界指定 |
ディスク読み込み量の増大 | 尋常でない大量データ時はカーソル（Keyset）型検討 |
レビュー用チェックリスト
AIが作成したSQL文をPR（プルリクエスト）や実務コードに組み込む前に、以下の項目を確認してください。
- セキュリティ: 動的な文字列結合を行わず、プレースホルダー形式になっているか
-
取得範囲: 不要な
SELECT *がなく、必要なカラムのみ指定されているか -
インデックス利用:
WHEREやJOIN条件の列に対して不要な関数（DATE(),UPPER()など）がかかっていないか - データ型: 比較対象の値のデータ型が列の定義と一致しているか（暗黙の型変換防止）
- ** N+1問題・サブクエリ**: ループ内でのクエリ実行や、不必要な相関サブクエリが含まれていないか
-
実行計画の確認: 大小さまざまなデータが入った検証環境で
EXPLAIN（実行計画）を取得し、フルスキャン（Seq Scan / ALL）の有無を確認したか
実務用プロンプトテンプレート
AIに安全かつ効率的なSQLを出力させるための指示テンプレートです。
【依頼内容】
以下の要件を満たすSQLクエリを作成してください。
【前提条件・環境】
・RDBMS: [例: PostgreSQL 15 / MySQL 8.0]
・テーブル定義:
- users (id INT, status VARCHAR(20), created_at TIMESTAMP)
- orders (id INT, user_id INT, amount DECIMAL, created_at TIMESTAMP)
・インデックス定義:
- users(status), orders(user_id, created_at)
【要件】
・[具体的な取得条件や集計ロジックを記載]
【制約事項（厳守）】
1. セキュリティ対策のため、変数埋め込み時は必ずプレースホルダー形式（バインド変数）を使用してください。
2. インデックスを有効活用するため、WHERE句の列側に対する関数適用（DATE()など）は避けてください。
3. SELECT * は使用せず、必要なカラムのみを明示的に指定してください。
4. 実行計画の観点からパフォーマンス上懸念がある場合は、注意書きを添えてください。
まとめ
AIはSQL文の構文を作成する強力なアシスタントですが、データベースの規模、インデックス設計、セキュリティ原則に対する判断は人間側で行う必要があります。
- セキュリティ: プレースホルダーの徹底
-
パフォーマンス: 実行計画（
EXPLAIN）の確認とSARGableな条件の維持 - 運用: 事前チェックリストを通じた検証
これらをルール化し、AIの利便性を活かしながら安全なシステム運用を目指しましょう。実行前には必ず開発環境で挙動と実行計画を確認することをお勧めします。