AI活用SQLライティング
AIに正確なSQLクエリを書かせるプロンプト技術をマスター——シンプルなSELECTから複雑なJOIN、サブクエリ、集計まで、あらゆるデータベースシステムに対応。
プレミアムコースコンテンツ
このレッスンはプレミアムコースの一部です。Proにアップグレードすると、すべてのプレミアムコースとコンテンツを利用できます。
- すべてのプレミアムコースを利用
- 1,000以上のAIスキルテンプレート付き
- 毎週新しいコンテンツを追加
🔄 前回のおさらい: レッスン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を使った実務でのクエリ作成はこのパターンに従います:
- 最初のプロンプト: スキーマコンテキスト付きで欲しいものを説明
- クエリ実行: 構文エラーをチェック
- 結果検証: 既知のデータポイントと比較
- 改良: 何が間違っているか具体的にAIに伝える(「日付範囲は包含的にして」「JOINで重複行が出る」)
- 反復 結果が期待と一致するまで
このループは複雑なクエリで通常2-3回の反復——それでもゼロから書くよりはるかに速い。
まとめ
- AIにSQLを依頼するときは常にスキーマ(テーブル名、カラム、型、リレーションシップ)を含める
- データベースシステムを指定する——PostgreSQL、MySQL、SQL Serverは日付、文字列、高度な機能の構文が異なる
- JOINはAIが最もミスする箇所——行数を検証し、重複やデータ欠落をチェック
- 反復改良(プロンプト→実行→検証→修正)は複雑なクエリで通常2-3サイクル
- CTEが複雑なAI生成クエリを読みやすく、セクションごとにデバッグしやすくする
次のレッスン
次は「AIでスキーマ設計」——ビジネス要件を正規化された効率的なテーブル構造に変換する方法を学びます。
理解度チェック
まず上のクイズを完了してください
レッスン完了!