CursorのRules（ルール）設定の書き方を、ファイルの置き場所から適用タイプの使い分け、「書いたのに効かない」ときの対処まで実際の運用目線で解説します。Rulesは、AIに毎回同じ前提（コーディング規約・技術スタック・禁止事項）を伝える仕組みで、正しく書けばAIの出力精度と一貫性が大きく変わります。逆に書き方を間違えると、無視されたりコンテキストを圧迫して精度を下げたりします。この記事では2026年7月時点の最新仕様（.cursor/rules ディレクトリ＋.mdc形式）に沿って、失敗しない書き方を整理します。
Cursor Rulesとは？3つの置き場所と優先順位
Cursorには、AIへの指示を永続化する仕組みが複数あります。まず全体像を把握しておくと、どこに何を書くべきか迷いません。
User Rules・Project Rules・旧.cursorrulesの違い
| 種類 | 置き場所 | 適用範囲 | 用途 |
|---|---|---|---|
| User Rules | Cursor設定画面（Rules） | 全プロジェクト共通 | 回答言語・口調・普遍的な好み |
| Project Rules | .cursor/rules/*.mdc |
そのリポジトリ内 | 技術スタック・規約・設計方針 |
| 旧 .cursorrules | プロジェクト直下の単一ファイル | そのリポジトリ内 | レガシー形式（非推奨・移行推奨） |
現在の主役はProject Rulesです。Cursor公式ドキュメントでも、単一の.cursorrulesファイルは非推奨（レガシー）とされ、.cursor/rulesディレクトリに複数の.mdcファイルを分割して置く方式が推奨されています。ルールを分割することで「必要なときだけ必要なルールを読み込む」制御ができ、トークンの無駄がなくなります。
モノレポではネストした.cursor/rulesが優先
リポジトリのルートだけでなく、サブディレクトリ（例：packages/api/.cursor/rules/）にもRulesを置けます。ネストされたルールは、そのディレクトリ配下のファイルを編集するときに読み込まれ、ルートのルールと内容が衝突する場合はネスト側が優先されます。バックエンドとフロントエンドで規約が違うモノレポでは、この階層化が整理のポイントになります。
.mdcファイルの書き方｜作成手順とフロントマター
作成手順（3ステップ）
- 手順1：コマンドパレット（Ctrl+Shift+P / Cmd+Shift+P）で「New Cursor Rule」を実行するか、
.cursor/rules/フォルダに手動でファイル名.mdcを作成する - 手順2：ファイル冒頭のYAMLフロントマターに
description・globs・alwaysApplyを設定する - 手順3：本文にMarkdownで指示を書く（箇条書き推奨・後述のコツ参照）
フロントマター3項目の意味
.mdcファイルの挙動は、冒頭のフロントマター3項目で決まります。
- description：ルールの一行要約。AIが「このルールを今読むべきか」を判断する材料になるため、「Reactコンポーネントの命名と構成規約」のように内容が推測できる書き方にする
- globs：ルールを自動適用するファイルパターン（例：
src/**/*.tsx）。該当ファイルを編集するときだけ読み込まれる - alwaysApply：
trueにすると全リクエストに常時読み込まれる。トークンを常に消費するため、本当に普遍的なルールだけに絞る
4つの適用タイプの使い分け
| タイプ | 設定 | 読み込まれる条件 | 向く内容 |
|---|---|---|---|
| Always | alwaysApply: true | 常時 | プロジェクトの大前提（言語・フレームワーク） |
| Auto Attached | globs指定 | 該当ファイルの編集時 | 言語別・ディレクトリ別の規約 |
| Agent Requested | descriptionのみ | AIが必要と判断したとき | 特定タスク用の補助知識 |
| Manual | チャットで@ルール名 | 手動で呼んだときだけ | 移行手順書・大きなテンプレート |
迷ったら「Always は最小限、大半は Auto Attached」が原則です。Cursorをこれから導入する方は、先にCursor AIの使い方（初心者向け解説）で基本操作を押さえておくとスムーズです。
AIの精度を上げる指示の書き方のコツ
短く・具体的に・箇条書きで
Rulesは長文の説明書ではなく、チェック可能な規則のリストにするのが鉄則です。常時適用のルールが長いほど、毎回のリクエストでコンテキストを圧迫し、かえって指示が無視されやすくなります。目安として、Alwaysルールは短く絞り、詳細な規約はglobs付きのAuto Attachedに逃がします。
良い例・悪い例
- 悪い例：「きれいで保守しやすいコードを書いてください」→ 抽象的すぎて挙動が変わらない
- 良い例：「関数コンポーネントのみ使用。クラスコンポーネント禁止」「エラーは必ずResult型で返し、例外をthrowしない」→ 守れたか機械的に判定できる
- 良い例：「新しい依存パッケージを追加する前に、必ず理由を説明して確認を取る」→ AIの暴走を止める行動ルール
globs設計は「規約が分かれる単位」で
globsはディレクトリ構成に合わせて「規約が変わる境界」で切るのがコツです。たとえばsrc/**/*.tsxにはUI規約、server/**/*.tsにはAPI設計規約、**/*.test.tsにはテスト方針、という分け方です。1ファイル1テーマにしておくと、後からルールを直すときも影響範囲が明確になります。
Rulesが効かないときのつまずき対処
よくある原因は4つ
- フロントマターの書式ミス：YAML部分の記法が崩れていると、ルール全体が正しく解釈されない。まず冒頭3行を疑う
- descriptionが空のAgent Requestedルール：AIが読み込むかを判断する手がかりがなく、実質的に呼ばれない
- ルールの肥大化：数百行のルールを常時適用にすると、重要な指示が埋もれて守られなくなる
- 旧.cursorrulesとの併用による競合：移行途中で両方に規約が残っていると、どちらが効いているか分からなくなる。移行を完了させて旧ファイルは削除する
「読み込まれているか」を確認する方法
チャット（Agent）の応答時に、コンテキストとして参照されたルールがパネル上で確認できます。まず「そのルールが今の会話に載っているか」を見るのが切り分けの第一歩です。載っているのに守られない場合は指示の書き方（抽象的すぎる・矛盾している）を、載っていない場合はフロントマター（globsの範囲・alwaysApplyの設定）を直します。日本語UIまわりの設定でつまずいている場合は、Cursorを日本語化する手順と「できない」ときの対処法もあわせて確認してください。
実運用でわかった失敗パターンと自己チェック表
ありがちな失敗3パターン
- 「全部盛り」ルール：ネットで見つけたテンプレートを丸ごとコピーして数百行のAlwaysルールにする→自分のプロジェクトに関係ない指示がノイズになり精度が落ちる。テンプレートは「自分のリポジトリで実際に起きた問題」に絞って削るのが正解
- 書きっぱなしで更新しない：技術スタックの変更後も古いルールが残り、AIが廃止済みの書き方を提案し続ける。ルールはコードと同じくレビュー対象にする
- 禁止ばかりで方針がない：「〜するな」の羅列だけだと、AIは代わりに何をすべきか分からない。禁止＋推奨をセットで書く（例：「anyを使わない。外部入力はunknownで受けて絞り込む」）
公開前の自己チェック表（当サイト作成）
筆者がRulesを整備する際に使っているチェック表です。5項目中4つ以上を満たせば、実用に耐えるルールになっています。
| チェック項目 | 判定基準 |
|---|---|
| Alwaysルールは最小限か | 常時適用は1〜2ファイル・短文に収まっている |
| 各ルールは1テーマか | ファイル名だけで中身が推測できる |
| 指示は判定可能か | 「守れた/守れなかった」を機械的に言える文になっている |
| globsは境界で切れているか | 規約が変わるディレクトリ単位で分割されている |
| 旧形式が残っていないか | .cursorrules単一ファイルを削除済み |
まとめ｜Rulesは「小さく分けて、判定できる文で」
CursorのRules設定は、.cursor/rulesディレクトリに.mdc形式で小さく分割し、Always・Auto Attached・Agent Requested・Manualの4タイプを使い分けるのが2026年時点の標準です。精度を上げる鍵は、長い説明ではなく「守れたか判定できる短い規則」を積み上げること。効かないときはフロントマター→コンテキスト読み込み→指示の具体性の順に切り分ければ、原因はほぼ特定できます。
CursorとほかのAIコーディングツールの使い分けを検討している方は、ClineとCursorの違いと使い分け（料金・APIコスト）も参考にしてください。まずはAlwaysルール1本＋よく触るディレクトリのAuto Attached1本、の計2ファイルから始めるのがおすすめです。
