CursorのRules、AGENTS.md、メモリ：毎回の説明を「書いておく」ための種類、置き場所、書き方、優先順位、チームでの共有を、公式ドキュメントで確かめる

この記事は、公式のドキュメント、ヘルプ、更新履歴、公式ブログを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はCursorを入れていますが、使い心地はこの記事には書いていません。ファイル名、設定の名前、メニュー名、コマンドは、公式に書かれているとおりに写したもので、動作確認はしていません。公式の文章は要約の形で取得したため、引用は少数にとどめ、ほとんどは言い換えています。バージョンや画面の名前は、更新で変わることがあります。

先に結論

• まず1本、プロジェクトの「常時」ルールか AGENTS.md を書く。 内容は、動かすコマンド、守るスタイル、見本にしてほしいファイルの場所くらいで足ります。長い説明は要りません。
• 「このファイルを触るときだけ」は、globs を使った .mdc。 公式の例では、src/components/**/*.tsx のような書き方で、一致するファイルが文脈にあるときだけ付きます。
• 自分の好みはUser Rules、組織の決まりはTeam Rules。 ただし、User RulesはAgent（チャット）にだけ使われます。ほかのAI機能には効きません。
• ルールを書いても効かないときは、まず種類と書き方を疑う。 公式のヘルプに、確認の順番が載っています（この記事の「うまくいかないとき」）。
• メモリは、読んだ範囲でははっきりしない部分が多い。 確実に残したいことは、メモリに頼らず、ルールのファイルに書いてgitに入れるほうが、公式の記載とは合っています（この点は僕らの見立てです）。

前提：用語をそろえる

置き場所と種類の一覧

公式のRulesのページとヘルプを合わせた表です（確認日10月24日）。

補足です。

• ホームフォルダの ~/.cursor/rules は、更新履歴の2.1（2025年11月21日）に、文脈に含まれるようになったと書かれています。ヘルプの記載とあわせると、「自分のパソコンだけで使うルール」の置き場所です。
• ヘルプには、User RulesとTeam Rulesは、プロファイルの書き出しに含まれない、とあります。パソコンを移すとき、プロファイルを書き出すだけでは、この2つは持っていけない、という意味に読めます（これは僕らの読みです）。
• .cursorrules（プロジェクトのルートに置く古い形式）は、ヘルプが「レガシーで、いずれ非推奨になる」と書いています。非推奨にする日付は、読んだ範囲では見つかりませんでした。移行の手順は、後の「古い .cursorrules があるとき」にまとめます。

Project Rules（.mdc）の書き方

置き方とfrontmatter

ルールは、.cursor/rules の下に、拡張子 .mdc で置きます。サブフォルダで整理できます。公式の例は次のとおりです。

.cursor/rules/
  react-patterns.mdc       # Recognized as a project rule
  api-guidelines.md        # Ignored (wrong extension)
  frontend/                # Organize rules in folders
    components.mdc

ヘルプは、フォルダを増やさずに平らに置くことを勧めています（入れ子も動くとも書かれています）。また、同じ名前のファイルが別のフォルダにあっても、ルールは完全なパスで区別されるので、条件に合えば両方が適用される、とあります。意図せず同じ内容が二重に入らないよう、名前は分けたほうがよい、というのは僕らの見立てです。

先頭には、--- で囲んだ設定を書きます。項目は3つです。

• description：エージェントが、このルールを取り込むかどうかを判断するための説明。
• globs：ルールを当てるファイルの型。複数ならカンマで区切る。
• alwaysApply：true なら毎回のチャットに入る。このとき globs と description は無視される。

4通りの動き方

エディタの種類のドロップダウンで切り替えると、上の項目が変わります。公式は、次の4つを挙げています。

よくある失敗として、公式のFAQには、Apply Intelligently は説明が必須で、Apply to Specific Files はパターンが合っている必要がある、とあります。

公式の例（そのまま写したもの）

常に入れるルールです。

---
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

ファイルの型で自動的に付くルールです。

---
globs: src/components/**/*.tsx
alwaysApply: false
---

- Use named exports, not default exports
- Co-locate styles in a module CSS file next to the component
- Keep components under 200 lines. Extract subcomponents into the same
  directory when a file grows beyond that
- Prefer composition over prop drilling. Pass children or render props
  instead of threading data through multiple layers

エージェントに判断させるルールです。

---
description: RPC service conventions and patterns for the backend
alwaysApply: false
---

- Define each service in its own file under `src/services/`
- Always validate inputs at the service boundary before passing data
  to internal functions
- Return structured error objects with a `code` and `message` field,
  never throw raw strings
- Read `@service-template.ts` for the standard boilerplate before
  creating a new service

名指しのときだけ使うルールです。

---
alwaysApply: false
---

- Every database migration must have both `up` and `down` functions
  so it can be fully reversed
- Never alter a column type in-place. Add a new column, backfill,
  then drop the old one in a separate migration
- Read `@migration-template.sql` for the expected file structure
  before writing a migration

globの書き方

公式の表から、初心者がよく使うものを選びました。

ファイルを参照するとき

ルールの中で @service-template.ts のようにファイル名を書いても、そのファイルの中身がルールに貼り付けられるわけではありません。エージェントが、必要になったときに、道具で読みに行きます。公式は、これはエディタでも、CLIでも、Cloud Agentsでも同じ、と書いています。つまり、毎回必ず文脈に入れたいことは、ルールの本文に直接書く必要があります。

AGENTS.mdとCLAUDE.md

AGENTS.md は、メタデータのない、ただのMarkdownです。プロジェクトのルートに置くと、Cursorが拾います。公式の例は次のとおりです。

# Project Instructions

## Code Style
- Use TypeScript for all new files
- Prefer functional components in React
- Use snake_case for database columns

## Architecture
- Follow the repository pattern
- Keep business logic in service layers

サブフォルダにも置けます。サブフォルダの AGENTS.md は、そのフォルダかその下のファイルを扱うときに自動で適用され、親フォルダの指示と合わさり、より細かい側が優先されます。公式の構成例は次のとおりです。

project/
  AGENTS.md              # Global instructions
  frontend/
    AGENTS.md            # Frontend-specific instructions
    components/
      AGENTS.md          # Component-specific instructions
  backend/
    AGENTS.md            # Backend-specific instructions

ヘルプには、条件つきで適用させたいなら .cursor/rules を使うように、とあります。AGENTS.md には globs や alwaysApply の設定欄がないからです。

CLAUDE.mdの扱い。 ヘルプによると、CLAUDE.md も AGENTS.md と同じように読まれます。そして、CLAUDE.md は alwaysApply の設定に関係なく、毎回の会話に適用される、とあります。CLIについては、公式の「CLI Capabilities」に、プロジェクトのルートの AGENTS.md と CLAUDE.md があれば読む、と書かれています。

どちらを選ぶか（僕らの見立てです）。 条件分けが要らず、できるだけ簡単にしたいなら AGENTS.md。ファイルの型で出し分けたい、または説明文でエージェントに判断させたいなら .mdc。公式がこの選び方を書いているのは、上のヘルプの1文（条件つきなら .cursor/rules）だけです。AGENTS.md と .cursor/rules の内容がぶつかったとき、どちらが勝つのかは、読んだ範囲では見つかりませんでした。ぶつからないように、同じことを両方に書かない、のが安全です。

User Rulesと、チームのTeam Rules

User Rules

Customize を開いて Rules に、自分の好みを書きます。公式の例は、「簡潔に答えて。余計な繰り返しや前置きは避けて」という趣旨の1文です。使われるのはAgent（Chat）だけで、インライン編集（Cmd/Ctrl+K）には使われません。ヘルプによると、アカウントに保存されて、パソコンをまたいで同期されます。

Team Rules

TeamとEnterpriseのプランで使えます。管理者が、ダッシュボードの cursor.com/dashboard/team-content で作ります。

• Enable this rule immediately。 チェックすると、作った時点で有効になります。外すと下書きとして保存されます。
• Enforce this rule。 有効にすると、チーム全員に必須になり、メンバーが Customize で無効にできなくなります。外しておくと、メンバーは Customize の Team Rules からオフにできます（ヘルプには、強制しないルールは、初期状態では有効で、メンバーが無効にできる、とあります。Rulesのドキュメントにも、強制しないルールはメンバーがオフにできる、とあります）。
• 書き方。 自由な文章で、フォルダ構造はありません。globs は使えます。globs のないルールは、すべての会話に適用されます。
• 範囲。 チームの全部のリポジトリ、全部のプロジェクトで、Agent（Chat）に適用されます。
• 注意。 公式は、強制されたルールはコンプライアンスの流れを支えられるが、AIへの指示だけをセキュリティ対策にしてはいけない、と書いています。

更新履歴には、1.7（2025年9月29日）で、チームが共有のグローバルルールをダッシュボードから決められるようになり、2.0（2025年10月29日）でTeam Commands（チーム用のコマンド）も加わった、とあります。

優先順位：ぶつかったらどちらが勝つか

公式の順番は、Team Rules、Project Rules、User Rules です。適用されるルールはすべて合わされ、指示がぶつかったときは、前の側が勝つ、と書かれています。

見立てです。「ぶつかったら勝つ側が決まっている」とはいえ、そもそもぶつからないように書くのが、一番確実です。たとえば、チームの決まりはTeam Rulesかプロジェクトのルール、自分の口調や言語の好みはUser Rules、と役割を分けておきます。

ルールを作る方法

公式に書かれている作り方は、次のとおりです。

最後のCLIの /rules は、注意が要ります。更新履歴にはそう書かれていますが、2026年10月24日に読んだCLIの「Slash commands」のリファレンスのページには、/rules が載っていませんでした。いまのCLIで使えるかどうかは、確認できていません。

古い .cursorrules があるとき

ヘルプに載っている移行の手順です。

1. 「New Cursor Rule」で、新しいルールを作る。
2. .cursorrules の内容を、新しいルールに写す。
3. 種類を Always Apply にする（古い動きと同じになる、と書かれています）。
4. プロジェクトのルートから .cursorrules を消す。

メモリは、ルールとは別のもの

「メモリ」という言葉は、公式の資料のなかで、2つの場面に出てきます。どちらも、ルールのように「自分で書くファイル」ではない点が違います。

エディタのMemories（2025年6月）。 更新履歴の1.0（2025年6月4日）に、Memoriesをベータの機能として出す、と書かれています。有効にする場所は、Settings の Rules。メモリはプロジェクトごとに、個人の単位で保存され、Settingsから管理できる、と書かれています（チームで共有されるかどうかには触れていません）。ここまでは更新履歴の記載です。そのあと、いまのエディタで、Memoriesがどうなっているか（設定の場所、名前、仕組み）は、確認できていません。いまのRulesのドキュメントとヘルプは、どちらもメモリに触れていないので、ルールのように、ここを頼りにして仕組みを組むのは避けたほうがよい、というのが僕らの見立てです。

Automationsのメモリ（いまの公式ドキュメント）。 Automationsは、クラウドで定期的、または出来事をきっかけに動くエージェントです（前のガイド04を参照）。そのページには、メモリは、初期設定で有効（無効にもできる）で、同じAutomationの、実行をまたいでメモを読み書きするために使われる、と書かれています。名前は、既定では MEMORIES.md で、エージェントの作業用のファイルの外に保存され、ツールの設定画面から見たり、編集したり、削除したりできます。エージェント自身が、古いメモリのファイルを、実行中に消すこともあります。

公式の警告は具体的です。信頼できない入力を扱うAutomationでは、メモリに気をつけて使うこと。入力によって、誤解させる内容や悪意のある内容がメモリに書かれ、次の実行に影響しうる、とあります。

つまり、Automationsのメモリは「放っておいても勝手に増える」ものです。ルールのように、中身を人が書いて、gitで見直せるものとは違います。最初は、読んだ内容を確かめるか、無効にしてから使うのも一案です（これは僕らの見立てです）。

なお、Rulesの公式のページには、LLMは会話をまたいで記憶を持たないので、ルールがプロンプトの水準で、持続する文脈を与える、という趣旨の説明があります。「記憶」の役目を、ルールが担っているということです。

ルール、コマンド、スキルの使い分け

3つとも、エージェントに読ませる文章ですが、働き方が違います。ここは公式の記載の整理です。

公式ブログ（2026年1月9日）は、ルールは「毎回入る」もので、スキルは必要なときに動的に読み込まれるので、文脈の窓がすっきり保てる、と説明しています。コマンドは、「繰り返したい手順が固まってから」足すよう勧めています。

Skillsの置き場所と書き方は前のガイド04で扱いました。ここでは1点だけ補足します。公式のSkillsのページによると、組み込みの /migrate-to-skills で、一部のルールをスキルに変換できます。変換されるのは、alwaysApply が false（または未設定）で、globs のない、いわゆる「AI判断」のルールです。alwaysApply: true のものと、globs のあるものは、変換されません。User Rulesも、ファイルとして保存されていないので、変換されません。

公式ブログには、「スキルはNightlyの配布経路のみ」という趣旨の記載がありますが、2026年1月の記事のものです。いまのドキュメントでは、スキルは通常の機能として説明されているので、このブログの記載は古い可能性があります。

書き方のコツ（公式の記載）

公式のRulesのページと、公式ブログ「Best practices for coding with agents」から整理します。

入れること。 - 動かすコマンド（ビルド、型チェック、テスト）。公式ブログの例は、ビルド、型チェック、テストのコマンドを並べています。 - 守ってほしいパターン（ES modulesを使う、など）。 - お手本になるファイルの場所（「components/Button.tsx が標準の形」など）。 - 作業の流れ（変更をまとめたら型チェックをする、など）。

入れないこと。 - スタイルガイドを丸ごと貼ること。そういうものは、リンター（自動で書き方を検査する道具）に任せる。 - npm、git、pytestのような、よく知られたコマンドの説明。エージェントはすでに知っている、と公式は書いています。 - めったに起きない例外のための指示。 - コードベースの中身の複製。見本のファイルを指す。

長さと育て方。 - 1つのルールは500行未満にする。大きいものは、小さなルールに分ける。 - ファイルは写さず、参照する。コードが変わっても、ルールが古くならない。 - 小さく始める。エージェントが同じ間違いを繰り返すとわかったら、そのときにルールを足す。 - gitに入れて、間違いがあったら直す。GitHubのIssueやPRで @cursor と書くと、エージェントにルールの更新を頼める、とあります。

公式ブログの例（そのまま写したもの）。

# Commands

- `npm run build`: Build the project
- `npm run typecheck`: Run the typechecker
- `npm run test`: Run tests (prefer single test files for speed)

# Code style

- Use ES modules (import/export), not CommonJS (require)
- Destructure imports when possible: `import { foo } from 'bar'`
- See `components/Button.tsx` for canonical component structure

# Workflow

- Always typecheck after making a series of code changes
- API routes go in `app/api/` following existing patterns

ブログは、別の箇所でルールを、毎回の会話の最初に見える「いつも入る（always-on）」文脈として説明しています。

指示の書き方についてのブログの助言は、具体的に書くこと、できる限り、確かめられる目標（型、リンター、テスト）を用意すること、大きな作業ではPlan Mode（Shift+Tab）で先に計画を作らせること、です。

最初の10分でやること

公式に書かれている範囲で組み立てた手順です。順番と時間の配分は僕らの整理です。

0〜2分：いまあるルールを見る。 1. 練習用でも仕事でも、プロジェクトのフォルダをCursorで開く。 2. サイドバーの Customize を開いて Rules を見る。すべてのルールとその状態が一覧になる、とあります。 3. プロジェクトのルートに、AGENTS.md、CLAUDE.md、古い .cursorrules がないか確かめる。.cursorrules があれば、上の移行の手順に回す。

2〜6分：「常時」の1本を書く。 4. 次のどちらかで始める。 - 条件分けが要らない: ルートに AGENTS.md を作る。 - 設定つきで管理したい: Agentに /create-rule と打ち、「毎回守ってほしいこと」を説明する。または Customize > Rules > Add Rule。 5. 中身は、公式の例に倣い、10〜15行ほどにする。コマンド（ビルド、テスト）、スタイルを2〜3行、見本のファイルの場所を1つ。すでに知られているコマンドの説明は書かない。 - たとえば、TypeScriptのWebアプリなら、次のような形です（僕らが作った例で、公式の例ではありません。動作確認はしていません。コマンド名は、自分のプロジェクトの package.json に合わせて直してください）。

# Project Instructions

## Commands
- `npm run build`: Build the project
- `npm run typecheck`: Run the typechecker
- `npm run test`: Run tests (prefer single test files)

## Code Style
- Use TypeScript for all new files
- Use named exports, not default exports
- See `src/components/Button.tsx` for the standard component shape

## Workflow
- Run the typecheck after a series of code changes

1. パスワード、APIキー、個人のメールアドレスなど、秘密の情報は書かない。ルールのファイルはgitで共有されうるからです（これは僕らの見立てです）。

6〜8分：「このファイルのとき」の1本を足す（任意）。 7. 毎回は要らないが、特定のファイルのときだけ守りたいことがあるなら、globs つきの .mdc を作る。公式の例のとおり、globs: src/components/**/*.tsx と alwaysApply: false を先頭に書く。

8〜10分：試して、残す。 8. 新しいチャットを開き、ルールの内容に関係する小さな作業を頼む。たとえば、コマンドを使うテストの実行や、ルールで決めた書き方のファイルの作成。ルールの内容に沿っているかを見る。頼み方の例は「ルールに書いたテストのコマンドを使って、このファイルのテストを実行して」です（僕らの例です）。 9. 沿っていなければ、「うまくいかないとき」の確認に進む。どのルールがチャットに適用されたかを、画面で確かめる方法は、読んだ範囲では見つかりませんでした。僕らの見立てとして、簡単な確かめ方は、ルールにだけ書いた合言葉（たとえば「返事の最後に必ず『確認済み』と書く」）を決めて、新しいチャットで従うかを見ることです（公式に書かれた方法ではなく、確かめてもいません。確かめたら、合言葉の行は消してください）。Rulesのドキュメントには、Customizeですべてのルールとその状態が見られる、とあります（その「状態」が、チャットに適用されたかどうかまで示すのかは、読んだ範囲では分かりません）。 10. 満足したら、.cursor/rules と AGENTS.md をgitにコミットする。チームで使うなら、これでメンバーにも届く。

この10分は、ルールを完璧にするためではありません。公式の勧めは「小さく始めて、間違いが続いたら足す」です。

チームで共有する

公式に書かれている共有の方法を、強さの順に並べます（強さの順は僕らの整理です）。

公式のRulesのページは、GitHubのリポジトリからルールを取り込むとき、ルールが自動では取り込まれず、プラグインにして公開する必要がある、と書いています。URLから直接ルールを取り込む方法は、書かれていませんでした。

ルールを育てる運用。 公式の勧めは、gitに入れる、間違いが繰り返されたら直す、GitHubのIssueやPRで @cursor と書いてルールの更新を頼む、です。個人の好みはUser Rules、チームの共通の決まりはリポジトリのルールかTeam Rules、と分けておくと、誰かの好みで全員の動きが変わることを避けられる、というのが僕らの見立てです。

うまくいかないとき

ヘルプの確認の順番（1から3）に、公式の別の記載から2つ（4と5）を足して整理します。

1. 種類を確かめる。 そのルールは、Always Apply、Apply to Specific Files、Apply Intelligently、Apply Manually のどれか。
2. Apply Intelligently なら、description を書いたか。 説明がないと、判断に使えません。
3. Apply to Specific Files なら、パターンが、いま編集しているファイルに合っているか。
4. 拡張子は .mdc か。 .md だけだと無視されます。
5. 使っている機能は、Agent（Chat）か。 ヘルプによると、ルールはAgent（Chat）にだけ適用され、Tab（入力補完）、インライン編集、BugbotのPRレビューには適用されません。Rulesのドキュメントも、ルールはCursor Tabなど、ほかのAI機能には影響しない、と書いています。

ひとつ補足します。ヘルプはBugbotに適用されないと書いていますが、更新履歴の1.7には、Bugbot用のチームのルールにも触れる記載がありました。Bugbotには、Bugbotなりのルールの仕組みがあるのかもしれません。読んだ範囲では、そこまで確認できていません。Bugbotの置き場所は、前のガイド04を見てください。

気をつけること

• ルールは「お願い」。 守られることは保証されません。止めたいことは、承認や許可の設定の役目です（前のガイド02）。公式も、AIへの指示だけをセキュリティ対策にしないよう書いています。
• 秘密を書かない。 ルールはgitで共有されます。.cursorignore のようなファイルでAIの文脈から外しても、公式のヘルプは、ターミナルのコマンドやMCPのツールからは読める可能性がある、と書いています（読んだ範囲では、.cursorignore とルールの関係は書かれていません）。
• ルールは読まれる量が増えるほど、文脈を使う。 1つは500行未満という公式の目安のとおり、短く、焦点を絞る。長いルールを常時にすると、毎回、その分が文脈に入ります（これは仕組みからの僕らの読みで、使用量への影響を、公式が数字で書いているわけではありません）。
• ルールをCloud Agentsなど、別の場所で使うときの扱いは、読めていません。 Rulesのドキュメントは、ファイルの参照は、エディタ、CLI、Cloud Agentsで同じ動きだと書いていますが、Cloud Agentsのページには、ルールの扱いの記載を見つけられませんでした。
• 2.2の更新履歴に、「ルールが、プロンプトやスクリプトなどと一緒に、フォルダにまとめられるようになった」という趣旨の1行があります。 具体的な書き方は、読んだページにはなく、確認できていません。
• Rulesの優先順位で、書かれていない組み合わせがあります（AGENTS.md と .mdc など）。ぶつからないように分けて書いてください。
• Memoriesの現状は確認できていません。 公式の更新履歴には、2025年6月にベータで始まったと書かれていますが、いまのエディタでの扱いは、読んだ資料にありませんでした。
• この記事は、実際に使って確かめた記録ではありません。運営者はCursorを入れていますが、使い心地はこの記事には書いていません。 ファイル名、設定の名前、メニュー、コマンドは公式の記載を写したものです。取得したのはページの要約なので、読み切れていない箇所があります。更新で変わる点は、公式の最新の表示で確かめてください。この記事は、セキュリティや法律の助言ではありません。

出典

• Rules（Cursor Docs、Cursor、2026年10月24日確認）
• Rules（Cursor Help、Cursor、2026年10月24日確認）
• Customize overview（Cursor Docs、Cursor、2026年10月24日確認）
• CLI Capabilities（Cursor Docs、Cursor、2026年10月24日確認）
• Slash commands（Cursor Docs、Cursor、2026年10月24日確認）
• Agent Skills（Cursor Docs、Cursor、2026年10月24日確認）
• Automations（Cursor Docs、Cursor、2026年10月24日確認）
• Ignore files（Cursor Help、Cursor、2026年10月24日確認）
• Best practices for coding with agents（Cursor Blog、Cursor、2026年1月9日、確認日2026-10-24）
• Changelog 1.0（Cursor、2025年6月4日、確認日2026-10-24）
• Changelog 1.6（Cursor、2025年9月12日、確認日2026-10-24）
• Changelog ページ14（1.7、2.0の記載、Cursor、確認日2026-10-24）
• Changelog ページ13（Cursor、確認日2026-10-24）
• Changelog 2.1（Cursor、2025年11月21日、確認日2026-10-24）
• Changelog 2.2（Cursor、2025年12月10日、確認日2026-10-24）
• CLI changelog（Cursor、2026年1月8日、確認日2026-10-24）
• Changelog 一覧（Cursor、確認日2026-10-24）