.cursorrulesは、AIエディタCursorのAgentに守らせたい指示をプロジェクト直下に1ファイルで書く、旧形式のルールファイルです。Cursorの公式ヘルプは2026年10月時点で「.cursorrulesはlegacy(旧形式)で、今後非推奨になる」と明記しており、後継は.cursor/rules/に置く.mdcファイル(Project Rules)です。この記事では、.cursorrulesが今も読み込まれるのか、移行の手順、.mdcの書き方、AGENTS.md・CLAUDE.mdとの違いを、公式ドキュメント、コミュニティフォーラムでのスタッフ回答、Cursor CLIの配布パッケージのコードをもとに整理します。
まとめ:.cursorrulesの現状と移行の要点
.cursorrulesは公式に「legacyで今後非推奨」とされています。ルールのリファレンス(docs/rules)にはもう記載がなく、ルールの種類はProject Rules・User Rules・Team Rules・AGENTS.mdの4つとして説明されています。- 削除はされていません。2026年10月22日版のCursor CLIのコードでも、
.cursorrulesはGitリポジトリのルートからalwaysApply: trueのルールとして読み込まれます。ただし.cursor/rules/*.mdcと内容が重なる部分は.mdcが優先されるため、両方を置いたままにすると旧ファイルが効いていないように見えます。 - 移行は、新しいルールを作って中身を貼り付け、適用タイプを
Always Applyにして旧ファイルを消す4手順です。Always Applyが旧形式と同じ挙動になります。 .cursor/rules/に置くファイルは拡張子.mdcが必須です。.mdで置くとルールとして読まれません。frontmatterのないプレーンなMarkdownで書きたいならAGENTS.mdを使います。- ルールが効くのはAgent(チャット)とCursor CLIで、Tab補完とBugbotのレビューには効きません。例外として、ソース管理の「Generate commit message」に指示を渡せるのは旧形式の
.cursorrulesだけです。
.cursorrulesの役割と2026年10月時点の位置づけ
.cursorrulesはリポジトリのルートに置くテキストファイルで、書いた内容がAgentへの指示として毎回モデルに渡されます。ファイルは1つだけで、特定のディレクトリや拡張子にだけ効かせる設定はできません。「TypeScriptで書く」「コメントは日本語」のようなプロジェクト全体の約束事を書く用途で広まりました。
.cursorrulesの非推奨化予告と公式ヘルプの記述
Cursorの公式ヘルプ「Rules」には、移行方法を説明する節があり、冒頭で.cursorrulesを「legacy and will be deprecated」と書いています。つまり2026年10月時点でも「非推奨化が予告された旧形式」であり、削除された機能ではありません。ただし、ルールのリファレンス(cursor.com/docs/rules)からは.cursorrulesの説明そのものが消えており、新しく書き足す先として案内されているのは.cursor/rules/とAGENTS.mdです。新規プロジェクトでAgentに渡すルールは、Project RulesかAGENTS.mdに書くのが公式の案内に沿った選択です。
旧形式が今も意味を持つ用途が1つだけあります。ソース管理タブの「Generate commit message」は独自のプロンプト設定を持たず、Project RulesやUser Rulesも反映されません。Cursorのスタッフは2026年3月に、リポジトリ直下の.cursorrulesに書いた指示ならコミットメッセージ生成に渡されると回答し、2026年7月23日に現行ビルドで再確認したうえで「.cursor/rulesはこの機能に効かず、効くのは旧形式の.cursorrulesだけ」と説明しています(Cursor Community Forum)。ただし.cursorrulesはAgentにも読まれるため、コミットメッセージ用の指示もAgentのコンテキストに毎回入ります。同じスレッドでも2026年9月に、ボタン1つのためにすべてのAgentへ指示が送られる点を懸念する投稿が出ています。使うなら指示は1〜2行に抑え、自分の環境だけに置く未追跡ファイルなら、スタッフが案内しているとおり.git/info/excludeに.cursorrulesを追加してコミット対象から外します。
「Agentでは読まれない」という説とフォーラムでの公式回答
日本語・英語の解説記事には「.cursorrulesはAgentモードでは読み込まれない」と書いたものがあります。関連する事例として、2026年2月にCursorのコミュニティフォーラムへ「Agentで.cursorrulesが無視される」というバグ報告が投稿されました。この報告にはCursorのサポート担当が「読まれるはず」と返し、報告者自身が再検証して、原因は同じワークスペースに残っていた.cursor/rules/*.mdcだったと訂正しています。
2026年3月10日の別スレッドでも、Cursorのスタッフが「.cursorrulesは当面は動くはず。.cursor/rules/*.mdcと並べて置いていると、重なる部分は.mdcのルールが優先される」と回答しています(Cursor Community Forum)。「Agentでは読まれない」と一律に断定するのは正確ではありません。この回答が示しているのは、「.mdcと併用すると旧ファイルの指示が上書きされる」という現象です。移行の途中で両方を残すと、この状態になります。
Cursorのルール6種の違い:置き場所・適用範囲・共有方法
Cursorでルールを書ける場所は、旧形式を含めて6つあります。公式ドキュメントの記述を並べると次のとおりです。
| 種類 | 置き場所 | 形式 | 適用のされ方 | 共有 |
|---|---|---|---|---|
| .cursorrules(旧形式) | プロジェクト直下 | テキスト1ファイル | 常に適用 | Git |
| Project Rules | .cursor/rules/ | .mdc(frontmatter付き) | 4タイプから選択 | Git |
| AGENTS.md | 直下・サブディレクトリ | プレーンなMarkdown | 常に適用(入れ子は配下のみ) | Git |
| CLAUDE.md | プロジェクト直下 | プレーンなMarkdown | 常に適用 | Git |
| User Rules | Customize → Rules | 自由記述 | 全プロジェクトで適用 | アカウント同期 |
| Team Rules | チームのダッシュボード | 自由記述 | 全メンバー(globs指定可) | サーバー配信 |
指示が食い違ったときの優先順位は、公式ドキュメントでTeam Rules → Project Rules → User Rulesの順と定められています。適用されるルールはすべてマージされ、衝突した部分だけ先に来るものが勝ちます。Team RulesはTeamプランとEnterpriseプランの機能で、管理者が「Enforce this rule」をオンにするとメンバー側でオフにできなくなります。
User Rulesは設定画面に書く方法のほか、~/.cursor/rules(Windowsは%USERPROFILE%\.cursor\rules)にファイルで置く方法もあります。設定画面の内容はアカウントに同期されますが、ファイルで置いたものはそのマシンにしか残りません。PCを替える予定があるなら、設定画面に書く方が安全です。
別のリポジトリからルール単体を直接取り込む機能はありません。社内の共通ルールを複数のリポジトリへ配りたいときは、公式ドキュメントの「Importing rules from a repository」のとおり、ルールをプラグインにまとめてマーケットプレイスとして公開し、Customizeの「From GitHub Repository」から取り込み、その後に対象プラグインをインストールします。取り込むリポジトリには.cursor-plugin/marketplace.jsonが必要です。
CLAUDE.mdは、Claude Codeと同じリポジトリを使う人向けの互換機能です。CursorはCLAUDE.mdをAGENTS.mdと同じように読み込み、frontmatterにalwaysApplyを書いても無視して常に適用します。Claude Code側でのCLAUDE.mdの書き方はClaude Codeの使い方|インストールから権限・CLAUDE.md設定、初日の進め方までで扱っています。
ルールが効く機能と効かない機能
公式ヘルプは、ルールがAgent(チャット)にだけ適用され、Tab補完とBugbotのPRレビューには適用されないと明記しています。インライン編集(Cmd/Ctrl+K)は、2026年9月時点のヘルプでは「適用されない」機能に含まれていましたが、10月の版ではこの記述が消えています。挙動が変わったのかどうかは公式に説明がないため、インライン編集で守らせたい約束事はプロンプトに直接書くのが確実です。前の章で触れたコミットメッセージ生成は、この一覧の外にある例外です。
Bugbotには専用の.cursor/BUGBOT.mdがあり、Bugbotのドキュメントは.cursor/rules/の.mdcがBugbotの実行に適用されないとしています。レビュー観点はBUGBOT.mdかBugbot Automationsのルールに設定します。どのルールがレビューに使われたかは、PRにbugbot run verbose=trueとコメントすると一覧で返ってきます。
Cursor CLIが読み込むルールファイル(2026.10.22版の実装)
ターミナルから使うCursor CLIについて、公式ドキュメント(Using Agent in CLI)は「エディタと同じ.cursor/rulesを使い、プロジェクトルートのAGENTS.mdとCLAUDE.mdもルールとして適用する」と書いているだけで、.cursorrulesには触れていません。そこで2026年10月22日に配布されたCLI(バージョン2026.10.22-27dcf5f)のパッケージを展開し、ルールを読み込む処理(LocalCursorRulesService)のコードを確認しました。読み取れた挙動は次の3点です。
.cursorrulesは今も読み込み対象:frontmatterをalwaysApply: trueに固定したルールとして扱われ、ファイルの変更を監視する対象にも入っています。探す場所はGitリポジトリのルート(Git管理外なら開いたフォルダ)だけです。モノレポのサブディレクトリでCLIを起動してもルートの.cursorrulesは読まれ、サブディレクトリに置いた.cursorrulesは読まれません。.cursor/rules/・AGENTS.md・CLAUDE.mdは親ディレクトリまでさかのぼる:開いたフォルダからファイルシステムの最上位まで、各階層でこの3つを探します。ホームディレクトリ直下にAGENTS.mdやCLAUDE.mdを置いていると、その配下のすべてのプロジェクトで読み込まれます。CLAUDE.mdとCLAUDE.local.mdは条件付き:サードパーティの設定を取り込むかどうかを判定する分岐の内側にあり、AGENTS.mdと.cursorrulesはその外で常に読まれます。エディタ側でこれに当たりそうな設定は、Cursor Settings → Agents → Third-Party Importsの「Include Third-Party Plugins, Skills, and Other Configs」(既定オン)で、公式ドキュメントはClaude Codeのフックを読み込む条件として説明しています。CLAUDE.mdとの対応は公式には書かれていません。
いずれもCLIの1つの版のコードから読み取った挙動で、エディタ本体や今後の版で同じとは限りません。CIでAgentを動かすときに「ローカルとCIで効くルールが違う」と感じたら、ルートの.cursorrulesと、上位ディレクトリのAGENTS.md・CLAUDE.mdを最初に疑うと切り分けが速くなります。CLIの導入と非対話実行の手順はCursor CLIの使い方|agentコマンドの導入・非対話実行とCI連携の手順を参照してください。
.cursorrulesから.cursor/rulesへの移行手順
.cursorrules移行の4手順とAlways Apply設定
公式ヘルプが示す移行手順は次の4つです。
- コマンドパレット(Mac: Cmd+Shift+P、Windows/Linux: Ctrl+Shift+P)で「New Cursor Rule」を選び、新しいルールを作る
.cursorrulesの中身を新しいルールファイルにコピーする- 適用タイプを
Always Applyにする(旧形式と同じ「常に適用」になる) - プロジェクト直下の
.cursorrulesを削除する
手順4を飛ばさないことが重要です。前の章のとおり、旧ファイルと.mdcが重なると.mdcが優先されるため、両方を残すと「どちらの指示が効いているのか」を後から追えなくなります。コミットメッセージ生成のために.cursorrulesを残す場合は、移行後の旧ファイルをコミットメッセージ用の1〜2行だけに減らします。次のコマンドは、プロジェクトルートで実行し、旧ファイルがGitにコミット済みで未変更、移行先のproject.mdcが未作成である場合の例です。実行後は生成内容と旧ファイルの削除を確認してください。
mkdir -p .cursor/rules
{ printf -- '---\nalwaysApply: true\n---\n\n'; cat .cursorrules; } > .cursor/rules/project.mdc
git rm .cursorrules
1ファイルを関心ごとに分割する例
丸ごとAlways Applyに移すのは最初の一歩です。公式のベストプラクティスは「1ルール500行未満」「大きなルールは組み合わせ可能な小さなルールに分ける」としており、.cursorrulesに全部書いていたなら、常に必要な約束事と、特定のファイルを触るときだけ要る規約に分けるとコンテキストを節約できます。
.cursor/rules/
project.mdc # 常に適用:言語・ディレクトリ構成・禁止事項
react-components.mdc # src/components/**/*.tsx のときだけ適用
api-validation.mdc # description で必要時にAgentが読み込む
migration.mdc # @migration で呼んだときだけ適用
フォルダで分けて整理することもできますが、公式ヘルプは「サブフォルダでも動くが、フラットな方が管理しやすい」としています。同じファイル名のルールが別フォルダにあっても、Cursorはフルパスで区別するので上書きは起きません。
.mdcファイルの書き方:frontmatter 3項目と4つの適用タイプ
.mdcファイルは、先頭の---で囲んだfrontmatterにdescription・globs・alwaysApplyの3項目を書き、その下に指示本文をMarkdownで書きます。エディタのルール画面で適用タイプを選ぶと、この3項目が書き換わります。組み合わせと挙動は公式ドキュメントで次のように定義されています。
| 適用タイプ | alwaysApply | description | globs | 挙動 |
|---|---|---|---|---|
| Always Apply | true | 無視 | 無視 | 毎回含める |
| Apply to Specific Files | false | 不問 | 指定 | 一致するファイルがあると付与 |
| Apply Intelligently | false | 指定 | なし | 説明文を見てAgentが判断 |
| Apply Manually | false | なし | なし | @ルール名で呼んだときだけ |
特定のファイルにだけ効かせるルールは次のように書きます。globsは複数指定するときカンマで区切ります。
---
globs: src/components/**/*.tsx
alwaysApply: false
---
- default export ではなく named export を使う
- スタイルはコンポーネントと同じディレクトリの CSS Modules に置く
- 1ファイル200行を超えたらサブコンポーネントに分ける
- 実装の型は @component-template.tsx に合わせる
最後の行の@component-template.tsxのようにファイルを参照しても、そのファイルの中身はルール本文に展開されません。公式ドキュメントによると、Agentは参照先を「見るべき場所」として受け取り、必要になったときに自分のツールで読みに行きます。エディタ・CLI・Cloud Agentsのどれでも同じです。毎回必ずコンテキストに入れたい内容は、参照で済ませずルール本文に書いてください。
Apply Intelligentlyのルールは、Agentがdescriptionを読んで使うかどうかを決めます。説明文が「バックエンドのルール」のように曖昧だと、Agentが関連性を判断しにくいため、「src/services/配下のRPCサービスを追加・変更するときの規約」のように、対象と場面を書きます。
本文の書き方について、公式ドキュメントは次の4点を避けるよう挙げています。
- スタイルガイドの丸写し(リンターに任せる。一般的な規約はAgentが知っている)
- npm・git・pytestのような一般的なコマンドの説明
- めったに起きない例外ケースへの指示
- コードベースにすでにある内容の複製(コードをコピーせず
@ファイル名で参照する)
ルールは最初から作り込まず、「Agentが同じ間違いを2回以上したら足す」のが公式の推奨です。ルールの下書きはAgentに作らせることもでき、チャットで/create-ruleと入力して内容を説明すると、frontmatter付きの.mdcが.cursor/rules/に保存されます。
ルールが効かないときの確認ポイント
ルールを書いたのにAgentが従わないとき、公式ドキュメントとフォーラムの回答から確認できる原因は次のとおりです。上から順に確認すると早く切り分けられます。
- 拡張子が
.mdになっている:.cursor/rules/内の.mdはfrontmatterを持たない扱いで、ルールとして無視されます。 Apply Intelligentlyなのにdescriptionが空:Agentが判断材料を持てないため呼ばれません。globsのパターンが対象ファイルに一致していない:*.tsはルート直下だけに一致し、全階層なら**/*.tsです。.cursorrulesと.mdcが同居している:重なる指示は.mdcが優先されます。alwaysApply: trueとglobsを併記している:2026年4月、Cursor 3.0.16でalwaysApply: trueのルールと.cursorrulesが常時適用されず「必要時に読む」扱いになるという報告があり、スタッフは既知の問題としたうえで、globs行を消してウィンドウを再読み込みすると直った例があると回答しています。同じスタッフは、プロジェクトのパスに日本語などASCII以外の文字が含まれるケースも切り分け候補に挙げています(原因として確定した説明ではありません)。当面の回避策は、必要なルールをチャットで@指定することです。- 上位ディレクトリの指示が混ざっている:Cursor CLIは親ディレクトリの
AGENTS.md・CLAUDE.md・.cursor/rules/も読みます。覚えのない指示に従うときは、ホームディレクトリやモノレポのルートを確認します。 - Tab補完で期待している:ルールはAgent(チャット)にしか適用されません。
適用状況を調べる補助として、目印になる指示を入れたルールを一時的に置けます。ただし、指示に従わない場合でも、ルールが未読とは限りません。フォーラムの検証でも、「新しいファイルの1行目に特定のコメントを入れる」という指示で、適用の有無を判定していました。
---
alwaysApply: true
---
- 回答の先頭に「RULE-CHECK」と1行だけ書く
新しいチャットで何か質問し、先頭にRULE-CHECKが出れば、そのルールは読まれています。確認が済んだらファイルを消してください。
AGENTS.md・CLAUDE.md・Agent Skillsとの使い分け
2026年のCursorには、ルール以外にもAgentへ前提を渡す仕組みが増えています。何を書くかで置き場所を決めると迷いません。
- 条件付きで効かせたい規約は
.mdc:ファイル単位で絞るglobsはProject RulesとTeam Rulesで使えますが、descriptionを読ませてAgentに適用を判断させられるのはProject Rulesだけです。 - ほかのAIツールと共有したい常時の約束事は
AGENTS.md:CursorはプロジェクトルートとサブディレクトリのAGENTS.mdを読み、入れ子のものは親と結合したうえで、より深い階層の指示を優先します。GitHub CopilotもVS Code・JetBrains IDE・Copilot CLIなど多くの環境でAGENTS.mdを読むため(2026年10月時点の公式の対応表でVisual Studioは対象外)、複数ツールを併用するチームではここに寄せるのが効率的です。GitHub Copilot側の指示ファイルとの関係はcopilot-instructions.mdとは?書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】、Clineの.clinerulesは.clinerulesとは?書き方・配置場所とCline v4.1での読み込み仕様にまとめています。 - Claude Codeと同じリポジトリなら
CLAUDE.mdも読まれる:常時適用なので、条件付きにしたい内容をCLAUDE.mdに書くと、Cursorでは毎回コンテキストに入ります。 - 手順書やスクリプトを伴う作業はAgent Skills:Skillsは
.cursor/skills/・.agents/skills/に置き、互換のため.claude/skills/と.codex/skills/も読み込まれます。組み込みの/migrate-to-skillsは、Apply Intelligentlyのルール(alwaysApplyがfalseでglobsなし)とスラッシュコマンドをSkillへ変換します。Always Applyやglobs付きのルール、User Rulesは変換対象外です。Skillの仕様はAgent Skillsとは?SKILL.md仕様とAAIF寄贈後も移植性を保つ実装手順で解説しています。
避けたいのは、同じ約束事を.cursorrules・.mdc・AGENTS.mdに重ねて書く運用です。優先順位のルールで片方が上書きされ、修正したつもりの指示が効かない原因になります。常時必要な約束事は、自動適用される1つのファイルに集約してください。補足資料は@ファイル名で参照できますが、Cursorでは参照先の本文が自動展開されるわけではありません。
Claude Code・GitHub Copilotとルールを共有する構成
チームにCursorとClaude Codeの利用者が混在すると、ルールの二重管理が問題になります。条件を書くキーの名前はツールごとに違い、Cursorはglobs、Claude Codeの.claude/rules/はpaths、GitHub Copilotの.instructions.mdはapplyToです。そのため、あるツール向けの条件付きルールを、そのまま別のツールへ置いても同じ適用条件にはなりません。手戻りが少ないのは、常に適用する指示をルートのAGENTS.mdに集め、ファイルの種類で切り替えるルールだけをツールごとに書く構成です。
repo/
AGENTS.md # 対応環境で共有する指示(ビルド手順、ディレクトリの約束、禁止事項)
CLAUDE.md # 1行だけ:@AGENTS.md
.cursor/rules/
api.mdc # globs: src/api/**/*.ts
.claude/rules/
api.md # paths: ["src/api/**/*.ts"]
.github/instructions/
api.instructions.md # applyTo: "src/api/**/*.ts"
CLAUDE.mdを@AGENTS.mdの1行だけにしているのは、Claude Codeの既定設定では作業ディレクトリかその上位にCLAUDE.md(CLAUDE.local.mdを含む)があるとAGENTS.mdを読まないためです(Claude Code公式ドキュメント。/configのProject instructionsで両方を読む設定にもできます)。一方、Cursorは既定でAGENTS.mdとCLAUDE.mdの両方を常に適用します。CLAUDE.mdにAGENTS.mdの本文を書き写す運用は、片方だけを更新して内容が食い違う原因になります。なお、2026.10.22版のCursor CLIには、同じディレクトリか親子の階層にあるAGENTS.md・CLAUDE.mdのうち、本文が完全に同じものや同じ実体を指すリンクを1つにまとめる処理があります。完全に同じなら二重には入りませんが、1行でも違えば両方が読み込まれます。
やってはいけないのは、Cursor用の.mdcを.claude/rules/へ.mdの名前でシンボリックリンクする共有です。Claude CodeはglobsとalwaysApplyを読まずに無視するため、Cursorでは特定のファイルに限っていたルールが、Claude Codeでは無条件に毎回読み込まれます。リンクで共有してよいのは、frontmatterを持たない常時適用の本文だけです。ツール別のファイルの片方だけを直す更新漏れが起きるようなら、APM(Agent Package Manager)とは?AIエージェント設定をnpm方式で一元管理するMicrosoft製OSSの仕組みのような配布の仕組みに寄せると食い違いを防げます。
よくある質問
.cursorrulesはもう使えませんか?
2026年10月時点では使えます。公式ヘルプは「legacyで今後非推奨」としていますが、削除はされておらず、2026年10月22日版のCursor CLIもGitリポジトリのルートにある.cursorrulesを常時適用のルールとして読み込みます。ただしルールのリファレンスからは説明が外れているため、新しく書くなら.cursor/rules/かAGENTS.mdを使ってください。
.cursorrulesと.cursor/rulesを両方置くとどうなりますか?
両方とも読み込まれますが、内容が重なる部分は.cursor/rules/の.mdcが優先されます。移行したら.cursorrulesは削除し、どちらか一方に寄せてください。コミットメッセージ生成のためだけに残す場合は、その用途の1〜2行に絞ります。
.mdと.mdcの違いは何ですか?
.mdcはfrontmatter(description・globs・alwaysApply)を持つCursorのルール形式です。.cursor/rules/に置いた.mdはルールとして無視されます。frontmatterなしのMarkdownで書きたい場合は、プロジェクト直下のAGENTS.mdに書きます。
Cursorのルールは自動生成できますか?
できます。Agentのチャットで/create-ruleと入力して作りたいルールを説明すると、frontmatter付きの.mdcが.cursor/rules/に保存されます。サイドバーのCustomize → Rulesの「Add Rule」からも作成できます。
おすすめのルールは何を書けばよいですか?
公式の推奨は「最初は最小限にし、Agentが同じ間違いを繰り返したら足す」です。まずはリンターで検査できない約束事(ディレクトリ構成、生成ファイルを編集しない、参照すべきテンプレート)を短く書き、スタイルガイドの丸写しや一般的なコマンドの説明は入れないのが公式ドキュメントの方針です。