Cursor Rulesは『AIにチームの規約を伝える仕組み』
Cursor RulesはCursor内で、AIに対してチームのコーディング規約・設計判断・命名規則・テスト方針などを伝える仕組みです。Rulesがあると、Cursorのコード生成・補完・エージェント動作の品質が大きく上がります。本記事では、Cursor の公式ドキュメント「Rules」（2026年10月21日確認）をもとに、Cursor Rulesの基本、書き方、運用パターン、つまずきポイントを整理します。ツールの仕様は変化するため、最新は公式情報をご確認ください。
Cursor Rulesで解決すること
(1) 命名・スタイルの統一：AIがチームの規約に従ったコードを書く。(2) 設計判断の伝達：「ここはこう作る」をAIに知らせる。(3) レビュー負荷の削減：規約違反の指摘がAI生成段階で減る。(4) 属人化の解消：ベテランの知見をルール化して共有。(5) 新人の学習加速：AIに「なぜこう書くか」を聞ける。エージェント型コーディングツールの選び方 もご参考に。
Rulesの4つの種類（公式）
公式ドキュメントは、ルールを4種類に分けています。(1) Project Rules：リポジトリの .cursor/rules に置き、バージョン管理するコードベース専用のルール。(2) User Rules：自分の Cursor 環境全体にかかるルールで、Agent（Chat）が使う。(3) Team Rules：ダッシュボードから管理するチーム全体のルール（Team・Enterprise プラン）。(4) AGENTS.md：マークダウンで書くエージェント向けの指示。(5) 使い分け：プロジェクトに固有か、個人趣向か、チーム共通かで分類。Claude CodeのSkills活用 と思想が近く比較しやすいです。
Project Rules のファイル形式と適用のされ方（公式）
Project Rules は .cursor/rules の中に .mdc という拡張子のファイルで置きます。公式ドキュメントには、同じ場所に置いた普通の .md ファイルはフロントマター（先頭の設定欄）がないため、ルールとしては読み込まれないと書かれています。「書いたのに効かない」というときに、まず確認したい点です。
| 適用のされ方 | いつ使われるか |
|---|---|
| Always Apply | すべてのチャットのセッションで使う |
| Apply Intelligently | ルールの説明（description）を見て、Agent が関係あると判断したとき |
| Apply to Specific Files | ファイルが指定したパターン（globs）に当てはまるとき |
| Apply Manually | チャットで @ルール名 と呼んだとき |
すべてを Always Apply にすると、関係のない作業のときにもルールが読み込まれます。言語やディレクトリに固有のルールは globs で対象を絞り、たまにしか使わない手順書のようなルールは Apply Manually にしておくと、ルールが増えても指示がぶつかりにくくなります。公式ドキュメントは、1つのルールを500行未満に収め、大きなルールは組み合わせられる小さなルールに分けることを勧めています。
フロントマターに書く項目は alwaysApply・description・globs の3つです。たとえばコンポーネント用のルールなら、先頭に「globs: src/components/**/*.tsx」と「alwaysApply: false」を書いておくと、そのパターンに当てはまるファイルを扱うときだけ読み込まれます。公式ドキュメントの例では、この形のルールに「default export ではなく named export を使う」「コンポーネントは200行以内に収め、超えたら同じディレクトリに分ける」といった具体的な決まりが並んでいます。
AGENTS.md との組み合わせ
AGENTS.md は、.cursor/rules を使うほどでもない単純な場合の代わりとして、プロジェクトのルートに置けます。公式ドキュメントによると、サブディレクトリにも置けて、そのディレクトリの中のファイルを扱うときに自動で使われます。入れ子になった AGENTS.md の指示は親ディレクトリのものと組み合わされ、より具体的な（深い階層の）指示が優先されます。Claude Code の CLAUDE.md など、ほかのツールの指示ファイルと内容をそろえておきたいチームにとっては、マークダウンだけで書ける AGENTS.md は扱いやすい入口です。
書き方の原則
(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)レビュー継続、です。エージェント型コーディングツール もご参考に。
この記事のデータの出典
- Cursor 公式ドキュメント「Rules」（2026年10月21日確認）
