Cursor Rulesは『AIにチームの規約を伝える仕組み』
Cursor RulesはCursor内で、AIに対してチームのコーディング規約・設計判断・命名規則・テスト方針などを伝える仕組みです。Rulesがあると、Cursorのコード生成・補完・エージェント動作の品質が大きく上がります。本記事では、Cursor Rulesの基本、書き方、運用パターン、つまずきポイントを編集部の視点で整理します。ツールの仕様は変化するため、最新は公式情報をご確認ください。
Cursor Rulesで解決すること
(1) 命名・スタイルの統一：AIがチームの規約に従ったコードを書く。(2) 設計判断の伝達：「ここはこう作る」をAIに知らせる。(3) レビュー負荷の削減：規約違反の指摘がAI生成段階で減る。(4) 属人化の解消：ベテランの知見をルール化して共有。(5) 新人の学習加速：AIに「なぜこう書くか」を聞ける。エージェント型コーディングツールの選び方 もご参考に。
Rulesの3階層（プロジェクト/個人/グローバル）
(1) プロジェクトRules：リポジトリ固有の規約。.cursor等で管理。(2) 個人Rules：自分の好みのコーディング習慣。(3) グローバルRules：全プロジェクト共通の方針。(4) 優先順位：プロジェクト > 個人 > グローバルの順で適用。(5) 使い分け：プロジェクトに固有か、個人趣向か、汎用かで分類。Claude CodeのSkills活用 と思想が近く比較しやすいです。
書き方の原則
(1) 具体的に：「読みやすく」より「行数50以内」「関数1つ1責務」。(2) 例を入れる：Good/Badの実例を示す。(3) なぜを書く：「ルールの背景」を簡潔に。(4) 言語・フレームワーク別に分割：1ファイルに詰め込みすぎない。(5) 更新可能に：リポジトリ管理で改善を続ける。Rulesは「人間向けドキュメント＋AI向け指示」を兼ねるよう設計します。TypeScript学習 もご参考に。
実用パターン
(1) ディレクトリ構造：「pagesはfeature単位」「APIはroutesに」等。(2) 命名規則：「kebab-case」「Booleanはis/can/has接頭辞」。(3) テスト方針：「新機能には必ず単体テスト」「mocksはvi.fn」。(4) エラーハンドリング：「Result型を使う」「Sentryにログ」。(5) セキュリティ：「APIキーは.envに」「環境変数のtype-safe化」。セキュリティエンジニアへの転身ガイド も併せて。
運用のコツ
(1) 小さく始める：3〜5個のRuleからスタート。(2) 違反パターンから追加：レビューで頻発する指摘をRule化。(3) 定期的に見直し：古くなったRuleは削除。(4) 新人のオンボーディング：Rules付きCursorは新人が早く立ち上がる。(5) チーム合意：押し付けではなく合意形成して導入。Rulesは「ベテランの暗黙知」を「チーム共通の明文知」に変える資産です。テックリード vs EM もご参考に。
失敗しがちなパターン
(1) 抽象的すぎる：「綺麗に書く」では伝わらない。(2) 多すぎて読まれない：AIにも人にも届かない。(3) 更新されない：古いRuleが残って混乱を生む。(4) 個人の押し付け：チームで合意してない指針。(5) レビューしない：AIの出力を盲信。対策は、(1)具体的に、(2)少数精鋭、(3)定期更新、(4)合意形成、(5)レビュー継続、です。エージェント型コーディングツール もご参考に。