SQLクエリの考え方をAIで整理するプロンプトテンプレート 集計条件・結合・確認観点を言語化する書き方
SQLを書く前に迷いやすいのは、構文そのものよりも「どの表を使い、どの条件で絞り、何を集計すれば答えになるのか」です。
このテンプレートは、売上分析、顧客リスト作成、採用データ確認、問い合わせ件数の集計など、業務データをSQLで取り出したい人向けです。SQL初心者がChatGPT、Claude、Geminiなどの汎用LLMに相談するとき、いきなり完成SQLを求めるのではなく、クエリの考え方を先に整理するために使います。
- 使う場面: SQLを書く前の設計整理、既存SQLの読み解き、集計条件の確認
- 向いている人: SQLに慣れていない業務担当者、分析担当者、開発者に依頼する前に要件を整理したい人
- 主な出力形式: 手順、確認質問、疑似SQL、最終SQL案、注意点
- 注意点: 実データ、個人情報、社外秘の表名や値は必要に応じて伏せる
ここがポイント: AIに「SQLを書いて」とだけ頼むより、目的、使える表、必要な列、除外条件、集計単位を渡した方が、後から直しやすいSQL案になります。
何に使うテンプレートか
このテンプレートの目的は、SQLの正解を丸投げで作ることではなく、欲しい答えにたどり着くための考え方を分解することです。
たとえば「先月の売上を出したい」という依頼だけでは、AIも人間も判断に迷います。
確認すべきことは、少なくとも次のように分かれます。
- 売上は注文金額か、入金済み金額か
- キャンセル注文を含めるか
- 税込みか税抜きか
- 日付は注文日か、発送日か、入金日か
- 店舗別、商品別、担当者別など、どの単位で見るか
SQLでは、このような業務上の決め方が WHERE、JOIN、GROUP BY、SUM() などに落ちます。だから、最初に整理すべきなのは文法ではなく、集計の前提条件です。
コピペ用プロンプトテンプレート
まずは、SQLを書かせる前に「考え方の整理」から依頼する形です。表名や列名がまだ曖昧でも使えるようにしています。
あなたはSQLに詳しい業務データ分析の補助者です。
以下の目的を達成するSQLを考える前に、必要な考え方を整理してください。
## 目的
{何を知りたいか}
例: 先月の商品別売上金額を確認したい
## 業務背景
{なぜその集計が必要か}
例: 月次会議で、売上上位の商品と落ち込みが大きい商品を確認したい
## 使えそうなテーブル
{テーブル名と分かる範囲の説明}
例:
- orders: 注文情報
- order_items: 注文明細
- products: 商品情報
## 分かっている列
{列名、意味、型が分かれば型}
例:
- orders.id: 注文ID
- orders.ordered_at: 注文日時
- orders.status: 注文状態
- order_items.order_id: 注文ID
- order_items.product_id: 商品ID
- order_items.quantity: 数量
- order_items.unit_price: 単価
- products.name: 商品名
## 条件
{絞り込み条件、除外条件、期間、集計単位}
例:
- 対象期間: {YYYY-MM-DD} から {YYYY-MM-DD} まで
- キャンセル注文は除外
- 商品別に合計する
## 出力してほしい内容
1. このSQLで決めるべき前提条件
2. 使うテーブルと結合の考え方
3. WHEREで指定すべき条件
4. GROUP BYで集計する単位
5. 疑似SQL
6. 最終SQL案
7. 実行前に確認すべき注意点
## 制約
- 不明点は勝手に決めず、確認質問として分けてください
- SQLは読みやすいように改行してください
- 個人情報を含む列が必要な場合は、使用理由と代替案も書いてください
- 方言は [{MySQL/PostgreSQL/BigQuery/SQL Server/不明}] を前提にしてください
このプロンプトの良い点は、AIにいきなり完成形を求めないことです。先に「決めるべき前提条件」を出させるので、SQLの間違いだけでなく、業務上の勘違いにも気づきやすくなります。
入力時に変える部分
テンプレート内の {} と [] は、毎回置き換える部分です。すべてを埋める必要はありませんが、目的、期間、使えそうな表の3つはできるだけ書いてください。
必ず入れたい項目
{何を知りたいか}: 売上、件数、人数、平均値、重複、未対応リストなど{なぜその集計が必要か}: 会議資料、施策確認、異常検知、依頼前の下調べなど{テーブル名と分かる範囲の説明}: 正確な表名が分からなければ「注文らしき表」でもよい{列名、意味、型が分かれば型}: 日付、ID、金額、状態、カテゴリなど{絞り込み条件、除外条件、期間、集計単位}: SQLの結果を左右する条件
固定した方がよい条件
毎回変えず、固定しておくと出力が安定する指示もあります。
- 不明点は推測せず確認質問にする
- SQLを読みやすく改行する
- 実行前の注意点を出す
- 個人情報を含む列の扱いを確認する
- SQL方言を指定する
SQLはデータベース製品によって日付関数や文字列処理の書き方が変わります。MySQL、PostgreSQL、BigQuery、SQL Serverなど、分かる場合は最初に指定しておくと修正が減ります。
NG例と改善例
SQL相談で失敗しやすいのは、短すぎる依頼です。AIは不足部分を補おうとしますが、その補完が業務ルールと合っているとは限りません。
NG例
先月の売上を出すSQLを書いて。
この依頼では、売上の定義も、使うテーブルも、除外条件も分かりません。AIがもっともらしいSQLを出しても、実務ではそのまま使いにくい状態です。
改善例
先月の商品別売上を集計するSQLを考えたいです。
まず、SQLを書く前に確認すべき前提条件を整理してください。
使えそうなテーブルは orders、order_items、products です。
注文日は orders.ordered_at、注文状態は orders.status、商品名は products.name、数量は order_items.quantity、単価は order_items.unit_price です。
キャンセル注文は除外したいです。
出力は以下の順にしてください。
1. 確認すべき前提条件
2. テーブル結合の考え方
3. 集計条件
4. SQL案
5. 実行前の注意点
変えたのは、情報量だけではありません。改善例では「まず確認すべき前提条件を整理」と指定しています。これにより、AIは完成SQLだけでなく、期間、注文状態、金額計算、結合条件の抜けを指摘しやすくなります。
出力を安定させるコツ
SQL系のプロンプトでは、出力形式、制約、確認手順を分けて指定すると安定します。
1. 完成SQLだけでなく、途中の考え方も出させる
完成SQLだけを見ると、どの条件がどこに反映されたか分かりにくくなります。特に初心者は、間違いがあっても気づきにくいです。
おすすめは、次の順番です。
- 前提条件
- 使うテーブル
- 結合条件
- 絞り込み条件
- 集計単位
- 疑似SQL
- 最終SQL
- 注意点
この順に出してもらうと、開発者やデータ担当者に確認を依頼するときも、会話が進めやすくなります。
2. SQL方言を指定する
同じ「日付を月ごとにまとめる」処理でも、データベースによって書き方が変わります。
- MySQL:
DATE_FORMAT()を使うことがある - PostgreSQL:
DATE_TRUNC()を使うことがある - BigQuery:
DATE_TRUNC()やFORMAT_DATE()を使うことがある - SQL Server:
FORMAT()やDATEFROMPARTS()などを使うことがある
方言が分からない場合は、[不明] と書いてかまいません。その代わり、「標準SQLに近い形で書き、方言依存の箇所を注記してください」と入れると扱いやすくなります。
3. 個人情報をそのまま入れない
AIに相談するときは、実名、メールアドレス、電話番号、住所、顧客IDなどをそのまま貼らない方が安全です。
相談時は次のように置き換えます。
customer_emailは列名だけにする- 実在のメールアドレスは
user@example.comのようなダミーにする - 氏名は
顧客A、社員Bのように置き換える - 実データの行を貼る場合は、値を匿名化する
SQLの設計相談では、多くの場合、実データそのものより「列の意味」と「条件」が重要です。
活用例: 業務カテゴリ別の使い方
同じテンプレートでも、業務によって入力すべき情報が変わります。以下は、実務で使いやすい切り口です。
分析: 売上や利用状況を集計する
売上、利用回数、アクティブユーザー数などを集計したい場合は、期間、対象状態、集計単位を明確にします。
目的: 今月の部署別問い合わせ件数を集計したい
条件: 完了済みと対応中を分けたい
出力: 部署名、対応状態、件数
確認したい点: 対応状態の定義、削除済みデータの扱い
件数集計では、重複を数えるかどうかが重要です。ユーザー数なら COUNT(DISTINCT user_id) が必要になる場合があります。
採用: 応募者の進捗を確認する
採用管理では、候補者ごとの状態、応募日、選考ステップが軸になります。個人情報を含みやすいため、AIに渡す情報は列名と条件に絞るのが基本です。
目的: 先月応募した候補者の選考ステップ別人数を集計したい
条件: 候補者名やメールアドレスは使わない
出力: 応募経路、現在の選考ステップ、人数
確認したい点: 辞退者を含めるか、重複応募をどう扱うか
法務・管理: 契約や期限を確認する
契約期限、更新日、承認状態を確認する場合は、日付条件とステータス条件が中心になります。
目的: 30日以内に更新期限が来る契約を一覧化したい
条件: 解約済み契約は除外
出力: 契約ID、取引先カテゴリ、期限日、担当部署
確認したい点: 今日の日付の扱い、更新済み契約の除外条件
契約名や取引先名をAIに渡す必要がない場合は、カテゴリやIDだけで相談できます。
開発: 既存SQLの読み解きに使う
既存SQLを渡して、何をしているか整理してもらう使い方もあります。この場合は、SQL全文だけでなく「知りたいこと」を添えると精度が上がります。
以下のSQLが何を集計しているか、初心者にも分かるように説明してください。
特に、JOIN、WHERE、GROUP BY、HAVINGの役割を分けて説明してください。
## SQL
{既存SQLを貼る}
## 出力してほしい内容
1. このSQLの目的の推測
2. 使っているテーブル
3. 絞り込み条件
4. 集計単位
5. 結果に含まれないデータ
6. 注意すべき点
既存SQLの解釈では、「結果に含まれないデータ」を聞くのが大切です。WHERE条件で除外された行や、INNER JOINで落ちるデータが見えると、集計結果の意味を判断しやすくなります。
出力形式別の追加指定
SQL相談では、最終SQLだけでなく、説明の形も指定できます。用途に応じて追加してください。
表で整理したい場合
出力は、以下の列を持つ表で整理してください。
- 項目
- 内容
- SQL上の反映箇所
- 確認が必要な理由
JSONで受け取りたい場合
最後に、以下のJSON形式でも整理してください。
キー名は英小文字のスネークケースにしてください。
{
"purpose": "",
"tables": [],
"join_keys": [],
"where_conditions": [],
"group_by": [],
"sql": "",
"check_points": []
}
依頼用メモにしたい場合
データ担当者に確認を依頼するため、以下の形式で短くまとめてください。
- 知りたいこと
- 想定しているテーブル
- 必要な条件
- 迷っている点
- 作ってほしいSQLの出力列
JSONや表形式は、後で別ツールに貼るときに便利です。ただし、初心者が最初に使うなら、まずは「前提条件」と「確認質問」を文章で出してもらう方が理解しやすいです。
モデルをまたいで使うときの前提
この記事のテンプレートは、2026年7月時点で一般的に使われているChatGPT、Claude、Geminiなどの汎用LLMを想定しています。各サービスの仕様や利用できるモデルは変わるため、最新の機能名や制限は公式情報を確認してください。
プロンプト作成の考え方としては、各社の公式ガイドでも、目的、文脈、制約、出力形式を明確にすることが重視されています。SQL相談でも同じです。
モデルごとの差より先に、次の情報を入れる方が効果があります。
- 何を知りたいか
- どの表と列を使えるか
- どのデータを除外するか
- どの単位で集計するか
- どの形式で出してほしいか
AIの出力は、実行前に必ず人間が確認してください。SQLは実行環境によってエラーになるだけでなく、条件の置き方ひとつで集計結果が変わります。
最後に確認するチェックリスト
SQLクエリの考え方をAIに整理させるときは、実行前に次を確認します。
- 目的は「何を知りたいか」まで具体化されているか
- 期間、状態、除外条件が書かれているか
- 売上、件数、人数などの定義が曖昧なままになっていないか
- JOINするキーが妥当か
COUNT(*)とCOUNT(DISTINCT ...)の違いを確認したか- 個人情報や機密情報をそのまま貼っていないか
- SQL方言が実行環境に合っているか
- AIが推測した部分と、事実として分かっている部分を分けて読めるか
SQLの相談で一番危ないのは、文法エラーではなく、間違った前提のまま正しそうな集計結果を作ってしまうことです。次にAIへ依頼するときは、完成SQLだけでなく「この条件で何が除外されるか」まで聞いてください。そこまで確認できると、SQLはただのコードではなく、業務判断に使える説明になります。