Cursor Rulesの書き方｜プロジェクト規約を対象ファイルごとに適用する

Cursor Rulesは、プロジェクトの規約や対象ファイル別の指示を`.cursor/rules`内の`.mdc`ファイルとして管理する仕組みです。1つの巨大なルールへ詰め込まず、適用範囲ごとに小さく分けると保守しやすくなります。

この記事では、4つの適用方式、Always・TypeScript・テスト用の3ルール例、scope確認と競合テストを解説します。

情報確認日：2026年7月18日（日本時間）

結論：共通規約と対象別規約を分け、適用されたかテストする

現在の規約と実行コマンドを棚卸しする
`.cursor/rules/*.mdc`へ責務ごとに分ける
Always・glob・Agent Requested・Manualを選ぶ
対象内・対象外のファイルで適用を確認する
競合する指示を削除し、変更時に更新する

Cursor Rulesの4つの適用方式

方式	適用	向く内容
Always	常にcontextへ含める	基本コマンド、禁止事項、全体方針
Auto Attached	globに一致するfileを参照したとき	言語・directory別の規約
Agent Requested	descriptionを基にAgentが必要時に参照	特定作業の詳しい手順
Manual	`@ruleName`で明示的に参照	頻度が低いreleaseやmigration

公式ドキュメントではProject RulesはAgentとCmd-Kのcontextとして説明されています。利用中の機能にどのRuleが対応するかは、Cursorの現行ドキュメントで確認してください。

まず規約を棚卸しする

install、development、test、lint、buildの正しいコマンド
主要directoryと責務
言語、framework、formatter、命名
変更してはいけない生成物やvendor
秘密情報、本番操作、DB migrationの制限
完了条件と最低限の確認

READMEやpackage scriptにない推測をRulesへ書くと、AIが一貫して間違えます。現行コードとCIを根拠にします。

例1：常に適用する基本ルール

.cursor/rules/project-core.mdcを作成します。

---
description: Core project commands and safety rules
globs:
alwaysApply: true
---

# Project core

- Install: `npm ci`
- Test: `npm test`
- Lint: `npm run lint`
- Build: `npm run build`
- Follow existing naming and formatting.
- Do not edit generated files under `dist/`.
- Never read or print secret files.
- Before finishing, run the narrowest relevant test.
- Report checks that could not be run.

Alwaysには、毎回必要な短い情報だけを置きます。長い設計書を全文入れず、必要なら参照先を示します。

例2：TypeScriptファイルへ自動適用するルール

.cursor/rules/typescript-source.mdcの例です。

---
description: TypeScript source conventions
globs: "src/**/*.ts"
alwaysApply: false
---

# TypeScript source

- Preserve strict typing; do not introduce `any`.
- Reuse types from `src/types/` before adding new ones.
- Validate unknown input at the boundary.
- Keep side effects in adapter modules.
- Add or update tests for changed behavior.

globは対象を広げすぎないようにします。テストファイルへ別規約を使うなら、sourceとtestのpatternが意図せず重ならないか確認します。

例3：必要なときAgentが参照するテストルール

.cursor/rules/testing-workflow.mdcの例です。

---
description: Use when adding or changing automated tests
globs:
alwaysApply: false
---

# Testing workflow

1. Identify the behavior and failure mode.
2. Add normal, boundary, and error cases.
3. Reuse existing fixtures and helpers.
4. Run the closest test file first.
5. Do not change production behavior only to satisfy a test.
6. Report the command and result.

Agent Requestedではdescriptionが「いつ使うか」を判断する手掛かりです。手動で確実に含めたい作業はManual ruleとして作成し、@ruleNameで参照します。

Rulesのscopeテスト表

操作	期待するRule	確認内容
`src/user.ts`を編集	core + TypeScript	strict型とtest確認が提案される
`docs/setup.md`を編集	coreのみ	TypeScript規約が混ざらない
test追加を依頼	core + TypeScript + testing	境界値と実行結果を扱う
Manual ruleを指定	core + 指定rule	`@ruleName`の内容を参照する

Cursor上で適用中Ruleを確認し、回答内容だけで推測しないことが重要です。UIの表示場所はバージョンで変わるため公式ページを確認してください。

指示競合をテストする

競合例
- core: npm testを実行する
- nested rule: pnpm testを実行する

確認
1. 実際のpackage managerはどちらか
2. nested directoryだけ別commandなのか
3. 同じ対象に矛盾する指示が適用されないか
4. 不要になった古いRuleが残っていないか
5. AIが採用したcommandを作業前に表示できるか

競合時の挙動へ頼るのではなく、同じscopeに矛盾を残さないことが基本です。monorepoではdirectoryごとの`.cursor/rules`を使い、ローカルな規約を近くへ置く方法もあります。

Rulesへ書かない方がよい内容

API keyやpasswordなどの秘密値
頻繁に変わる一時的な作業メモ
現行コードと矛盾する理想論
実行不能な「必ず完璧にする」などの抽象指示
テストやレビューを省略させる指示
複数Ruleに重複する長文

.cursorrulesは使えますか？

公式ドキュメントでは`.cursorrules`はlegacyとして扱われています。新規では`.cursor/rules`のProject Rulesを使い、既存ファイルは内容を責務別の`.mdc`へ移行します。

よくある質問

Ruleは1ファイルにまとめた方がよいですか？

共通部分は短いAlways、言語や作業別は個別Ruleに分ける方が適用範囲を確認しやすくなります。

Rulesを書けばAIの出力は保証されますか？

保証されません。Rulesはcontextであり、安全境界や自動テストの代替ではありません。差分はAIコードレビューのチェックリストで確認します。

CLAUDE.mdと考え方は同じですか？

プロジェクト指示をversion管理する点は似ていますが、書式と適用機能が異なります。Claude Code側はCLAUDE.mdの書き方を参照してください。

まとめ

Cursor Rulesは`.cursor/rules`へ`.mdc`として保存し、Always、Auto Attached、Agent Requested、Manualを用途別に使い分けます。基本規約、対象ファイル規約、作業手順を分離してください。

作成後は対象内・対象外のファイルで適用を確認し、競合や古い指示を削除します。ツール全体の比較はAIコーディングツール比較を参照してください。