AI活用SQLライティング

🔄 前回のおさらい: レッスン1では、AIがデータベース業務をどう変えるか、そして検証マインドセットの重要性を学びました。今回は実践です——AIに正確なSQLを書かせるプロンプト技術をマスターします。

スキーマファースト・プロンプトパターン

AI活用SQL作成で最も重要なテクニック：常にスキーマを提供する。

悪いプロンプト： 「非アクティブな顧客を見つけるクエリを書いて」

良いプロンプト：

データベース: PostgreSQL
テーブル:
- customers (id SERIAL, name TEXT, email TEXT, created_at TIMESTAMP)
- orders (id SERIAL, customer_id INT REFERENCES customers(id), total DECIMAL, order_date DATE, status TEXT)

過去90日間に注文がないが、それ以前に少なくとも1回注文した顧客を見つけるクエリ。名前、メール、最終注文日、生涯購入合計を含む。

スキーマコンテキストが推測を排除します。AIが正確なカラム名、データ型、リレーションシップを知ることで、最初の実行で動くクエリが生成されます。

✅ 確認クイズ: プロンプトでtotalカラムのDECIMALやorder_dateのDATEを明示することが重要な理由は？（データ型が使える関数を決める。AIが日付カラムをTEXTと思えば、適切な日付演算ではなく文字列比較を試みるかもしれない。totalがDECIMALとわからなければ丸め処理が不正確に。明示的な型がより正確なクエリを生む——特に日付計算と数値集計で。）

JOINs：ミスが起きる場所

JOINはAI生成SQLが最も間違いやすい箇所です。よくあるエラー：

重複行： AIがGROUP BYやDISTINCTが必要なのに通常のJOINを使用。

データの欠落： AIがLEFT JOINが必要なのにINNER JOINを使用（注文のない顧客が消える）。

リレーションの誤り： テーブル名が曖昧な場合、AIが間違ったカラムでJOIN。

検証のコツ： JOINクエリ実行後、行数を確認。顧客が1,000人なのにクエリが5,000行返したら、JOINによる意図しない直積が発生している可能性大。

集計とGROUP BY

集計クエリ（SUM、COUNT、AVG）とGROUP BY、HAVINGはAIの得意分野——手動では面倒だがAIはうまく処理します。

✅ 確認クイズ: 前年同期比成長率のクエリが月次売上のクエリより難しい理由は？（成長率は2つの異なる期間——今年と昨年——を同じカテゴリーで比較する必要がある。これには通常ウィンドウ関数やセルフJOINが必要で、より複雑。AIは可能だが、日付境界を慎重に検証すべき。よくあるAIの間違い：ビジネスが会計年度を使っているのにカレンダー年度で比較。）

反復改良ループ

AIを使った実務でのクエリ作成はこのパターンに従います：

1. 最初のプロンプト： スキーマコンテキスト付きで欲しいものを説明
2. クエリ実行： 構文エラーをチェック
3. 結果検証： 既知のデータポイントと比較
4. 改良： 何が間違っているか具体的にAIに伝える（「日付範囲は包含的にして」「JOINで重複行が出る」）
5. 反復 結果が期待と一致するまで

このループは複雑なクエリで通常2-3回の反復——それでもゼロから書くよりはるかに速い。

まとめ

• AIにSQLを依頼するときは常にスキーマ（テーブル名、カラム、型、リレーションシップ）を含める
• データベースシステムを指定する——PostgreSQL、MySQL、SQL Serverは日付、文字列、高度な機能の構文が異なる
• JOINはAIが最もミスする箇所——行数を検証し、重複やデータ欠落をチェック
• 反復改良（プロンプト→実行→検証→修正）は複雑なクエリで通常2-3サイクル
• CTEが複雑なAI生成クエリを読みやすく、セクションごとにデバッグしやすくする

次のレッスン

次は「AIでスキーマ設計」——ビジネス要件を正規化された効率的なテーブル構造に変換する方法を学びます。