.cursorrules vs .cursor/rules（MDC形式）完全比較ガイド【2026年版】

.cursorrules は2026年現在も動作しています。ただし、CursorのAgentモードでは読み込まれません。Agentモードを使ったワークフローを採用している場合、あるいは今後採用する予定がある場合、.cursorrules に書いたルールはAgentモード実行中は完全に無視されます。

この問題への対応が .cursor/rules/*.mdc（MDC形式）です。本記事では両フォーマットの仕様を詳細に比較し、どちらをいつ使うべきかの判断基準と、具体的な移行手順を解説します。

.cursorrules とは

.cursorrules はプロジェクトルートに置く単一のMarkdownファイルです。Cursorはプロジェクト内のすべてのチャット・Composerセッションで自動的に読み込み、その内容を永続的なコンテキストとして参照します。

project-root/
└── .cursorrules

フロントマターもなく、起動条件の設定もなく、スコープの指定もありません。ファイルの中身がプロジェクト全体のすべてのセッションに一律で適用されます。この「シンプルさ」こそが .cursorrules の存在意義です。

典型的な .cursorrules の記述例：

あなたはNext.js 15 App Routerプロジェクトに精通したTypeScript開発者です。

コード規約:
- 非同期処理はasync/awaitのみ使用。.then()は禁止
- コンポーネントはデフォルトでServer Component。"use client"は本当に必要な時だけ
- エクスポートはnamed exportを優先
- バリデーションはすべてZodで行う

プロジェクト構成:
- 認証: NextAuth v5
- DB: Drizzle ORM + PostgreSQL
- スタイリング: Tailwind CSS v4

.cursorrules が適している場面

単一スタックの個人・小規模チームプロジェクトで、Agentモードを使わない場合は .cursorrules で十分です。設定不要でMarkdownを書くだけ、チームへの共有もファイル1つで済みます。

.cursorrules でできないこと

• ファイルスコープの指定不可。 フロントエンドとバックエンドのルールが常に同じコンテキストに混在し、無関係なリクエストでもトークンを消費します。
• Agentモード非対応。 Cursorのagentモード実行中は .cursorrules が読み込まれません。バグではなく、Agentモードは異なるコンテキスト読み込み経路を使用するため、レガシー形式がバイパスされます。
• 起動条件の制御不可。 すべてのルールがすべてのプロンプトに適用されます。オプトイン形式や条件起動のルールは作れません。
• 単一ファイルの限界。 大規模プロジェクトではルールファイルが数千行規模になり、保守が困難になります。

.cursor/rules/*.mdc とは

MDC形式（Markdown with frontmatter Configuration）は、単一ファイル方式に替わるモジュール構成のルールファイルシステムです。各ファイルは .cursor/rules/ ディレクトリ配下に .mdc 拡張子で配置し、YAMLフロントマターブロックで起動条件を制御します。

project-root/
└── .cursor/
    └── rules/
        ├── base.mdc
        ├── react.mdc
        ├── api.mdc
        └── testing.mdc

基本的な .mdc ファイルの構成：

---
description: "TypeScriptとプロジェクト基本規約"
alwaysApply: true
---

あなたはNext.js 15 App Routerプロジェクトに精通したTypeScript開発者です。

コード規約:
- 非同期処理はasync/awaitのみ
- コンポーネントはデフォルトでServer Component
- エクスポートはnamed exportを優先

フロントマターのフィールドは3つです：

4つの起動モード

.cursorrules との最大の違いは、MDCには4種類の起動モードがある点です。.cursorrules には「常に全体適用」の1種類しかありません。

1. Always Apply（常時適用）

---
description: "プロジェクト基本規約"
alwaysApply: true
---

チャット・Composer・Agentすべてのセッションに必ず読み込まれます。言語バージョン、命名規則、コミットメッセージのフォーマットなど、常に適用すべき基盤ルールに使います。

注意: alwaysApply: true のルールはコードが分析される前にコンテキストバジェットを消費します。複数ファイルの合計トークン数は2,000以内に収めることを推奨します。

2. Auto Attach（グロブスコープ）

---
description: "Reactコンポーネント規約"
alwaysApply: false
globs: ["**/*.tsx", "**/*.jsx"]
---

指定したグロブパターンにマッチするファイルが会話のコンテキストに含まれると自動起動します。.tsx ファイルを参照していれば読み込まれ、APIルートの .ts ファイルのみの場合は読み込まれません。

よくある誤解: グロブマッチにはマッチするファイルが実際にプロンプト内で参照されているか、エディタで開かれている必要があります。ファイル名を指定せず「Reactコンポーネントの設計について」と聞くだけでは起動しないケースがあります。

3. Agent Requested（AIが判断して起動）

---
description: "認証コードのセキュリティレビューチェックリスト。ログイン・サインアップ・セッション管理・JWT処理のコードをレビューする際に使用。"
alwaysApply: false
globs: []
---

alwaysApply: false かつ globs が空の場合、AIがdescriptionを読んで現在のタスクへの関連性を判断し、適切と判断したときのみ読み込みます。このモードではdescriptionの精度が性能を左右します。曖昧な説明文は適用漏れの原因になります。

4. Manual（手動起動）

チャット内で @rule-name 構文を使って明示的に呼び出すモードです。デプロイ手順書、スキーマ移行チェックリスト、セキュリティ監査プロトコルなど、頻繁には不要だが必要な時に確実に使いたい手続きをルール化するのに適しています。

機能比較表

MDCファイルの実例

ベースルール（Always Apply）

---
description: "TypeScriptプロジェクトの基本規約"
alwaysApply: true
---

## 言語・ランタイム
- TypeScript strict mode有効
- Node.js 22 LTS
- `any` 型は原則禁止。使用する場合はコメントで理由を記載

## コードスタイル
- async/awaitを一貫使用。.then() チェーンは禁止
- エクスポートはnamed exportを優先
- すべての関数に明示的な戻り値型

## エラーハンドリング
- 非同期処理はすべてtry/catchで囲む
- 回復可能なエラーはResult<T, E>パターンで返す
- エラーをサイレントに握りつぶさない

Reactコンポーネントルール（グロブスコープ）

---
description: "ReactとNext.jsのコンポーネント規約"
alwaysApply: false
globs: ["**/*.tsx", "app/**/*.tsx", "components/**/*.tsx"]
---

## コンポーネント構造
- デフォルトはServer Component。インタラクティビティやブラウザAPIが必要な場合のみ "use client"
- スタイルはCSSモジュールまたはTailwindでコンポーネントと同じ場所に配置
- Propsインターフェースはコンポーネントの直前に定義し、`[コンポーネント名]Props` と命名

## Next.js App Router
- `loading.tsx` でSuspenseバウンダリを設定
- 静的ルートは `generateStaticParams` を使用
- データキャッシュには `unstable_cache` を使用

APIルートルール（グロブスコープ）

---
description: "Next.js Route HandlerのAPIルート規約"
alwaysApply: false
globs: ["app/api/**/*.ts", "app/api/**/*.tsx"]
---

## リクエスト処理
- リクエストボディは処理前にZodでバリデーション
- エラーレスポンスは統一形式: `{ error: string, code: string }`
- HTTPステータスコード: バリデーション→400 / 認証エラー→401 / 権限エラー→403 / 未発見→404

## 認証
- 保護されたルートは最初の処理として `requireAuth()` を呼び出す
- クライアントから受け取ったユーザーIDは信頼しない。常にセッションから取得

セキュリティレビュールール（AI判断）

---
description: "セキュリティレビューチェックリスト。認証フロー・セッション管理・JWT処理・パスワード操作・ユーザー認証情報を扱うコードをレビューする際に使用。"
alwaysApply: false
globs: []
---

## 認証チェックリスト
- [ ] パスワードはbcrypt（コストファクター12以上）またはArgon2でハッシュ
- [ ] JWTシークレットは環境変数。ソースコードへのハードコーディング禁止
- [ ] 権限昇格時にセッショントークンをローテーション
- [ ] ログインエンドポイントにレート制限
- [ ] 認証エラーは汎用メッセージを返す（メールアドレスの存在有無を漏らさない）

Agentモードと .cursorrules の問題を検証する

Agentモードでの挙動の違いは理論上の話ではありません。実際に以下のような結果が報告されています。

.cursorrules のみを設定したプロジェクトでのテスト：

• チャット・Composerモード: ルール準拠率 9/9
• Agentモード: ルール準拠率 0/9

同じ内容を alwaysApply: true のMDCファイルに変換した場合：

• Agentモード: ルール準拠率 9/9

Agentモードを使うワークフロー — リファクタリング、フィーチャー実装、コードレビューの自動化 — に移行しているプロジェクトでは、.cursorrules の内容はAgentに対して完全に無効です。

もう一点注意が必要な挙動として、両形式が同一プロジェクトに共存している場合、MDCが .cursorrules に優先します。MDCファイルのテスト中に既存の .cursorrules が上書きされる可能性があります。

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

移行は複雑な作業ではありませんが、意図的な整理が必要です。

ステップ1: 既存の .cursorrules を分類する

mkdir -p .cursor/rules

.cursorrules を読み返し、各セクションに以下のタグを付けます：

• [always] — ファイル種別に関係なく常に適用（言語バージョン、Gitコメントフォーマット等）
• [frontend] — UIコンポーネントに関するルール
• [backend] — APIルート・サービス・データ層のルール
• [test] — テストファイルのルール
• [manual] — 頻繁には不要で、必要時に手動で呼び出したいルール

ステップ2: ルールファイルを作成する

まずAlways Apply用の base.mdc から：

cat > .cursor/rules/base.mdc << 'EOF'
---
description: "プロジェクト全体に適用する基本規約"
alwaysApply: true
---

[always] タグのセクションをここに貼り付け
EOF

次にスコープ別ファイルを作成：

cat > .cursor/rules/frontend.mdc << 'EOF'
---
description: "フロントエンド・UIコンポーネント規約"
alwaysApply: false
globs: ["**/*.tsx", "**/*.jsx", "**/*.css", "**/*.scss"]
---

[frontend] タグのセクションをここに貼り付け
EOF

cat > .cursor/rules/api.mdc << 'EOF'
---
description: "APIルートとサーバーサイド規約"
alwaysApply: false
globs: ["app/api/**/*.ts", "server/**/*.ts", "lib/api/**/*.ts"]
---

[backend] タグのセクションをここに貼り付け
EOF

cat > .cursor/rules/testing.mdc << 'EOF'
---
description: "テストファイルの規約とパターン"
alwaysApply: false
globs: ["**/*.test.ts", "**/*.spec.ts", "**/*.test.tsx"]
---

[test] タグのセクションをここに貼り付け
EOF

ステップ3: ルールの読み込みを検証する

グロブパターンにマッチするファイルを明示的に参照するプロンプトを作成し、ルールが適用されていることを確認します。Agentモードでの検証は、新規ファイル作成をAgentに依頼して出力にコーディング規約が反映されているかを確認します。

ステップ4: 旧ファイルの扱いを決める

MDCの動作を確認できたら .cursorrules を削除して構いません。後方互換性のために残す場合は、MDCとの内容の整合を維持するか、.cursorrules は実質的に無効であると認識した上で残してください。

ステップ5: Gitにコミットする

git add .cursor/rules/
git commit -m "chore: .cursorrules を .cursor/rules MDC形式へ移行"

.cursor/rules/ はリポジトリにコミットしてチーム全体で共有します。これをしないと各開発者のルール設定がバラバラになります。

.cursorrules を使い続けていいケース

MDCへの移行が推奨されている一方で、.cursorrules のままで十分な状況も明確に存在します。

単一スタックの個人プロジェクト: 単一フレームワークで開発し、Agentモードも使わないなら、MDCへの移行はコストが見合いません。

ルールを外部に公開・共有したい場合: コミュニティのルールコレクションやテンプレートリポジトリの多くは .cursorrules 形式で配布されています。発見されやすく、コピー&ペーストのしやすさでは単一ファイル形式に軍配が上がります（ルールギャラリーも参照）。

素早くルールを試したい場合: アイデア段階でのルール試行には、.mdc ファイルを適切に構成するよりも .cursorrules を直接編集する方が速いです。

.cursor/rules/ を選ぶべきケース

以下のいずれかに当てはまる場合はMDCに移行してください。

Agentモードを定期的に使っている。 これは絶対条件です。AgentモードはMDCを読みますが、.cursorrules は読みません。

複数の技術ドメインをまたぐプロジェクト。 Reactフロントエンド、Node.js API、Pythonデータパイプラインが混在するモノレポでは、単一ルールファイルは非効率です。グロブスコープで無関係なコンテキストを排除できます。

チームでルールを共有・管理している。 数値プレフィックス規約（001-base.mdc、010-frontend.mdc）でロード順と優先度を明確にできます。プルリクエストでのルール変更レビューもしやすくなります。

AI判断で起動するルールが必要。 デプロイ手順、アーキテクチャ決定テンプレート、セキュリティ監査のような「必要な時だけ読み込みたい」手続きは、.cursorrules では実現できません。

Cursor Enterpriseを利用している。 チームルール（管理者管理、組織全体適用）はMDCシステムでのみ機能します。

判断フローチャート

Cursor Agentモードを使っている？
├── はい → .cursor/rules/*.mdc を使う
└── いいえ → 続けて確認...

複数の技術スタックや言語が混在するプロジェクト？
├── はい → .cursor/rules/*.mdc を使う（グロブスコープが有効）
└── いいえ → 続けて確認...

2名以上のチームでAI規約を共有・管理している？
├── はい → .cursor/rules/*.mdc を使う（Gitレビューと優先度管理のため）
└── いいえ → 続けて確認...

Cursor Enterpriseを使っている？
├── はい → .cursor/rules/*.mdc を使う（チームルールに必須）
└── いいえ → .cursorrules で十分

よくある間違い

間違い1: 両形式を整合なく共存させる

.cursorrules と .cursor/rules/ が同じプロジェクトに混在し内容が矛盾している場合、MDCが優先されますが挙動が予測しにくくなります。完全に移行するか、意図的に内容を同期させるかどちらかにしましょう。

間違い2: alwaysApply: true の書き忘れ

base.mdc を作成したが alwaysApply: true を書き忘れた結果、基本規約がほとんどのセッションで読み込まれないというケースが多く報告されています。コアルールには必ず alwaysApply: true を設定してください。

間違い3: AI判断モードでdescriptionが曖昧

# 悪い例
description: "コーディングルール"

# 良い例
description: "TypeScriptのエラーハンドリングパターン。外部APIの呼び出し、DB操作、ユーザー入力のバリデーションを含む関数を書く際に使用。"

AI判断モードではdescriptionがルール起動の唯一の判断材料です。「いつ使うべきか」が一読で分かる具体的な記述にしてください。

間違い4: Always Applyのルールに詰め込みすぎ

alwaysApply: true のルールはコード分析前にコンテキストバジェットを消費します。Always Applyのルール合計が2,000トークンを超えると、実際のコード解析に使えるコンテキストが圧迫されます。本当に常時必要なルールのみに絞りましょう。

間違い5: グロブパターンのミスマッチ

# このルールは `.tsx` ファイルで起動しない
globs: ["**/*.ts"]

# 修正
globs: ["**/*.ts", "**/*.tsx"]

グロブスコープルールはマッチするファイルが実際にコンテキストに含まれていることが必要です。各グロブパターンはマッチするファイルを明示してプロンプトを投げ、実際に起動するか確認しましょう。

間違い6: .cursor/rules/ をGitにコミットしない

.gitignore に入れていたり単にコミット忘れだったりで、開発者ごとにルール設定がバラバラになります。共有規約としての価値が失われます。必ずリポジトリにコミットしてください。

大規模プロジェクトでの番号付けルール

ルールファイルが増えてきたプロジェクトでは、ファイル名に番号プレフィックスをつけてロード順と優先度を明示する規約が有効です：

.cursor/rules/
├── 001-base.mdc           # Always Apply。基本規約
├── 010-typescript.mdc     # 言語固有ルール
├── 020-react.mdc          # フロントエンドフレームワーク
├── 030-api.mdc            # バックエンド規約
├── 040-database.mdc       # データ層
├── 050-testing.mdc        # テスト規約
├── 100-security.mdc       # AI判断起動。セキュリティチェック
└── 200-deployment.mdc     # 手動起動。デプロイ手順

Cursorはルールをファイル名順に読み込み、後のファイルが競合時に優先されます。番号付けにより、各ファイルを開かなくても優先順位が一目でわかります。

AGENTS.md との関係

CursorはMDCの代替として AGENTS.md もサポートしています。プロジェクトルート（またはサブディレクトリ）に置くプレーンMarkdownで、フロントマターは不要です。

AGENTS.md は .cursorrules とMDCの中間的な選択肢です。サブディレクトリ配置によるパススコープが使える点は .cursorrules より柔軟ですが、フロントマターもグロブパターンも起動モードの制御もない点ではMDCより機能が劣ります。

Claude Codeなど複数のAIツールをまたいでルールを共有したい場合は AGENTS.md が有効な選択肢ですが、Cursor専用での運用ならMDCを選ぶのが無難です。

まとめ

一言で整理します。Agentモードを使っていない小規模プロジェクトなら .cursorrules のままで問題ありません。Agentモードを有効にした瞬間から、そのルールはAgentに対して完全に無効になります。移行作業は多くのプロジェクトで1時間以内に完了し、効果は即座に現れます。

実際のルールテンプレートを探している場合はルールギャラリーもご活用ください。Cursor用のルール例を多数掲載しています。他のAIコーディングツールとのルール形式比較についてはクロスツール比較ガイド、Claude Codeへの移行については移行ガイド、すぐ使えるテンプレートはCursorルールテンプレート集をご覧ください。