Cursorに同じ指摘を毎回繰り返させていないだろうか。原因の多くはコードの書き方ではなく、ルールファイルの置き方・書き方にある。本稿では公式ドキュメントをもとに、Cursorのルール機構を整理し、Claude Codeなど他のAI開発ツールと併用する際の実践的な設計方針をまとめる。
なぜ「毎回同じ指摘」が起きるのか
大規模言語モデルは補完(completion)をまたいで記憶を保持しない。会話が長くなっても、モデルの重みそのものは前回のやり取りを覚えているわけではなく、毎回プロンプトとして渡されたコンテキストだけを見て応答している。つまり「このプロジェクトではこう書く」「このディレクトリは触らない」といった約束事は、明示的にプロンプトの一部として毎回渡さない限り、エージェントは知らないのと同じ状態になる。この永続コンテキストを提供する仕組みが、Cursorの「Rules」機能だ。
Cursorが持つ4種類のルール
公式ドキュメントによれば、Cursorには次の4種類のルールがある。
| 種類 | 保存場所 | スコープ |
|---|---|---|
| Project Rules | .cursor/rules(.mdcファイル) |
リポジトリ単位・バージョン管理対象 |
| User Rules | Cursor環境設定 | 自分の全プロジェクトに適用(Agent/Chatで使用) |
| Team Rules | ダッシュボード管理 | チーム全体(Team/Enterpriseプランのみ) |
| AGENTS.md | リポジトリ直下 | .cursor/rulesの簡易な代替、Markdownのみ |
初めてCursorのルールを設計するなら、まず一番細かく制御できるProject Rulesの仕組みを理解しておくと応用が利く。
Project Rulesの4つの適用モード
.cursor/rules内の.mdcファイルは、frontmatter(先頭の---で囲んだメタデータ)の組み合わせによって、いつエージェントのコンテキストに読み込まれるかが変わる。
alwaysApply |
description |
globs |
挙動 |
|---|---|---|---|
true |
— | — | 常に読み込まれる。description/globsは無視される |
false |
— | 指定あり | 該当パターンのファイルがコンテキストに含まれると自動適用 |
false |
指定あり | 省略 | 説明文を見てエージェントが「関連しそう」と判断したときだけ取り込む |
false |
省略 | 省略 | チャットで@ルール名と明示的にメンションしたときのみ適用 |
例えば、常時適用したいコーディング規約は次のように書く。
---
alwaysApply: true
---
- All source files must include the company copyright header
- When you are unsure about implementation details, read the relevant source files before proposing changes
- Never modify generated files in the `dist/` or `build/` directoriesよくあるつまずきは、frontmatterを付けずに素の.mdファイルを.cursor/rulesに置いてしまうケースだ。この場合ルールは静かに無視される。ルールが効いていないと感じたら、まずfrontmatterの有無とglobsの書式を確認するとよい。
AGENTS.mdとCLAUDE.mdの二重管理を避ける
CursorとClaude Codeを併用しているチームでは、同じ約束事を2つのファイルに書いてしまい、内容がずれていく「二重管理」が起きやすい。Claude CodeもCLAUDE.md(プロジェクト直下・~/.claude/CLAUDE.mdなど複数スコープ)と.claude/rules/(paths:frontmatterでパス指定)という、Cursorとよく似た階層構造を持つ。
両ツールに共通するAGENTS.mdを一次情報として1つだけ用意し、CLAUDE.md側からは@AGENTS.mdで読み込むだけにするのが実務上シンプルだ。逆に、ファイルではなくエージェントが実行中に学習した「一時的な知見」(このAPIは実はこう振る舞う、この設定は罠、など)は、そもそもfrontmatterの条件やCLAUDE.mdのローカルスコープに縛られるため、単一ファイルで解決しようとせず、必要なら共有のメモ置き場を別途用意するという整理が現実的だ。
ルール本文を書くときの実務Tips
- 重要なルールを先頭に置く — ファイルが長いと後半が切り詰められることがある。
- 命令形で書く — 「〜した方がよい」ではなく「Xを使う」と言い切る。
- 具体例で示す — 抽象的な説明より、実際のコード例の方が伝わる。
- 重複させない — Linter設定や
.editorconfigに書いてあることを繰り返さない。 - 古くなったら消す — 実態と合わない指示は、書かないより有害。
- 失敗から学んだことを書き足す — 何度も試行錯誤して解決した問題は、直後にルールへ1行追記する習慣をつけると、同じ落とし穴を二度と踏まなくなる。
Vibe coding運用での注意点
ルールを整えても、コーディングそのものの進め方が雑だと効果は薄い。実務者向けの解説記事では、次のような運用が共通して推奨されている。
- プロンプトの冒頭に、対象アプリの目的・利用者を1ページで要約した仕様を貼っておく。
- 一度の変更を「確認できる大きさ」に留める — 大規模な一括変更は差分レビューが破綻しやすい。
- 変更後にエージェント自身へ平易な言葉で「何を変えたか」を説明させる。
- シークレット(APIキーなど)はコードに一切含めない。
- 動作確認が取れた状態でこまめにコミットする。
あるコンサルタントは、プロトタイプ段階ではLovableやBolt.newのようなオールインワン型ツールで素早く形にし、本番相当のコードに仕立てる段階でCursorやClaude Codeへ「移植」するワークフローを勧めている。ツールごとに得意な工程が異なるため、プロジェクトの成熟度に応じて使い分けるという発想だ。
主な情報源
- Rules | Cursor Docs
- Share One Memory Between Cursor and Claude Code (MemoryLake)
- Do you write an AGENTS.md? (SSW.Rules)
- The Complete AGENTS.md Guide for AI Coding Agents (Moxie Docs)
- How to Vibe Code: A 7-Step Method for Founders (2026)
- Best AI Coding Tools for Vibe Coding (2026)
各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。