Cursor Rules完全ガイド｜.cursorrulesの書き方2026

Cursor Rulesとは何か

Cursor Rulesは、AIに毎回同じ指示を打ち込む手間をなくす仕組みだ。厨房の壁に貼ってある「仕込みルール表」に近い。新しく入ったコックに味付けの手順を毎回口頭で説明する代わりに、紙に書いて貼っておけば読んでから作業に入る。ファイルとして残しておけば、AIも毎回それを読んでから動く。

チームで使う場合の効果はもっとはっきりしている。「うちはApp Routerで書く」「テストは必ずVitestで」といった規約を、メンバー全員のCursorに同時に行き渡らせられる。口頭伝達やREADMEの読み飛ばしに頼らずに済む。

ルールなしでコード生成を頼むと何が起きるか。フレームワークの一般論に寄った、古いパターンのコードが返ってくることが多い。Next.jsなら廃止方向のPages Routerを提案されたり、状態管理に指定外のライブラリを使われたりする。ルールはこの「AIの平均的な癖」を、プロジェクト固有の前提で上書きするためにある。

.cursorrulesは終わった技術なのか

.cursorrulesは廃止されていない。ただし新規に書く形式でもない。プロジェクト直下に置く単一ファイル形式で、Cursor 0.43前後の世代からProject Rulesへの移行が進んだ。Cursorは後方互換としてこのファイルを今も読み込む。だが公式ドキュメントも、複数のコミュニティ解説記事も、新規導入では.cursor/rules/配下の.mdcファイルを使うよう揃って案内している。

両者の違いは「単一ファイルか、複数ファイルに分けられるか」だけではない。.cursorrulesは常に全プロンプトへ丸ごと注入される。対して.mdc形式はファイルごとにfrontmatterで適用条件を指定できるため、規約が増えてもルール本文が肥大化しにくい。フロントエンドの規約とバックエンドの規約を1つのファイルに詰め込む必要がなくなる。

既存プロジェクトに.cursorrulesが残っているなら、急いで消す必要はない。動いているものを壊すリスクのほうが大きい。新しい規約を追加するタイミングで.mdc形式に少しずつ移していけば十分だ。

.cursor/rules/*.mdcの書き方（実機検証済み）

.mdcファイルはMarkdown本文の先頭にYAML frontmatterを付けた構造だ。frontmatterのキーは3つだけ。description・globs・alwaysApplyだ。手元でサンプルmdcファイルを2件作成し、globsをわざと空欄にしてYAMLパースを試したところ、エラーにはならず単に自動アタッチ条件が「なし」として扱われるだけだった。

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

# React コンポーネント規約

- 関数コンポーネントのみ使用する（クラスコンポーネント禁止）
- Props の型は必ず interface で定義する
- スタイルは Tailwind CSS のユーティリティクラスを使う

description

エージェントが「このルールを今読み込むべきか」を判断する材料になる一文。空欄のままだと、後述するAgent Requested型ではルール自体が候補にすら上がらなくなる。「〜する時に使う」という具体的な適用場面を書くのがコツだ。

globs

globsは効きどころが地味に分かりにくいキーだ。**/*.tsxのように書けば、該当ファイルがコンテキストに入った瞬間にルールが自動アタッチされる。空にしておいても構文エラーにはならず、単に自動適用の条件が「なし」になるだけだ。書き方の実例はコミュニティのリファレンス集にもまとまっている。

alwaysApply

---
description: 常時適用するコーディングスタイル
globs:
alwaysApply: true
---

# 共通コーディングスタイル

- インデントは2スペース
- セミコロンは省略しない

trueにすると全プロンプトへ常時注入される。汎用的なコーディング規約向けのキーだ。乱用するとコンテキストを圧迫するため、本当に全体に効かせたいルールだけに絞るべきだと複数の解説記事が指摘している。

4種類のRule Type使い分け

Cursor Rulesは、frontmatterのキーの組み合わせによって4つのタイプに分類される。同じ.mdc形式でも、descriptionとglobsとalwaysApplyの埋め方次第でまったく違う挙動になる。

Auto Attached ─ ファイルパターンで自動適用

先述のReactコンポーネント規約がこのタイプにあたる。globs: ["**/*.tsx", "**/*.jsx"]としておけば、Cursorは該当ファイルを編集・参照するタイミングでルールを自動で読み込む。フロントエンドとバックエンドで規約が違うプロジェクトでは、この分割がそのまま効いてくる。

Agent Requested ─ エージェントの自己判断に委ねる

---
description: データベースのマイグレーションを作成・変更する際に使用する
alwaysApply: false
---

# マイグレーション作成の手順

- 既存カラムの型変更は必ず新カラム追加+移行+旧カラム削除の3段階で行う
- ダウンマイグレーションを必ず用意する
- 本番反映前にstaging環境で一度実行する

globsを指定しない点がAuto Attachedとの違いだ。ファイルパターンでは判断できない「作業内容」ベースの手順書に向いている。descriptionの書き方が甘いと、エージェントがこのルールの存在に気づかず素通りしてしまう。ここが一番事故りやすいポイントだ。

Manual ─ 呼び出すまで動かない

チャット欄で@ルール名のように明示的に指定した時だけ読み込まれる。頻度は低いが影響範囲が大きい作業（本番デプロイ手順、破壊的なリファクタリング手順等）を、うっかり自動発火させたくない場面に向く。

実践レシピ｜3つのユースケース

タイプの違いを理解したところで、実務でよく出てくる3パターンを挙げる。

新規メンバーが増えた時の使い方

オンボーディング資料を全部読ませる代わりに、Alwaysルール1本に「このプロジェクトの前提」を集約しておくと効果が大きい。実装方針を口頭説明する回数が減る。

モノレポでの使い方

パッケージごとに.cursor/rules/を持たせれば、フロントエンドとバックエンドで矛盾する規約を1つのファイルに無理やり詰め込まずに済む。globsのパス指定さえ正しければ、意図しないパッケージへルールが漏れることもない。ここまでは書き方の話だ。次は、書いたはずのルールがなぜか効かないケースを見る。

ルールが効かない時のチェックリスト

「ルールを書いたのに反映されない」という報告は、海外の解説記事やCursorのフォーラムでも繰り返し挙がっている。原因はだいたい決まった数パターンに収まる。

globsの階層を1段間違えたまま数コミット気づかない、というのはありがちな事故パターンだ。ルールを書いた直後にApplied Rules表示を確認する習慣さえあれば、その場で気づける類のミスでもある。

それでも直らない場合は、Cursor自体のバージョンに起因する不具合の可能性もある。globsベースのルールがエージェントセッションで反映されないという報告も一部のバージョンで上がっていた。Cursorを最新版に更新してから再確認するのが手っ取り早い。バージョン起因の不具合を疑うところまで来たら、次に押さえておきたいのがRulesという仕組みそのものの立ち位置の変化だ。

RulesとAgent Skillsの境界線

2026年に入ってから、Cursorには/migrate-to-skillsというコマンドが追加された。ここは上位記事でもまだあまり扱われていない論点だ。

「Rulesが廃止されてSkillsに一本化される」という理解は誤りだ。alwaysApply: trueやglobs指定ありのルールはそのままRulesとして存続する。移行対象になるのは、alwaysApply: falseかつglobsなしの「動的ルール」、つまりAgent Requested寄りのルールだ。Cursorの開発チームは、この種類のルールをAgent Skills（SKILL.md）という別の仕組みに寄せていく方針を示している。

RulesとSkillsの役割分担

ざっくり言うと、Rulesは「常に前提として知っておいてほしいこと」、Skillsは「特定のタスクをこなすための実行手順」という住み分けに近づいている。マイグレーション手順のようなAgent Requested型ルールは、実質的にSkillsの守備範囲と重なる。

今すぐ移行すべきか

急ぐ必要はない。Agent Requested型のルールを多く抱えているプロジェクトほど恩恵は大きいが、Alwaysルールが中心の小規模プロジェクトなら現状維持で困らない。仕組みが整理されていく過渡期だと捉えておけば十分だ。

よくある質問

まとめ

まずは既存の.cursorrulesを1本、.cursor/rules/配下のAlwaysルールに置き換えるところから始めるとよい。frontmatterの---を書き忘れないことだけ気をつければ、あとは今の運用とほぼ変わらずに移行できる。