CursorのProject Rulesが期待どおりに効かないときは、まず「適用条件に合っていない」のか、「適用された指示に出力が従っていない」のかを分けます。全ルールをAlways Applyへ変える前に、対象ファイル一つとルール一つで確認してください。
目次
最初に記録するもの
利用しているCursorのバージョン、Agentを開いたプロジェクト、対象ファイルの相対パス、ルール名、期待した出力、実際の出力を控えます。接続不能やプロジェクトを読み込めない状態なら、ルールの条件を直す前にその問題を解消します。この記事はAgentのProject Rulesを対象にした確認手順です。Tab補完など別機能へ同じ適用を期待しないでください。
配置とファイル形式を確認する
公式資料ではProject Rulesは .cursor/rules 以下の .mdc ファイルです。名前が似ていても、同ディレクトリの通常の .md ファイルはProject Rulesとして扱われません。拡張子が隠れる環境では実際のファイル名まで確認します。
ルールはfrontmatterと本文を分けて読みます。本文に具体的な指示があるか、設定値を本文へ書いていないかを確認し、現在の画面にあるルール種別とファイル内容を照合します。
表は横にスクロールできます
| 適用の方法 | 確認する条件 |
|---|---|
| Always Apply | alwaysApply: true。常時必要な短い指示に限定する |
| ファイル指定 | globs と、コンテキストに入れたファイルのパスが一致するか |
| 関連性で選択 | description が作業内容を具体的に表しているか |
| 手動 | チャットで対象ルールを明示的に参照したか |
名前を付けただけでは自動適用の条件にはなりません。関連性で選ぶ方法は、毎回必ず選ばれる保証として扱わないでください。Cursor Rules（新しいタブで開く）
一つの対象ファイルで試す
以下は確認用の架空例です。既存の重要なルールを書き換えず、作業用の小さなプロジェクトで試します。
---
globs: "src/demo/**/*.ts"
alwaysApply: false
---
この対象ファイルの説明の最後に「確認用ルールを参照」と付ける。
src/demo/sample.ts をコンテキストに入れ、「このファイルの役割を説明して」と依頼します。次に対象外のパスでも同じ依頼を行い、差を記録します。複数のルール、既存会話の指示、手動参照が混ざると原因が分かりにくいため、比較では一条件だけ変えます。
Agentに「ルールを読んだ」と言わせるだけでは適用の証明になりません。画面で参照状況を確認できる場合はその表示と、実際の出力を別々に記録します。結果の一文だけから内部の適用状態を断定しないことが大切です。
適用されていても従わない場合
指示が長い、曖昧、他のルールと矛盾する場合は、期待する行動を一つに絞ります。「品質を上げる」より「変更した関数の引数と戻り値を説明する」の方が判定しやすくなります。Team Rulesなど上位の指示との関係も公式資料で確認します。
ファイル指定で必要なルールを常時適用へ変えると、対象外の作業にも指示が入ります。切り分けの一時確認と、運用上採用する設定を分け、試験後は意図した範囲へ戻します。
解決しないときに渡す記録
対象パス、ルール全文、適用方法、Cursorのバージョン、再現手順、期待と実際の差を一組にします。社内コードや認証情報を含めず、同じ症状を示せる最小例を用意してください。形式・条件の問題を除外しても出力が安定しない場合は、指示遵守の問題として扱います。
AIものさしの判断
最初の到達点は「全ルールを必ず守らせる」ことではなく、どの条件で期待が外れたか説明できることです。対象と適用方法を固定してから、必要な修正だけを選びます。この手順は公式仕様に基づく案内であり、特定バージョンの実機で成功を確認した体験報告ではありません。