2025年6月12日

Cursor Project Rulesのベストプラクティス

1. 公式のベストプラクティス

  • 焦点を絞り、コンパクトに ルールは「ひとつの目的」に集中させ、長くても約 500 行以下に抑えると管理しやすいです (docs.cursor.com)。
  • 大きな概念は分割 ひとつのルールに複数の異なる責務を持たせず、複数の小さなルールに分割して組み合わせることで再利用性が高まります (docs.cursor.com)。
  • 具体例を併記 抽象的な指示だけでなく、適用対象となるコード例やファイルパスを示すことで、AI に意図を正確に伝えられます (docs.cursor.com)。
  • 曖昧さを排除 「なるべく」「可能な限り」といった曖昧な文言は避け、必須事項/任意事項を明確に区別しましょう (docs.cursor.com)。
  • 既存ルールの再利用 同じプロジェクト内で似た指示が増えてきたら、共通化して使い回すことでメンテナンスコストを下げられます (docs.cursor.com)。

2. 書き方のヒント(チーム知見)

  • 同僚に説明するように 自分以外の人にも読みやすいドキュメントを書くつもりで、専門用語の定義や背景もひとこと添えると親切です (cursor101.com)。
  • プロジェクト特有のワードを活用 チームのコーディングスタイルや慣例(例:Tailwind、Framer Motion、zod など)をルール内で明示することで、AI の出力がプロジェクト標準に即したものになります (cursor101.com)。
  • 定期的な見直し・更新 プロジェクトが成長するにつれ要件も変わるため、ルールを放置せず、半年に一度などで内容をリファインしましょう (cursor101.com)。

3. MDC ファイル構成と命名規則

  • YAML 形式の .mdc ファイル Cursor は YAML ベースの MDC フォーマットのみを認識します。必ず拡張子を .mdc にし、ヘッダにメタデータ(nameglobsalwaysApply など)を記述してください (forum.cursor.com)。
  • 番号+識別子で整理 ファイル名を「001-Core-Security.mdc」「100-API-Integration.mdc」のように三桁番号+説明的な名前にすると、優先順序やカテゴリ分けがひと目でわかります (forum.cursor.com)。

4. ファイル分割とモジュール化の実践例

  • 機能別にルールを分ける

    • core.mdc:常に適用したい基本ルール
    • request.mdc:新機能追加や修正時のガイドライン といった具合に、「何を」「いつ」「どう適用するか」でファイルを分割するとメンテナンス性が向上します (medium.com)。
  • グローバル vs. スコープ適用 プロジェクトルートの .cursor/rules に加え、特定サブディレクトリにも配置してスコープを制御すると、ディレクトリごとに異なるポリシーを敷けます 。


まとめ

  1. 短く、具体的に:500行以内・動作サンプル付きで
  2. 分割・番号化:小さく分けて三桁番号+説明的ファイル名
  3. プロジェクト知見を反映:チームの用語・スタイルをルール化
  4. 定期的に見直す:要件変化に合わせて更新