Cursor Rulesを最初に作るためのチェックリスト

Cursor Rulesは、AIへ毎回同じ注意を言い直さないための仕組みです。ただし、最初から長い「理想のルール集」を作ると、どの指示が効いたのか分からなくなります。最初の1本は、対象ファイル、実行してほしい行動、失敗時の停止条件だけを持つ小さなルールで十分です。

この記事では、プロジェクト用Rulesの保存場所、MDCファイルの書き方、適用範囲の決め方、作成後の確認方法を1本の手順にまとめます。読者が手元の小さなプロジェクトで再現できるように、実際の最小ファイルと確認結果も示します。古い .cursorrules を新規作成する方法ではなく、現在の公式ドキュメントが案内している .cursor/rules を使います。

最初に決めるのは「何を書きたいか」ではなく「いつ適用するか」

CursorのProject Rulesは、リポジトリ内の .cursor/rules に置くルールです。ルールごとにMDC形式のファイルへ分け、Gitでコードと一緒に管理できます。公式のCursor Rulesドキュメントでは、Project Rulesを次の4種類に分けています。

種類	適用されるタイミング	最初の用途
Always	常にコンテキストへ含める	ごく短い全体原則
Auto Attached	globに一致するファイルを扱う時	言語・フォルダ別の規約
Agent Requested	説明文をもとにAgentが必要性を判断	特定の作業手順
Manual	明示的に指定した時だけ	まれに使うレビュー手順

最初の1本にはAuto Attachedが扱いやすいです。たとえばTypeScriptを編集する時だけテスト手順を読ませたいなら、globs を src/*.ts や src/**/*.ts のように限定します。すべての会話へ常時入れる必要はありません。

ここで重要なのは、ルールの文字数より適用範囲です。対象を決めないまま alwaysApply: true にすると、Markdownの文章修正でも、画像整理でも、TypeScript向けの規約がコンテキストへ入り得ます。使わない指示も入力コンテキストを占めるため、最初は「必要なファイルにだけ付く」形から始めます。

なお、プロジェクト直下の .cursorrules は旧形式です。公式ページでは現在も対応しているものの、非推奨へ向かうLegacy扱いと説明されています。新しく作る場合は .cursor/rules/*.mdc を選ぶほうが、範囲を分けやすく、後で整理もしやすいです。

私が手元で作った最小ルール

今回、私は公開用の検証フォルダを作り、TypeScriptファイルだけへ付けるルールを1件作成しました。作成したファイルは .cursor/rules/project-safety.mdc です。内容は次の11行です。

---
description: TypeScript filesを変更する前後に安全確認を行う
globs: "src/*.ts"
alwaysApply: false
---

# TypeScript変更ルール

- 変更前に対象ファイルと関連テストを確認する。
- 変更後にテストを実行する。
- テスト失敗時は公開やデプロイへ進まない。

このルールに入れたのは3項目だけです。

変更前に見るもの
変更後に実行するもの
失敗した時に進まない場所

「高品質なコードを書いてください」「最善の方法を選んでください」のような抽象表現は入れていません。実行後に守れたか判定できないからです。代わりに、テストを実行したか、失敗時に止まったかという確認可能な行動へ変えました。

ローカルでは、MDCファイルが1件、324バイト、11行であることを確認しました。frontmatterからは description、globs、alwaysApply の3キーを読み取れました。また同じ簡易検査で、src/app.ts はglobに一致し、docs/guide.md は一致しない結果になりました。

この検査で確認できたのは、ファイルの置き場所、frontmatterの基本構造、意図したパス範囲です。一方で、Cursor Agentが実際の会話で毎回指示へ従うかまでは検証していません。ルールファイルの構文確認と、モデルの行動確認は別のテストとして扱う必要があります。

作成手順は5段階に分ける

1. 繰り返している注意を1つ選ぶ

チャットで2回以上言い直した注意から選びます。候補が多くても、最初は1つだけです。たとえば次のような指示です。

変更後にテストを実行する
生成ファイルは編集しない
APIのレスポンス型を変更したら型テストも直す
認証情報をコードへ直接書かない

この時点では文章をきれいにする必要はありません。「対象」「行動」「停止条件」の3列へ分ければ、ルールにすべき内容か判断できます。

対象	行動	停止条件
`src/*.ts`	関連テストを実行する	テスト失敗なら公開へ進まない

2. ルール用ディレクトリを作る

プロジェクト直下で次の場所を用意します。

mkdir -p .cursor/rules

すでにディレクトリがある場合は、既存ルールを先に確認します。同じ目的のルールを別名で追加すると、似た指示が重複し、後からどちらを直すべきか分かりにくくなります。

find .cursor/rules -maxdepth 1 -type f -name '*.mdc' -print

3. ルール名を目的で付ける

rule1.mdc や important.mdc ではなく、typescript-tests.mdc、api-safety.mdc のように役割が分かる名前にします。Cursorの公式ドキュメントも、ルールは焦点を絞り、具体的で、必要なら複数ファイルへ分割することを勧めています。

ファイル名だけで優先順位を表現しようとせず、競合するルール自体を減らします。「常に短く書く」と「すべて詳細に説明する」が同時に存在すれば、名前を工夫しても判断は安定しません。

4. frontmatterと本文を書く

Auto Attachedとして使う最小形は次のようになります。

---
description: APIコード変更時に検証手順を適用する
globs: "src/api/*.ts"
alwaysApply: false
---

- 変更前に既存のレスポンス型を確認する。
- 変更後にAPIテストを実行する。
- 互換性が壊れる変更は、理由と移行方法を提示する。

description にはルールの中身を丸ごと書かず、「何をする時に使うルールか」を書きます。globs は実際に編集するパスへ合わせます。alwaysApply は、本当に全作業で必要な原則以外では安易にtrueへしません。

5. ルールが付いたことと、行動結果を分けて確認する

確認は2段階です。

最初に、対象ファイルを開いた時に該当ルールが利用可能または添付されているかをCursor上で見ます。次に、小さい変更を依頼し、ルールに書いた確認行動が実際に行われたかをレビューします。

テスト用の依頼は、結果を壊さない小さなものにします。

src/app.ts の定数名を読みやすく変更してください。
変更後に、このプロジェクトのルールに従って確認してください。

ここで見るのは返答の丁寧さではありません。関連テストを探したか、テストを実行したか、失敗した場合に次の操作を止めたかを見ます。守られなかった場合は、いきなりルールを長くせず、対象glob、description、行動文の曖昧さを順番に確認します。

ルールが効かない時の切り分け

globが対象ファイルに合っていない

src/**/*.ts と書いたつもりでも、実際のコードが app/ や packages/ にある場合は付きません。まず対象ファイルの相対パスを確認し、必要最小限のパターンに直します。

find src -type f -name '*.ts' | head

モノレポで複数領域へ同じルールを広げる前に、1つのディレクトリで動作を確認します。範囲を一度に広げると、どのファイルで期待どおり付かなかったかを追いにくくなります。

descriptionが用途を説明していない

Agent Requested型では、Agentがdescriptionを見て必要性を判断します。「重要なルール」だけでは、いつ読むべきか分かりません。「データベースのマイグレーションを作成・変更する時に使う」のように、作業のトリガーを書きます。

Alwaysへ逃げている

Auto Attachedで付かない時に、すぐ alwaysApply: true へ変えると、一見直ったように見えます。しかし、無関係な会話へもルールが入り、指示の競合とコンテキスト増加を招きます。先にglobと保存場所を確認します。

1ファイルへ目的を詰め込みすぎている

コード規約、テスト、Git、デプロイ、文章表現を1本にまとめると、修正の影響範囲が大きくなります。対象と確認方法が異なるなら分けます。分割後は、Alwaysルールが増えすぎないかも見直します。

トークンを無駄にしないRulesの保ち方

Rulesは便利ですが、適用された内容はモデルの入力コンテキストになります。したがって、長ければ長いほど安心とは限りません。私なら次の基準で削ります。

コードを見れば分かる説明は書かない
同じ指示を別の言葉で繰り返さない
例は1つで足りるなら1つにする
対象が限定できる指示をAlwaysにしない
一度も使われないルールは削除候補にする

月1回程度、MDCファイル数と行数を確認すると、増え方を把握できます。

find .cursor/rules -type f -name '*.mdc' -print
find .cursor/rules -type f -name '*.mdc' -exec wc -l {} +

行数だけで品質は決まりませんが、急増を見つける目安になります。1本のルールへ説明が増え続けた場合は、対象を分割するか、既存ドキュメントを @filename で参照する方法を検討します。公式ドキュメントでは、ルールから関連ファイルを参照して追加コンテキストに含める方法も案内されています。

ただし、大きな仕様書を常に参照すれば、その分だけコンテキストは重くなります。参照先を追加する時も「この作業で毎回必要か」を確認します。

User Rules、Project Rules、AGENTS.mdの使い分け

混同しやすい3つを整理します。

置き場所	向いている内容	注意点
Cursor SettingsのUser Rules	返答言語や全プロジェクト共通の短い好み	すべてのプロジェクトへ影響する
`.cursor/rules/*.mdc`	リポジトリ固有、ファイル範囲固有の手順	globと適用方法を確認する
`AGENTS.md`	複数の対応Agentが読むプロジェクト指示	対応範囲は利用するツールごとに確認する

Cursor CLIについては、公式のUsing CLIで、.cursor/rules に加えてプロジェクト直下の AGENTS.md と CLAUDE.md もルールとして読むと説明されています。IDEだけを使うのか、CLIも使うのかで、正本をどこに置くかを決めます。

同じ指示を3か所へコピーすると、更新漏れが起きます。共通原則は1か所へ寄せ、Cursor固有の適用範囲が必要なものだけMDCへ分けるほうが管理しやすくなります。

公開前チェックリスト

最初のCursor Ruleを保存する前に、次を確認します。

.cursorrules ではなく .cursor/rules/*.mdc を選んだ
1ファイルにつき目的を1つに絞った
descriptionに「いつ使うか」が書かれている
globが実際の対象パスに一致している
Alwaysが本当に必要か確認した
抽象的な理想論ではなく、確認できる行動を書いた
失敗した時に止める条件を書いた
対象外ファイルへルールが付かないことも確認した
小さい変更で、Agentの実際の行動をレビューした
同じ指示がUser RulesやAGENTS.mdに重複していない

最初から完璧なRules集を作る必要はありません。1つの繰り返し注意を、1つの対象範囲と1つの確認方法へ落とし込む。それが守られたことを確認してから、次のルールを追加します。この順番なら、ルールを増やすほど分かりにくくなる状態を避けられます。

関連するCursor本体の初期設定も確認したい場合は、CursorでAIコーディングを始める前の設定チェックも参照してください。Rulesを作る前の権限、保存先、任せる範囲を分けて整理しています。