なぜ「SQLの修正」はこんなにも心理的ハードルが高いのか
「このクエリ、誰が書いたんだ…？」
深夜のオフィス、あるいは自宅のデスクで、モニターに映し出された数百行に及ぶSQLを見つめながら、絶望的な気分になったことはありませんか？
5つのテーブルが複雑にJOINされ、サブクエリが入れ子になり、WHERE句には謎の条件分岐が散りばめられている。ドキュメントはなく、当時の担当者はすでに退職済み。触れば何かが壊れそうだが、パフォーマンスは限界に達しており、修正は待ったなしの状況。
システム受託開発やデータ分析基盤構築の現場において、レガシーシステムのデータベース周りのメンテナンスは、地雷原を歩くような緊張感を強いられる作業です。
「動いているものには触るな」の呪縛
ソフトウェア開発には「動いているものには触るな」という、ある種の呪いのような格言があります。特にデータベースはシステムの心臓部です。アプリケーションコードのバグならデプロイし直せば済みますが、不適切なUPDATE文やDELETE文、あるいはインデックス設計のミスによるDBサーバーのダウンは、ビジネスに甚大な被害をもたらします。
この「取り返しのつかないミス」への恐怖が、エンジニアを保守的にさせます。「遅いけれど、動いているからそっとしておこう」。そうして技術的負債は雪だるま式に膨れ上がり、誰も手出しできないブラックボックスが完成してしまうのです。
属人化したクエリと解読の徒労感
SQLは、書く人の癖が強く出る言語です。可読性を無視したエイリアス（別名）の使用や、特定のDB製品に依存した独自関数の乱用など、他人が書いたクエリを解読するには膨大なエネルギーが必要です。
ロジックを追うだけで半日が過ぎ、結局怖くて修正を断念する。そんな徒労感が、エンジニアのモチベーションを削いでいきます。費用対効果の観点からも、解読に多大な時間を費やすことは望ましくありません。
AIに任せることへの漠然とした不安
ここで「AIを使って効率化しよう」という話になりますが、慎重なエンジニアほどこう思うはずです。
「AIが生成したSQLなんて信用できるか？ もしデータが消えたら責任は誰が取るんだ？」
その懸念は完全に正しいものです。AIは平気で嘘をつきますし、文脈を無視した破壊的なクエリを提案することもあります。だからこそ、AIを「コードを書く作業者」としてではなく、「相談できるツール」として扱うことが現実的なアプローチとなります。
Cursorというツールは、使い方次第で「勝手に書き換える機械」にもなれば、「頼れる専属DBA（データベース管理者）」にもなります。本記事では、現場の課題に即した「データベースを壊さないためのAI活用術」について論理的に解説します。
Cursorを「専属DBA」として活用するという考え方
Cursorを導入する際、多くの人が「自動生成」の機能に目を奪われがちです。しかし、データベース設計やSQL最適化の文脈において、最も価値があるのはその「対話能力」と「コンテキスト認識能力」です。
実務の現場では、Cursorを「新人エンジニア」ではなく「ベテランのDBA」だと思って接することが推奨されます。DBAに対して「これ書き換えて」といきなり丸投げはしませんよね？ まずは「これどう思う？」「リスクはある？」と相談するはずです。
コード生成ではなく「解説」から始める安全性
最も安全な使い方は、AIにいきなりコードを書かせないことです。まずは「読む」作業を手伝ってもらいましょう。
例えば、難解なクエリを選択し、CursorのChat機能（Cmd+L / Ctrl+L）で次のように問いかけます。
「このSQLの意図を、ビジネスロジックの観点から解説して。特に、なぜここでLEFT JOINを使っているのか、データの整合性にどのような影響があるか教えて」
こうすることで、AIはコードを解析し、人間の言葉でロジックを説明してくれます。このプロセスを経ることで、エンジニア自身がコードの理解を深め、「どこを触ればどうなるか」という勘所を掴むことができます。理解していないコードをAIに修正させることほど危険なことはありません。
プライバシーモードで社内データを守る
データベース周りの情報を扱う際、セキュリティは最優先事項です。Cursorには「Privacy Mode」があり、これを有効にすることで、コードがAIの学習データとして使用されることを防げます。
設定画面（Settings > General > Privacy mode）で「Privacy Mode」をオンにすることを強く推奨します。また、プロンプトに入力する際は、実際の顧客名や個人情報が含まれるレコードそのものを貼り付けないよう注意が必要です。スキーマ情報（テーブル定義）やクエリの構造だけで、十分なアドバイスは得られます。
コンテキスト認識がもたらす「文脈のある」提案
Cursorの強みは、プロジェクト全体を認識できる点にあります。@Codebase 機能を使えば、関連するアプリケーションコードや、ORM（Object-Relational Mapping）の定義ファイルを参照させることができます。
一般的なChatGPTなどのチャットツールでは、SQLの断片しか見えませんが、Cursorなら「このテーブル定義ファイル（schema.prismaなど）を踏まえて、このクエリのインデックスが効いているか確認して」といった指示が可能です。
これにより、単に構文的に正しいだけでなく、「現在のシステム設計に合致した」アドバイスを引き出すことができるのです。
Scene 1：ブラックボックス化したクエリの「安全な」解読と改善
では、具体的なシーンを見ていきましょう。目の前には、前任者が残した数百行のレガシーSQLがあります。実行に数秒かかり、タイムアウトのエラーが頻発していると仮定します。
「このSQLは何をしている？」から始める対話
まずは恐怖心を取り除くところからです。該当のSQLファイルを開き、全体を選択してチャットを開始します。
プロンプト例：
「このSQLは複雑すぎて理解が困難です。ステップバイステップで何をしているか分解して解説してください。特にパフォーマンスのボトルネックになりそうな怪しい箇所があれば指摘してください」
Cursorは、CTE（共通テーブル式）やサブクエリごとにロジックを分解し、「ここではユーザーの購入履歴を集計しています」「ここでは在庫がない商品を除外しています」といった具合に説明してくれます。
この時点で、「なんだ、意外と単純なことをやっているだけか」と気づくことも多いものです。未知への恐怖が、既知の課題へと変わる瞬間です。
実行計画（Explain）の読み解きをAIに依頼する
次に、パフォーマンス改善の定石である「実行計画（EXPLAIN）」の分析を行います。しかし、データベースが出力する生の実行計画は非常に読みづらく、専門知識がないと解読は困難です。
ここでCursorの出番です。実際のDBで EXPLAIN ANALYZE を実行した結果（JSONやテキスト形式）をコピーし、Cursorのチャットに貼り付けます。
プロンプト例：
「このクエリの実行計画結果を貼り付けます。どの処理が最もコストがかかっているか特定し、具体的な改善案（インデックス追加やクエリ書き換え）を3つ提案してください。それぞれの案について、副作用のリスクも併せて教えて」
「副作用のリスク」を聞くのがポイントです。「インデックスを追加すると書き込み速度が若干低下します」や「この書き換えを行うと、NULLの扱いが変わる可能性があります」といった、専門的な視点を提供してくれます。
段階的なリファクタリングの提案を受ける
いきなり完成形を求めると、元のロジックと乖離するリスクがあります。Cursorには「Composer」という機能（Cmd+I / Ctrl+I）がありますが、複雑なSQLの場合は、まずはチャットで方針を固めてから、小さな単位で修正を適用することをお勧めします。
例えば、「まずはサブクエリをCTE（WITH句）に書き換えて可読性を上げるだけにして。ロジックは絶対に変えないで」と指示します。可読性が上がれば、人間がレビューしやすくなり、その後のロジック改善も安全に進められます。
Scene 2：失敗しないデータベース設計の「壁打ち」パートナー
既存コードの修正だけでなく、新規機能開発におけるデータベース設計でもCursorは強力なパートナーになります。ここでは、設計ミスを未然に防ぐ「壁打ち」としての活用法を紹介します。
要件定義書からER図のドラフトを起こす
自然言語の要件からスキーマを提案させるのは、LLM（大規模言語モデル）の得意分野です。
プロンプト例：
「ECサイトの定期購入機能を実装したい。ユーザーは複数の商品を異なるサイクル（週次、月次）で定期購入できる。また、一時的なスキップや解約も可能にしたい。必要なテーブル構造（PostgreSQL向け）をDDLで提案して。ER図の構造もテキストで説明して」
これだけで、subscriptions, subscription_items, delivery_schedules といったテーブル案が出てきます。しかし、ここからが本番です。AIが出した最初の案は、たいてい「動くけど拡張性がない」ものです。
正規化の漏れやインデックス設計の不備を指摘してもらう
出てきたスキーマ案に対して、あえて批判的な視点でレビューを依頼します。
プロンプト例：
「提案ありがとう。でも、これだと将来的に『商品の価格が変わった場合』に、過去の注文履歴の金額まで変わってしまう恐れがない？ 履歴データを正しく保持するための設計に修正して。あと、検索頻度が高いと思われるカラムにインデックスを貼って」
このように、人間が気づいた懸念点をぶつけることで、AIはより堅牢な設計へと修正してくれます。一人で考えていると見落としがちな「正規化の崩れ」や「履歴管理の観点」を、対話を通じて補完していくのです。
将来の拡張性を見越した「意地悪な質問」をAIに投げかける
設計の質を高めるために、よく「意地悪な質問」をAIに投げかけます。
- 「ユーザー数が1000万人に増えたら、この設計のどこが最初に破綻する？」
- 「多言語対応が必要になったら、どのテーブル修正が必要になる？」
- 「このステータス管理で、デッドロックが起きる可能性はある？」
これらは熟練のエンジニアが設計レビューで行う指摘そのものです。Cursorを相手にこの壁打ちを行うことで、実際のレビュー前に設計品質を飛躍的に高めることができます。
AIの「知ったかぶり」を防ぐ：人間が握るべき最終ハンドル
ここまでAIの活用法を述べてきましたが、最も重要なことをお伝えします。それは「AIを盲信するな」ということです。特にSQLにおいて、AIのハルシネーション（もっともらしい嘘）は致命的なデータ破損につながります。
ハルシネーションを見抜くコツ
AIは自信満々に存在しない関数を使ったり、間違った構文を提案したりすることがあります。特に、使用しているDBのバージョン特有の機能については間違いが多いです。
対策として、必ずCursorの「Docs」機能（@Docs）を活用しましょう。公式ドキュメント（PostgreSQLやMySQLのマニュアルなど）をCursorにインデックスさせ、それを参照元として指定します。
プロンプト例：
「@PostgreSQL_Docs を参照して、バージョン14で利用可能な機能のみを使ってクエリを修正してください」
これにより、存在しない関数を使われるリスクを大幅に低減できます。
テストデータ生成機能を使った検証の自動化
生成されたSQLが正しいかどうか、本番データで試すわけにはいきません。そこで、検証用のテストデータ生成スクリプトもCursorに書かせましょう。
プロンプト例：
「このSQLを検証したいので、エッジケース（境界値）を含んだテストデータを100件分INSERTするPythonスクリプトを書いて。NULLのケースや、日付が未来のケースも含めて」
検証環境でこのスクリプトを実行し、実際にクエリを流して結果を確認する。ここまでやって初めて、そのSQLは「安全」と言えます。テストコードを書く手間をAIが肩代わりしてくれるため、これまで億劫だった「しっかりとした検証」が手軽に行えるようになります。
コミット前の「人間によるダブルチェック」リスト
最後に、コードをマージする前のチェックリストです。
- 破壊的変更の確認:
DROP,TRUNCATE,DELETEが予期せぬ場所に含まれていないか。 - トランザクション: 複数の更新処理がある場合、
BEGIN~COMMIT/ROLLBACKで囲まれているか。 - WHERE句の漏れ: 更新・削除処理に適切な絞り込み条件があるか。
これらは、AIがいかに進化しても、最後は人間が責任を持って確認すべき項目です。「AIが書いたから」は免罪符にはなりません。
結論：AIはあなたの仕事を奪うのではなく、不安を取り除く
SQLの最適化やデータベース設計において、Cursorは強力な武器になります。しかしそれは、エンジニアの仕事を奪うものではありません。むしろ、「壊すかもしれない」という不安を取り除き、エンジニアが本来向き合うべき「どうあるべきか」という設計思考に集中させてくれるツールです。
「恐る恐る修正」から「確信を持った改善」へ
一般的な傾向として、Cursorを適切に活用することで、レガシーコードへの心理的抵抗が劇的に下がるケースが多く見られます。「分からなければAIに聞けばいい」「リスクもAIと一緒に洗い出せばいい」と思えるようになるからです。
結果として、これまで放置されていたボトルネックが解消され、システム全体の健全性が向上する事例も少なくありません。これは、単なる作業効率化以上の価値をもたらします。
明日から試せる小さな第一歩
まずは、手元のプロジェクトにある「一番読みたくない長いSQL」をCursorに読ませてみてください。そして、「これ、わかりやすく説明して」と話しかけてみてください。
そこから始まる対話は、孤独なデバッグ作業から解放し、頼れる相棒とのペアプログラミングへと導いてくれるはずです。
チーム全体での導入方法や、より具体的なセキュリティ設計、あるいは複雑に入り組んだレガシーシステムのモダナイズ戦略については、専門的なリソースを参照することをおすすめします。AIツールは導入して終わりではなく、どう使いこなすかが重要です。現場の課題に即した現実的な「AIとの付き合い方」を検討しましょう。
コメント