Cursor の Rules と .mdc 設定の書き方 実践ガイド

Cursor を使い込むほど、「同じ指示を毎回チャットに打ち込んでいる」「人によって AI への前提の与え方がバラバラで、生成されるコードの質が揃わない」という悩みにぶつかります。これを解決するのが Rules です。プロジェクトのルートに .cursor/rules/ ディレクトリを置き、.mdc という形式のファイルでコーディング規約や技術スタックの前提を書いておくと、Cursor がコンテキストとして自動で読み込み、毎回の指示なしに方針を守った生成をしてくれます。

この記事では、レガシーな .cursorrules から .mdc への変遷、.mdc ファイルの構造、効くルールと効かないルールの違い、ファイル種別ごとのスコープ指定、ルールの分割と命名までを、FIXIT が実プロジェクトで使っている構成を交えて解説します。Claude Code を併用している人向けに、CLAUDE.md との対応関係も整理します。

Cursor Rules とは(.cursorrules から .Cursor/rules/*.mdc への変遷)

Cursor の Rules は、AI に渡す「常設の前提情報」です。プロジェクトの言語、フレームワーク、命名規約、テストの方針、レビューで嫌われるパターンなどを書いておくと、Chat や Composer(Agent)がその内容を踏まえて回答・生成します。人間でいえば、新しくジョインしたメンバーに最初に渡すオンボーディング資料に近い役割です。

歴史的には、Cursor の Rules はプロジェクトルートに 1 枚置く .cursorrules というプレーンテキストファイルから始まりました。書くのは簡単ですが、すべてのルールを 1 ファイルに詰め込むため肥大化しやすく、「フロントエンドのときだけ効かせたい規約」と「全体に効かせたい規約」を分けられないのが弱点でした。

現在の Cursor は、.cursor/rules/ ディレクトリ配下に複数の .mdc ファイルを置く方式を推奨しています。.mdc は Markdown に YAML 形式のメタデータ(フロントマター)を付けたもので、ファイルごとに「いつ適用するか」を制御できます。.cursorrules も後方互換で読み込まれますが非推奨扱いなので、新規プロジェクトは最初から .cursor/rules/ で組むのがよいでしょう。ディレクトリ配下に置くため Git でそのままバージョン管理でき、リポジトリをクローンした全員に同じルールが効くのも利点です。

.cursor/
└── rules/
    ├── baseline.mdc
    ├── frontend.mdc
    ├── backend.mdc
    └── review.mdc

.mdc ファイルの基本構造(description / globs / alwaysApply)

.mdc ファイルは、先頭にフロントマター、その下に本文(Markdown のルール)を書きます。フロントマターで使う主なキーは description、globs、alwaysApply の 3 つです。

---
description: React コンポーネントの実装規約
globs: src/**/*.tsx
alwaysApply: false
---
 
- コンポーネントは関数コンポーネントで書き、default export は使わない。
- 状態が複雑になる場合は useReducer を検討する。
- スタイルは Tailwind CSS のユーティリティクラスで当てる。

この 3 つのキーの組み合わせで、ルールの適用タイミングが決まります。種類を整理すると次のようになります。

alwaysApply: true にすると、ファイルの種類に関係なく、そのプロジェクトでの全リクエストにルールが常時読み込まれます。言語指定や全体共通の規約はこれにします。

globs にパターンを書き alwaysApply: false にすると、そのパターンに一致するファイルを編集・参照しているときだけ自動でルールが適用されます。たとえば src/**/*.tsx ならフロントエンドのコンポーネントを触っているときだけ React 規約が効く、という挙動になります。

description だけを書いて globs を省くと、AI が「このルールが今の作業に関係しそうか」を description の文面から判断して、必要なときに自分で読み込む形になります。ここで description が曖昧だと拾われないので、後述するように具体的に書くことが重要です。

description を空にして本文だけ置いたファイルは、エディタ内で @ルール名 として手動で呼び出す使い方になります。たまにしか使わない特殊な手順(リリース作業の段取りなど)はこの形が向いています。

つまり「常に効かせる」「ファイル種別で自動的に切り替える」「AI に判断させる」「手動で呼ぶ」の 4 段階を、フロントマターの書き方で選べるということです。

効くルールと効かないルールの違い(具体・短く・例示)

Rules を書いても期待どおりに効かない、という相談はよくあります。原因の多くはルールの書き方にあります。AI に守らせるルールは、人間向けのコーディング規約ドキュメントとは書き方の最適解が違います。

効かないルールの典型は、抽象的で長いものです。「コードは保守性と可読性を重視し、適切に設計すること」のような文は、人間には響いても AI には判断基準を与えません。「適切」が何を指すのかが空欄のままなので、生成結果に反映されません。

効くルールは、具体的で、短く、できれば例が添えてあるものです。同じ意図でも「関数は 1 つの責務に絞る。50 行を超えたら分割を検討する」「early return を使い、ネストは 2 段までにする」のように、観測可能な基準に落とすと守られやすくなります。

- API レスポンスの型は zod スキーマから推論する。手書きの interface を新設しない。
- 例(良い): const schema = z.object({ id: z.string() }); type User = z.infer<typeof schema>;
- 例(避ける): interface User { id: string } を別途定義する。

このように「やること」と「避けること」を対にして、具体的なコード例を 1 つ添えるのが、いちばん効果が安定する書き方です。逆に、1 ファイルに何十項目も詰め込むと、AI が全部を等しく重視しなくなります。重要度の高い数項目に絞り、細かい話は対象ファイルが限られる別ルールへ追い出すと、コアな規約がぼやけません。

もう 1 つの勘所は、二重否定や条件分岐の多い言い回しを避けることです。「特別な理由がなければ原則として避けるが場合によっては許容する」のような文は、AI にとっては「許容してよい」と読めてしまいます。守らせたいなら「使わない」と言い切る。例外を認めるなら、どういうときに認めるかを具体的に書く。曖昧さを残さないことが、そのままルールの効き目につながります。

スコープ指定でファイル種別ごとにルールを切り替える

プロジェクトが大きくなると、フロントエンドとバックエンド、テストコードで守るべき規約が変わってきます。これを 1 ファイルに混ぜると、バックエンドを触っているのに React の規約まで読み込まれ、コンテキストが無駄に膨らみます。globs によるスコープ指定で、関係するルールだけが効くように分けるのが定石です。

たとえばテストコードだけに効かせたいルールは次のように書きます。

---
description: テストコードの実装方針
globs: ["**/*.test.ts", "**/*.test.tsx"]
alwaysApply: false
---
 
- テストは Arrange / Act / Assert の 3 段で構成する。
- 1 つの it は 1 つの観点だけを検証する。
- モックは必要最小限にとどめ、実装の内部詳細に依存しない。

globs は配列で複数パターンを指定できます。src/api/**/*.ts でサーバー側だけ、**/*.css や **/*.scss でスタイルだけ、といった形で、ファイルの場所や拡張子に応じてルールを切り替えられます。

スコープを切る利点は 2 つあります。1 つは、無関係なルールが読み込まれないのでコンテキストが軽くなり、AI が本当に関係するルールに集中できること。もう 1 つは、ルールの責任範囲がファイル名と globs から一目で分かり、メンテナンスしやすくなることです。「このルールはどこに効くんだっけ」と毎回中身を読まずに済みます。

ルールの分割と命名(baseline / tech-stack / review の整理)

ルールをどう分割するかに正解の数式はありませんが、FIXIT では「適用範囲」と「役割」で切ると運用が安定します。実際によく使うのは次の 3 系統です。

baseline 系は、プロジェクト全体に常時効かせる土台のルールです。回答言語、コミットメッセージの方針、ディレクトリ構成の前提、命名規約など、どのファイルを触っても守ってほしいことを alwaysApply: true でまとめます。ここはなるべく短く保ち、本当に全体共通のものだけを置きます。

tech-stack 系は、技術スタックごとの規約です。frontend.mdc(React/Tailwind の規約、globs: src/**/*.tsx)、backend.mdc(API レイヤの規約)、testing.mdc(テストの方針)のように、globs で対象を絞って自動適用させます。スタックを増やすときはここにファイルを足していけば、baseline を汚さずに済みます。

review 系は、レビューで繰り返し指摘されるパターンを言語化したものです。「マジックナンバーを直書きしない」「any を新設しない」「副作用のある関数に純粋関数のような名前を付けない」など、過去のレビューコメントをルールに昇格させていくと、同じ指摘の再発が目に見えて減ります。チームのレビュー知見をルールに蓄積していく感覚です。

命名は baseline.mdc frontend.mdc review.mdc のように、開いた瞬間に役割が分かる名前にします。日付や連番を付けるより、内容を表す名前のほうが、後から探すときも追記するときも迷いません。

CLAUDE.md との考え方の対応・使い分け

Claude Code を併用しているチームなら、Cursor の Rules と CLAUDE.md は同じ目的の仕組みだと捉えると整理しやすくなります。どちらも「AI に渡す常設の前提情報」であり、プロジェクトの規約・技術スタック・やってほしいこととやってほしくないことを書く点は共通です。

違いは、ファイル分割とスコープ指定の細かさです。CLAUDE.md は基本的に 1 ファイル(と階層的な配置)で全体を表現するのに対し、Cursor の Rules は .mdc ごとに globs でスコープを切り、ファイル種別ごとに自動で出し入れできます。Cursor のほうが「どのルールをいつ効かせるか」を細かく制御できる、と考えるとよいでしょう。

両方のツールを使うプロジェクトでは、規約の中身そのものはどちらでも変わらないので、共通部分は表現を揃えておくと管理がラクになります。CLAUDE.md 側の書き方の勘所はCLAUDE.md ベストプラクティスにまとめてあるので、Cursor の baseline 系ルールを設計するときの参考にもなります。実際、効くルールの条件(具体・短く・例示、曖昧さを残さない)は両ツールで共通です。

FIXIT のテンプレートに見る実運用ルール構成

最後に、FIXIT が新規プロジェクトの立ち上げ時に置く .cursor/rules/ の基本構成を紹介します。あくまで出発点で、プロジェクトに合わせて足し引きしますが、骨組みはほぼ共通です。

baseline.mdc は alwaysApply: true で、回答とコメントは日本語、コミットメッセージは prefix を英語・本文を日本語、ディレクトリ構成の前提、を数項目だけ書きます。短く保つのがポイントです。

tech-stack.mdc(または frontend.mdc / backend.mdc)は globs で対象を絞り、採用フレームワークのバージョン、型の扱い方、状態管理の方針、避けたい書き方を具体例付きで書きます。スタックが分かれているプロジェクトでは複数ファイルに分けます。

review.mdc は、そのプロジェクトのレビューで頻出する指摘を description 付きで置き、AI が関係しそうな場面で自分で読み込むようにします。プロジェクトが進むたびに、新しい指摘をここへ追記していきます。

この 3 系統で始めて、テストの方針が固まってきたら testing.mdc を、頻度の低い定型作業が出てきたらリリース手順のような手動呼び出しルールを足していくのが基本形です。重要なのは、最初から完璧を目指さないことです。まず baseline と tech-stack を最小限で置き、運用しながら「毎回同じ指示をしているな」と気づいたものをルールへ昇格させていく。この積み上げ方が、結局いちばん効くルールセットになります。

チームへ Cursor を本格導入する段階では、こうしたルールの初期セットを用意してから配ると立ち上がりが速くなります。手順の全体像はCursor をチームに導入する手順で、日本語環境での設定はCursor の日本語化と日本語設定で解説しています。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、Cursor や Claude Code をチームの開発フローに組み込む支援を行っています。ルール設計やツール定着の進め方に悩んだら、AI 開発ツール導入支援からお気軽にご相談ください。

関連記事: Cursor をチームに導入する手順はこちらでまとめています。