みなさん、こんにちは。
新卒でエンジニアをやっている赤神です。
Xを見ていると、CursorなどのAIが学生無料になっているみたいで、学生に戻りたい...と思っている日々です。
ところで、皆さんはCursor Rulesを設定していますか？
設定するのとしないので、ま じ で 生産性が変わるので設定をしましょう！
今日は、Cursor Rulesの基本的な話と私が気に入っているruleを1つご紹介します！
皆さんもCusor Rulesを書いて、頼もしい相棒を手に入れましょう💪
基本的な話
そもそも、なんでRulesを設定するの？という話。
基本的にCursorなどの生成AIに精度高く動いてもらうには、きちんとプロンプトを書く必要があります。
ただ、普段の作業の中でいちいち細かくプロンプトを書くのって正直めんどくさいですよね。同じことを何度も書かないといけないし...。
そのような、何度も何度もあなたがCursorに言っていることを言わなくていいようにするためのものがCursor Rulesです！
何はともあれ実物を見てみましょう！
（これは、cursorに書かせたrulesのファイルです。）
---
description:
globs:
alwaysApply: false
---
1. 変数名はキャメルケース（camelCase）で記述すること
2. 関数名はキャメルケース（camelCase）で記述すること
3. コンポーネント名はパスカルケース（PascalCase）で記述すること
4. インデントはスペース2つを使用すること
5. セミコロンは必ず付けること
6. コメントは日本語で記述すること
7. importの順序は以下の通りとすること：
- 標準ライブラリ
- サードパーティライブラリ
- 自作モジュール
8. 未使用の変数やインポートは削除すること
9. マジックナンバーは使用せず、定数として定義すること
10. コンポーネントは1ファイルにつき1つのみ定義すること
Cursor Rulesは、 .mdcというファイルで作成をします。
このファイルが、Cursorが参照するプロジェクト固有のルールやコンテキストを定義するためのファイルです。
場所は、 .cursor/rules/*.mdc 。
もちろん、GItHubなどで管理することができるので、共同開発の際にチームで共有できます！
このファイルはYAML形式のフロントマター（コードで言うと、1~5行目）とMarkdownの内容を合わせたハイブリッド形式で記述されています。
【YAML形式のフロントマター】
-
description: このルールが何をするものかを記述する部分 -
globs: このルールをどのファイルに適用するかをGlobパターンで指定する部分-
**/*.pyだとPythonのファイル全体 -
src/components/**/*.tsxだとあるディレクトリ配下のTSXファイル など
-
【Markdownの内容】
- AIに守ってほしいことなどを書く部分
ちなみに、YAML形式のフロントマターの部分はコードとして書くのではなく、マウス操作で設定することができます。
では、実際に作り方をみてましょう。
作り方!
まずは、Cursorの右上の「⚙️」のアイコンをクリックして、Cursorの設定画面を開きましょう。
「Rules」を選択すると次のような画面になるかと思います。
User Rulesというのが、Cursor全体に対して適応されるRuleになります。
私は、日本語で反応してほしいので「Always respond in 日本」と書いています。
今回設定したいRuleはProject Rulesの方なので、「+ Add new rule」をクリックしましょう。
適当な名前を書いて、エンターを押すとCursorがディレクトリを作成してくれます。
作成されたディレクトリ構造は、次のようになっていると思います。
root/
└── .cursor/ # Cursor AIアシスタント設定ディレクトリ
└── rules/ # Cursor Rules設定ファイル
└── main.mdc # 今から編集するファイル
次にファイルの中身を見ていきましょう。
Rule Typeの部分が選べるようになっていると思います。
ここで設定するのが先ほど紹介したYAML形式のフロントマターの部分です。
Rule Typeは4つあります。
-
Always: 常にコンテキストとして参照 -
Auto Attached:globで指定されたパターンにマッチした場合に参照- フロントマター部分の
File pattern matchesのところにglobを書く
- フロントマター部分の
-
Agent Requested:descriptionに記載された内容を元に、エージェントが参照するかを決定- フロントマター部分の
Descriptionのところにdescriptionを書く
- フロントマター部分の
-
Manual: プロンプトにルールを明確に指定した場合（@ファイル名でメンションできる）にのみ参照
常に意識してほしい場合は、 Always 、特定の作業の際に使いたい場合は Manual にしてメンションで呼び出す、のように自分の好みで設定しましょう！
ここまで、ざっくりとですがCursor Rulesについて説明してきました。
最後に私が愛用しているRulesをご紹介したいと思います！
コミットメッセージを考えてくれるRule
チーム開発の際にGitHubなどを活用していると思うのですが、コミットメッセージって悩みませんか...？（私だけ？）
そこで私が愛用しているので次のRulesになります！
**原則**
- まず、このファイルを参照したら、「commit_message.mdcを参照しました」と叫ぶこと
- 前回のコミットの差異を自動的に取得した上でコミットメッセージの案を出すこと
1. 差分の取得：
- 以下のコマンドを実行して現在の変更点を取得してください
```bash
git diff HEAD
```
- もしくはステージングされた変更のみを確認する場合は
```bash
git diff --staged
```
- これらの結果を分析してコミットメッセージを作成してください
2. コミットメッセージは以下の形式で記述してください：
```
<type>: <subject>
<body>
```
3. typeは以下のいずれかを使用してください：
- feat: 新機能
- fix: バグ修正
- docs: ドキュメントのみの変更
- style: コードの意味に影響を与えない変更（空白、フォーマット、セミコロンの追加など）
- refactor: バグ修正や機能追加ではないコードの変更
- test: テストの追加・修正
- chore: ビルドプロセスやツールの変更、ライブラリの更新など
4. subjectは以下のルールに従ってください：
- 命令形で記述（例：「add」ではなく「added」）
- 50文字以内
- 文末にピリオドを付けない
- 日本語の場合は「〜を追加」「〜を修正」などの形式
5. bodyは以下のルールに従ってください：
- 変更の理由や背景を説明
- 72文字以内で折り返し
- 空行で区切って複数段落を記述可能
6. コミットメッセージを作成する際は、以下の手順で進めてください：
- 前回のコミットからの変更内容を確認
- 変更の種類（type）を特定
- 変更内容を簡潔に説明するsubjectを作成
- 必要に応じて詳細な説明をbodyに記述
統一感があって、コミットメッセージを見たら変更の概要を掴める方が絶対に良いと思うので、私はCursorにコミットメッセージを考えてもらうようにしています。
ただし、普通に「コミットメッセージを書いて」と指示をすると、頓珍漢なことを言ってきたり、Cursorが書いたコードの部分だけに該当するコミットメッセージを提案してきたりします。
そこで、このRulesでは、git diff HEAD などのコマンドを実行して差分を取得するところから始めるんだよ？と教えています。
こうすることで、Cursorとユーザーがそれぞれ変更したことを総合してコミットメッセージを書いてくれます！（やったぜ）
それに、複数行にわたる詳しめなコミットメッセージを書いてくれるのも感動です。
（人間がこれを書こうとするとVimとかnanoで書かないといけないので、慣れていないと一苦労...）
また、冒頭に「原則」と表記して「まず、このファイルを参照したら、「commit_message.mdcを参照しました」と叫ぶこと」という指示を与えています。
これは何かというと、Rulesをきちんと参照したかをユーザーが確認できるようにするための呪文みたいなものです。
CursorはRule TypeをAlwaysにしていてもRulesを参照しないときがたまにあります（プレミアムモデルを使っていると少ない）。
叫ばせておくと何かと一安心です。
ちなみにこのRuleは、Cursorのチャットでメンションするだけでいい感じに動いてくれます。
プロンプト？いりません。
最後に
Curosorを使う上で、Cursor Rulesを設定していないのはCursorを使っている意味がないですよ！！
これは少々言い過ぎかもしれませんが、生成AIをそのまま使うと勝手に使っているライブラリをアップデートしたりだとか、変なところにファイルを作成したりだとかすることがまあまああるかと思います。
そうしたことを減らすため、そして、普段の作業をより効率的に行うための頼もしい相棒になってもらうためにもぜひCursor Rulesを作成しましょう！
p.s.
とは言いつつも、Cursor Rulesを書くのすらめんどくさいですよね...。
めんどくさいことはCursorにやらせればいいという思考のもと、最近、私はCursorに自分でRulesを書かせていたりします（そのための、Rulesも作って）。
また、Cursor Rulesをきちんと書くということはチームで開発する際のルールを明文化することにも繋がりそうだなあと薄々感じています。
また、Cursor Rulesへの愛が爆発した頃に記事を書こうと思います。