Cursorに対する4つの疑問に、元Webアプリエンジニアのデータアナリストが答えます

「AIエディタって話題だけど、結局、自分で書いたほうが確実でしょ？」
「GitHub Copilotで十分満足してるし……」
そう思っている方にこそ、伝えたいことがあります。

こんにちは、データアナリストの大橋です。
私は9カ月前までWebアプリエンジニアとして、PHPStorm × GitHub Copilotを使って開発をしていました。
その後データアナリストに転身してSQLが中心になり、ふと悩んだのが 「どのエディタを使うべきだろう？」 ということです。
そんなとき、他のデータアナリストのメンバーが導入したのがCursorでした。

実際に使ってみて確信したのは、「これは補完ツールではなく、頼れるペアプログラマーだ」ということです。

ここからは、私がCursorを手放せなくなった理由を、よく聞かれる4つの疑問に答える形でまとめます。

Q1. 「結局、自分で書いた方が早くない？」

A. タイピングは早くても、整形と思考を含めるとAIが有利です。

確かに、単純なクエリを打つだけなら手作業も早いです。しかし、AIを使うメリットは「並列処理」と「ルールの自動適用」にあります。

思考の先取り

私が「このテーブルとあのテーブルを結合して……」と指示を出し、Cursorが数十行のSQLを生成している数秒間。私はただ待っているわけではありません。
「次はあのマスタも結合しないと」と、次にやるべき思考や設計の時間に充てています。手を動かす作業をAIに任せ、人間は脳を動かすことに集中できるのです。

暗黙のルールも勝手に整形

さらに、チームのコーディング規約への自動修正です。 Cursorは自動的に「予約語は大文字」「インデントは4スペース」といったチームのルールに従って整形してくれます。

デバッグも丸投げ

さらに、エラーが出た時も自分で悩みません。エラーログをそのままCursorに投げれば、「カンマが抜けています」「GROUP BYの項目が足りません」と即座に修正してくれます。

説明コストを削減

複雑なSQLを書いた後、ドキュメントに残したり他人にわかりやすく説明したりするのも意外と時間を取られる作業です。
私はクエリ作成後に「このクエリの概要をまとめて」と一言投げています。すると、「目的」「使用テーブル」「出力形式」等をMarkdownで即座に出力してくれます。
書く手間だけでなく、未来の自分や他のメンバーがコードを読み解く時間を節約できるのです。

Q2. 「AIに頼りすぎるとスキルが落ちるし、そもそも信用できないでしょ？」

A. だからこそ「ペアプロ」として使うと効果が最大になります。

レビュアー視点が育つ

おっしゃる通り、AIのコードを無条件に信用するのは危険です。

「JOIN条件は妥当か」「パフォーマンスに問題はないか」
実はこの確認作業が、スキルアップに繋がります。

「信用できないからこそ、しっかりレビューする」。 この緊張感ある関係性こそが、品質を高め、私自身の「見る目」も養ってくれています。

また、コーディングルールをMarkdownファイルとして定義しておくことで、自分のコードはもちろん、他のメンバーのコードレビューにもAIを活用できるようになります。

自分の知識の幅が広がる

また、AIの提案を見て「へぇ、そんな方法もあるんだ」と気付かされることも多々あります。
自分一人では思いつかなかったアプローチに触れることで、結果として自分の知識の引き出しが増えていくのも大きなメリットです。

Q3. 「複雑な指示を出すと、意図と違うコードにならない？」

A. 「分割」と「確認」で劇的に改善します。

「あれもこれもやって」と一度に指示すると、Cursorも混乱して変なコードを書くことがあります。これはAIの性能不足というより、指示の出し方の問題で、私は以下の2点を気を付けています。

大きな変更は分割する

「リファクタリングしてバグも直して」ではなく、「まずはCTE（共通テーブル式）に書き換えて」→「次に日付のバグを修正して」と、ステップ・バイ・ステップで依頼します。

不明点の事前確認

指示の最後に「不明な点はありますか？」と付け加えます。
するとCursorは、いきなりコードを書くのではなく、「1. 抽出条件に使うカラムは〇〇でよろしいでしょうか？」「2. NULLの扱いはどうしますか？」と逆質問をしてくれます。この「認識合わせ」を挟むだけで、意図とのズレはほとんどなくなります。

Q4. 「複雑な指示や、大量の修正は結局手作業では？」

A. それこそAIの出番。「手順書」作りから任せれば簡単です。

大量の単純作業も自動化できます。 例えば「カラム変更に伴い、関連する50個のクエリを修正する」といった作業があるとします。

計画立案

まずはCursorに「これらを一括置換するための手順書（Markdown）を作って」と依頼します。 私が手順書をレビューし、「OK、この手順をファイルに保存して」と指示を出す。

実行

Cursorのチャットに@対象ディレクトリ @手順書.mdと投げるだけで修正を開始してくれます。

人間は「手順の承認」を行い、実際の作業はAIがやる。 そして最後にまた人間がレビューする。この役割分担ができると、業務効率が向上します。

おまけ：Cursorの文脈理解を支えるディレクトリ構成

Cursorがプロジェクト全体の文脈を理解したり、一括修正ができたりするのは、私たちが分析用クエリもシステム開発と同じようにGitリポジトリで管理しているからです。

以下に、実際のディレクトリ構成（ワークスペース）を共有します。

analysis_cursor/
├── .cursor_rules/                # 詳細なルール定義（Cursor Rules）
│   ├── naming-and-structure.mdc  # ディレクトリ構成や命名規則の定義
│   └── sql-style.mdc             # SQLのスタイルガイド（Q1の自動整形はここを参照）
├── docs/                         # 手順書・ドキュメント
│   └── TDtoBQ_conversion.md      # TreasureDataからBigQueryへの移行手順書
├── queries/                      # 分析クエリの置き場
│   ├── Dataform/                 # データソースを作るためのSQL
│   └── project/                  # 担当プロジェクト単位で分類
└── tools/                        # 各種ツール
    ├── tool_BQ_dryrun.py         # BQのドライランを実行
    └── tool_review_query.md      # レビュー観点指示書

このようにファイルが構造化されているため、Cursorはプロジェクト全体の依存関係を読み取ったり、他のクエリを参考にして提案することができるのです。

さいごに

使い慣れたツールを変えるのは勇気がいります。 PHPStormやVS Code、Copilot、Geminiなど、それぞれに良さがあり、正解は一つではありません。

ただ一つ言えるなら、「食わず嫌いでAIを遠ざけてしまうのはもったいない」ということです。

• ルールを覚えるのが面倒
• 文脈理解が欲しい
• 単純作業から解放されたい

もし一つでも当てはまるなら、ぜひ一度、Cursorでも他のツールでも良いので試してみてください。

オープンワークでは、セキュリティ基準をクリアした認可ツールを積極的に取り入れ、「AI活用による生産性向上」を推進しています。
この記事を読んでオープンワークに少しでも興味を持った方は、ぜひ採用サイトもご覧ください。

www.openwork.co.jp