「来週の会議までに、地域別・商品カテゴリ別の四半期売上推移を出してほしい。あ、キャンセル済みオーダーは除外してね」
上司やマーケティングチームからこんな依頼が飛んできた瞬間、背中に冷たい汗が流れるのを感じたことはありませんか？
頭の中では「ordersテーブルとproductsテーブルを繋げて…いや、地域情報はusersテーブルにあるからそれもJOINして…」と考え始めるものの、いざエディタに向かうと指が止まる。「あれ、結合キーはcustomer_idだっけ？ user_idだっけ？」「LEFT JOINにすべきかINNER JOINにすべきか…」
そして勇気を出して実行したSQLが真っ赤なエラーメッセージを吐き出した時の、あの絶望感。
「AIに書いてもらえばいいじゃないか」と思うかもしれません。しかし、ChatGPTやCursorに「売上集計して」と頼んでみたものの、返ってきたSQLを実行したら「そんなカラムは存在しません」と怒られたり、もっと怖いことに、エラーは出ないけれど数字が全然合っていないという経験をしたことがある人も多いはずです。
実務の現場におけるAIプロジェクトの傾向として、SQL生成におけるAI活用の失敗には、共通点が存在します。
それは、AIを「魔法使い」だと勘違いし、手ぶらで地図のない森へ送り込んでいるということです。
安心してください。あなたがSQLに苦手意識を持っているのは、能力の問題ではありません。AIというパートナーへの「情報の渡し方」を少し変えるだけで、その不安は「確信」へと変わります。
本記事では、AIエージェント開発や高速プロトタイピングの知見から、Cursorを使って複雑なJOINを含むSQLを「安全に」「正確に」生成するための実践的なテクニックを解説します。プロンプトの暗記は必要ありません。必要なのは、AIと正しく対話するための少しの準備と心構えだけです。
なぜ、AIに「売上集計して」と頼むと失敗するのか？
まず、なぜAIは平気で嘘をつくのか、そのメカニズムを理解しておきましょう。敵を知れば、怖くありません。
多くの人がやりがちなのが、Cursorのチャット欄にいきなりこう打ち込むことです。
「先月の商品別売上ランキングを出して」
これは、初めて会った人に「私の家の冷蔵庫にあるもので夕食を作って」と頼むようなものです。相手はあなたの家に何があるか（食材）、調味料はどこか、そもそもアレルギーはあるか（制約条件）を全く知りません。
「文脈不足」が引き起こすSQLエラーの恐怖
AI、特に大規模言語モデル（LLM）は、確率論に基づいて「もっともらしい言葉」を繋げるのが得意です。あなたが「売上」と言えば、AIは世の中の一般的なデータベース構造を想像し、「たぶんsalesテーブルがあって、amountカラムがあるだろう」と推測してSQLを書きます。
しかし、実際のデータベースでは、テーブル名はt_order_historyかもしれませんし、金額はpriceとquantityを掛け合わせないと出ないかもしれません。
この「推測」と「事実」のズレが、エラーや誤った集計結果の正体です。
AIはあなたのデータベースの中身を知らない
Cursorは非常に優秀なエディタですが、デフォルトの状態では、データベースサーバーの中身を透視することはできません。セキュリティの観点からも、それは当然のことです。
AIが見ているのは、あくまでエディタで開いているファイルや、チャットで明示的に渡した情報だけです。データベースのスキーマ情報（テーブル定義やリレーション）が渡されていない状態でSQLを書かせようとするのは、目隠しをして迷路を走らせるようなもの。壁に激突するのは当たり前ですよね。
ハルシネーション（もっともらしい嘘）が起きるメカニズム
さらに厄介なのが、AIが自信満々に間違える「ハルシネーション」です。
例えば、usersテーブルとordersテーブルを結合する際、AIは勝手に「users.id = orders.user_id で結合すればいい」と判断することがあります。しかし、実際にはordersテーブルにはcustomer_codeというカラムしかなく、それをキーにしなければならない場合、生成されたSQLはエラーになるか、最悪の場合、偶然型が一致してしまい間違ったデータ同士を結合してしまうリスクがあります。
これが「AIは怖い」と感じる根本原因です。しかし、これはAIの欠陥というよりは、人間側が「コンテキスト（文脈・背景情報）」を与えていないことに起因します。
Cursorを「専属DB管理者」に変えるための準備儀式
では、どうすればいいのでしょうか？ 答えはシンプルです。AIにデータベースの「地図」を渡してあげればいいのです。
Cursorには、この「地図」を読み込ませるための素晴らしい機能が備わっています。これを使いこなすことで、Cursorは単なるチャットボットから、データベース構造を熟知した「専属DB管理者」へと進化します。
DDL（定義書）を読み込ませることが安心への第一歩
最も確実で効果的な方法は、CREATE TABLE文（DDL）をAIに共有することです。
実際のデータ（個人情報や機密情報）を渡す必要はありません。必要なのは「構造」だけです。
- データベースから主要なテーブルの
CREATE TABLE文をエクスポートします。 - それを
schema.sqlのようなファイルに保存し、Cursorのプロジェクト内に置きます。 - チャットをする際に、このファイルを参照させます。
これだけで、AIは「ordersテーブルにはcustomer_codeがある」「statusカラムは整数型で定義されている」といった事実を理解します。推測でカラム名をでっち上げる必要がなくなるのです。
「@Symbols」機能でテーブル定義をピンポイントで渡す
Cursorのチャット機能には「@（アットマーク）」を使って特定のファイルやシンボル（関数やクラス、そしてSQLのテーブル定義など）をコンテキストとして渡す機能があります。
もしプロジェクト内で、ORM（Object-Relational Mapping）のモデル定義ファイルや、スキーマ定義ファイルが開ける状態なら、チャット欄で@を入力し、関連するファイルを選択してください。
「@schema.sql を参照して、ユーザーごとの注文総額を集計するSQLを書いて」
このように指示すれば、AIは渡されたファイルの中身を読み込み、そこに定義されている正確なテーブル名とカラム名を使ってクエリを構築します。これこそが、ハルシネーションを防ぐ最強の「安全装置」です。
ER図の関係性を言葉で補足する重要性
DDLだけでは伝わりきらない「暗黙のルール」がある場合もあります。例えば、「deleted_atに日付が入っているレコードは論理削除されたものとして扱う」といったビジネスロジックです。
これらは、Cursorの「.cursorrules」ファイル（プロジェクト固有のAIへの指示書）に記述しておくか、チャットの冒頭で明示的に伝えます。
「このデータベースでは、以下のルールを守ってください」
- 削除フラグ：
is_deleted = 1のデータは除外する - 結合ルール：
ordersとproductsはorder_itemsという中間テーブルを介して結合する
このように「地図（DDL）」と「交通ルール（ビジネスロジック）」をセットで渡すこと。これが、精度の高いSQLを引き出すための準備儀式です。
実践：複雑なJOINを「分解」して対話で組み立てる
準備ができたら、いよいよSQL生成の実践です。ここで多くの人が陥る罠があります。それは、「一発で完璧な回答を得ようとすること」です。
複雑なJOINを含むクエリを、たった1回のプロンプトで生成させようとすると、AIも混乱しやすくなりますし、何より出力された長いSQLが合っているのかどうか、人間側が検証できなくなります。
ここで推奨するのは、「システム思考」に基づいた段階的なアプローチです。大きな問題を小さな要素に分解し、一つずつAIと合意形成しながら積み上げていくのです。プロトタイプ思考のように、まずは小さく動くものを作り、検証を繰り返すことが重要です。
いきなり完成形を求めない「段階的生成」のススメ
料理を作る時も、いきなり完成品はできませんよね。材料を切り、炒め、味付けをするという工程があります。SQLも同じです。
以下のステップで、AIと「会話」をしながら作っていきましょう。
ステップ1：必要なテーブルとカラムの洗い出し
まずは、どのテーブルを使うかだけを確認します。
あなた: 「@schema.sql を見て。地域ごとの売上を出したいんだけど、どのテーブルが必要になると思う？」
Cursor: 「
usersテーブル（地域情報）、ordersテーブル（注文情報）、order_detailsテーブル（金額詳細）の3つが必要になりそうです。」
この時点で、AIの認識が合っているかチェックできます。もし「いや、地域情報はaddressesテーブルにあるんだ」となれば、その場で修正できます。これならSQLを書く前の段階で軌道修正が可能ですよね。
ステップ2：結合条件（ON句）の確認と合意
次に、テーブル同士をどう繋ぐかを確認します。
あなた: 「OK。じゃあ、それらのテーブルをどうやって結合（JOIN）するのが適切？ 結合キーを教えて。」
Cursor: 「
users.idとorders.user_id、そしてorders.idとorder_details.order_idでINNER JOINするのが適切です。」
ここで「LEFT JOINにすべきかINNER JOINにすべきか」を相談するのも良いでしょう。「注文のないユーザーも表示したい？」とAIに聞かれたら、「いや、売上があった地域だけでいい」と答えれば、INNER JOINで確定します。
ステップ3：集計条件（GROUP BY）の追加
最後に、集計ロジックを追加してSQLを完成させます。
あなた: 「わかった。じゃあその結合条件を使って、地域名（
users.region）ごとに売上合計（price * quantity）を集計するSQLを書いて。キャンセル済み（status = 9）は除外してね。」
こうして段階を踏むことで、ブラックボックス化を防ぎ、「なぜそのSQLになったのか」を完全に理解した状態でコードが生成されます。これなら、エラーが出てもどの段階がおかしいかすぐに分かります。
生成されたSQLの「正しさ」を検証する安心テクニック
「AIが書いたコードだから大丈夫」と盲信するのは危険ですが、「AIが書いたから全部疑わしい」と怯えるのも非効率です。
重要なのは、「検証（Validation）」のプロセスを自動化・効率化することです。SQLがあまり読めなくても、ロジックの正当性を確認する方法はあります。
AI自身に「解説」させてロジックの矛盾を突く
生成されたSQLが複雑で理解できない時は、Cursorにこう聞いてみてください。
「このSQLの実行計画と、各行で何をしているか、小学生でもわかるように日本語で説明して」
これを「XAI（説明可能なAI）」のアプローチと呼びます。AIにロジックを言語化させることで、「あ、ここで全結合（CROSS JOIN）しちゃってるからデータが爆発的に増えるかも」といった矛盾点に気づきやすくなります。
また、「このクエリで、売上が二重計上されるリスクはある？」と、意地悪な質問を投げかけるのも効果的です。AIは自己批判的な分析も得意なので、「あ、確かに1対多の結合なので、GROUP BYの前に集計するとズレる可能性があります」と自らバグを発見してくれることがあります。
ダミーデータやLIMIT句を使った安全なテスト実行
本番環境でいきなり重いクエリを投げるのはご法度です。まずは安全にテストしましょう。
- LIMIT句の活用: 「とりあえず10件だけ取得するクエリにして」と依頼し、結果を目視確認する。
- 特定のIDで絞り込み: 「
user_id = 123のデータだけで試して」と依頼し、そのユーザーの実際の注文履歴（管理画面などで見れる正解データ）と一致するか照合する。
エッジケース（NULLや重複）の考慮漏れチェック
初心者がハマりやすいのが、NULL値の扱いです。
「もし
regionがNULLのデータがあったら、この集計結果はどうなる？」
と聞いてみてください。AIは「その場合、集計から除外されます」や「'不明'というカテゴリにまとめられます」と答えます。それが意図と合っているかを確認するのです。
このように、「コードを書かせる」だけでなく「コードをレビューさせる」パートナーとしてAIを使うのが、品質を担保するコツです。
SQL作成を「苦役」から「データ探求」の時間へ
ここまで、Cursorを使って安全にSQLを生成するテクニックをお伝えしてきました。
- 地図を渡す: DDLやスキーマ情報を共有し、推測ではなく事実に基づかせる。
- 対話で刻む: いきなり完成形を求めず、テーブル選定→結合→集計とステップを踏む。
- 逆に問う: 解説やリスク指摘をAIに求め、検証プロセスを挟む。
これらを実践することで、これまで「エラーが出たらどうしよう」「データが合っているか不安だ」と怯えていたSQL作成の時間が、劇的に変わります。
構文エラーとの戦いを終わらせる
もう、カンマの位置や括弧の閉じ忘れでイライラする必要はありません。それはAIが完璧にやってくれます。集中すべきは、「どのデータを組み合わせればビジネスの問いに答えられるか」という本質的なロジックの組み立てです。
ビジネスロジックの定義に集中する
「売上とは何か？」「アクティブユーザーの定義は？」といった、ビジネス上の定義を言語化し、それをAIに正確に伝える能力。これこそが、AI時代に求められるデータリテラシーです。
SQLへの苦手意識を克服することは、単なる業務効率化ではありません。データを通じてビジネスの現状を正しく把握し、自信を持って意思決定できるようになるための、大きな一歩なのです。
チーム全体で「安全なデータ抽出」を標準化する
もし、チームでまだ「SQLは詳しい人に頼むしかない」という属人化が起きているなら、今回紹介した「スキーマ定義ファイル（地図）」をチームで共有し、Cursorを使った標準的な抽出フローを作ってみてはいかがでしょうか。
それでも、「自社のデータベース構造が複雑すぎて、AIにどう説明していいかわからない」「レガシーなシステムでDDLが出せない」といった固有の課題があるかもしれません。
そのような場合は、専門家に相談することをおすすめします。データ環境に合わせた「AIとの付き合い方」を設計することが、解決への近道となるでしょう。
データは怖くありません。正しい地図とコンパス（AI）があれば、そこは宝の山です。さあ、一緒にデータの森へ探検に出かけましょう。
コメント