Cursorでルールが守られないとき、設定・置き場所・書き方を順に確認する手順

確認順のフロー

上から順に見て、最初に当てはまったところを直します。

• 1、確認すること：使っているのはAgent(Chat)か、当てはまったら：Tabなど他の機能ならルールの対象外。機能を変える
• 2、確認すること：Customize → Rules の一覧にルールが出ているか、当てはまったら：出ていなければ置き場所・拡張子を直す
• 3、確認すること：適用タイプが今の作業に合っているか、当てはまったら：alwaysApply・globs・descriptionを見直す
• 4、確認すること：別のルールと矛盾していないか、当てはまったら：内容を一本化する
• 5、確認すること：ルール文は具体的で検証できるか、当てはまったら：書き換える

1. 効く機能を使っているか

公式ドキュメントによると、ルールはAgent(Chat)に対するものです。同ページのFAQには、Cursor Tabなど他のAI機能には影響しないと明記されています。補完が規約に従わない場合は、ルールを直しても改善しません。

なお、確認したページには、Ask、Plan、Debugなど個別のモードでルールがどう扱われるかの記述はありませんでした。モードによる違いは断定できないので、同じルールで別のモードも試して比べると手がかりになります。

2. 置き場所と拡張子を確かめる

プロジェクトルールの置き場所は .cursor/rules/ です。公式には、プロジェクトルールは .mdc 拡張子を使う必要があり、.cursor/rules にある通常の .md は無視される、と書かれています。README.md のような感覚で typescript.md を置いても読まれません。

プレーンなMarkdownで済ませたい場合は、公式が代替として挙げている AGENTS.md を使います。プロジェクトルートに置けるほか、サブディレクトリにも置けて、近い階層の指示が優先されるとされています。

次に、Customize → Rules を開いて、ルールが一覧に出ているかを見ます。公式ではここで各ルールとその状態を確認できます。一覧に出ないなら、まず置き場所と拡張子を再確認します。

個人用のUser Rulesは全プロジェクト共通でAgent(Chat)に使われます。チームで共有したい内容を自分のUser Rulesだけに書いていると、他の人の環境では効きません。共有したい決まりは、リポジトリ内のProject Rulesに置きます。

3. 適用タイプが場面に合っているか

一覧に出ているのに発動しないなら、frontmatterを疑います。公式の組み合わせは次のとおりです。

• true、globs：無視される、description：無視される、動作：常に含まれる
• false、globs：あり、description：任意、動作：一致するファイルがコンテキストにあるとき自動添付
• false、globs：なし、description：あり、動作：Agentが説明を読み、関連すると判断したら取り込む
• false、globs：なし、description：なし、動作：チャットで @ 指定したときだけ

よくある食い違いは次の3つです。

• globsを書いたが、そのファイルが会話に入っていない。 「一致するファイルがコンテキストにあるとき」が条件です。対象ファイルを開いて @ で渡すか、新規ファイルを作る依頼の場合はalwaysApplyを検討します。
• descriptionが「コーディング規約」のように広すぎる、または狭すぎる。 Agentはこの一文で必要かどうかを判断します。「React コンポーネントを新規作成・修正するときの命名とpropsの規約」のように、発動してほしい場面を書きます。
• alwaysApplyがfalseで、globsもdescriptionもない。 この組み合わせでは、チャットでルールを @ 指定したときだけ取り込まれます。

説明用の例(動作は未検証)として、フロントエンドの規約を特定ファイル向けにする場合の書き方です。

---
description: Reactコンポーネントの作成・修正時の規約
globs: src/components/**/*.tsx
alwaysApply: false
---
- コンポーネントは関数コンポーネントで書く
- propsの型は同じファイル内で `type Props` として定義する

4. 他のルールとの競合を探す

優先順位は公式では Team Rules → Project Rules → User Rules の順です。User Rulesに「コメントは日本語で書く」、Project Rulesに「コメントは英語で書く」とあれば、期待どおりにならない原因になります。Customize → Rules の一覧を見て、同じ話題を扱うルールが複数ないかを探し、一本に統合します。

また、ルールが適用されるとき、その内容はモデルのコンテキストの先頭に含められると公式に書かれています。ルールが入っていることと、モデルが毎回その通りに従うことは別の話です。公式にも、従うことの保証は書かれていません。だからこそ次の書き方の見直しが効いてきます。

5. ルール文を短く具体化する

ここまでで設定に問題がなければ、書き方を直します。公式のガイドは、ルールを焦点が絞られ実行可能な内容にすること、曖昧な指示を避けて社内ドキュメントのように明確に書くこと、500行未満にすることを挙げています。また、スタイルガイドの丸写しや、まれなエッジケースの列挙は避け、リンターで足りるものはリンターに任せるよう勧めています。

以下は、編集の観点で作った書き換え例です(説明用の例で、効果を測定したものではありません)。

• きれいなコードを書いて、問題：判定基準がない、書き換え後：関数は1つの責務にし、40行を超えたら分割案を先に提示する
• テストも忘れずに、問題：いつ・何をかが不明、書き換え後：公開関数を追加・変更したら、同じ変更内に *.test.ts のケースを1件以上追加する
• 適切にエラー処理して、問題：「適切」が人によって違う、書き換え後：外部APIの呼び出しは try/catch で包み、失敗時は Result 型でエラーを返す。例外は投げない
• 既存の書き方に合わせて、問題：参照先がない、書き換え後：新しいAPIルートは @src/routes/users.ts と同じ構成にする

最後の例は、公式が勧める「ファイルを参照する」書き方に沿っています。ルール内で @ファイル名 のように言及すると、Agentが必要に応じてツールで読み込む、と説明されています。参照先の内容は自動でコンテキストに展開されないため、常に必要な指示はルール本文に書きます。長いサンプルコードをルールに貼らずに済みます。

書き換えの型は3つです。数字や名前で判定できる形にする、いつ適用するかを文頭に置く、1ルール1論点にする。複数の論点が混ざっていたら、ファイルを分けてそれぞれにdescriptionかglobsを付けます。

6. それでも守られないときの切り分け依頼文

新規チャットを開き、次のように頼むと、ルールが見えているかを探る手がかりになります。モデルの自己申告なので、証拠ではなく目安です。

このチャットで参照できるプロジェクトルールの名前を挙げてください。
そのうえで、src/components/Button.tsx に「ローディング中の状態」を
追加してください。適用したルールごとに、どの行で従ったかを
最後に箇条書きで示してください。

ルール名が挙がらなければ、2〜3の設定側を再確認します。挙がるのに守られなければ、4〜5の競合と書き方を見直します。長く続いたチャットで守られなくなる場合は、新規チャットで同じ依頼を試して差を見るのも一つの方法です。これは公式の仕様ではなく、切り分けのための編集上の提案です。

まとめて直すときのチェックリスト

• 対象はAgent(Chat)か
• ファイルは .cursor/rules/*.mdc か AGENTS.md か
• Customize → Rules の一覧に出ているか
• 適用タイプと今の作業が合っているか
• 同じ話題のルールが複数ないか
• 各ルールは数字・名前・参照ファイルで判定できるか

人が最終的に確認するのは、実際の差分がルールどおりになっているかです。AIの「従いました」という報告だけで済ませず、書き換えたルール1件ごとに小さな依頼を1回投げ、出力を目で確かめてください。