なぜCursorはまっさらな状態から始まるのか、そして実際に何が引き継がれるのか
ルールを配置できる4つの場所
Cursorのドキュメントに記載されているセットは以下の通りです：
Project rules（プロジェクトルール）は、.cursor/rules 内に .mdc ファイルとして保存され、バージョン管理されます。これらは「パスパターンを使用してスコープが設定されるか、手動で呼び出されるか、あるいは関連性に基づいて組み込まれます」。
User Rules（ユーザールール）は、「Customize → Rules で定義されるグローバルな設定で、すべてのプロジェクトに適用されます」。これらは Agent (Chat) によって使用され、コミュニケーションスタイルや個人のコーディング規約を記述するのに最適です。
Team Rules（チームルール）は、「ダッシュボードから管理されるチーム全体のルール」であり、TeamプランおよびEnterpriseプランで利用可能です。
AGENTS.md は、「マークダウン形式の Agent 指示書。.cursor/rules のシンプルな代替手段」と説明されています。ネスト（入れ子）構造もサポートされており、任意のサブディレクトリに AGENTS.md を配置すると、そのディレクトリまたはその配下の子ファイルで作業する際に自動的に適用されます。指示内容は「親ディレクトリのものと結合され、より具体的な指示が優先されます」。
多くの開発者は、これらのうちの1つだけを記述し、それですべてがカバーされていると思い込んでいます。
確実に適用されるルールタイプは1つだけ
ここが核心です。ドキュメントに記載されているCursorの4つのルールタイプは以下の通りです：
| ルールタイプ | 適用されるタイミング |
|---|---|
| Always Apply（常に適用） | 「すべてのチャットセッションに適用」 |
| Apply Intelligently（インテリジェントに適用） | 「Agentが説明（description）に基づいて関連性があると判断したとき」 |
| Apply to Specific Files（特定のファイルに適用） | 「ファイルが指定されたパターンに一致したとき」 |
| Apply Manually（手動で適用） | 「チャット内で @ メンションされたとき」 |
内部的には、フロントマター（frontmatter）の3つのフィールドによってこれが決定されます。alwaysApply: true は「常に含まれます。Globパターンと説明（description）は無視されます」という意味です。alwaysApply: false でGlobパターンが指定されている場合、ルールは「一致するファイルがコンテキスト内にあるときに自動的に添付」されます。説明がありGlobパターンがない場合は、「Agentが説明を読み、関連性がある場合にルールを取り込みます」。どちらも指定されていない場合は、「チャットでルールを @ メンションしたときのみ含まれます」となります。
つまり、3週間前にフロントマターを設定せずに書いたルールは、あなたが一度も入力したことのない @ メンションを待ち続けている状態なのです。紛失したわけではありません。最初から呼び出されていなかったのです。
Cursor自身のFAQの回答が、最も素早い診断方法になります。「ルールタイプを確認してください。Apply Intelligently の場合は、説明（description）が定義されていることを確認してください。Apply to Specific Files の場合は、ファイルパターンが参照されているファイルと一致していることを確認してください。」
.cursor/rules 内の通常の .md ファイルは警告なしに無視される
これは、何の警告も表示されないため、最も時間を無駄にするエラーです。ドキュメントにはこう明記されています。「.cursor/rules 内の通常の .md ファイルは、description、globs、alwaysApply を指定するフロントマターがないため、ルールシステムによって無視されます。通常のマークダウンを好む場合は、代わりに AGENTS.md を使用してください。」
もし .cursor/rules 内で notes.md を管理していて、「なぜ何も反映されないのだろう」と疑問に思っていたなら、それが原因です。拡張子を .mdc に変更してフロントマターを追加するか、コンテンツを AGENTS.md に移動してください。
ルールは読み込まれたが、参照先が読み込まれなかった
ルールは設計上、短く保つことが推奨されています。Cursorのガイドラインでは、ルールを500行未満に抑え、大きなルールは組み合わせ可能な小さなルールに分割し、そして重要なこととして「コンテンツをコピーするのではなく、ファイルを参照すること。これによりルールを短く保ち、コードの変更に伴ってルールが古くなるのを防ぐことができます」とされています。ファイルは @filename.ts のようにして取り込むことができます。
これが二次的なギャップを生み出します。「当社のサービス規約に従う」というルールは、その規約にアクセスできて初めて機能します。ルールはポインタと指示の組み合わせであり、知識そのものではありません。ツールをまたいだこの違いこそが、why agents ignore the instruction files you wrote で解説されている、エージェントが作成した指示ファイルを無視する理由です。
ルールが保存された場所は、必ずしも想定している場所とは限らない
ルールは git にコミットされ、チームで共有されます。しかし、新しいルールは現在作業しているフォルダの .cursor/rules に作成されます。サブフォルダをプロジェクトとして開くと、ルールはそのサブフォルダにスコープが限定されます。これは5秒で確認できることであり、半日の無駄な作業を防ぐことができます。
よく試されるアプローチとその限界
チャットの開始時に毎回プロジェクトの説明をやり直す。 確実に機能しますが、毎回同じコストがかかります。このループについては how to stop re-explaining context to AI で解説しています。
1つの巨大な「常にオン」のルールを書く。 確かにすべてのセッションに適用され、すべてのメッセージでモデルコンテキストの先頭に含まれます。しかし、Cursor自身が避けるべきこととして「スタイルガイド全体をコピーすること」（代わりにlinterを使用すべき）や、「考えられるすべてのコマンドを文書化すること」（Agentはすでに npm、git、pytest などを理解しているため）を挙げています。
1つのチャットを永遠に開き続ける。 境界を越えるのではなく、境界を先延ばしにしているだけです。
すべてを「Apply Intelligently」に設定する。 一見合理的に思えますが、5秒で書いた説明文（description）に判断を委ねることになります。説明が曖昧な場合、ルールは適用されません。
アーキテクチャの決定事項をルールに貼り付ける。 直感としては正しいですが、器が間違っています。ルールは短く保ち、何かを指し示すためのものです。この問題の背景は why Cursor forgets architectural decisions で説明されています。
マシン間でルールを手動で同期する。 よく行われますが、ズレが生じます。マシン間の境界に関する問題は how to stop Cursor forgetting across machines でカバーされています。
解決策：ルールを適切に分類し、設計の背景はルールの外に置く
2つのステップで進めます。最初のステップでCursorに書いた内容を確実に読み込ませ、次のステップで500行の制限には収まらない知識の保管場所を用意します。
既存のルールを監査し、拡張子を修正する。 .cursor/rules を開きます。.md で終わるファイルは無視されているため、フロントマター付きの .mdc に変換するか、AGENTS.md に移動します。
各ルールに、常に正しい最小限のタイプ（型）を割り当てる。 普遍的な制約には alwaysApply: true を設定します。言語やディレクトリ固有の規約には globs を設定します。状況に応じたガイダンスには、Agentが実際に関連性を判断できるように具体的な説明（description）を記述します。めったに必要としない手順は手動（manual）のままにし、必要に応じて @ メンションします。
グローバルなものとローカルなものを分ける。 コミュニケーションスタイルや個人のこだわりは、Customize → Rules の下にある User Rules に記述します。リポジトリの規約はプロジェクトルールまたは AGENTS.md に記述し、git にコミットしてチーム全体で共有できるようにします。
複雑なGlobパターンを駆使する代わりに、ネストされた AGENTS.md を使用する。 ルートファイルに加えて、主要なディレクトリごとに1つ配置することで、フロントマターを一切使わずにスコープを設定できます。より具体的な指示が優先されます。
コードをコピーするのではなく、標準的な例を指し示す。 @file 参照を使用します。Cursorのドキュメントでは、その理由が明確に述べられています。コピーはコードの変更に伴って古くなってしまうからです。
これで読み込みの問題は解決します。しかし、ルールが意図的に除外しているレイヤー、すなわち「なぜそのようなアーキテクチャになっているのか」「すでに試して断念したアプローチは何か」「一見奇妙に見える決定を正当化する制約は何か」といった部分はカバーできません。Cursorのガイドラインでは、Agentが同じ間違いを繰り返していることに気づいたときにルールを追加することを推奨しています。これは優れたアドバイスであると同時に、ルールが捉えるのは結論であり、設計の背景（reasoning）ではないことを認めていることでもあります。
これこそが MemoryLake が保持するものです。ツールが読み取れるレイヤーにプロジェクトの永続的な知識を保管することで、ルールを短く保ちつつ、設計の背景をいつでも利用可能な状態にします。セットアップは3つのステップで行えます。
ステップ 1: APIキーを作成する
MemoryLake にサインインし、APIキーを作成します。接続するすべてのツールで共通の認証情報を1つ使用します。
ステップ 2: 最初の記憶（memory）をアップロードする
ルールファイルには収まりきらない内容について、1項目につき1つの主張として短いエントリーを記述します：
制約を伴う決定事項。 「ORMのEager Loading（即時読み込み）によってページネーションが壊れたため、クエリはリポジトリレイヤーを経由する。」 ルールでは前半部分のみを規定できますが、この背景（理由）を記述しておくことで初めて、同じ提案が繰り返されるのを防ぐことができます。
すでに却下したアプローチ。 最も価値の高いカテゴリであり、リポジトリのどこにも存在しない情報です。新しいセッションが始まるたびに、AIは再びそれを提案してきます。
リポジトリをまたぐ知識。 プロジェクト間で共通して適用されるドメイン用語や標準。プロジェクトルールは設計上リポジトリ単位ですが、この知識はそうではありません。
これまでに複数回行った修正。 Cursor自身が推奨するルール作成の基準であり、その修正の背後にある理由（reasoning）は、ルールのすぐ隣のここに置くべきです。
ステップ 3: AIとエージェントを接続する
お使いのツールを接続します。MemoryLake は MCP（Model Context Protocol）および API 経由でアクセス可能です。そのため、Claude Code、Codex、OpenClaw などの MCP ネイティブなエージェントは MCP サーバーを指定することで接続でき、その他のアシスタントは API を通じて同じ記憶（memory）を読み取ることができます。
ここで、3つの率直な制限事項があります。MemoryLake は Cursor のルールを自動作成するわけではなく、ルールの代替品でもありません。ルールは Agent をコントロールするためのものであり、依然として適切に記述する必要があります。また、MemoryLake はあなたやエージェントが書き込んだ内容のみを保持するため、ステップ2は手動で行う必要があります。さらに、ルールは強制的な設定ではなく、プロンプトレベルのコンテキストです。これは Cursor の設計思想であり、メモリレイヤーを導入してもその性質自体は変わりません。
導入によって実際に変わること
「なぜルールに従わなかったのか？」の確認が2秒で終わるようになります。 拡張子、ルールタイプ、パターンの順に確認するだけです。ほぼ確実にこの3つのいずれかが原因です。
「常にオン」のルールが短くなります。 実体が別の場所に保管されていれば、常にオンにするファイルは、すべてのメッセージに添付される巨大な文書ではなく、真に必要な一握りの制約事項だけに絞り込むことができます。
新しいリポジトリでも、ゼロからのスタートにはなりません。 プロジェクトルールはリポジトリ間を移動しませんが、その外に保管された知識は移動します。
チームのオンボーディングが「口伝の歴史」ではなくなります。 コミットされたルールは規約を示し、メモリレイヤーはその理由を示します。新メンバーにはその両方が必要ですが、通常は片方しか明文化されていません。
他のツールも同じコンテキストを参照できます。 Cursor、Claude Code、Codex のどれが読み取る場合でも、アーキテクチャの背後にある設計思想は同一です。この仕組みについては what persistent memory actually means で解説しています。
永続的に機能するCursorルールのベストプラクティス
.cursor/rules 内では .mdc を使用するか、AGENTS.md を使用する。 ルールディレクトリ内の通常の .md ファイルは無視されるため、絶対に使用しないでください。
ルールごとにタイプを意図的に設定する。 フロントマターを空のままにして期待しないでください。空欄は手動（manual）を意味します。
初対面の人でも判断できるような説明（description）を書く。 「バックエンド向けのRPCサービス規約とパターン」は判断可能ですが、「バックエンド関連」では判断できません。
ルールは500行未満に抑え、肥大化したものは分割する。 これはCursor自身が提示している数値です。組み合わせ可能なルールにしておくことで、スコープが変更された際の設定変更も容易になります。
ファイルをコピーするのではなく、参照する。 コピーは古くなりますが、@file 参照は古くなりません。
ルールはリアクティブ（事後的）に追加する。 ドキュメントには明確に「Agentが同じ間違いを繰り返していることに気づいたときにルールを追加する」と書かれています。自身の開発パターンを把握する前に、過剰に最適化しすぎないようにしましょう。
ルールを git にコミットし、更新し続ける。 GitHub の Issue や PR で @cursor をタグ付けして、Agent にルールを更新させることも可能です。
ディレクトリのスコープ設定には、ネストされた AGENTS.md を優先する。 管理するフロントマターが減り、優先順位も予測しやすくなります。
設計の背景（理由）はルールの外に保存する。 ルールは指示やポインタのためのものです。「なぜ（why）」があるからこそ、エージェントは想定外のケースにも対応できるようになります。そして、それは500行には収まりません。この一般的な課題については why RAG isn't memory で解説しています。
結論
Cursorは、モデルが補完間でメモリを保持しないこと、そしてRules（ルール）がプロンプトレベルで永続的かつ再利用可能なコンテキストを提供する仕組みであることを明言しています。したがって、セッション間でコンテキストを引き継ぐには、ファイルの拡張子、ルールのタイプ、スコープ、そしてルールが保存された場所の4つを正しく設定するだけです。これらを修正すれば、「忘れてしまった」という問題の大部分は解消されます。
残るのは、ルールが意図的に保持しないように設計されている部分です。ルールには上限があり、複製するのではなくファイルを参照するように作られており、議論のプロセスではなく結論を記録するものです。決定事項、制約、そして却下されたアプローチをツールが読み取れるレイヤーに配置し、ルールを短く適切に分類しておきましょう。そうすれば、新しいセッションが始まるたびに、指示とその背後にある理由の両方を備えた状態でスタートできます。