Cursorのルール(Rules)の書き方:プロジェクト全体と一部のファイル向けを分ける

切り分けの基準:判断表

公式ドキュメントによると、ルールが適用されるとその内容はモデルのコンテキストの冒頭に入ります。常時適用のルールは、どんな依頼でもその分だけ場所を取ることになります。これは仕様からの私の推論ですが、長い常時ルールは「効かせたい一文」が埋もれやすくなります。そこで次の表で分けます。

• 使用言語・主要フレームワーク、ビルドとテストのコマンド、置き場所：常時適用、理由：全タスクの前提になる
• 触ってはいけないディレクトリ、秘密情報の扱い、置き場所：常時適用、理由：場所を問わず守らせたい
• コンポーネントの書き方(src/components/のみ)**、置き場所：ファイル限定、理由：他のファイルでは不要
• テストの命名・モック方針(/*.test.tsのみ)**、置き場所：ファイル限定、理由：テストを触るときだけ必要
• DBマイグレーション手順など、たまに行う作業、置き場所：手動(@で呼ぶ)または説明ベース、理由：普段は不要
• 整形・インデント・import順、置き場所：ルールに書かずリンターへ、理由：機械で強制できる

Cursorの4つの適用方式

公式ページでは、Project Rulesは.cursor/rulesに.mdcファイルとして置き、先頭のメタデータ(description、globs、alwaysApply)で適用条件が決まると説明されています。

• Always Apply、alwaysApply：true、description：不要、globs：不要、動き：常に含まれる
• Apply Intelligently、alwaysApply：false、description：あり、globs：なし、動き：Agentが説明を見て必要か判断する
• Apply to Specific Files、alwaysApply：false、description：不要、globs：あり、動き：パターンに一致するファイルがコンテキストに入ると適用
• Apply Manually、alwaysApply：false、description：なし、globs：なし、動き：チャットで@で指定したときだけ

注意点が二つあります。公式ページには、.cursor/rules内の通常の.mdはメタデータがないため無視される、という趣旨の記載がありました。拡張子は.mdcにしておくのが確実です。また、ルールはCursor Tabなど他のAI機能には影響しないと書かれています。Tabの補完を変える目的でルールを書いても効きません。

型1:プロジェクト全体(常時適用)

次は説明用の例です。実際のプロジェクトで試した結果ではないので、〔〕の部分を自分の環境に置き換えてください。

---
description: プロジェクト共通の前提
alwaysApply: true
---

# 前提
- 言語/FW: 〔TypeScript / Next.js〕
- 確認コマンド: `〔npm run lint && npm test〕`
- 変更後は上のコマンドを実行し、結果を報告する

# 守ること
- `〔migrations/〕`配下の既存ファイルは編集しない
- 環境変数の値や鍵をコードやログに書かない
- 依頼範囲外のファイルは変更せず、必要なら提案だけする

# 参照
- 設計の概要: @docs/architecture.md

ポイントは三つです。

• 命令形で、確認できる文にする。 「きれいに書く」ではなく「変更後にlintとテストを実行する」のように、守れたか確認できる形にします。
• 長い説明はコピーせず参照にする。 公式ページでは、ファイル名の言及はAgentが必要なときに読み、内容はプロンプトに埋め込まれないと説明されています。逆に言えば、毎回確実に読ませたい内容は本文に書く必要があります。
• 500行未満は推奨であって目標ではない。 公式は500行未満を推奨していますが、常時適用なら20〜30行程度を私は目安にしています(編集上の提案です)。

型2:一部のファイル向け(globsで限定)

---
description: Reactコンポーネントの書き方
globs: src/components/**/*.tsx
alwaysApply: false
---

- 関数コンポーネントで書き、propsの型は同じファイルで定義する
- 状態管理は既存の例に合わせる: @src/components/Button.tsx
- 新規コンポーネントには同名の`.test.tsx`を作る

パターンの書き方は、**が複数階層、*が単一のファイル名部分に対応します。複数指定するときはカンマ区切りです(例:docs/**/*.md, docs/**/*.mdx)。

ファイル限定ルールは「このパターンの範囲で、既存のどのコードを手本にするか」を1つ指すと、短く済みます。手本ファイルは実在するパスにして、リネームしたらルールも直します。

書かない方がよい内容の例

公式ページは、スタイルガイド全体のコピー、一般的なコマンド(npmやgitなど)の説明、まれなエッジケース、コードベースにすでにある内容の重複を避けるよう述べています。これを踏まえた例を挙げます(説明用)。

• 「インデントは2スペース、セミコロンあり、シングルクォート…」、代わりにどうするか：Prettier/ESLintの設定に任せ、実行コマンドだけルールに書く
• 「git commitでコミットし、npm installで依存を入れる」、代わりにどうするか：書かない。一般的な操作は既知
• 「年に一度の決算バッチで、うるう年の場合のみ…」、代わりにどうするか：該当ファイルのコメント、または手動ルールに分ける
• コードの関数一覧を丸写し、代わりにどうするか：@ファイル名で参照する
• 「丁寧に」「高品質に」「ベストプラクティスで」、代わりにどうするか：具体的な行動(テスト実行、変更範囲の限定)に言い換える
• 本物のAPIキー、社内URL、顧客名、代わりにどうするか：一切書かない。ルールはリポジトリで共有されうる

下書きをAIに作らせる依頼文

ルールは、自分のコードを読ませて下書きを作ると早くできます。ただし「何を常時にするか」の判断は人が持ちます。

このリポジトリを読み、Cursorのルール案を作ってください。
条件:
- 常時適用は30行以内。前提、確認コマンド、禁止事項のみ
- フォルダ固有の決まりは、globs付きの別ルールに分ける
- 整形やimport順などリンターで強制できるものは含めない
- 各行について、根拠となるファイルのパスを括弧で添える
- 推測で書いた行には「要確認」と付ける
出力は.mdcファイルごとのコードブロックで。

案が出たら、人が次を確認します。

1. 各コマンドを実際に実行できるか
2. 根拠に挙がったパスが存在するか
3. 「要確認」の行を残すか削るか決めたか
4. 常時適用の側に、特定フォルダでしか使わない決まりが混ざっていないか
5. 秘密情報や社内固有名詞が入っていないか

運用では、AIが同じ誤りを繰り返したときに1行ずつ足し、半年に一度など区切りを決めて、効いていない行や古くなった行を消す形が続けやすいです。ルールを増やす前に、まず既存の行が守られているかを見てください。