プロンプト工房
なぜこう書くのか
ブロックを押すとその段落が見られます
私は{{データベース}}を使用しており、分析ツールを使わずに直接クエリを書いて数値を確認する必要があります。以下に実際のテーブル構造を記載しました。
回答を出す前に、テーブル構造だけでは判断できない点（期間の基準となるカラム、キャンセル・返金分の除外有無、重複集計の処理など）があれば、まず最大3つまで質問してください。私が回答した後にクエリを作成してください。
クエリを提示する際は、実行可能なSQLを1つのブロックとして最初に提示し、その下に私の要望をどのように解釈したかを示す「解釈・根拠としたカラム」の表を付け、最後に結果として出力されるカラムを1行で記載してください。
以下の構造に存在しないテーブルやカラムは使用しないでください。必要な値が構造にない場合は、クエリを勝手に作らず、何が不足しているかをまず教えてください。
- 材料 AIが知るべきこと ×2
- やること 何をどう進めるか ×2
- 仕上がり どんな形で受け取るか ×2
SQLクエリの作成をAIに依頼する際、最も頻繁に発生するのは、実行した瞬間に「そのようなカラムは存在しません」というエラーが出るクエリを受け取ることです。テーブル構造を渡さないと、AIはorders.order_dateやusers.is_activeといった、よくある名前を勝手に捏造してしまいます。文法は完璧なため一見正しそうに見え、貼り付けて実行して初めて間違いに気づきます。
解説をもっと読む · 3段落
そのため、コンテキストがこのプロンプトの半分を占めます。カラム一覧やCREATE TABLE文をそのまま貼り付けることで、AIは名前を捏造する必要がなくなります。データベースの種類も併せて指定します。日付の差分を求める関数ひとつをとっても製品ごとに名前が異なるため、この1行があるだけで実行不可能なクエリの生成を大幅に減らせます。
聞き返しの段落は、誤った集計値を事前に防ぎます。「先月の売上」という一言には、基準が注文日なのか決済日なのか、キャンセル分を引くのかが含まれていません。質問させないと、AIは勝手に1つを選んで処理を進めてしまい、数値の間違いはレポート提出後に発覚することになります。質問を3つに限定しているのは、聞き返しが際限なく続くのを防ぐためです。
フォーマットの「解釈・根拠としたカラム」表は検算のための仕組みです。クエリだけを受け取ると、条件が正しく反映されているかSQLを読めないと確認できませんが、解釈が文章で書かれていれば目視で照合できます。テーブル構造を"""で囲んでいるのは、定義内のコメントなどが指示として誤読されるのを防ぎ、どこまでがデータであるかの境界を明確にするためです。
用語が分からなければAha AIで: hallucination, prompt
悪い例との比較
先月に2回以上注文した顧客数を出すSQLを書いて
テーブル名がordersやusersと勝手に決められ、注文日のカラムもorder_dateと捏造されます。実行するとエラーになるか、運悪く名前が一致してもキャンセル注文まで含まれた間違った数値が出力されます。何を基準に「先月」としたのかも説明にないため、結果を信頼できません。
バリエーション
聞き返しなしでドラフトを急ぐ場合
時間がないときに使用します。聞き返しをなくした代わりに前提をコメントに残させることで、後からどこを修正すべきかを把握できるようにしています。
プロンプトを見る
{{データベース}}を基準に、以下のテーブル構造のみを参照して「{{知りたいこと}}」を算出するクエリを作成してください。私への質問は不要です。曖昧な条件がある場合は最も保守的な前提を置き、その前提条件の一覧をクエリの最上部にコメントとして残してください。
""" {{テーブル 構造}} """
結果の数値が想定より大きい場合
集計が狂っている場合、原因の多くはJOINによる行の増殖です。検証用クエリも一緒に入手しておけば、次回以降も同様の手順で確認できます。
プロンプトを見る
以下の{{データベース}}のテーブル構造において「{{知りたいこと}}」を算出しましたが、数値が想定よりも大きくなっています。JOIN・重複行・NULLによって数値が膨らむ可能性のあるポイントをリストアップし、それぞれを確認するための検証用クエリも併せて提示してください。
""" {{テーブル 構造}} """
モデル別の注意
生成されたクエリは本番の運用データベースで直接実行せず、まずは読み取り専用権限のアカウントで確認してください。件数が想定と異なる場合は、条件を1つずつ外しながら絞り込むと原因を素早く特定できます。
最終更新 2026-09-02 · 誤りがありますか？ 知らせる