Cursor使ってみてます - ユニファ開発者ブログ

こんにちは。ユニファで開発している安田です。今回の記事はここ数ヶ月Cursorを使用してみての経験や考えていることなどを秋も近づいているので、まとめてみようと思います。

ユニファ開発者ブログではCursorなどのAIに関する記事が既に沢山あるのでまずはそちらを読んでいただけると嬉しいです！

tech.unifa-e.com

はじめにこの記事への期待値を調整しておきます

この記事で書かないこと

細かいCursorの技術仕様について

この記事で書くこと

この数ヶ月の間のCursorの用途がどんなものであったのか。
現時点で何をやっているのか。今後どうしたことをやっていきたいか。

この数ヶ月の間のCursorの用途について

元々弊社の開発チームでこれからAIエディタを使ってみよう！という話が出て、エディタを選択するタイミングがあったのですが、どれが一番いいかその時自分は判断できなかったので、connpass という勉強会のサイトからいくつかのAIエディタに関する開発者向けのイベントに参加してみて「使っている人が多い。学習リソースが見つけやすい」と感じたのでCursorを選択させていただくことにしました。

使いはじめてから1〜3ヶ月間の用途

それぞれのリポジトリで文字列修正系のものなど小さな指示や、調査系の影響範囲や既存コードの理解について依頼を投げてどういう結果になるか確認を繰り返し、結果をファイルに出力してもらう
期待値と違うものが出てきた時は、修正が正しいものになるまでやり取りを繰り返して、なぜ最初から最終的な変更に近い修正が入れられなかったのかについてを確認し、その内容をプロジェクトのルールファイルに次に同種の作業をして貰うときに同じミスをしないために追記して貰うということを繰り返す。

なれてきた頃

チーム内でネックになりつつあった運用作業についてCursorに修正方針を伝えた上で、詳細調査と骨組みをまとめてもらい、それを軸に少しづつ作ってもらえた

画面のあるリポジトリ・・・既存コードとモデルの理解から依頼し、それに対する環境制限をつけた上で一覧画面、新規作成画面、編集画面を追加したいという順番で依頼した。

画面から呼び出されるapi関係のリポジトリA・・・既存コードからシンプルに今回の追加分についてのコードを生成して貰えたのですんなり完了。

画面から呼び出されるapi関係のリポジトリB・・・各クラスの構成についての情報を与えなかったので最初は意図するコードを書いて貰えなかったが、条件を指定したらほしい内容のアウトプットを出して貰えたので苦労しなかった。

画面のあるリポジトリは認証部分の解釈がCursorにうまく伝えられずに完成まで本体コードとユニットテストの両面でやり取りが比較的頻繁に必要だったが、それ以外の２つのリポジトリは片手で足りる程度のやり取りで期待するものを作って貰えた。

結果として2箇所チームメンバーからのPRレビューで指摘をいただいたが、コードレビューの時間もそこまでチームの負担をかけずにクリアした。

Cursorとやり取りをして修正した後、rspecを実行して失敗したテストについても修正依頼を出していた。

ここがクリアできないと、Cursorに依頼できる作業には限界があると思っていたのでユニットテストの実行環境についてはこだわって何度も試行錯誤していた。失敗したテストについて何で失敗するコードを書いたのかを確認し、それをまたテスト実行用のファイルに気を付ける項目として追記してもらっていた。こういうテストコードは書かないでほしいというものも手動でプロジェクトルールへ追記していた。

チームで共有しているリポジトリでプロジェクトルールを管理することについての意見収集などもはじめていた

現時点で何をやっているのか。

複数のリポジトリに対して複数windowを開いて、それぞれ作業を依頼することは継続。

でもこれは作業内容を頭で理解できている範囲内でどこで何をやったらいいかに基づいて指示をそれぞれで出しているだけなので、全くの白紙で１つのチケット内容の中でこのリポジトリではこれをやらないといけないといった自動でCursorが作業範囲を決めるというところまでできているわけではない。

例えばapiサーバのリポジトリであれば「このapiのxxxという機能を追加してほしい。機能を追加したらテストを追加し、rspecを流してほしい。」というようなものを出している。リポジトリの関係性を表すようなものを共通でどのwindowでも参照できるように用意できれば該当リポジトリではこれをやる、ということを自動で出してもらえるかもしれないが、まだこの部分は検証もできてないので今進行中のことの結果を見てまた考える。

gitのworktree機能を使えば複数の開発ブランチに対して同一リポジトリで別windowを開きCursorへ指示を出せることがわかったので効率を上げるために最近取り入れた
Cursorにコミットまで進めて貰うイメージがついてきたので、Cursor用のコミット関係のルールについてチーム内で追加検討中

コミット関係のルールの一部でこだわってるところは、

* コミットの粒度に対しての期待値を明記していること

* Conventional Commitsに沿うが、今のチームにあったカスタムを加え、いらないものは不要と書く。

# .cursor/rules/commit-message-rule.mdc

.....中略.....

## チェックリスト
- [ ] 追跡番号が footer の先頭行にあるか（例: `Refs: ticket-xxxx`）
- [ ] 追跡番号の指定がなかった場合、コミット前に依頼元へ確認したか
- [ ] 単一論点・小さな単位のコミットになっているか（複数修正を混在させない）
- [ ] Cursor 実行のコミットであれば `Committed-by: Cursor` をフッター末尾に付記したか
## Cursor への指示
- 判断に迷う場合（type/scope/subject など）は、ユーザーに確認を入れてから提案を確定すること
- 追跡番号が未提示の場合は、コミット前にユーザーへ確認し、提供された場合は footer の先頭行に配置すること
- コミットは単一論点・小さな差分で提案し、混在が見られる場合は分割案を提示すること
- Closes/Fixes/Resolves は使用しない。関連付けは Refs のみとすること
- Cursor がコミットを実行する場合は、フッター末尾に `Committed-by: Cursor` を必ず付記すること
 - ブランチポリシー: `master`, `main`, `release*`（`release/` などを含む）へのコミットは禁止。該当ブランチ上にいる場合はユーザーへ確認し、機能ブランチ（例: `feature/...`, `fix/...`, `hotfix/...`）の作成・切替を提案してからコミットすること

整備を検討していた「プロジェクトルール ( .cursor/rules/* )」について修正頻度の高い特定のリポジトリに関して優先してチーム内で導入を検討中

rspec実行用のルールファイルについて一部記載します。こだわってるところは、

* チームメンバーが扱いやすいように日本語版と英語版をルールファイルとして用意し、一方への編集がある場合は、他方へも同期させていくようにしている点。

* こちらの返事を待たずに進められることを期待したルール設計。

# .cursor/rules/rspec-execution-and-auto-fix-rule-ja.mdc
このリポジトリは、docker環境で開発しています。
docker 環境で RSpec を実行する場合は、以下のように実行します（内部固有名はプレースホルダーで記述）。

.....中略.....

## コンテナの中に入ったら、以下の手順でRSpecを実行する：
### 1. 修正したファイルに関係するテストファイルのRSpec実行
（注）直近の修正に対応するテストファイルが存在しない場合、このステップはスキップして構いません。
## bundle exec rspec {{修正したファイルに関連するテストファイルのパス}}
#### 実行テンプレート（任意のテストファイルに置換して使用）

# 単一ファイルを実行
bundle exec rspec [SPEC_PATH] --format progress
# 行を指定して再実行（例：失敗行）
bundle exec rspec [SPEC_PATH]:[LINE] --format progress


### 2. RSpec失敗時の自動修正プロセス（最大3回まで自主的に実行）
RSpecが失敗した場合、以下の手順を最大3回まで**指示を待たずに自主的に**繰り返す：
#### 2-1. 失敗内容の分析（即座に実行）
- エラーメッセージを詳しく分析
- 失敗の原因を特定
- **分析完了後、即座に次のステップに進む**
#### 2-2. 自動修正の実行（即座に実行）
- テストコードまたは本体コードを修正
- 修正内容を説明
- **修正完了後、即座に次のステップに進む**
#### 2-3. 修正後の再実行（即座に実行）
## bundle exec rspec {{失敗したテストファイルのパス}}:{{失敗した行番号}}
または
## bundle exec rspec {{失敗したテストファイルのパス}}
- **実行完了後、結果に応じて即座に次のアクションを決定**
#### 2-4. 3回目でも失敗した場合（即座に実行）
- 試した修正内容をまとめて報告
- 残る原因の可能性を分析して報告
- **ユーザーに追加の指示を求める（ここで初めて待機）**
### 3. 全体テストの実行（即座に実行）
修正したテストが通るようになったら、**即座に**全体のRSpecを実行：
## bundle exec rspec
- **実行完了後、結果に応じて即座に次のアクションを決定**
### 4. 他のファイルの失敗時の対応（即座に実行）
全体テストで他のファイルが失敗した場合、**即座に**2の手順を実行する。
## 重要な注意事項
- **指示を待たずに自主的に修正を繰り返す（最大3回まで）**
- **各ステップは即座に実行し、途中で待機しない**
- 修正内容は必ず説明する
- 3回目でも失敗した場合は、試したことと残る原因の可能性を報告する
- **ユーザーの指示を待つのは、3回目でも失敗した場合のみ**
- コンテナ内ではdockerコマンドは使用しない
- **成功した場合は、全体テストまで一気に実行する**

.....中略.....

## 🔄 同期に関する注意
**重要**: この日本語版を更新する際は、英語版（`rspec-execution-and-auto-fix-rule-en.mdc`）も更新して両ファイルを同期させてください。両言語間で内容が同等になるようにしてください。

注意）ここで記載した抜粋内容はまだチーム内でレビューを進めている段階なのでそのまま使用した場合の動作に関する保証はありません。あらかじめご了承ください。