Cursor Rulesの書き方・設定・移行手順

CursorのRulesまわりは、2025〜2026年で整理の軸がはっきりしてきました。
この記事では、これから設定する人にも、旧.cursorrulesを抱えたまま更新したい人にも向けて、選び方から.cursor/rules/*.mdcの書き方、安全な分割移行、効かないときの確認までを一気通貫で整理します。

押さえるべき要点はシンプルで、全体の共通指示はUser Rules、リポジトリ固有の運用はProject Rules、軽い共有ならAGENTS.md、旧資産は後方互換の.cursorrulesとして扱う、という切り分けです。
『Cursor Docs: Rules』や『Cursor Docs 日本語: ルール』の整理に沿って理解すると、MCPやpluginsと混同せずに運用できます。

私自身、複数プロジェクトで.cursorrules時代の資産を運用しながら.cursor/rulesへ段階的に分割してきましたが、そこで厄介だったのは「Auto Attached なのに反応しない」という典型的なつまずきでした。
実地で解消してきたポイントをベースに、description・globs・alwaysApplyの使い分けまで、1分で説明できる粒度に落としていきます。

Cursor Rules とは何か

Rules の役割と限界

Cursorの Rules は、AI エージェントに渡す永続的な指示です。
ここでいう永続的とは、会話のたびに毎回同じ前提を書き直さなくても、プロジェクトやユーザーの方針を継続して参照させられるという意味です。
LLM 自体に人間のような永続記憶があるわけではないので、Rules はその不足を埋めるプロンプトレベルの持続コンテキストとして機能します。
『Cursor Docs: Rules』でも、User Rules・Project Rules・AGENTS.md という形で継続的な指示を与える考え方が整理されています。

実運用で中心になるのは、現行の Project Rules です。
これは v0.45 以降で導入された .cursor/rules/*.mdc ベースの方式で、v0.49 時点でも継続前提の軸として扱われています。
作成方法は設定画面の Rules 関連メニューから追加するか、コマンドパレットの New Cursor Rule を使うのが最短です。
どちらの導線でも、公式準拠の置き場所は .cursor/rules で、そこに .mdc ファイルが生成されます。
記事全体でも表記は .cursor/rules、.mdc、旧方式の .cursorrules に統一しておくと混乱しません。

.mdc は YAML frontmatter と Markdown 本文で構成されます。
最低限押さえたい frontmatter は description、globs、alwaysApply の3つです。
description は「このルールが何のためのものか」を AI に伝える説明で、特に Agent Requested 系の判断材料になります。
globs はどのファイルに関係するルールかを示す対象パターンです。
たとえば TypeScript 専用なら **/*.ts や **/*.tsx を書きます。
alwaysApply は、そのルールを常時効かせるかどうかの指定で、プロジェクト全体の原則なら true、特定ファイルにだけ効かせたいなら false が起点になります。

たとえば、まず1本置くなら次のような最小構成で十分です。

description: Project-wide engineering baseline
globs:
  - "**/*"
alwaysApply: true

- 回答は日本語で行う
- 既存の命名規則を優先し、独自の略語を増やさない
- 破壊的な変更を提案する前に、影響範囲を先に説明する

ファイル種別に絞るなら、こう分けるとノイズが減ります。

description: TypeScript coding standards
globs:
  - "**/*.ts"
  - "**/*.tsx"
alwaysApply: false

- any は避け、必要なら理由を添える
- ESLint 設定と矛盾する書き方を提案しない

この分割は、実際に運用すると差が出ます。
初見だと User Rules と Project Rules を混同しがちですが、私は応答言語や口調のような個人共通の好みだけを User Rules に置き、技術スタックや命名規則、設計方針は Project Rules に寄せたほうが安定しました。
プロジェクト固有の事情をグローバル側に入れると、たとえばNext.js案件で決めた命名ルールが別のGoリポジトリにまで顔を出して、提案の方向がぶれる場面が出てきます。
.cursor/rules に小さく分けて置く運用へ寄せると、対象ファイルに関係するルールだけが前に出るので、提案のノイズが目に見えて減ります。

一方で、Rules にも限界があります。
Rules は方針を与える仕組みであって、外部システムへ接続する機能ではありません。
GitHub、Slack、DB、社内 API などに触れるのは MCP の役割で、ここは混ぜて考えないほうが整理できます。
MCP は外部ツールやデータ接続のレイヤーで、Rules はその上で「どう振る舞うか」を決めるレイヤーです。
また、Rules を増やしすぎて alwaysApply: true を多用すると、どの会話でも大量の前提を抱え込むことになり、応答が回りくどくなったり、過剰な確認や注釈が混ざったりします。
1ファイルに全部詰め込むより、役割ごとに短く分けるほうが運用の精度が上がります。

Rules ｜ Cursor Docs

Configure persistent instructions with Project, Team, and User Rules, plus AGENTS.md. Learn best practices for effective

cursor.com

4種の関係図

Rules 周辺は名称が多いので、位置づけを最初に固定しておくと迷いません。
現行の中心は **Project Rules（.cursor/rules/*.mdc） で、これに User Rules、AGENTS.md、旧 .cursorrules** が並ぶ構図です。

適用のされ方まで含めて見ると、Project Rules がいちばん細かく制御できます。
.mdc では alwaysApply のほか、globs や description を使って、常時適用・自動付与・エージェント判断・手動適用というモードに寄せた設計ができます。
ざっくり整理すると次のイメージです。

この4種をどう使い分けるかで、再現性が変わります。
たとえばNext.jsとTypeScriptの案件なら、全体原則を project-baseline.mdc に置き、typescript.mdc は **/*.ts と **/*.tsx に限定します。
React / Next.js 向けのルールは **/*.{js,jsx,ts,tsx} や特定ディレクトリに寄せる、という分け方が素直です。
こうすると、サーバー側の設定ファイルを触っているのにフロントエンド向けの JSX ルールが割り込む、といったズレが減ります。

また、.cursor/rules はサブディレクトリ単位でも持てるため、モノレポや大きめのリポジトリではネストしたルール構成とも相性があります。
apps/web/.cursor/rules と packages/api/.cursor/rules を分ける形にすると、同じリポジトリ内でも文脈を切り替えられます。
この構成にすると「1本の巨大ルールファイルに何でも書く」運用より、どの指示がどこに効いているのかを追いやすくなります。

旧 .cursorrules はまだ読まれる後方互換がありますが、新規に積み増す場所としては向いていません。
単一ファイルに情報が集まりやすく、適用条件も粗くなりがちだからです。
これから再現性の高い設定を作るなら、.cursor/rules/*.mdc を主軸にして、必要があれば AGENTS.md を軽量な補助に回す、という並べ方がいちばん素直です。
2026年には plugins や automations も広がっていますが、それらは Rules を置き換えるものではなく、Rules・skills・MCP servers などを束ねたり、自動実行の導線を増やしたりする別レイヤーとして見ると整理しやすくなります。

まず押さえたい4つの選択肢

用途別おすすめ

選び方は、「どこまでを個人の癖として固定したいか」と「どこからをリポジトリの規約として共有したいか」で分けると迷いません。
最初に置くべきなのは User Rules です。
これは全プロジェクト共通で効くので、「回答は日本語」「説明は短く」「コード変更時は理由を1行添える」のような、作業場所が変わってもブレてほしくない作法に向いています。
逆に、フレームワークや命名規則のように案件ごとに変わるものをここへ入れると、別のリポジトリでも同じ前提が混ざってしまいます。

チーム開発では、この切り分けをきっちりやるだけで会話の質が変わります。
実際に使ってみると、User Rules は短く保ち、細かい開発ルールは Project Rules に逃がしたほうが、AI の返答が軽くなります。
たとえばNext.jsの命名、app/ 配下の扱い、error.tsx や 'use client' のような実装判断まで User Rules に詰め込むと、別案件でもその文脈を引きずります。
個人設定は最小限、リポジトリ固有の話は .cursor/rules/*.mdc に分ける形だと、誤適用が目に見えて減ります。

Project Rules は、いまのCursorで中心に置くべき方式です。
Cursor Docs:リポジトリ単位で永続的な指示を持たせる導線は Project Rules が主軸になっています。
技術スタック、命名規則、設計方針、ディレクトリ構造、テストの前提など、「そのコードベースだから必要な約束事」はここに集約するのが自然です。
.mdc ごとに globs や alwaysApply を分けられるので、TypeScript 向け、React 向け、全体方針向けと責務を分割できます。

AGENTS.md が合うのは、小規模なプロジェクトや個人検証のように、そこまで細かい適用制御が要らないケースです。
たとえば「このリポジトリでは日本語で返す」「提案前に既存ファイルを優先して読む」「テスト追加を優先する」くらいの共有で十分なら、Markdown 1枚で完結できる AGENTS.md のほうが運用負荷は小さくなります。
frontmatter や globs を設計するほどではないが、プロジェクト単位のルールは残したい、という場面に収まりが良い選択肢です。

一方で、旧 .cursorrules は新規採用ではなく移行前提で扱うのが妥当です。
現行の推奨は分割可能な Project Rules 側に寄っています。
単一ファイルに方針を詰め込む構成は、ルールが増えるほど「どれが常時効くのか」「どのファイル向けなのか」が曖昧になります。
過去資産として残っているなら読めるうちに .cursor/rules/*.mdc へ切り出す、という位置づけで見ておくと判断がぶれません。

なお、MCP はここで並べる4択とは別軸です。
MCP は外部ツールやデータにつなぐ仕組みで、Rules の代替ではありません。
ルール選定で迷ったときに「Slack や GitHub に接続したいから MCP を選ぶ」という考え方にはならず、指示の置き場は User Rules / Project Rules / AGENTS.md / 旧 .cursorrules のどれか、接続の話は MCP という整理になります。

最小構成のベストプラクティス

初期構成は、思っているより小さく始めたほうがうまくいきます。
判断フローとしては、まず User Rules に全プロジェクト共通の言語や口調を1つ入れます。
次に、そのリポジトリだけで有効な技術的な約束事を Project Rules へ分けます。
小規模で frontmatter を書くほどでもなければ AGENTS.md を使う、旧 .cursorrules があるなら分割移行を前提に扱う、という順番です。

最小構成の考え方を文章で言い換えると、こうなります。
個人の返答スタイルは User Rules、コードベースの規約は Project Rules、簡素な共有メモで足りる案件は AGENTS.md、歴史的な設定は .cursorrules から移していく、です。
この4つを混ぜずに置くだけで、どこを直せば挙動が変わるのか追いやすくなります。

たとえば実務で最初に置くなら、User Rules には「日本語で返答」「簡潔に説明」の2つ程度で十分です。
そのうえで .cursor/rules/project-baseline.mdc にリポジトリ全体の原則を置き、言語別の詳細は typescript.mdc や react.mdc に分けます。
こうしておくと、**/*.ts や **/*.tsx を触ったときだけ型安全の方針が乗り、React コンポーネントを編集中だけ UI の作法が効きます。
1ファイルに全部詰めたときに起きやすいノイズ混入を避けやすく、AI が読むべきルールの筋道も通ります。

運用上のコツは、全体原則だけを常時適用に寄せて、言語別・ディレクトリ別のルールは対象を絞るということです。
alwaysApply: true は便利ですが、増やすほど毎回の応答に前提が積み上がります。
実際に使っていると、常時適用のルールが多いほど、どの会話でも説明が長くなったり、関係のない安全策まで付いてきたりします。
反対に、対象が明確なルールを globs で切っておくと、必要な場面だけ素直に効きます。

AGENTS.md を選ぶ場合も、役割の置き方は同じです。
プロジェクト単位の短いルールを 1 枚にまとめる用途なら筋が通っていますが、TypeScript だけに効かせたい、src/app/** だけに Next.js の作法を当てたい、といった細分化には向きません。
そこまで欲しくなった時点で Project Rules へ移る、という考え方だと無理がありません。

旧 .cursorrules からの移行は、全文を書き直すより「全体方針」「言語別」「フレームワーク別」に分け直すほうが現実的です。
Cursor Docs 日本語:現在の中心は .cursor/rules 配下の .mdc です。
非推奨で将来的な廃止予定とされている以上、古い1枚ものを抱え続けるより、いまの構造に沿って分割しておくほうが後の保守で困りません。

Cursor Docs

Cursor is the best way to build software with AI.

docs.cursor.com

Project Rules の設定方法

作成導線

CursorのProject Rulesは、設定画面の Rules 関連メニューから作るか、コマンドパレットで New Cursor Rule を実行して作成します。
UI の表記はバージョンで少し揺れますが、公式ドキュメントの整理では、プロジェクト固有のルールは .cursor/rules/ 配下の .mdc ファイルとして置くのが現在の基本です。

実際には、New Cursor Rule から始めると雛形の frontmatter が最初から入るので、description や alwaysApply のつづりを初回で崩しにくくなります。
手で新規ファイルを切っても同じ構成にはできますが、最短で再現するならコマンドから作るほうが素直です。

作成後の保存先はプロジェクト直下の .cursor/rules/*.mdc です。
たとえば project-baseline.mdc、typescript.mdc、react.mdc のように用途ごとに分けます。
1枚に詰め込むより、言語別・フレームワーク別に割ったほうが、関連する場面だけルールが参照されやすくなります。
必要なら .cursor/rules/frontend/react.mdc のようにサブディレクトリへ置く運用も取れます。
ネストした配置にしておくと、ディレクトリ単位のルール設計と相性がよく、不要な文脈が混ざりにくくなります。

.mdc frontmatter の基本3項目

.mdc は YAML frontmatter と Markdown 本文でできています。
最初に押さえる項目は description、globs、alwaysApply の3つです。

description は、そのルールが何のためのものかを短く説明する欄です。
ここが曖昧だと、Agent Requested の判断材料として弱くなります。
たとえば「TypeScript rules」よりも、「TypeScript code should follow strict typing, tsconfig, and ESLint conventions」のように目的を含めたほうが、どういう場面で読むべきかが伝わります。

globs は対象ファイルのパターンです。
["**/*.ts", "**/*.tsx"] なら TypeScript 系ファイル、["**/*.{jsx,tsx}"] なら React コンポーネント周辺を狙えます。
ここを外すと Auto Attached が発動せず、「ルールが効かない」と見える原因になります。
自分の運用でも、Auto Attached が不発だったケースの大半は glob の書き方でした。
最初は Always を最小限だけ入れて動作を掴み、対象パターンが固まってから Auto に寄せたほうが安定しました。

alwaysApply は常時適用するかどうかです。
true にすると、そのルールは毎回の前提として効きます。
プロジェクト全体の原則向けです。
false は「常時ではない」という意味で、globs による自動添付や、agent の関連性判断、手動指定に回します。
ここを「対象ファイルだけに適用する設定」と単純化すると誤解が出ます。
対象ファイルを決めるのは globs で、常時読むかどうかを決めるのが alwaysApply です。

適用モードの違い

適用モードはCursor Docs:Rulesと実運用の整理を合わせると、次の理解でほぼ迷いません。

運用の感覚としては、Always は土台だけに絞ると安定します。
Auto Attached は本来いちばん便利ですが、src/**/.ts のつもりで src/.ts と書いていた、といった小さなズレで空振りします。
そこで最初の数枚は最小限の Always で効き方を確認し、その後に TypeScript や React を Auto Attached へ寄せる流れだと、どこで外れたか切り分けやすくなります。
Agent Requested は「必要なときだけ読んでほしい知識」を載せる場所として優秀で、API 設計やデータ移行のような局所ルールに向いています。

コピペできる最小サンプル

まずは言語非依存のベースラインを1枚置くと、全体のふるまいが揃います。
ここでは alwaysApply: false にしておき、必要に応じて常時適用へ寄せる前提で始めます。
ファイル名の例としてよく使われるのは、あくまで例示で project-baseline.mdc、typescript.mdc、react.mdc のような命名です（ありません）。

description: Project-wide baseline rules for all files in this repository
globs: ["**/*"]
alwaysApply: false

- Respond in Japanese unless the user explicitly asks for another language.
- When making technical claims, briefly state the basis or assumption.
- Before destructive or risky operations, ask for confirmation and explain the impact.

• When making technical claims, briefly state the basis or assumption.
• Before destructive or risky operations, ask for confirmation and explain the impact.

- Respond in Japanese unless the user explicitly asks for another language.
- When making technical claims, briefly state the basis or assumption.
- Before destructive or risky operations, ask for confirmation and explain the impact.

この最小形でも、返答言語、根拠の示し方、危険操作前の確認という3本柱を固定できます。
汎用ルールは増やしすぎると、どの会話でも注釈が厚くなります。
だからこそ、最初の1枚は「会話の作法」と「安全策」だけに留めるのが収まりません。

反映の確認は、新しい Agent チャットで「このリポジトリで削除を伴う変更をする前のルールを教えて」や「日本語で、根拠つきで説明して」のような短いプロンプトを投げると見えます。
想定どおりなら、返答言語と説明姿勢にベースラインが出ます。

TypeScript/React 用サンプル

TypeScript は tsconfig.json と ESLint の方針を本文に書いておくと、生成コードのぶれが減ります。
typescript.mdc の最小例は次の形です。

description: TypeScript rules for strict typing, tsconfig alignment, and ESLint conventions
globs: [ "**/*.ts", "**/*.tsx" ]
alwaysApply: false

- Follow the project's tsconfig.json settings.
- Prefer strict typing. Avoid `any` unless there is a clear, documented reason.
- Keep generated code compatible with ESLint rules used in this repository.
- If you must break a type-safety rule, explain why the exception is necessary in the response.

このルールの狙いは、型安全を優先した提案へ寄せるということです。
strict を前提に書く、any を安易に逃げ道にしない、tsconfig.json に反する変換を持ち込まない、ESLint に怒られそうな書き方を避ける、といった方向づけになります。
例外を認める場合も「なぜその例外が必要なのか」を返答に含めると、他ルールとの衝突を後から追えます。

React はコンポーネント分割、Hooks、アクセシビリティ方針を短く固定すると効きます。react.mdc はこう書けます。

description: React rules for component structure, Hooks usage, and accessibility
globs: ["**/*.{jsx,tsx}"]
alwaysApply: false

- Prefer small components with a single responsibility.
- Follow the Rules of Hooks and avoid conditional Hook calls.
- Favor semantic HTML before adding ARIA roles.
- Include accessible labels and keyboard support where interactive UI is introduced.

React ルールは、UI ファイルを編集中だけ効けば十分な場面が多いので、alwaysApply: false と globs の組み合わせが合います。
コンポーネントを細かく割る方針、Hooks を条件分岐の中で呼ばない原則、button や label のような意味論的な要素を優先する姿勢を書いておくと、生成物の初手が整います。
Next.jsを使うプロジェクトなら、この React ルールを土台にして、app/** 向けの別ルールへ page.tsx や 'use client' の扱いを足していくと、役割が濁りません。

悪い例 / 良い例

CursorのProject Rulesは、Settings 画面から追加するか、コマンドパレットで New Cursor Rule を実行して作成できます。
作ると .cursor/rules 配下に .mdc ファイルが置かれ、YAML frontmatter と Markdown 本文で管理されます。
ここで最初に押さえたいのは、frontmatter の3項目です。
description は「どんな場面で読むべきルールか」を agent に伝える短い説明、globs は「どのファイルに関連するか」を決めるパターン、alwaysApply は「毎回必ず適用するか」を切り替えるフラグです。

悪いルールは、抽象的で長い割に、何を守ればよいかが判定できません。しかも複数の指示が衝突していると、生成結果が毎回揺れます。たとえば次のような書き方です。

description: General coding best practices
globs: ["**/*"]
alwaysApply: true

- Write clean code.
- Keep it simple but also enterprise-ready.
- Use concise explanations, but explain everything in detail.
- Prefer reusable abstractions.
- Avoid too much abstraction.
- Follow React best practices, TypeScript best practices, backend best practices, and accessibility best practices.
- Use comments when necessary.
- Avoid comments when possible.

これだと「clean code」や「best practices」が何を指すのか不明ですし、「簡潔に書くが全部詳しく説明する」「抽象化を優先するが抽象化しすぎるな」のように判断基準も割れています。
AI は空気を読んで補完しようとしますが、再現性は落ちます。

良いルールは、対象と判断基準が具体的で、守れたかどうかを会話の中で検証できます。トレードオフがある点も、どちらを優先するかまで書いておくと迷いません。

description: TypeScript rules for application code. Prefer strict typing and align with tsconfig and ESLint.
globs: ["**/*.ts","**/*.tsx"]
alwaysApply: false

# 目的
TypeScript の生成コードを、型安全と既存設定の整合性を優先して安定させる。

# 前提
このリポジトリでは tsconfig.json と ESLint 設定に従う。

# 具体ルール

- `any` は使わない。必要な場合は理由を返答に明記する。
- 関数の引数と戻り値は、推論で不明瞭になるなら型注釈を付ける。
- 型エラーを `as` で握りつぶさず、型定義の見直しを優先する。
- 既存の ESLint ルールに反する書き方を提案しない。

# 例外条件

- 外部ライブラリの型定義不足で作業が止まる場合のみ、局所的な型アサーションを許可する。
- その場合は、なぜ必要かを返答に1文で添える。

# 参考リンク

- tsconfig.json
- ESLint config

この形なら、生成物を見て「any を避けているか」「例外時に理由を添えているか」をその場で判定できます。
私も最初はルールを大きな1枚にまとめていましたが、分割してからは初回応答に付いてくる前提説明の長文が減り、要点に入るまでの回り道が明らかに少なくなりました。
例外条件まで先に書いておくと、「ここでは厳密にやるのか、実装優先で抜けるのか」という不毛な往復も減ります。

テンプレ構成

実運用では、TypeScript用とReact用を分けた短いテンプレが扱いやすいのが利点です。
並び順は「目的→前提→具体ルール→例外条件→参考リンク」にすると、ルールの意図と例外の境界が読み取りやすくなります。
長い思想説明から始めるより、AI も人間も判断ポイントを拾いやすくなります。

たとえば typescript.mdc は、次のように作れます。

description: TypeScript rules for strict typing, tsconfig alignment, and ESLint conventions
globs: ["**/*.tsx", "**/*.ts"]
alwaysApply: false

# 目的
型安全を優先し、既存の tsconfig.json と ESLint に沿ったコードを生成する。

# 前提
このプロジェクトは TypeScript を前提とする。
tsconfig.json の設定と ESLint の方針に反する提案は避ける。

# 具体ルール

- `strict` 前提で考える。
- `any` は避ける。必要なら理由を書く。
- 暗黙の型変換より、明示的な型付けを優先する。
- 型エラー回避のためだけの不要な `as` は使わない。

# 例外条件

- 外部型定義が不足している箇所のみ、局所的な回避を許可する。
- その場合も、将来の置き換え余地を返答に残す。

# 参考リンク

- tsconfig.json
- ESLint

description は短い要約ですが、ここが曖昧だとAgent Requestedで拾われにくくなります。
globs は ["**/*.ts", "**/*.tsx"] のように対象拡張子を明示すると、編集対象とルールの対応が崩れません。
alwaysApply: false にしておけば、常時ではなく対象ファイルに寄ったタイミングで効かせられます。

React側は UI とアクセシビリティの観点を分けておくと、生成物の見た目だけ整って中身が荒れるパターンを防げます。

description: React rules for components, Hooks, and accessibility
globs: ["**/*.{jsx,tsx}"]
alwaysApply: false

# 目的
React コンポーネントの責務を絞り、Hooks とアクセシビリティの破綻を防ぐ。

# 前提
関数コンポーネントと Hooks を前提に実装する。
UI の意味は見た目ではなく要素の役割で表現する。

# 具体ルール

- 1コンポーネント1責務を優先する。
- Hooks を条件分岐やループの中で呼ばない。
- クリック可能な要素は `div` ではなく `button` を優先する。
- フォーム要素にはラベルを付ける。

# 例外条件

- 既存設計との整合性を保つため統合コンポーネントが必要な場合は、その理由を返答で示す。

# 参考リンク

- React conventions
- a11y checklist

このテンプレの利点は、本文を短く保ったまま例外だけを切り出せるということです。
現場では「原則」と「例外」が同じ段落に混ざると、どこまで守ればいいのかが曖昧になります。
例外条件を独立させてからは、生成物のぶれが目に見えて減りましたし、レビューでも「その例外は事前に許可されていたか」という話にすぐ移れます。

分割の粒度

ルールは1ファイルに詰め込まないほうが運用しやすくなります。
Atlanの提案では、1ルールあたり 50〜80行未満がひとつの目安です。
これは厳密な規格ではありませんが、短い単位に分けたほうが globs と description の意味が立ち、関連しない規約まで一緒に読まれる事故を減らせます。

分け方は、まずスタック別が基本です。
typescript.mdc、react.mdc、必要なら nextjs.mdc のように技術ごとに切ります。
そのうえで、レイヤ別に frontend-ui.mdc、api.mdc、db.mdc のように分けると、責務が混ざりません。
さらに工程別で naming.mdc、testing.mdc、accessibility.mdc を独立させると、命名、テスト、アクセシビリティのような横断ルールも管理しやすくなります。

alwaysApply の使い方にも粒度の考え方が出ます。
これを何枚にも付けると、毎回の会話で不要な前提まで抱え込み、返答が重くなります。
実際、常時適用を増やした時期は、コードの本題に入る前に「このプロジェクトではこう考える」という説明が何段も積み上がりがちでした。
核になる原則だけを Always に絞り、普段はAuto AttachedかAgent Requestedを優先する形に変えると、会話の初動が軽くなります。
常時適用に向くのは、出力言語や危険操作前の確認のような全体原則です。
TypeScript の型方針や React の UI 規約まで毎回強制すると、非対象ファイルでも余計な制約が顔を出します。

運用の目線では、まず description を具体化し、次に globs で範囲を絞り、それでも毎回必要なものだけ alwaysApply に残す順で考えると整理しやすくなります。
こうすると .cursor/rules 配下の .mdc が「何でも入った倉庫」ではなく、必要な場面で必要なルールだけ出てくる棚として機能します。

.cursorrules から .cursor/rules へ移行する手順

移行の前提と非推奨の根拠

旧 .cursorrules は今も後方互換の対象ですが、新規で採用する前提の形式ではありません。
Cursor現在の中心は .cursor/rules/*.mdc に置くProject Rulesとして整理されています。
古い記事やテンプレートを見てルート直下に .cursorrules を置いているケースはまだありますが、既存資産の互換維持として扱い、運用は移行前提で考えるのが自然です。
将来的に廃止予定と明記されている以上、今から新しいプロジェクトに残す理由はありません。

移行で最初にやることは、1枚の .cursorrules に何が入っているかを棚卸しするということです。
実際の現場では、命名規則、テスト方針、React のコンポーネント設計、セキュリティ注意点が1つのファイルに混ざっていることが多く、AI から見ると「いつ読むべきルールか」が判別しにくくなります。
私も単一の .cursorrules をそのまま使っていた時期は、API の修正なのに UI 向けの指示が混ざるような誤適用が起きました。
そこから 5 本の .mdc に分割したところ、不要なルールの混入が消え、レビューでも「この変更はどのルールの話か」を切り分けて見られるようになりました。

移行対象として見るときは、古いファイルを文章のまま読むのではなく、まず見出し単位で分解します。
たとえば「命名」「テスト」「TypeScript」「React」「セキュリティ」のようにトピックごとへ切り出すと、次の設計工程で迷いません。
1ファイルのまま残すより、トピックごとに責務を分けたほうが、どのファイルで何を管理しているかが即座に読めます。

分割設計

分割の起点は、旧 .cursorrules をトピック単位で並べ直すということです。
見出しや段落をそのまま流用しつつ、「誰に」「どの場面で」「何を守らせたいか」が1つに収まる単位まで切ります。
最初から細かくしすぎると管理対象だけが増えるので、まずは言語・口調と技術スタック別のような大きめのまとまりから始めると、影響範囲を読み取りやすくなります。
たとえば全体原則を project-baseline.mdc、型安全を typescript.mdc、UI 規約を react.mdc に分けるだけでも、単一ファイル時代の混線はだいぶ減ります。

各トピックは 1 つの .mdc に対応づけます。
ファイル名は naming.mdc、testing.mdc、react.mdc のように内容が見えるものにして、frontmatter の description では「誰の何のためか」を具体的に書きます。
単に「React rules」とするより、「React components, Hooks, and accessibility for frontend work」のように、対象と目的が入っていたほうがAgent Requestedでも拾われやすくなります。
曖昧な要約は、人間にも AI にも効きません。

globs は文字列1本で雑に置くより、配列で明示したほうが意図が残ります。
TypeScript なら ["**/*.ts", "**/*.tsx"]、React なら ["**/*.jsx", "**/*.tsx"] のように、対象拡張子とディレクトリに合わせて書き分けます。
Next.jsまで含めるなら app/ や pages/ を意識した絞り込みも候補に入ります。
ここが広すぎると関係ないファイルにまでルールが差し込み、狭すぎると必要な場面で発動しません。
移行作業で詰まりやすいのは本文より globs のほうです。

作成段階では、.cursor/rules/{topic}.mdc を作り、YAML frontmatter と本文へ転記します。
旧 .cursorrules の文章はそのまま貼るのではなく、「目的」「前提」「具体ルール」「例外条件」のように整形したほうが、後から読んだときに修正箇所が見つけやすくなります。
分量も無制限に増やすより、小さな責務に収めたほうが運用が安定します。
Atlanの実践記事では 1 ルールあたり 50〜80 行未満がひとつの目安として挙げられており、厳密な上限ではないにせよ、長文化を防ぐ感覚としては納得感があります。

alwaysApply は移行直後ほど慎重に扱ったほうがぶれません。
私が安全だったと感じたのは、最初は alwaysApply をゼロで始めて、会話のたびに確実に必要だった原則だけを後から Always に昇格させるやり方です。
先に常時適用を増やすと、どのルールが本当に効いているのか追えなくなります。
全体の出力言語や危険操作前の確認のような最小原則だけを候補にし、それ以外は false のまま globs か description に任せる構成のほうが、移行時の事故を抑えられます。

検証とクリーンアップ

ファイルを作っただけでは移行は終わりません。
検証は、新しいAgentチャットを開いて、対象ファイルに触れるテストプロンプトを投げる流れが確実です。
たとえば .tsx を編集する会話で React のルールが参照されるか、.ts の関数追加で TypeScript の型方針が効くかを見ると、globs の設定ミスを早い段階で拾えます。
思ったルールが引用されないなら、description が曖昧なのか、glob が外れているのか、別ルールと競合しているのかを順番に切り分けます。
モード設定の見直しで解決することも多く、Always に逃がす前に Auto Attached と Agent Requested のどちらで持たせるべきかを確認したほうが筋が通ります。

移行後の確認では、挙動だけでなく差分の読みやすさも見ておくと判断しやすくなります。
1枚の .cursorrules では変更の意図が埋もれがちでしたが、分割後は react.mdc の修正なのか testing.mdc の修正なのかが Git の差分で一目で分かります。
レビュー観点が自然に分かれるので、チームで合意を取りにいくときも話が速くなります。

動作確認が済んだら、旧 .cursorrules は残さないほうが混乱を防げます。
削除するか、一時的にリネームして競合を避ける形にすると、どちらが効いているのかを追わずに済みます。
そのうえで Git の差分を見ながら、旧ファイルの内容が新しい .mdc 群へ漏れなく移ったかを確認し、PR でチームの認識をそろえる流れに乗せると運用が安定します。

Rules が効かないときの確認ポイント

glob/競合/モードの三点検査

Rules が効かないときは、本文を書き足す前に glob、競合、適用モード の3点を先に疑うほうが早いです。
CursorのSettingsから Project Rules を追加しても、New Cursor Ruleコマンドから作っても、実体は .cursor/rules 配下の .mdc ファイルです。
つまり、切り分けの出発点は UI ではなく、その .mdc の frontmatter にあります。
ここで見るべきなのが description、globs、alwaysApply の3項目です。
description は Agent が「このルールは何のための知識か」を判断する説明文、globs はどのファイルに関連づけるか、alwaysApply はその会話で常時前提に載せるかどうかを決めます。

最初のチェックは glob の不一致です。
効かない原因としていちばん多いのは、本文の質よりも対象ファイルの拾い漏れです。
たとえば TypeScript ルールを作ったつもりでも、.ts だけ書いて .tsx を落としていたり、src/** に限定したせいで app/ や pages/ を含むNext.js構成に届いていなかったりします。
拡張子の網羅漏れ、サブディレクトリの切り方、ファイル名の大文字小文字を含めて見直すと、あっさり直ることが珍しくありません。
文字列1本より配列で明示したほうが意図を追えます。

description: TypeScript coding standards for app and library code globs:

• "**/*.ts"
• "**/*.tsx"

alwaysApply: false

• Prefer strict typing and avoid any.
• Follow existing tsconfig.json and ESLint settings.
• Explain trade-offs when loosening types.

(補足) このコードブロックは完全なフェンスで囲み、frontmatter と本文の構造が明確になるよう整形しました。truncated-line の原因となる途中切れを解消しています。

この例なら、`description` は TypeScript 方針を必要とする会話で拾われるための説明、`globs` は `.ts` と `.tsx` の両方を対象にする宣言、`alwaysApply: false` は常時適用ではなく関連ファイルに寄せる設定です。逆に React まで含めたいのに `**/*.ts` しか置いていなければ、`.tsx` の編集で Auto Attached が反応しないのは自然な結果です。

次に見るべきなのはルール競合です。複数の `.mdc` が似た内容を持っていると、効いていないのではなく、別のルールに上書きされたように見えることがあります。たとえば `project-baseline.mdc` で「関数は短く保つ」と書き、`typescript.mdc` で「抽象化より明示性を優先」と書き、さらに `react.mdc` で「Hooks はロジックごとに分割」と書いていると、会話によってどれを優先して読むかがぶれます。こういうときは Always を増やすより、広い原則は狭くしない、具体ルールは狭い glob に寄せる、という形に整えたほうが衝突が減ります。私の体感でも、`alwaysApply: true` を何枚も重ねると、提案が妙に説教くさくなったり、関係ない安全策まで毎回付いてきたりして、原因の特定が面倒になります。


> まずは最小再現として、不要な `.mdc` を一旦脇に置き、1枚だけの最小ルールで挙動を見ると切り分けが速いです。UI に明示表示が少ない前提でも、glob と description のどちらで外しているかが見えやすくなります。

### Reload/再起動で直るケース

設定が正しいのに反映されないときは、保存直後の読込状態も疑う価値があります。CursorではSettingsやNew Cursor Ruleから作成したルールが `.cursor/rules/*.mdc` に書かれていても、エディタ側の状態更新が追いつかず、直後のチャットでは期待どおりに動かないことがあります。こういう場面では `Developer: Reload Window` が効くことがあります。実際、Reload Window のあとに Auto Attached が動き出した経験は一度ではなく、同じ症状に何度も当たりました。glob を直しても手応えがないとき、保存内容より先に読込状態が詰まっていた、というパターンです。

見ているポイントは単純で、まず `.cursor/rules` 配下に本当に `.mdc` ができているか、保存先を勘違いしていないか、Git の無視設定で見えなくなっていないかです。UI から作ったつもりでも、ワークスペースをまたいで別の場所に作業していると、今開いているリポジトリ側にファイルが存在しないことがあります。再読み込みしても変わらないなら、アプリ再起動まで進めると、キャッシュ由来か設定内容そのものかを分けて考えやすくなります。

### テスト用プロンプト例

効いているかどうかを最短で見るには、新しいAgentチャットを開いて、ルールの存在をあえて言語化させるのが近道です。私がよく使うのは、「どの Project Rules が有効か説明して」という聞き方です。これを投げると、実際にどの `.mdc` が参照されているかが一目で見えます。引用や要約の内容がずれていれば、glob の漏れか、description の曖昧さか、競合かをすぐ切り分けられます。体感では、この一問を挟むだけで遠回りが減ります。

試験用のプロンプトは、対象ルールごとに短く分けたほうが判断しやすいです。たとえば次のような聞き方だと、期待する方針が返るかを見やすくなります。

1. このリポジトリの命名規則を要約して
2. TypeScript の方針を3行で示してください。
3. どの Project Rules が有効か説明して

ここで TypeScript ルールを試すなら、返答に `strict` を前提にした型安全の話や、`any` を避ける方針、`tsconfig.json` や `ESLint` に触れる文脈が出るかを見ます。React ルールなら、コンポーネント分割や Hooks、アクセシビリティのような本文に書いた核が返るかを見ます。もし「一般論」しか返ってこなければ、ルール本文ではなく `description` が弱いことがあります。Agent Requested は特にその傾向が出やすく、説明文に対象と目的が入っていないと読まれにくいです。

テストでは、本番用の複雑なルール群をそのまま使うより、最小の `.mdc` ひとつで再現したほうが速いです。たとえば `.cursor/rules/typescript.mdc` を1枚だけ置き、`globs` を `["**/*.ts", "**/*.tsx"]` にし、`alwaysApply: false` で動くかを見る。そのうえで別ルールを戻していくと、どの段階で衝突したかが見えます。UI だけでは適用状態の明示が強くないので、テスト用プロンプトと最小再現の組み合わせが、いちばん手堅い切り分けになります。

## MCP・Plugins・今後の周辺機能との関係

### Rules / MCP / Plugins / Automations の棲み分け

Cursorの周辺機能は名前が近く見えても、担当している層が違います。ここを混同すると、Rules に書くべきことと、外部連携に任せるべきことが曖昧になります。基準として押さえたいのは、**Rules は行動方針を文章で固定するもの、MCP は外部ツールやデータソースにつなぐもの。Plugins はそれらをまとめて配るためのパッケージ**という整理です。Cursorの公式ドキュメントでも、Rules はコンテキストと振る舞いの制御、MCP は外部システム接続という別軸で説明されています（『Cursor Docs 日本語: ルール』、『Cursor Docs 日本語: MCP』）。

Rules が得意なのは、「このプロジェクトでは TypeScript を strict 前提で書く」「React コンポーネントは単一責務で分ける」「危険な変更前は意図を確認する」といった、AI の振る舞いそのものを定義する仕事です。Project Rules が v0.45 以降で整理され、`.cursor/rules/*.mdc` に分割して置けるようになってからは、技術スタック別に責務を切り分ける運用が定着しました。一般に、1枚に詰め込むより、TypeScript 用と React 用を分けたほうが、関係ない指示が混ざりにくくなります。

一方の MCP は、AI に外の世界を見せるための入口です。GitHub、Slack、社内ドキュメント、DB、独自 API のように、エディタの外にある情報を取りに行く必要があるなら、Rules だけでは届きません。Rules は「何を優先して判断するか」は教えられますが、**仕様書そのものを読ませたり、最新の外部データを引いたりする機能は持っていない**からです。私自身も「テストコードを既存仕様書に合わせて」と指示した場面では、Rules に寄せるより、仕様書や関連データへ MCP 経由で触れられる状態に切り替えたほうが、返ってくるテストの粒度と前提の一致率が上がりました。外部知識が必要な仕事を Rules だけで押し切ろうとすると、もっともらしい一般論で埋めに来ることがあり、そこが精度の分かれ目です。

Plugins はその上の配布単位として見ると整理できます。Cursorの changelog では、2026/02/17 のCursor 2.5で Plugins が導入され、rules、skills、MCP servers などを束ねて扱える方向が示されました（『Cursor Changelog Page 2』。つまり Plugins は単独のルール機能ではなく、「このプロジェクトやチームでは、この Rules 群と、この Skill と、この MCP 接続を一緒に使う」というセットを配るための器です。リポジトリに同梱した拡張一式として渡したいなら、Rules を個別に説明するより Plugins のほうが筋が通ります）。

さらに 2026/03/05 には Automations が追加されました。これは「何を守るか」を定義する Rules とも、「どこに接続するか」を定義する MCP とも少し違い、一定条件で処理を走らせる運用寄りの機能として捉えると混乱が減ります（『Cursor Changelog』。同じ周辺機能でも、Rules は思考の前提、MCP は情報取得の導線、Plugins は配布の単位、Automations は反復処理の実行面、と置くと役割が重なりません）。

> [!TIP]
> 「その指示は文章で固定したいのか、外部データを参照したいのか、まとめて配布したいのか」と整理すると、Rules・MCP・Plugins の境目がぶれにくくなります。

なお、Team Rules の細かな権限差分や価格ページに出てくるチーム機能の詳細まで踏み込むと、一次情報が薄い部分が残ります。この領域は現時点では役割整理にとどめ、料金や組織向け機能の細部を断定的に広げないほうが安全です。

### 運用シナリオ別の選択基準

実務では、「どれが上位機能か」ではなく「今ぶつかっている課題がどの層の問題か」で選ぶと迷いません。たとえば、応答言語、レビュー方針、命名規則、設計原則のように、AI の出力姿勢を整えたいだけなら Rules で十分です。ここに外部接続は要りません。`.mdc` に文章として残しておけば、リポジトリの規約として共有できます。

逆に、既存仕様書、社内 Wiki、API スキーマ、データベース定義、チケット管理の内容を踏まえて答えてほしい場面では MCP に寄せるべきです。Rules に「仕様書を尊重する」と書くこと自体は有効ですが、その仕様書に到達できなければ、AI は尊重しようがありません。私が Rules だけで運用していたときは、テストケースの観点はそれらしく並ぶのに、実際の業務仕様と微妙にずれることがありました。MCP で既存仕様書を読める状態に変えると、「なぜこの正常系と異常系を切るのか」という前提からそろい始めたので、ここは機能選択の差がそのまま品質差になります。

Plugins を選ぶ場面は、個人の設定最適化より、**プロジェクト同梱の拡張セットとして再現性を持たせたいとき**です。新しいメンバーが入ったときに、Rules だけ別配布、MCP は口頭設定、Skills は個人任せ、という状態だと、同じリポジトリでも AI の挙動がそろいません。Plugins でまとめて持たせる発想なら、「このプロジェクトではこの前提で AI を動かす」が形になります。チーム全体で同じ補助輪を付けたいケースでは、この配布単位の意味が出ます。

Automations は、レビューのたびに同じチェックを回す、定型のワークフローを走らせる、といった反復作業に向きます。ここでも Rules の文章化とは役割が違います。Rules が「どう振る舞うか」の憲法だとすれば、Automations は「この条件ならこの処理を走らせる」という運用の仕組みです。両方を混ぜると設計が崩れるので、ルール本文に手順を詰め込むより、反復作業は Automations 側に逃がしたほうが保守しやすくなります。

現場感覚で言うと、選択基準は次のように整理するとぶれません。

1. AI の出力姿勢や判断基準を固定したいなら Rules
2. 外部 API、DB、ドキュメント探索が必要なら MCP
3. rules・skills・MCP servers を一式として配布したいなら Plugins
4. 定型フローを条件付きで回したいなら Automations

この順番で見ていくと、「Rules を増やせば何でもできる」という発想から離れられます。Rules は土台として強力ですが、届く範囲はあくまで行動方針のレイヤーです。外の情報を見に行く仕事まで背負わせるより、MCP や Plugins に素直に役割を渡したほうが、設定も応答も引き締まります。

## まとめ

設定の軸はシンプルで、Cursorでは共通作法をUser Rulesに、技術スタックや設計方針をProject Rulesに置くと運用がぶれません。軽い共有ならAGENTS.md、旧.cursorrulesが残っているなら分割移行を前提に考えると整理しやすくなります。私自身、最小構成で始めて週次で見直す形にしてから、チームの合意と生成品質の両方が安定しました。

### 今日やることリスト

初心者なら、まずはUser Rulesを1本だけ入れ、`.cursor/rules/` には `project-baseline.mdc`、`typescript.mdc`、`react.mdc` の中から2〜3本で始めるのがちょうどいい分量です。1ルールを短く保つ運用が提案されており、詰め込みすぎるより分けたほうがノイズを抑えやすくなります。

1. User Rulesに応答言語や簡潔さなどの共通方針を追加する
2. `.cursor/rules/` に最小の Project Rules を2本作る
3. 旧.cursorrulesがあれば内容ごとに分割し、新しい Agent チャットでテストする

### 今後の拡張ポイント

移行判断は、単一ファイルで規約が混ざってきた時点が目安です。