Cursor を毎日触っていて、こんな経験はありませんか。「またこの命名規則を直された」「server component で書いてって何度言えば…」。私も先月まで全く同じことを繰り返していました。
原因は AI ではなく、ルールの書き方でした。2026 年の Cursor は .cursorrules 単一ファイルから .cursor/rules/*.mdc のディレクトリ構成に主軸が移っており、ここを知っているかどうかで AI 提案の採用率が大きく変わります。この記事では、私が実際に 3 つのプロジェクトで運用して得た書き方のコツを、コード例つきで共有します。
結論:.cursorrules ではなく .cursor/rules/*.mdc に移行する
先に答えだけ書きます。2026 年現在、新規プロジェクトでルールを書くなら .cursor/rules/ ディレクトリに .mdc ファイルを複数置く のが正解です。
単一の .cursorrules は今も読み込まれますが、すべての会話に全文がロードされる「トークン税」が発生します。SQL マイグレーションを書いている最中に React コンポーネント規約まで毎回ロードされる、あの無駄です。.mdc 形式なら globs やトリガーで必要なときだけ発火させられます。
根拠は Cursor 公式ドキュメントと、複数の 2026 年版ガイド(techsy.io、vibecodingacademy.ai など)の記述で一致しています。公式が「leads with」している現行フォーマットです。
なぜ Cursor のルール設計で AI 提案の採用率が変わるのか
率直に言うと、ルールなしの Cursor は「優秀だが事情を知らない新人」です。TypeScript も React も知っていますが、あなたのチームが enum を禁止していることや、@/ プレフィックスで絶対パス import すること、サーバーコンポーネントをデフォルトにしていることは知りません。
DEV Community の Cursor ルール解説記事では、適切なルール導入で AI 提案の採用率が 30% から 80% 台に上がったという報告があります。私自身の感覚値とも一致していて、特に「変数名を直す手間」「import 文を書き直す手間」がほぼ消えました。
ここで重要なのは、ルールは AI を賢くするためのものではなく、AI と自分の前提を揃えるための契約書 だということです。優秀な業務委託に最初に渡すオンボーディング資料、と言い換えてもいい。
.mdc ファイルの 4 つの発火モードを使い分ける
.cursor/rules/*.mdc には 4 つの発火モードがあります。これを理解せずに書くと「ルールを書いたのに効かない」現象に必ず当たります。
Always Apply(常時適用)
すべての会話に注入される最強モード。代わりに、毎リクエストでトークンを食います。200 語以内に収める のが鉄則です。
私はここに「プロジェクト概要・技術スタック・絶対禁止事項」だけを書いています。コーディング規約の細部は別ファイルに逃がします。
Auto Attached(globs マッチ時に自動適用)
frontmatter で globs: "**/*.tsx" のように書くと、対象ファイルを開いている/編集している時だけロードされます。React コンポーネント規約、API ルート規約、テストコード規約はここに置くと相性がいいです。
Agent Requested(AI が必要に応じて呼ぶ)
description を見て Agent が自分で「これが必要だな」と判断して読み込みます。Stripe 決済フローや認証フローなど、特定ドメインで深い知識が必要なとき に効果的です。
コツは description を人間に対する説明として書くこと。「Stripe payment intent を実装する時の規約」のように具体的に書くと拾われます。「payment 関連」みたいな曖昧な書き方だと一生発火しません。
Manual(@rule-name で明示呼び出し)
チャット内で @security-checklist のように手動で呼ぶ用。コードレビューや脆弱性チェックなど、ユーザーが意図して使うシーン にハマります。
採用されるルールを書く 5 つの実践テクニック
5 つは具体的なテクニックです。順番に見ていきます。
1. 「禁止」を明示する
AI に「やってほしいこと」を書くより「やってほしくないこと」を書くほうが効きます。これは想像以上に効きました。
NEVER:
- barrel exports(index.ts で再エクスポート)を作らない
- enum を使わない。const オブジェクト + 'as const' を使う
- 何もせず props を渡すだけのラッパーコンポーネントを作らないこの 3 行を入れただけで、私の Next.js プロジェクトでは「不要なラッパーが生えてくる問題」が一晩で消えました。
2. フレームワーク固有のルールに踏み込む
「TypeScript を使う」「クリーンコードを書く」は無意味です。AI はもう TypeScript を知っています。
価値が出るのは Next.js 14 App Router 特有の判断、Remix の loader/action 規約、Astro の島アーキテクチャといったフレームワーク固有の判断基準 を書いた時です。
## Next.js App Router
- デフォルトは Server Component。'use client' は必要最小限
- データ取得は Server Component 内の async/await。SWR は client component 限定
- ルートハンドラは route.ts に集約、Server Action と混ぜない3. Agent 暴走への安全弁を書く
2026 年の Cursor は Background Agents や自律エージェントが当たり前になりました。これは便利ですが、.env を消されたり package.json を勝手に書き換えられたりするリスクとセットです。
GitHub で公開されている 2026 年版ベストプラクティスでは、エージェント境界として以下のような記述が推奨されています。
# Agent Boundaries
- ユーザーレビューなしで commit しない
- .env や package.json を明示確認なしに削除しない
- セキュリティ脆弱性を発見したら作業を停止して報告する
- npm パッケージを import する前に `npm list <package>` で実在を確認する最後の「実在確認」は地味に重要です。学習データにあった存在しないパッケージを AI が import するハルシネーションを防げます。
4. 1 ファイル 100 行以内に抑える
公式ドキュメントは「500 行まで」と言っていますが、実用上は 100 行を超えたら分割 したほうが安定します。長いルールはトークンを食うだけでなく、AI 自身も読み飛ばします。
私の手元の最大プロジェクトでも、.cursor/rules/ 配下は 8 ファイルで合計 600 行程度。1 ファイル平均 75 行に収めています。
5. 「再説明したら 3 回目はルール化」を運用ルールにする
これは一番効く運用です。Cursor に同じ指摘を 3 回したら、その瞬間にルールへ昇格させます。
たとえば「日付フォーマットは YYYY-MM-DD で」を 3 回言ったら、.cursor/rules/conventions.mdc に書く。これを徹底すると、ルールが死蔵されず、生きた規約集になります。
.cursorrules から .mdc への移行手順
既存プロジェクトを段階移行するなら、こうやります。
mkdir -p .cursor/rules
touch .cursor/rules/00-project.mdc # Always Apply 用
touch .cursor/rules/10-react.mdc # globs: **/*.tsx
touch .cursor/rules/20-api-routes.mdc # globs: **/route.ts
touch .cursor/rules/30-stripe.mdc # Agent Requested
touch .cursor/rules/99-security.mdc # Manual 呼び出し各ファイルの先頭には frontmatter を入れます。
---
description: React コンポーネントの規約
globs: ["**/*.tsx"]
alwaysApply: false
---
# React 規約
- 関数コンポーネント + hooks
- named export のみ
...旧 .cursorrules は即削除せず、内容を .mdc に少しずつ移しながら挙動を確認します。Cursor は両方を読むので、移行中のグレーゾーンも問題なく動きます。動作確認が終わってから旧ファイルを消す、で OK です。
よくある詰まりどころと回避策
運用していて見つけた地雷を 3 つ。
Always Apply のルールが肥大して Cursor が重くなる。これが一番多いです。1000 語の Always Apply を入れると、毎リクエスト最初に 1000 語消費する税金になります。Auto Attached に切り替えるだけで体感速度が変わります。
Agent Requested ルールが発火しない。description が抽象的すぎるのが原因。「決済関連」より「Stripe Payment Intent を作成する際のエラーハンドリング規約」のほうが圧倒的に拾われます。
チームで挙動がバラバラ。.cursor/rules/ ディレクトリを git に commit していないケースが多いです。個人設定だけ personal.mdc として .gitignore に追加し、それ以外は全部 commit してください。
まとめ:今日からやる 4 つのアクション
長くなったので、今日試せる行動だけ抜き出します。
.cursor/rules/ディレクトリを作る。まずは 1 ファイル00-project.mdcから- 直近 1 週間で 3 回以上 AI に指摘した内容を Always Apply に書く(ただし 200 語以内)
- NEVER ブロックを 3 行書く。禁止事項のほうが効きます
- Agent 境界(
.env削除禁止など)を必ず入れる。Background Agents 時代の必須項目
私の体感ですが、ここまでやると Cursor の提案を「ほぼそのまま受け入れる」割合が明確に上がります。差し戻し回数が減れば、Pro プラン($20)のクレジットも結果的に長持ちします。
まずは 1 ファイル、今夜書いてみてください。
参考リンク
- TECHSY - Cursor Rules: Write .cursor/rules That Work (2026) — .mdc 形式と発火モードの解説
- Vibe Coding Academy - Cursor Rules: Complete .mdc Guide — トークン税と 4 モードの整理
- DEV Community - Best Cursor Rules for Every Framework 2026 — 採用率向上の体感値とフレームワーク別例
- GitHub - cursor-ai-tips cursorrules-2026-best-practices — Agent 境界・依存検証のテンプレート
- AnyCap - Cursor AI 2026 Complete Guide — Cursor v3.0 と .cursorrules の位置づけ