なぜCursorは私のプロジェクトルールを忘れるのか？

Cursorがあなたのプロジェクトルールを忘れる理由は、ルールが静的テキストとしてプロンプトに追加され、有限の予算のためにコードコンテキストと競合するからです。グロブスコープのルールはファイルパスが一致したときのみ発火し、alwaysApplyルールは取得されたコードでプロンプトが満たされるにつれて重みを失います。従来の.cursorrules形式は、.cursor/rules/*.mdcに置き換えられつつあります。修正方法は、ルールをプロンプトに詰め込まれたテキストではなく、クエリ可能なコンテキストにすることです。

Cursorのルールシステム、特に新しい.cursor/rules/*.mdc形式のYAMLフロントマター（説明、グロブ、alwaysApply）は、スケーラブルなプロジェクトごとのガイダンスを実現するための本当の試みです。しかし、メカニズムにはまだ漏れがあります。

1. ルールはコードとプロンプト予算を共有します。 発火するすべてのルールはプロンプトに追加されます。Cursorがコンテキストとして取り込むファイルが多いほど、ルールの効果的なスペースは減少します。重要なガイダンスはプロンプトの早い段階に配置され、モデルは最近のコードに対してそれに対する重みを減らします。

2. グロブスコーピングは静かです。 globs: src/components/**/*.tsxを持つルールは、同じフォルダー内の.stories.tsxファイルを編集しても発火しません。ルールは技術的にはリポジトリに存在しますが、このプロンプトからは欠如しており、Cursorは警告しません。

3. 長いセッションはコンテキストを排除します。 セッションが多くのファイルを読み込むと、モデルの効果的な作業コンテキストが減少し、以前の指示、ルールを含めて、最近のコードに対して重みを失います。大きなリファクタリングにおけるスタイルとルールの漂流は、Cursorユーザーフィードバックでよく文書化されたパターンです。

4. 従来の形式は廃止されつつあります。 プロジェクトルートの.cursorrulesはまだサポートされていますが、.cursor/rules/*.mdcに置き換えられる予定です。移行していないプロジェクトは、一貫して読み込まれないルールを持つことになります。

結果として、ちょっとしたタスクでは機能する思慮深いルール設定が、大きなタスクでは失敗します。

すべてのルールミスはレビュー時間を浪費し、そのコストは実際のコードベース全体にわたって累積します：

• アーキテクチャのガードレールが崩れます。 「Reactコンポーネントからの直接DB呼び出しはしない」というルールは、リファクタリングの3ファイル目で破られ、レビュー時にしか気づきません。
• セキュリティルールが緩みます。 「リクエストボディをログに記録しない」というルールは、新しいロガーユーティリティで破られますが、グロブが一致しなかったためです。
• 慣習の強制が弱まります。 「生のfetchではなく、共有のuseQueryラッパーを使用する」というルールは、ルールファイルが長いプロンプトの後半で重みを失ったために無視されます。

修正方法は「すべてのルールをalwaysApplyにする」ことではありません。それはすべてのプロンプトにさらにテキストを押し込むだけで、排除問題を加速させます。修正方法は、ルールを静的に追加するのではなく、手元の変更にスコープを持たせて、必要に応じて取得可能にすることです。

Cursorはここに実際の機構を出荷しましたが、どれもギャップを完全に埋めるものではありません。

*プロジェクトルール（`.cursor/rules/.mdc）**は、description、globs、alwaysApplyを持つフロントマターをサポートしており、ファイルパスによってルールをスコープし、各ルールが毎回発火するか、一致したときのみ発火するかを決定できます。これは現代的で推奨される形式であり、従来の.cursorrules`ファイルに対する明確な改善です。

記憶はチャット履歴から短いルールを自動生成し、プロジェクトにスコープします。これらはベースラインとして便利ですが、推測された好みの要約であり、権威ある契約ではありません。

ネイティブMCPサポートにより、Cursorは.cursor/mcp.jsonまたは設定UIを通じて外部サーバーからコンテキストを取得できます。これは最もクリーンな逃げ道であり、MCPはプロンプト予算を事前に消費するのではなく、必要に応じてコンテキストを返します。

Cursorのルールに関する独自のドキュメントは、公式Cursorドキュメントで読むことができます。

軽い使用の場合、ルールと記憶がそれを処理します。密度が高く、ルールが多いコードベースの場合、ネイティブが漂流します。

より深い問題は、実際のコードベースにおけるルールが層状になっていることです：アーキテクチャルール、フレームワークルール、セキュリティルール、チームの慣習、そして先週のコードレビューでの決定です。すべてを静的な.mdcファイルに詰め込み、プロンプト予算が保持されることを期待するのは脆弱です。また、多くのチームが現在Cursor、Claude Code、Cline、Copilotのバリアントを並行して実行しているため、ルールをCursor内にロックすることになります。

これがクロスツール記憶層が修正するものです：1つのルールストア、必要に応じて取得され、変更にスコープされ、チームのすべてのAIエディタで共有されます。

MemoryLakeは、あなたと使用するすべてのAIの間に位置するクロスモデル記憶層です。ルールファイルだけに依存するのではなく、MemoryLakeプロジェクトにルールを保存し、CursorはMCPを通じて編集ごとに適切なスライスを取得します。

• 必要に応じて取得され、プロンプトに詰め込まれない。 CursorはターンごとにMemoryLake MCPエンドポイントを呼び出し、編集中のファイルに関連するルールのみを取得するため、ルールはコードとプロンプト予算を競合しなくなります。
• バージョン管理され、監査可能。 MemoryLakeのGitスタイルのバージョン管理は、すべてのルール変更、誰が行ったか、なぜ行ったかを追跡します。これは、ルールが動作を破ったときに、チームがロールバックする必要がある場合に重要です。
• 他のすべてのAIコーディングツールにポータブル。 同じルールセットはClaude Code、Cline、Windsurf、そしてMCP対応の任意のエディタで機能します。チームメイトがツールを切り替えると、ルールも一緒に移動します。

MemoryLakeはLoCoMoの長文コンテキストベンチマークで94.03%を記録し、2026年時点での最高の公開結果であり、ミリ秒単位の取得とAES-256のエンドツーエンド暗号化を提供します。

1. プロジェクトを作成し、ルールを読み込む。 MemoryLakeにサインインし、プロジェクト管理を開き、プロジェクトを作成をクリックし、リポジトリにちなんで名前を付けます（例：「Cursor - payments-serviceルール」）。.cursor/rules/*.mdcファイルをドキュメントドライブにインポートし、最も価値の高いルールを記憶タブに構造化されたエントリとして記述し、トピックごとに取得可能にします。
2. MCPサーバーエンドポイントを生成する。 プロジェクト内のMCPサーバータブを開き、「MCPサーバーを追加」をクリックし、「Cursor統合」と名付けて「生成」をクリックします。MemoryLakeはAPIキーID、シークレット、およびエンドポイントURLを返します。シークレットは一度だけ表示されるため、すぐにコピーしてください。
3. Cursorを接続する。 Cursorは2025年からネイティブMCPサポートを提供しており、これが最もクリーンな方法です。リポジトリのルートにある.cursor/mcp.jsonにMemoryLakeサーバーエントリを追加し（またはCursor設定 > 機能 > MCPを通じて接続し）、エンドポイントURLとBearerトークンを貼り付けてCursorを再読み込みします。あなたの.mdcルールはベースラインとしてそのままにしておき、MemoryLakeが必要に応じてより深く取得可能なルールストアを提供します。