はじめに
自分は現在、バックエンドエンジニアとして、Laravelフレームワークを用いて実装を行っています。
2024年2月あたりからはGitHub Copilotを導入して、PhpStorm + GitHub Copilotみたいな組み合わせで実装を行っていたのですが、2025年7月あたりからは話題になってたCursorに自分も興味があったので、Teamsプランで私も使わせてもらっています。
PhpStorm + GitHub CopilotからCursorに環境を乗り換えて数ヶ月使ってみた感想を両者を比較する形でまとめたいと思います。
結構Cursorを気に入ってしまったので、Cursorの肩を持つような言い回しになっちゃっている箇所がありますが、一個人の感想として参考にしていただけますと幸いですm(_ _;)m
前提
この記事を執筆時点でのバージョンを以下に記載します。
| 開発環境 | バージョン |
|---|---|
| Cursor | [1.7.54] |
| PhpStorm | [2025.1.5] |
| GitHub Copilot | [1.5.59-243] |
| MacBook Pro | [Apple M1, 16GB RAM] |
| macOS | [15.6.1 (24G90)] |
また、CursorのAIモデルはclaude-4-sonnet、もしくはAuto(モデル指定よりレスポンススピード早めモード)、GitHub CopilotのAIモデルはClaude Sonnet 4, GPT-4oを用いることが多かったと思います。
どちらもAskモードではなく、Agentモードについての比較をしていきます。
CursorとPhpStorm + GitHub Copilotを比較
コードリーディングについて
既存の実装の仕様把握などに使うという観点では、Cursorの方が使いやすく感じました。
簡潔にいうと、Cursorは本当に欲しい情報をくれるイメージで、Copilotは欲しい情報が足りなかったり、逆にいらない情報を返してしまい、見辛くなってしまうなどが多いと感じました。
まず、コードリーディングをAIにやらせる際によく送っていたプロンプトの例とレスポンスのざっくりとした例を以下にまとめます。
プロンプト例
「〇〇(機能やドメイン名など)について教えて下さい」
Cursorのレスポンス例↓
フローの説明
ビジネスルール
DBへの影響
バリデーションや制限
関連する箇所のテーブル構造
Copilotのレスポンス例↓
全体概要
主要な機能領域列挙
関連するテーブルのカラム列挙
関連するファイル列挙
関連機能列挙
プロンプトの送り方次第で、Copilotの方のレスポンスもある程度コントロールできるのかもしれませんが、Cursorは割と雑にプロンプト投げてもちゃんと人間が欲しいと思っている情報を返してくれている印象だったので、その点使いやすいです。
コード生成について
コード生成については両者にあまり差は無いように思えました。
ただ、人間が理解して欲しいと思っている仕様を理解するまでの時間はCursorの方が早いと思ったので、若干Cursorの方がプロンプト数は多少、少なくコード生成できる印象でした。
プロンプト例:新たなリポジトリメソッドを作成したい場合
「〇〇という条件に当てはまるユーザーを取得するメソッドを作成して」
Cursorのレスポンス例↓
期待した通りのリポジトリメソッドが生成される
Copilotのレスポンス例↓
少し仕様を勘違いしたレスポンスが生成される
↓
その後、正しい仕様をプロンプト教える
↓
期待した通りのリポジトリメソッドが生成される
コード生成についても割と雑なプロンプトでこちらの意図を汲んでコードを生成してくれます。
テストコードを生成する際も記入するテストファイルに他のコードが既に生成されていれば、そのフォーマットを模倣して書いてくれることが多いです。
またCursorを使ってから僕がよくやっていたのが、テスト駆動でAIに書かせるというやり方です。具体的なやり方は、
1.テストコードをAIに生成させる
↓
2.テストを自分が確認して修正(テストを自分で修正する場合と、プロンプトを修正してAIに修正させる場合両方あった)
↓
3.実装をAIに生成させる
↓
4.自分が最終確認
2の段階で漏れがないテストを書かせることさえできれば、あとは「テストが通るように実装側を書いて下さい」という風に命令して、その後はテストが通るようにリファクタリングを何回かやらせるだけで実装は完了するのでとても楽に実装できました。
ただ、Cursor側で一点困ったのは、 「テストの期待値が完成したので、それが通るように実装側を書いて下さい」 とプロンプトを送り実装側のコード生成後、テストでエラーが起こった場合、 「テストケースが間違えていた可能性があるので、テストを修正します」 というふうに勝手にテストの期待値が間違えたと勘違いしてしまったことです。(実際に期待値は自分の目で確かめてちゃんと合っている事を確認済み)
そのため、Cursor Settings→Rules&MemoriesからCursorに守らせたいルールを設定し、テストでエラーが出た際に勝手に期待値を変えないというルールを追加したところ、100%では無いですが、テスト駆動開発時に期待値を固定して実装側の修正を行ってくれるようになりました。
Rules&Memoriesからルールを追加
UIについて
UIに関して、個人的には2年半ほどPhpStormを使ってきたということもあり、UI面においてはPHPStormの方が好みです。
CursorはVSCodeを元に作られたエディターなので、元々VSCodeを使っていた人なら、UI面での導入コストはほとんどないと言えると思います。
また、VSCodeでの設定や拡張などをCursorに引き継げるらしいです。(私はVSCodeをほとんど使ってなかったので、こちらはやってません。)
Cursor側で一個問題点というかバグっぽいのがあって、AIとのチャット画面を別ウィンドウで開くとチャット欄に何も入力できなくなってしまいます。
例えば、チャット画面をメイン画面とドッキングしている状態は以下の通りです。
この状態ならチャット欄に正常に入力できます。
ドッキング状態ならテキスト入力できる様子
しかし、以下のように別ウィンドウで開くとチャット欄に何も入力できなくなってします。
チャット欄に何も入力できない様子
これの解決法として、個人的に発見できたのは以下の通りです。
- エディターを再起動する(治らない場合が多い)
- 新規チャットを始める
2については、今までのチャット履歴を追うのが面倒になり大変です。
そのため、結局最近は別ウィンドウで開くのはやめてほとんどドッキング状態で使っています。(画面の占有率が多くなってしまい、正直邪魔です。)
ちょっと症状違いますが、チャット欄に入力できないという問題は他の人も抱えてるみたいです↓
まとめ
やっぱり、エディターのUI周りについては、長い間親しんでたという要素も強いかも知れませんが、PhpStormの方が使いやすく感じます。
ただ、Cusorは実装のコードを読ませるという観点と、その仕様を理解した上で新たにコードを生成するという観点において個人的にかなり人間の気持ちを汲んでくれているように感じたので、しばらくはCursorメインで使っていこうかなと思います。
UIに関してはずっと使っていれば慣れるかと思いますしd(￣ ￣)
Discussion