🤖
Cursorで何をしていますか？開発効率は上がりましたか？

hosoy
2025/06/04に公開
Cursorで何をしているか・使ってみて開発効率が上がったのか、社内で少し話す機会があったので振り返ってみました。

私がCursorを使い始めたのが今年の4月頃からなので、使用2ヶ月ほどの振り返りです。

 ちゃんとCursorのAI機能使ってた？まずそもそもCursorのAI機能を使ってたのか、ただのVSCodeとして使ってたのか確認しました。


ちゃんとAI機能つかってました。チャット機能はほぼエージェント機能を使ってます。



使用言語はプロジェクトで使用している全ての言語がリストアップされていたので、フロント・バックエンド問わずCursorを活用していたみたいです。


 Cursorのエージェント機能で何をしていた?
 エラーの原因特定とコード修正まちがいなく、これがトップだと思います。
ビルドエラー
Sentryでキャッチしたエラー（不具合、バグ）
開発中の機能において、期待と異なる動作をしている
例えばVueでフロントエンド開発をしているときに、エラーがでた場合にCursorにこのように投げかけます。

Cursorがエラーの原因を特定して、修正案を提示してくれます。
エラーの原因は、hogehoge.vue ファイルの huga 関数内で、fooRepository.bar メソッドを呼び出す際に、引数として渡している ob オブジェクトのプロパティ名の大文字・小文字が間違っているためです。
具体的には、エラーメッセージ RequiredError: Required parameter p3 was null or undefined when calling hogefuga. が示すように、hogefuga 関数に必要な p3 パラメータが null または undefined として渡されています。
...
この問題を修正するために、hogehoge.vue の該当箇所を以下のように修正します。
...
エラーの内容としては単純ですが、自力で原因を探して修正するよりもCursorに原因調査を依頼したほうが間違いなく早いです。

ただ、Cursorにコード修正を依頼したときに時間がかかりすぎている場合はキャンセルして自力で修正することも少なくないです。
コードの修正以外にも、例えばGitHub Actionsの実行時に発生したエラーの原因も教えてくれます。

Cursorの回答
...
deploy.yaml の内容から、ワークフローは staging ブランチへのプッシュでトリガーされています。この staging ブランチからのアクセスが、Google Cloud側で許可されているか確認する必要があります。
以下の手順でGoogle Cloud Consoleの設定を確認してください。
1. Google Cloud Console にログインします。
2. [IAMと管理] > [Workload Identity連携] に移動します。
3. エラーが発生しているプロジェクトに関連付けられた Workload Identity プール を選択します。
4. プール内の、GitHub Actions用に設定した プロバイダ を選択します。
5. プロバイダの構成ページで、属性条件 (Attribute condition) の設定を確認します。
...
見慣れないエラーの原因調査は時間がかかりがちなので、Cursorがエラー原因と対応方法を教えてくれるのは本当に助かります。

 実装の依頼や相談どういうことをやりたいか、コードの中に詳しくコメントで書いておいてあとはエージェント機能に任せます。Cursorへの投げ方は雑ですが、これでコードを書いてくれます。

もしくはチャット機能で指示する場合もあります。以下はCursorにマイグレーションファイルを作成してもらっています。

変数名に迷った場合はCursorに意見を聞きます。



Cursorの回答
日本語の変数名として「最後にレコードを取得した日時」を表す場合、lastFetchTime と latestFetchTime のどちらも意味合いは近いですが、ニュアンスに若干の違いがあります。
lastFetchTime: 「最後に取得した時間」という意味合いが強いです。一連の取得処理の中で、最後のものを指すイメージです。
latestFetchTime: 「最新の取得時間」という意味合いが強いです。これまでに取得した時間の中で、最も新しいものを指すイメージです。
...
私が所属しているプロジェクトは複数の言語を扱うので、この言語でこの処理はどうやって書くんだっけというケースがしょっちゅうあります。例えばTypeScriptでフィルター処理ってどう書くか忘れたときにネットで検索するよりも、CursorにhogeListからhugaFlagがFalseの値を除外するフィルター処理を書いてくださいと依頼するほうが早いと感じます。

 テストデータの生成テストデータをjsonファイルで管理しているのですが、
ファイルをコピーして
uuidを生成してidを置き換え
created_atを現在時刻（UTC）に置き換え
以上の処理をCursorにやってもらっています。同じ処理を何回も実行して1スレッドあたりのやり取りが増えてきた場合など、処理の途中で止まることがあるので、これらの処理を実行するシェルスクリプトをCursorに作ってもらったほうが効率的かもしれません。

 Cursorを使用するうえで気をつけていることCursorが提案・修正したコードを100%鵜呑みにしないことです。一通り目を通し、疑問を持った場合は〇〇の処理は必要ですか、とCursorに確認をいれます。実装の内容によっては新しくライブラリやモジュールを導入しようとしたり、導入済みライブラリやモジュールのバージョンを勝手に上げようとすることがあるので、生成されたコードの確認は必須だと感じています。

コードの内容に問題がなければAcceptして動作確認を行うという手順で開発しています。

 結論：Cursorの導入によって開発効率は上がった。無いと困る。開発業務の大半を占める（と感じている）エラーの原因調査と修正にかかる時間が大幅に短縮されたことは、私にとってかなり大きなメリットです。Cursorに限らずAIコードエディタが業務で使えなくなってしまうと本当に困ってしまいます。

私はCursorをフル活用できているわけではありませんが、それでも十分に恩恵を感じられているので、もしAIコードエディタの使用を迷っているようであれば少し触ってみるのをおすすめしたいです。