複数クライアントのリポジトリを行き来すると、AIエディタの指示が前の案件のまま残り、CSSの命名規則やWordPressの触ってはいけないパスまで提案されてしまう——そんな週に整えたいのがCursor Project Rules 設定です。私はWeb制作と実装の合間でCursorを使いますが、グローバルなUser Rulesだけに頼ると、案件ごとの「ここは触るな」「ここはFLOCSS」が薄くなりがちでした。
本記事は機種選びではなく、リポジトリ単位のProject Rules（.cursor/rules など）を案件フォルダごとに分ける手順に絞ります。エディタ側の信頼境界はVS Code Workspace Trustを案件フォルダで分けるが近い話で、今回はAIへの指示文をリポジトリに紐づけます。以下は、私が実際に運用している分け方と、Cursor公式ドキュメントで説明されている概念を混ぜずに書きます。
この記事でわかること
- User Rules と Project Rules の役割の違い
- 案件リポジトリに置く
.cursor/rulesの最小構成 - クライアント別に変えるべき項目（命名・触らないディレクトリ・検証手順）
- ルールが肥大化したときの整理のしかた
先に結論
- 向いている人: 複数リポジトリを週単位で切り替えるフリーランス、Laravelと静的HTMLを別案件で扱う人、チーム共有より自分用のAI指示をリポジトリに残したい人
- 向いていない人: 1リポジトリだけを半年触り続ける人（User Rulesだけで足りることが多い）、ルールよりNotionの仕様書が正本でAIは補助だけの人
- 私のおすすめ: まず共通のUser Rulesは短くし、案件差分は必ずProject Rulesへ。リポジトリを開いた瞬間にその案件のルールだけが効く状態を作る
私は「User Rulesは口調と安全、Project Rulesはそのサイトの憲法」と割り切ると、提案のブレが一気に減りました。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
User Rules と Project Rules の違い
Cursorには、大きく分けてユーザー全体に効く設定と開いているプロジェクトに効く設定があります。名称はバージョンで表記が変わることがありますが、考え方は次のとおりです。
| 種類 | 置き場所の目安 | 書く内容 |
|---|---|---|
| User Rules | Cursor設定（アカウント／アプリ全体） | 日本語で答える、秘密を出さない、ですます調など全案件共通 |
| Project Rules | リポジトリ内 .cursor/rules/ など |
その案件のディレクトリ構成・禁止事項・検証コマンド |
User Rulesに案件固有のパスを書かないのが第一歩です。「wp-content/themes/foo は触るな」はProject Rules側にのみ書きます。そうしないと、別クライアントのリポジトリを開いたときに前の禁止パスが残り、AIが不必要に縛られたり、逆に古い案件のルールが漏れる原因になります。
手順1：リポジトリに .cursor/rules を作る
- 案件リポジトリのルートで
.cursorフォルダを作成する（既にある場合は中身だけ追加） rulesサブフォルダを作り、1テーマ1ファイルが目安（例:client-brand-voice.mdc,wordpress-boundaries.mdc）- ファイル先頭に、Cursorが認識する形式（
.mdcのメタデータや説明ブロック）を付ける——詳細はCursor公式ドキュメントのProject Rulesを参照 - 変更をGitにコミットし、クライアントリポジトリなら個人情報や本番URLをルールに書かない
私は「Voice」「Boundaries」「Verify」の3ファイルに分けることが多いです。Voiceは語り口とコミット方針、Boundariesは触らないパス、Verifyは make test や npm run build など終わり方のコマンドだけを書きます。
手順2：案件ごとに変える項目チェックリスト
Project Rulesに書く候補を、Web制作向けに絞ると次のとおりです。
- スタック判定 — Laravel / WordPress / 静的HTML など、最初に1行で宣言
- CSS方針 — FLOCSS、Tailwind、上書きCSSファイル名など
- 触らない範囲 — プラグイン本体、本番DB、他案件の共通ライブラリ
- 検証 — Dockerの
make up、Playwrightの有無、lintコマンド - アフィリエイトや個人情報 — ダミーデータのみ、
.env禁止など（全案件共通ならUser Rulesへ）
WordPressテーマ案件では「functions.php は分割読み込みのみ、コアは触らない」、静的LPでは「static/YYMMDD を正本にBladeへ当て込み」など、そのリポジトリのREADMEと同じ粒度がちょうどよいです。
ルールは長文化するとAIも人も読みません。私は1ファイル300行を超えたら「Boundaries」と「Verify」に分割しています。
手順3：VS Code 側の信頼設定とセットで使う
CursorはVS Code系のワークスペースを開きます。Workspace TrustをRestrictedのままにしていると、拡張やタスクの挙動が変わるため、Project Rulesと矛盾することがあります。案件フォルダを信頼済みにするかどうかは、クライアントのセキュリティポリシーに合わせてください。
- 信頼境界の整理: VS Code Workspace Trustを案件フォルダで分ける
- AIを使わない編集だけなら、Visual Studio Code単体でも同じフォルダ構成は有効
Project Rulesはリポジトリにコミットされるため、チームメンバーと共有しやすいのが利点です。一方、クライアントの未公開情報はルールに直書きせず、プレースホルダ（例: CLIENT_THEME_SLUG）に留める方が安全です。
手順4：グローバルUser Rulesの最小例
User Rules側には、次のような短い共通方針だけを残します。
- 回答は日本語
- 推測と体験を分けて書く
- 秘密情報（
.env、実名、本番パスワード）を出力しない - 依頼範囲外のファイルを勝手に変更しない
案件ごとに「Laravelならマイグレーション命名は日本時間」など技術スタック依存の話は、すべてProject Rulesへ移します。User Rulesが長いと、Project Rulesより優先されて見える場合があり、意図と逆になることがあります（一般論として、短いUser・厚いProjectが安定しやすいです）。
よくある失敗と対処
| 失敗 | 対処 |
|---|---|
| 前案件のルールが効いている | 別ウィンドウでリポジトリを開き直す／User Rulesから案件固有を削除 |
| AIがルールを無視する | Boundariesを箇条書き3〜7項目に絞り、Verifyに「完了前に実行するコマンド」を1つだけ書く |
| ルールとREADMEが矛盾 | READMEを正本にし、Project RulesはREADMEへの参照1行＋差分のみ |
| クライアントrepoに個人情報 | ルールから削除し、Git履歴も含めてマスク対応 |
案件A／案件Bの分け方（具体例）
案件A（静的→WordPress当て込み）のProject Rulesでは、次を強調します。
- 正本HTMLのDOM順を崩さない
- overrides CSSファイル名を固定
- Blade側でHTMLにない要素はコメントアウトで残す
案件B（Laravel API＋管理画面）では、次を強調します。
app/Http以外の大規模変更は相談- Featureテストの実行コマンドをVerifyに記載
- マイグレーションは日本時間ファイル名
同じUser Rulesのまま、リポジトリを切り替えるだけでAIの提案の土台が変わる状態が理想です。私は月曜の朝に「今週触る3リポジトリ」のProject Rulesを5分ずつ見直す習慣にしています（体験談です。必須ではありません）。
よくある質問
Q. Project Rulesは .cursorrules 1ファイルのままでもよいですか？
A. 小さな個人プロジェクトなら1ファイルでも動きます。ただし複数クライアントを扱うなら、テーマ別に .mdc を分割した方が差し替えとレビューが楽です。Gitの差分も読みやすくなります。
Q. CursorをやめてVS Codeだけに戻す場合、ルールは無駄になりますか？
A. Project RulesはCursor向けですが、中身の禁止事項や検証手順はREADMEやCONTRIBUTINGにコピーすればそのままチーム規約になります。エディタをVisual Studio Codeに戻しても、人間向けドキュメントとして再利用できます。
Q. クライアントに .cursor フォルダを見せても問題ないですか？
A. ルールに未公開URL・実データ・ログイン情報が無ければ、多くの場合は「AI用の開発規約」として共有可能です。不安ならBoundariesから本番ホスト名を削り、Issueで都度指定する運用に切り替えてください。
Q. User Rulesに「Always respond in Japanese」と英語で書く必要はありますか？
A. 英語でも動きますが、日本語案件なら日本語でUser Rulesを書く方が、私はメンテしやすいです。Project Rulesも同じ言語に揃えると、AIの出力がブレにくいです（一般論）。
まとめ
Cursor Project Rules 設定は、案件リポジトリの .cursor/rules に置き、User Rulesは短い共通方針だけに留めるのが失敗しにくいです。VS CodeのWorkspace Trustとセットでフォルダ境界を揃えると、AI提案とセキュリティの両方が整理しやすくなります。
今日やることは1つだけで十分です。いま開いているリポジトリに Boundaries.mdc を1枚追加し、触ってはいけないパスを3行書く。それだけでも、次の生成から提案の質が変わることがあります。
関連記事: VS Code Workspace Trustを案件フォルダで分ける / 在宅Mac作業環境の選び方
