最近では、ChatGPTやClaude、CodexなどのAIにSQLを書かせることが珍しくなくなりました。

「この条件でSQLを書いて」と指示するだけでも、それらしいSQLが返ってきます。

しかし、実務で使うとなると話は別です。

ユーザーが2026年に登録した件数を取得するSQLを書いて

これだけでもSQLは生成できます。

しかし、本当に欲しいSQLは、

• どのテーブルを使うのか
• 日付はどのカラムなのか
• 削除済みデータを除外するのか
• タイムゾーンは何か
• JOIN条件は何か
• NULLをどう扱うのか
• PostgreSQLなのかMySQLなのか

によって変わります。

つまり、**AIにSQLを書かせるときに重要なのは、SQLの知識だけではなく「データベースの情報をAIに正しく渡すこと」**です。

この記事では、AIにSQLを書かせるときの実践的なコツを紹介します。

1. 「SQLを書いて」だけでは情報が足りない

まず、ありがちな指示です。

user_idが123のユーザーの注文履歴を取得するSQLを書いて

これではAIからすると情報が足りません。

例えば、

users
orders

という2つのテーブルがあったとしても、

orders.user_id

なのか、

users.id = orders.customer_id

なのか分かりません。

そこで、テーブル定義を一緒に渡します。

例えば、

DB: PostgreSQL

users
- id: bigint
- name: varchar
- created_at: timestamp

orders
- id: bigint
- user_id: bigint
- amount: integer
- created_at: timestamp

さらに、

users.id = orders.user_id

というリレーションも伝えます。

これだけでAIがSQLを生成するための材料がかなり増えます。

2. テーブル定義をAIに渡す

実務では、これがかなり重要です。

例えば、

以下のテーブルがあります。

users
- id bigint PRIMARY KEY
- name varchar(255)
- created_at timestamp
- deleted_at timestamp NULL

orders
- id bigint PRIMARY KEY
- user_id bigint
- amount integer
- status varchar(20)
- created_at timestamp

そして、

orders.user_id = users.id

deleted_at IS NOT NULL のユーザーは削除済みユーザーとして扱う。

と伝えます。

そのうえで、

2026年に注文したユーザー数を取得するSQLを書いてください。
削除済みユーザーは除外してください。
PostgreSQL用でお願いします。

とします。

するとAIは、

SELECT COUNT(DISTINCT o.user_id)
FROM orders o
INNER JOIN users u
    ON u.id = o.user_id
WHERE o.created_at >= '2026-01-01'
  AND o.created_at < '2027-01-01'
  AND u.deleted_at IS NULL;

のようなSQLを生成できます。

ここで重要なのは、「SQLを書いて」という指示よりも、SQLを考えるためのコンテキストのほうが重要ということです。

OpenAIのプロンプト設計でも、モデルに対して目的・コンテキスト・出力形式などを具体的に指定することが推奨されています。

3. DBの種類を必ず指定する

これも地味に重要です。

例えば、

SQLを書いて

だけでは、

• PostgreSQL
• MySQL
• SQLite
• SQL Server
• Oracle

のどれを想定しているのか分かりません。

DBによってSQLの書き方は変わります。

例えばPostgreSQLなら、

LIMIT 10

だけでなく、PostgreSQL固有の関数や型、RETURNING、ILIKEなどを利用できます。

一方でMySQLでは別の書き方になるケースがあります。

したがって、

PostgreSQL 18用のSQLを書いてください。

のように指定します。

4. 「何を取得したいか」を具体的にする

悪い例です。

売上を取得するSQLを書いて

「売上」が何なのか分かりません。

例えば、

2026年1月〜3月の売上を月単位で集計してください。

条件：
- orders.status = 'completed' のみ対象
- amountを売上金額として使用
- 月ごとの件数も取得
- 売上金額の降順ではなく年月順に並べる
- PostgreSQL用

とします。

すると、

SELECT
    DATE_TRUNC('month', created_at) AS month,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount
FROM orders
WHERE status = 'completed'
  AND created_at >= '2026-01-01'
  AND created_at < '2026-04-01'
GROUP BY DATE_TRUNC('month', created_at)
ORDER BY month;

のように、かなり具体的なSQLを生成できます。

5. 「SQLを書いて」ではなく「SQL + 解説」を要求する

個人的におすすめなのがこれです。

以下の条件でSQLを書いてください。

SQLだけではなく、

1. SQL
2. 各JOINの意味
3. WHERE条件の意味
4. インデックスが利用される可能性
5. パフォーマンス上の注意点

も説明してください。

これだけで、AIの回答をレビューしやすくなります。

特に複雑なSQLでは、

LEFT JOIN

と

INNER JOIN

をAIが選択した理由を説明させるのが有効です。

6. AIに「SQLレビュー」もさせる

SQLを生成して終わりにする必要はありません。

むしろ、

生成 → レビュー → 修正

の流れにすると便利です。

例えば、

以下のSQLをレビューしてください。

レビュー観点：
- SQLとして正しいか
- 意図したデータを取得できるか
- JOIN条件に問題がないか
- NULLの扱い
- 重複行が発生しないか
- N+1などの問題
- インデックスが利用できるか
- 大量データで遅くならないか
- PostgreSQLとして適切か

問題があれば修正版SQLも提示してください。

とします。

これなら単純なSQL生成ではなく、SQLコードレビュー担当としてAIを使うことができます。

7. EXPLAINの結果をAIに渡す

ここからは一段上の使い方です。

SQLの性能改善にもAIを利用できます。

例えばPostgreSQLでは、

EXPLAIN ANALYZE
SELECT ...

を実行できます。

PostgreSQLのEXPLAINは、クエリプランナーが選択した実行計画を確認するための機能です。テーブルのスキャン方法やJOIN方法などを確認できます。

例えば、

以下はPostgreSQLのEXPLAIN ANALYZE結果です。

このSQLが遅い原因を分析してください。

特に、
- Seq Scan
- Index Scan
- Nested Loop
- Sort
- 行数の見積もり
- 実際の処理時間

に注目してください。

改善案があればSQLとインデックス定義も提示してください。

として、

EXPLAIN ANALYZEの結果

を貼ります。

するとAIに、

SQLを生成する

だけではなく、

SQLを分析する
↓
ボトルネックを発見する
↓
インデックスを提案する
↓
改善SQLを作る

という使い方ができます。

8. UPDATE・DELETEは特に慎重にする

AIにSQLを書かせるとき、最も注意したいのが、

UPDATE
DELETE

です。

例えば、

2025年以前のユーザーを削除するSQLを書いて

という指示だけで、

DELETE FROM users
WHERE created_at < '2026-01-01';

のようなSQLが生成される可能性があります。

そこで、まず、

SELECT *
FROM users
WHERE created_at < '2026-01-01';

を生成させます。

そして結果を確認したあとで、

先ほどのSELECTと同じ条件でDELETE文を作ってください。

とします。

つまり、

SELECTで対象確認 → UPDATE/DELETE

という手順にします。

本番DBでは特に重要です。

9. SQLインジェクション対策はAI任せにしない

アプリケーションコードをAIに生成させる場合、ここは特に注意が必要です。

例えば、

const sql = `
  SELECT *
  FROM users
  WHERE name = '${name}'
`;

のようなコードを生成してしまうと、SQLインジェクションのリスクがあります。

OWASPでは、SQLインジェクション対策として**Prepared Statement（パラメータ化クエリ）**を推奨しています。ユーザー入力をSQL文字列に直接連結するのではなく、SQLとデータを分離する考え方です。

AIにコードを書かせる場合も、

ユーザー入力は必ずパラメータ化クエリを使用してください。
SQL文字列への直接連結は禁止してください。

と明示しておくとよいでしょう。

10. AIにSQLを書かせるためのテンプレート

実際には、毎回ゼロからプロンプトを書く必要はありません。

以下のようなテンプレートを作っておくと便利です。

あなたは経験豊富なデータベースエンジニアです。

以下の条件をもとにSQLを作成してください。

## DB
PostgreSQL 18

## テーブル定義
users
- id bigint PRIMARY KEY
- name varchar(255)
- created_at timestamp
- deleted_at timestamp NULL

orders
- id bigint PRIMARY KEY
- user_id bigint
- amount integer
- status varchar(20)
- created_at timestamp

## リレーション
orders.user_id = users.id

## 要件
2026年の月別売上を取得する。

条件：
- status = 'completed' のみ
- deleted_at IS NOT NULL のユーザーは除外
- 月ごとの注文数も取得
- 月順に並べる

## 出力
以下の順番で回答してください。

1. SQL
2. SQLの解説
3. 想定される問題
4. パフォーマンス上の注意点
5. 必要なインデックス

この形なら、かなり再利用できます。

11. さらに一歩進んだ使い方

AIにSQLを書かせるとき、

「SQL生成ツール」として使うだけでは少しもったいないです。

例えば、

要件
 ↓
AI
 ↓
SQL生成
 ↓
SQLレビュー
 ↓
EXPLAIN
 ↓
性能分析
 ↓
インデックス提案
 ↓
修正版SQL

という流れを作れます。

さらにClaude CodeやCodexのような開発エージェントを利用すれば、リポジトリ内のモデル・マイグレーション・既存SQL・ORMのコードなどを参照しながらSQLを作らせる、という使い方もできます。

ここで重要なのは、AIに「SQLの知識」を与えることより、「そのプロジェクトでSQLを書くために必要な情報」を与えることです。

まとめ

AIにSQLを書かせるときのポイントをまとめると、以下のようになります。

結局のところ、

AIにSQLを書かせるコツは、「SQLを書いて」と頼むことではなく、「AIが正しいSQLを判断できるだけの情報を渡すこと」です。

そして、生成されたSQLをそのまま本番環境で実行するのではなく、人間によるレビュー、テストデータでの検証、EXPLAINによる性能確認まで含めて使うのが実務的なAI活用方法です。

関連URL

• OpenAI — プロンプト設計のベストプラクティス
• PostgreSQL — EXPLAIN
• PostgreSQL — EXPLAIN SQLリファレンス
• OWASP — SQL Injection Prevention Cheat Sheet
• OWASP — Query Parameterization Cheat Sheet