短い答え
Cursorがあなたのアーキテクチャの決定を忘れるのは、プロジェクトルールが理由ではなく行動を説明し、記憶がチャットから派生した短い要約であり、ADRsは取得時にプロンプトに表示されるからです。決定の文脈が欠けていると、モデルは業界標準のアーキテクチャにデフォルトで戻ります。修正は、Cursorがアーキテクチャを提案する前に読み取ることができるクエリ可能な記憶として決定を公開することです。
なぜCursorはあなたのアーキテクチャの決定を忘れるのか
Cursorはあなたのリポジトリをインデックスし、ターンごとに関連するチャンクを取得します。アーキテクチャの決定がそのパイプラインを通過しないのは3つの理由があります。
1. 理由を取得するのは何を取得するよりも難しい。 コードベースのインデックスはコードをうまく表示しますが、文章はあまり信頼性がありません。/docs/adr/0017-single-postgres.mdのADRは、取得が現在のクエリに関連するとスコアが付けられたときにのみプロンプトに入ります。「新しいサービスを追加しています」という文は、決定文書に高いスコアを付けることはほとんどありません。
2. プロジェクトルールはルールを持ち、理由を持たない。 「単一のPostgresを使用する」というルールは強制可能です。「二相コミットが私たちの整合性モデルにとって受け入れられなかったため、単一のPostgresを選んだ」という理由を説明するルールは、.mdcのフロントマターに収まらないため、理由が失われ、モデルは表面のタスクが2つ目のDBを必要とするように見えるときにルールと対立します。
3. 記憶は要約であり、決定記録ではない。 Cursorの記憶はチャットから短いルールを自動生成します。これは決定ログではありません。アーキテクチャの選択を知らせた理由、考慮されたトレードオフ、重要な制約は、構造化された記憶としては残りません。
その結果：Cursorは決定が文脈にあるときにはそれに従い、そうでないときにはそれを上書きします。
Cursorがアーキテクチャの決定を忘れたときに失うもの
忘れられた決定は、再議論や時には再実装を必要とし、そのコストはサービスの寿命にわたって累積します：
- 決着した議論が再開される。 「私たちはJSONBクエリとトランザクションの整合性のためにPostgresを選びました」は見えなくなり、Cursorは3ヶ月後に再びMongoを提案します。
- 制約が無視される。 「コールドスタート予算のためにエッジ関数から内部サービスを呼び出さない」は生成されたエッジハンドラーで無視されます。
- 新しいサービスが標準から逸脱する。 Cursorは新しいサービスのためにウェブ上で最も一般的なパターンを選び、あなたのプラットフォームチームが標準化したものではありません。
修正は「すべてのADRを.mdcルールにすること」ではありません。それは誰も維持しない文章でルールフォルダを溢れさせます。修正は、決定をその理由を保持したままクエリ可能な記憶として公開することです。
Cursorの組み込みワークアラウンド
Cursorはここで実際の機能を出荷しました。どれもギャップを完全に埋めるものではありません。
*プロジェクトルール (`.cursor/rules/.mdc)** は、ADRからルールをエンコードでき、フロントマターとグロブを使用していつ発動するかを制御します。これは強制可能な結論には良いですが、理由には弱いです。なぜなら、alwaysApply`ルールはプロンプトの予算を共有し、長いルールの文章は削減されるからです。
記憶 はチャットから短い自動生成されたガイダンスをキャプチャします。「私たちはランタイム検証のためにZodを使用します」には良いですが、「私たちは2024年に静的型推論のためにZodをYupより選び、この決定を四半期ごとに見直します」には悪いです。
ネイティブMCPサポート はCursorが.cursor/mcp.jsonまたは設定UIを通じて外部記憶に接続できるようにします。これはアーキテクチャの決定にとって最もクリーンな方法です。なぜなら、MCPはルールに圧縮するのではなく、必要に応じて完全なADRとその理由を公開できるからです。
CursorのMCPセットアップガイドは公式Cursorドキュメントで読むことができます。
小さなリポジトリでは、ルールとインデックスがそれを処理します。実際のアーキテクチャを持つシステムでは、決定が滑り落ちます。
Cursorの組み込み記憶が不足している点
より深い問題は、アーキテクチャの決定がルールではなく推論の産物であることです。これらは、Cursorが何かを提案する瞬間に、理由、代替案、日付を含めて完全に取得可能である必要があります。それは、チームが使用するすべてのAIエディタに適用される必要があります。なぜなら、Claude Codeのチームメンバーが、あなたがスプリントをかけて取り除いたパターンを再導入する可能性があるからです。
それがクロスツールの記憶レイヤーが修正するものです：1つの決定記録、要求に応じて取得可能で、チームのすべてのAIエディタで共有されます。
MemoryLakeがCursorのアーキテクチャの決定を忘れる問題を解決する方法
MemoryLakeは、あなたと使用するすべてのAIの間に位置するクロスモデルの記憶レイヤーです。/docsのADRsが重要なときに取得されると信頼するのではなく、MemoryLakeプロジェクトに決定を保存し、CursorはMCPを通じてターンごとに関連するものを引き出します。
- クエリ可能な記憶としての決定。 各ADRは、ルール、理由、代替案、日付を持つ構造化された記憶として存在します。Cursorは圧縮された行ではなく、完全な記録を取得します。
- 決定に対するGitスタイルのバージョン管理。 ADRが上書きされると、MemoryLakeのバージョン管理が上書きを追跡するため、古い決定が静かに再浮上することはありません。
- 他のすべてのAIコーディングツールに移植可能。 同じ決定記憶はClaude Code、Cline、Windsurf、MCP対応のエディタで機能します。異なるツールのチームメンバーが誤って非推奨のパターンを再導入することはありません。
MemoryLakeはLoCoMoの長文コンテキストベンチマークで94.03%を記録し、2026年時点での最高の公開結果であり、ミリ秒単位の取得とAES-256のエンドツーエンド暗号化を実現しています。
MemoryLakeをCursorに接続する3つのステップ
- プロジェクトを作成し、決定を読み込む。 MemoryLakeにサインインし、プロジェクト管理を開き、プロジェクトを作成し、システムの名前を付けます（例：「Cursor - payments-platform architecture」）。ADRと設計文書をドキュメントドライブにドロップします。見出しの結論と理由を記憶タブの構造化されたエントリとしてキャプチャし、各決定がトピックごとに取得可能で、理由が保持されるようにします。
- MCPサーバーエンドポイントを生成する。 プロジェクト内のMCPサーバータブを開き、「MCPサーバーを追加」をクリックし、「Cursor統合」と名付けて「生成」をクリックします。MemoryLakeはAPIキーID、シークレット、エンドポイントURLを返します。シークレットは一度だけ表示されるため、すぐにコピーしてください。
- Cursorを接続する。 Cursorは2025年からネイティブMCPサポートを提供しており、これが最もクリーンな方法です。リポジトリのルートにある
.cursor/mcp.jsonにMemoryLakeサーバーエントリを追加します（またはCursor設定 > 機能 > MCPを通じて接続します）、エンドポイントURLとBearerトークンを貼り付け、Cursorを再読み込みします。Cursorは、アーキテクチャを提案する前や新しいサービスを配線する前に決定記録をクエリできるようになります。