Cursorを1ヶ月ガチで使った結果 — 開発速度は本当に上がるのか？【エンジニア体験記】

はじめに — なぜCursorに乗り換えたのか

正直に言う。最初は「また新しいAIツールか」くらいの感覚だった。

2026年2月まで、私の開発環境はVS Code + GitHub Copilotで完全に固まっていた。Copilotの補完には満足していたし、わざわざエディタごと変える理由が見当たらなかった。

きっかけは、チーム内のテックリードが「Cursorに変えてからPRのマージ速度が体感1.5倍になった」と言い出したことだ。体感ではなく数値で示してほしいと思ったが、同時に気になった。本当にそこまで変わるのか？

そこで、2026年2月17日から3月17日までの1ヶ月間、実務のすべてをCursorに切り替えて検証することにした。この記事は、その1ヶ月間の記録だ。

導入前の状況を整理する

まず前提条件を明確にしておく。

• 使用言語: TypeScript（Next.js）、Python（FastAPI）
• チーム規模: 4人のバックエンドチーム
• 従来環境: VS Code + GitHub Copilot Business
• 担当領域: API設計・実装、コードレビュー、テスト設計
• 経験年数: エンジニア歴7年

Copilotには十分満足していた。タブ補完は高精度だし、Copilot Chatも調べ物には便利だった。ただ、ファイルを横断した大きな変更や既存コードを踏まえたリファクタリングでは物足りなさを感じていたのも事実だ。

Cursorがその部分を埋めてくれるのか。それが今回の検証テーマだった。

1週目: 導入と初期設定 — 思ったより移行はラク

セットアップは拍子抜けするほど簡単

CursorはVS Codeベースのエディタだ。つまり、VS Codeの拡張機能・設定・キーバインドをほぼそのままインポートできる。

実際にやったことは以下の3ステップだけだった。

1. Cursorの公式サイトからインストール
2. 初回起動時に「VS Codeから設定をインポート」を選択
3. Cursor Pro（月額$20）のサブスクリプションを開始

所要時間は15分程度。拡張機能も含めて、ほぼ完全に移行できた。ESLint、Prettier、GitLens、Docker拡張など、普段使っているものはすべてそのまま動いた。

第一印象: Cmd+Kの衝撃

最初に驚いたのは**Cmd+K（インラインエディット）**だ。

コードを選択して「この関数をエラーハンドリング付きにリファクタして」と日本語で指示するだけで、その場でコードが書き換わる。Copilotのインライン提案とは根本的に違う。Copilotが「次の1行を予測する」のに対して、Cursorは「意図を理解してブロック単位で書き換える」。

もうひとつ印象的だったのが**Cmd+L（チャットパネル）**のコンテキスト理解力だ。開いているファイルだけでなく、プロジェクト全体のコードベースを参照した上で回答してくれる。「このAPIのレスポンス型を変更したら、影響を受けるファイルを全部教えて」という質問に、正確なファイルリストが返ってきたときは素直に感動した。

1週目の生産性: ほぼ変化なし

ただし、1週目の生産性はほぼ変わらなかった。理由は単純で、操作に慣れていなかったからだ。

Cmd+Kを使うべき場面でつい手動で書いてしまったり、チャットへの指示が曖昧で意図しないコードが生成されたりと、試行錯誤の時間が発生していた。新しいツールの導入には必ずこの「慣れコスト」がかかる。

2週目: 本格的に実務投入 — 「これは戻れない」と思った瞬間

Composerが本領を発揮する

2週目に入り、Cursorの真価を発揮する機能に出会った。**Composer（マルチファイル編集）**だ。

ある日、APIのレスポンス構造を変更する必要が出た。影響範囲はAPIハンドラ、型定義ファイル、テストコード、フロントエンドの型定義と、4ファイルにまたがっていた。

従来ならそれぞれのファイルを開いて手動で修正し、型チェックを通し、テストを直すという作業に1〜2時間かかっていた。

Composerに「UserResponseの型にcreatedAtフィールドを追加して、関連するすべてのファイルを更新して」と指示したところ、4ファイルの差分がまとめて提示された。しかもテストコードにも適切なアサーションが追加されている。所要時間は確認と微調整を含めて15分だった。

この瞬間、「VS Codeには戻れないかもしれない」と思った。

.cursorrulesの威力

もうひとつ大きかったのが、プロジェクトルートに.cursorrulesファイルを配置することだ。

# プロジェクトルール
- TypeScriptのstrictモードを前提とする
- エラーハンドリングにはResult型パターンを使う
- テストはdescribe/it形式で書く
- APIレスポンスはcamelCaseに統一する
- コメントは日本語で書く

このファイルを置くだけで、AIが生成するコードがチームのコーディング規約に沿うようになる。Copilotでは毎回「うちのプロジェクトではこういうスタイルで…」と説明する必要があったが、.cursorrulesがあればその手間がゼロになる。

2週目の生産性: 明確に向上

PR作成数が目に見えて増えた。特に「型変更の波及修正」や「ボイラープレートの生成」といった定型的だが時間のかかる作業が劇的に速くなった。

3週目: 壁にぶつかる — AIに頼りすぎる罠

「とりあえずAIに聞く」の危険性

3週目に入って、自分の開発スタイルに違和感を覚えた。

気づけば、まず自分で考える前にCursorに聞くという癖がついていた。ロジックの設計段階からAIに丸投げし、出てきたコードをそのまま採用する。一見効率的に見えるが、いくつかの問題が顕在化した。

問題1: コードの理解度が下がる

AIが生成したコードを「動くから良い」で通してしまうケースが増えた。あるとき、チームメンバーからコードレビューで「この実装の意図は？」と聞かれて即答できなかった。自分が書いたはずのコードなのに、中身を理解していない。これは危険だ。

問題2: 微妙なバグが混入する

AIが生成したコードは「だいたい正しい」が、エッジケースの考慮が甘いことがある。3週目だけで、AIが生成したコードに起因するバグを3件見つけた。いずれもnullチェックの漏れや、非同期処理の競合状態といった「一見動くが特定条件で壊れる」タイプのバグだった。

問題3: 設計力の低下

最も危惧したのがこれだ。AIに頼りきりになると、自分でアーキテクチャを考える筋力が衰える。短期的な生産性と引き換えに、エンジニアとしての成長を止めてしまう可能性がある。

コードレビューでの指摘が増加

3週目のコードレビュー指摘数は、導入前と比べて約1.4倍に増えた。速く書けるようになった分、レビューの質に対する意識が薄れていたのだ。

4週目: 最適な使い方が見えてきた

「AIは下書き、人間は編集長」モデル

3週目の反省を踏まえ、4週目はCursorの使い方を意図的に変えた。

確立したのは**「AIは下書き、人間は編集長」**というメンタルモデルだ。具体的には以下のルールを自分に課した。

1. 設計は自分で考える: アーキテクチャ、データフロー、責務の分割は必ず自分の頭で設計する
2. 実装の下書きをAIに任せる: 設計が決まったら、具体的な指示とともにCursorに実装を依頼する
3. 生成されたコードは必ず読む: 1行ずつ理解してから採用する。理解できないコードは書き直す
4. テストは自分で設計する: テストケースの設計（何をテストするか）は自分で考え、テストコードの記述をAIに任せる

このルールを導入してから、生産性を維持しつつ、コード品質も安定するようになった。

Cursorが特に威力を発揮する場面

4週間の経験から、Cursorが真価を発揮する場面が明確になった。

• 既存コードのリファクタリング: コンテキストを理解した上でのリネームや構造変更
• テストコードの記述: テスト設計さえできれば、記述はAIが圧倒的に速い
• ボイラープレートの生成: CRUD APIのハンドラ、型定義、バリデーションなど
• ドキュメントの生成: JSDoc、APIドキュメント、READMEの下書き
• デバッグの補助: エラーメッセージを貼り付けるだけで原因と修正案を提示

逆に、AIに任せるべきでない場面もはっきりした。

• アーキテクチャの設計判断
• ビジネスロジックの核心部分
• セキュリティに関わる実装
• パフォーマンスが重要な処理の最適化

定量データ: 数値で見る1ヶ月の変化

ここからが本題だ。1ヶ月間の定量データを、導入前の1ヶ月間（2026年1月17日〜2月16日）と比較する。

PR（プルリクエスト）数の変化

期間	PR数	1日あたり
導入前（1月）	23件	約1.15件
1週目	5件	約1.0件
2週目	8件	約1.6件
3週目	9件	約1.8件
4週目	8件	約1.6件
導入後合計	30件	約1.5件

PR数は約30%増加した。特に2週目以降、Composerを使いこなせるようになってからの伸びが顕著だ。

コミット数の変化

期間	コミット数
導入前（1月）	87件
導入後（2〜3月）	118件

コミット数は約36%増加。ただし、これはAIが生成したコードを小まめにコミットする習慣がついたことも影響している。単純に「たくさん書いた」とは言い切れない。

コードレビュー指摘数の変化

期間	指摘数	PR1件あたり
導入前（1月）	31件	1.35件
1〜2週目	15件	1.15件
3週目	17件	1.89件
4週目	8件	1.0件

3週目にレビュー指摘が急増した経緯は前述の通りだ。しかし4週目にはPR1件あたりの指摘数が導入前を下回った。.cursorrulesによる規約の自動適用と、「AIは下書き、人間は編集長」モデルが効いた結果だと考えている。

体感ベースの変化

数値には表れにくいが、体感として大きかった変化も記録しておく。

• 「型変更の波及修正」の所要時間: 1〜2時間 → 15〜30分（50〜75%短縮）
• テストコードの記述時間: 約40%短縮
• 新規API実装の初動速度: ボイラープレート生成により約60%短縮
• ドキュメント作成: ほぼゼロコストに（AIが下書きを生成し、修正するだけ）

結論: 開発速度は上がったか？

結論: 上がった。ただし条件付きで。

定量的には、PR作成数が約30%増、コミット数が約36%増。体感ベースでは、定型的な実装作業の速度が50〜75%向上した。1ヶ月トータルで見れば、開発速度は確実に向上したと言える。

ただし、重要な条件がある。

「AIの使い方を自分で設計できること」が前提だ。

3週目に経験したように、AIに丸投げすると品質が下がり、結果的にバグ修正やレビュー対応で時間を取られる。Cursorの恩恵を最大化するには、「どこをAIに任せ、どこを自分で考えるか」の線引きが必要だ。

この線引きができるエンジニアにとって、Cursorは間違いなく最強のツールだ。逆に、この線引きができないまま使うと、短期的には速くなっても中長期的にはマイナスになりうる。

こんな人にはおすすめ

• 実務経験3年以上のエンジニア: コードの良し悪しを自分で判断できる人
• TypeScript / Python をメインで使う人: Cursorのコンテキスト理解はこれらの言語で特に精度が高い
• リファクタリングやテスト記述に時間を取られている人: 最も効果を実感できる領域
• チーム開発をしている人: .cursorrulesによるコーディング規約の自動適用が非常に便利
• VS Code ユーザー: 移行コストがほぼゼロ

Cursor Proの詳細はこちら（月額$20 / 年額$192）

こんな人にはおすすめしない

• プログラミング初学者: AIが生成したコードの品質を判断できないと、悪い癖がつく
• Vim / Emacs など VS Code 以外のエディタに強いこだわりがある人: 移行コストが大きい
• 機密性の高いコードを扱う人: クラウドベースのAIにコードを送信することへのセキュリティポリシーを確認する必要がある
• 月額$20の投資対効果が見合わない人: 趣味開発がメインで、速度向上の恩恵が小さい場合

おわりに

1ヶ月前の自分に伝えるなら、こう言う。

「Cursorは魔法のツールじゃない。でも、使い方を覚えれば確実に武器になる。大事なのは、AIに何を任せて何を自分でやるかを決めること。その判断力があるなら、今すぐ乗り換えろ。」

AIコーディングツールは今後も進化し続ける。Cursorがその最前線にいることは間違いない。まずは無料プランで試してみて、自分の開発スタイルに合うかどうかを確かめてほしい。

---

この記事は2026年3月時点の情報に基づいています。Cursorの機能・料金は今後変更される可能性があります。