https://tech.smarthr.jp/entry/2025/08/12/153557

こんにちは！新規事業開発チームでプロダクトエンジニアをしているmuranoです。

新規事業開発チームでは、AIを活用した開発効率向上に積極的に取り組んでいます。特に実装フェーズではCursor（AIコードエディタ）を使ってAIのサポートを受けており、2ヶ月間の試行錯誤を経て、とてもいい感じのプロジェクトルールを作ることができました🐶

そこで今回は、作成したRailsプロジェクト向けのCursorプロジェクトルールをテンプレートとして公開し、その背景にある2ヶ月間の取り組みや知見も合わせて共有できればと思います。Railsの開発をしていてこれからCursorを導入したい方に、ぜひ参考にしていただけたら嬉しいです。

Cursorとは

Cursorは、AIを活用したコードエディタです。VS Codeをベースに開発されており、VS Codeの拡張機能や設定をそのまま利用できるため、既存のVS Codeユーザーでも違和感なく使い始めることができます。

Cursorの最大の特徴は、GPT-4などの大規模言語モデルと統合されており、コード補完、リファクタリング、バグ修正、機能実装などを自然言語で指示して実行できることです。単純なコード補完を超えて、「この関数をテストケース付きで作って」「このコードをより効率的にリファクタリングして」といった複雑な指示にも対応してくれます。

特にプロジェクトルール（.cursor/rules）を設定することで、プロジェクト固有のコーディング規約や技術スタック、アーキテクチャパターンをAIに理解させることができ、より精度の高いコード生成が可能になります。

Railsプロジェクト向けCursorプロジェクトルールのテンプレート

私達のチームは、2025年3月からCursorを使い始め、その後プロジェクトルールを作成し改善を続けてきました。そして、約2ヶ月間のブラッシュアップしたプロジェクトルールを一般的なRailsプロジェクトに適用可能なテンプレートにしました。

ブラッシュアップは、Cursorの公式ドキュメントにあるベストプラクティスに従い、ファイルやルールを小さく保つことを念頭に行いました。結果的に、「globsでなるべく設定ファイルを区切る」ことが重要なポイントだったと思います。

「globs」とは、特定のパターンにマッチするファイルやディレクトリを指定するためのワイルドカード表現です。たとえば、app/models/**/*.rb のように記述することで、app/models 配下のすべてのサブディレクトリを含むRubyファイルを一括で指定できます。

Cursorのプロジェクトルールでは、このglobsを使って「どのファイル群にどんなルールを適用するか」を柔軟にコントロールできます。たとえば、app/controllers/**/*.rb にはコントローラ用のルール、spec/**/*_spec.rb にはテスト用のルール、といった具合に、ファイルの種類や役割ごとにルールを分けて記述できます。

globsの効果は公式ドキュメントには記載がありませんが、Cursorに聞いてみたところ、必要なファイルのみがAIのコンテキストに含まれるようになるため、トークン使用量が最適化され、より多くの有用な情報を処理可能になるようです。生成精度としては、30-40%程度の向上が期待できるとのことです。「本当かな？」と思う反面、確かにそのくらいの向上を実感しています。

このようにglobsを活用することで、プロジェクト全体のルールを細かく分割し、管理しやすくできます。

設定されているルールの一例

テンプレートとして設定されているルールの一部を以下に紹介します。これらは、Rails開発におけるベストプラクティスなどを反映したものになっています。

Controller実装規約
- DHHルーティングに従い、routes.rbでresourcesおよびresourceによって宣言できるアクション（index、show、create、update、destroy）のみを定義する
ドキュメンテーションコメント
- メソッドにはYard記法でドキュメンテーションコメントをつけ、@returnもしくは@raiseを必ず記述する
マイグレーションファイル規約
- Date型カラムは末尾に_date、DateTime型カラムは末尾に_atをつけ、カラムには論理名（日本語）をコメントとして追加する
テストコーディングルール
- テスト対象のメソッドやスコープはsubjectを使用して定義し、ActiveRecord/ActiveModelのオブジェクト検証にはhave_attributesを使用する

設定方法

muraaano/cursor-project-rules-on-railsリポジトリをクローンする
.cursor/rules 以下を導入したいリポジトリにコピーする

カスタマイズのポイント

プロジェクトごとにリポジトリのディレクトリ構成が異なる場合は、Cursorルールの配置場所やglobsのパスも合わせて調整しましょう。

リポジトリのルートに直接Railsアプリがある場合

リポジトリのルートに直接Railsアプリがある場合、テンプレートのまま .cursor/rules/ 配下にルールファイルを置き、globsも app/models/**/*.rb などそのままのパスで問題ないです。

.
├── .cursor/
│   └── rules/
│       ├── models.md（globs: app/models/**/*.rb など）
│       └── controllers.md（globs: app/controllers/**/*.rb など）
├── app/

`./backend/` などサブディレクトリにRailsアプリがある場合

./backend/ などサブディレクトリにRailsアプリがある場合、ルールファイルも .cursor/rules/backend/ のようにサブディレクトリを作って配置すると、他の言語やフロントエンドのルールと分けて管理しやすくなります。
backend/app/models/**/*.rb のように、globsのパスも合わせて変更してください。

.
├── .cursor/
│   └── rules/
│       └── backend/
│           ├── models.md（globs: backend/app/models/**/*.rb など）
│           └── controllers.md（globs: backend/app/controllers/**/*.rb など）
├── backend/
│   ├── app/
│   └── ...

プロジェクトルール作成の背景と2ヶ月間の取り組み

ここでは、プロジェクトルール作成の背景について説明します。

導入の背景と目的

Cursorの導入を始めたきっかけは、もともとGitHub Copilotを利用しており、copilot-instructionsでプロジェクト独自のルールを記述していた経験があったためです。そのため、Cursorのプロジェクトルールにも違和感なくスムーズに移行することができました。

Copilotの時点で「ルールを明示的に書くことでAIの提案精度が上がる」ことを実感していたため、Cursorでもルールの整備・改善を積極的に行うモチベーションが自然と生まれました。実際、導入初期から「こうした方が良さそう」「このルールは不要かも」といった気づきが頻繁にあり、ほぼ毎週何かしらのルールを更新し続けていました。

このように、既存のAIツールでの経験があったことで、Cursorのプロジェクトルールも抵抗なく受け入れられ、継続的な改善サイクルを回すことができたのが大きなポイントだったと感じています。

試行錯誤のプロセス

プロジェクトルールの運用を始めて最初の頃は、実装ファイルとテストファイルでルールを分けていましたが、記述量が増えるにつれて、より細かくglobsごとにルールを分割していくようになりました。たとえば、モデル、コントローラ、サービス、テストなど、役割ごとにglobsで対象ファイルを指定し、それぞれに最適なルールを適用する形に進化していきました。

また、プルリクエストのレビューコメントで指摘された内容を、その都度プロジェクトルールに反映する運用を徹底しました。レビューコメントは、チーム内での認識のズレや設計方針の違いに気づくきっかけになることが多いため、このタイミングでCursorのルールをアップデートすることで、AIの提案精度向上だけでなく、チーム全体の設計方針やコーディング規約を揃える機会としても非常に有効でした。

このようなサイクルを繰り返すことで、プロジェクトルール自体もチームの成長やプロジェクトの変化に合わせて柔軟に進化させていくことができたと感じています。

実際に使って感じたメリット・デメリット

Cursor導入初期はAIモデルにclaude-3.7-sonnetを使用していました。一定の効果は得られていたものの、体感としては約50%程度は意図と異なるコードが生成されていました。しかし、5月頃にclaude-4-sonnet（thinking）を使い始めたところ、一気に精度が向上し、意図と異なるコードの割合は10%程度まで減少しました（いずれも体感値です）。

この精度向上により、AIによるコード生成や提案の信頼性が大きく高まり、実務での活用度も向上しました。特に、複雑なロジックやプロジェクト固有のルールを反映した提案が増え、レビュー時の修正工数も減少したと感じています。

一方で、AIのバージョンアップによる挙動の変化には注意が必要であり、定期的にプロジェクトルールや運用フローを見直すことの重要性も再認識しました。

テンプレート活用のポイント

このように私のチームではプロジェクトルールの重要性を実感するとともに、Rails向けの有用なCursorルールが公開されていないことに気づきました。そこで、私たちが実際に運用・改善してきたルールを改変してテンプレートとして公開することにしました。

Cursorをすでに使っている方はもちろん、これから導入を検討している方にも、このテンプレートが役立つことを願っています。テンプレートをベースに自分たちのプロジェクトに合わせてルールをカスタマイズし、継続的に改善していくことで、より良い開発体験につながるはずです。

このルールはGitHub Copilotのルールにも応用が可能だと思いますので、Cursorを使っていない方の参考にもなれば嬉しいです。Copilotでも.github/instructions/を活用してプロジェクト独自のルールを明示することで、AIの提案精度や一貫性を高めることが可能だと思います。

また、Cursorルールを通じて実装方針を見直したり、チームでコーディング規約や設計方針の認識を揃えるきっかけにもなれば嬉しいです。このテンプレートがプロジェクトルールの改善サイクルを回すきっかけになればとても嬉しいです。

今後の展望

今後の改善点としては、さらなるルールの拡充によるAI提案精度の向上を目指すとともに、静的解析ツール（例: RuboCop）で十分にカバーできる内容についてはCursorルールから除外し、ルールの重複や冗長さを減らしていきたいと考えています。また、ルールの有無によるAI提案の精度や開発効率への影響を、定量的に比較・検証する取り組みも進めていきたいと思っています。