Cascadeが記憶を失った理由
まず、ドキュメントの場所と製品名が変更されました
何よりも先に実用的な注意点として、古いガイドが分かりにくくなっている原因を説明します。現在、docs.windsurf.comはdocs.devin.aiにリダイレクトされ、エディタはDevin Desktopとしてドキュメント化されています。CascadeのMemoriesのページはdocs.devin.ai/desktop/cascade/memoriesにあります。
これはファイルパスにも反映されています。ワークスペースルールの推奨保存先は.devin/rules/になり、.windsurf/rules/はフォールバックとして残されています。ドキュメントには、.devin/が「推奨される場所であり、優先されます」と記載されています。.windsurf/のみに言及している説明を読んでいる場合、それらは依然として機能しますが、フォールバックの動作について説明していることになります。
Memoriesはレガシーエージェントに紐づいている
主な原因に話を戻しましょう。Devin Desktopには、会話間でコンテキストを保持するための2つの仕組みがドキュメントに記載されています。「Cascadeによって自動的に生成されるMemories」と、「ユーザーがグローバル、ワークスペース、またはシステムレベルで手動で定義するRules（ルール）」です。
MemoriesはレガシーなCascadeエージェントにスコープが限定されています。新しいタブはデフォルトでDevin Localエージェントになりますが、ドキュメントによると、このエージェントは「Memoriesを保持しません」。そのため、「昨日は動いていたのに、今日は真っ白」という現象は、メモリが失われたのではなく、そもそもメモリを持っていない別のエージェントが起動していることが原因であることが多いのです。
ドキュメントで推奨されている解決策は移行ウィザードです。Devin: Open Cascade Migration Wizardコマンドを実行すると、依存しているMemoriesをSkillsに移行できます。
自動生成されるMemoriesは常にローカルかつワークスペース限定だった
レガシーエージェントであっても、Memoriesの適用範囲は多くの人が思っているよりも狭いです。Cascadeは「記憶する価値があると判断したコンテキストに遭遇した場合、自動的にMemoriesを生成して保存する」ことができ、ユーザーはいつでも「〜のメモリを作成して」とプロンプトで指示することができます。
しかし、これらは「作成されたワークスペースに関連付けられ、ローカルの~/.codeium/windsurf/memories/に保存されます」。さらに明示的に、「あるワークスペースで生成されたMemoriesは別のワークスペースでは利用できず、リポジトリにコミットされることもありません」とされています。ドキュメントの注記には、「自動生成されたMemoriesはあなたのマシン上にのみ存在します」とはっきりと書かれています。
そのため、新しいノートPC、2つ目のクローンリポジトリ、あるいはチームメンバーのマシンには、それらの記憶は一切存在しません。唯一の小さな救いは、「自動生成されたMemoriesの作成と使用はクレジットを消費しない」点です。
開発元自身も、これらに依存しないことを推奨している
これは外部の意見ではなく、開発元自身の推奨事項であるため、真剣に受け止める価値があります。「Cascadeに確実に再利用させたい知識については、自動生成されるMemoriesに頼るのではなく、Ruleとして記述するか、リポジトリのAGENTS.mdに追加してください。Rulesはバージョン管理が可能で、チームと共有でき、有効化のタイミングを明示的に制御できます。」
機能比較表でも、1行で同じことが述べられています。MemoriesはCascadeに「単発の事実を記憶させる」ためのものであり、「永続的な知識には、RulesまたはAGENTS.mdを推奨する」となっています。Skills（スキル）にいたっては、さらに率直に「ここに投資すべき」と注記されています。
Rulesは引き継がれるが、設定したモードに依存する
Rulesはセッションの境界を越えて存続します。特定のメッセージでそれらがCascadeに届くかどうかは、フロントマターのtriggerフィールドの設定に完全に依存します。
| モード | trigger: | Cascadeへの到達方法 | コンテキストコスト |
|---|---|---|---|
| Always On (常時オン) | always_on | すべてのメッセージで、システムプロンプトにルールの全内容が含まれる | すべてのメッセージ |
| Model Decision (モデルの判断) | model_decision | システムプロンプトには説明（description）のみが含まれ、Cascadeがその説明を関連性があると判断したときにファイル全体を読み込む | 説明は常に、コンテンツは必要に応じて |
| Glob (グロブ) | glob | Cascadeがglobsにマッチするファイルを読み込みまたは編集するときに適用される | マッチするファイルが操作されたときのみ |
| Manual (手動) | manual | システムプロンプトには含まれない。有効化するには@rule-nameと入力する | @メンションされたときのみ |
manualに設定されたルールは、呼び出すまで認識されません。曖昧な説明が書かれたmodel_decisionのルールは、一度も読み込まれない可能性があります。どちらも壊れているわけではなく、それが仕様通りの挙動です。これは、エージェントが作成した指示ファイルを無視する理由で説明されている問題と同じカテゴリに属します。
覚えておく価値のある2つの例外：「グローバルルールファイル（global_rules.md）とルートレベルのAGENTS.mdファイルはフロントマターを使用せず、常にオン（always on）になります。」
文字数制限と、新しいルールが実際に保存される場所
ドキュメントに記載されている制限：~/.codeium/windsurf/memories/global_rules.mdにあるグローバルルールファイルは「6,000文字制限」、.devin/rules/*.mdにあるワークスペースルールは「1ファイルあたり12,000文字制限」です。ワークスペースのルートにあるレガシーな単一ファイル.windsurfrulesも引き続き読み込まれます。
そして、スコープに関する罠があります。ルールの検出はワークスペース、そのサブディレクトリ、そしてgitルートまで探索しますが、「新しいルールを作成すると、必ずしもgitルートではなく、現在のワークスペースの.devin/rulesディレクトリに保存されます」。サブフォルダをワークスペースとして開くと、新しいルールはそのサブフォルダにスコープが限定されてしまいます。
よく試される対策（とその限界）
毎朝プロジェクトについて再説明する。 永久に機能しますが、毎回同じコスト（手間と時間）がかかります。これはAIへのコンテキストの再説明をやめる方法で説明されているループです。
重要なことすべてについて、Cascadeに「メモリを作成して」と頼む。 レガシーエージェントにおいては何もしないよりはマシですが、作成されるものはローカルかつワークスペース限定で、コミットもされず、新しいタブのデフォルトエージェントからは利用できません。
すべてをglobal_rules.mdに詰め込む。 常にオンになりますが、すべてのワークスペースのすべてのメッセージで6,000文字が送信されることになります。これは単なる入れ物ではなく、実際のコンテキスト予算を消費します。
すべてのルールをAlways Onに設定する。 信頼性は解決しますが、関係のないタスクであっても、メッセージごとに最大のコンテキストコストを支払うことになります。
マシン間で~/.codeiumをコピーする。 サポート外の領域であり、同じ知識を必要とするチームメンバーの役には立ちません。これはWindsurfがプロジェクトルールを忘れる理由で説明されている一般的なケースです。
名称変更が何かを壊したと思い込む。 通常、そんなことはありません。.windsurf/rulesはフォールバックとして機能し続け、.windsurfrulesも引き続き読み込まれます。デグレード（先祖返り）だと結論付ける前に、タブのエージェントを確認してください。
解決策：自動生成Memoriesから脱却し、Rules、AGENTS.md、Skillsへ移行する
開発元の推奨事項と、実践的な解決策は同じです。これを一度行えば、タブレベルのエージェントの違いを気にする必要はなくなります。
移行ウィザードを実行する。 自動生成されたMemoriesに依存していた場合は、ドキュメントの指示通り、Devin: Open Cascade Migration Wizardを使用してSkillsに移行します。これは多くの人が見落とし、結果として1週間混乱することになるステップです。
永続的な知識はAGENTS.mdに記述する。 ルートレベルのファイルはフロントマターなしで常にオンになり、サブディレクトリのファイルはそのディレクトリに対して自動的にグロブ（適用）されます。最もメンテナンスの手間がかからないオプションであり、バージョン管理されるため、共有も容易です。
ルールを意図的に分類する。 普遍的な制約はalways_on。言語やパス固有の規約はglob。状況に応じたガイダンスは、ルーティングに十分なほど具体的な説明を添えたmodel_decision。めったに必要としない手順はmanualにし、使用時には@メンションする必要があることを覚えておきます。
global_rules.mdは本当にグローバルな制約のみに限定する。 すべてのワークスペース、すべてのメッセージで6,000文字が消費されます。高コストなものとして扱ってください。
複数ステップの手順にはSkills（スキル）を活用する。 ドキュメントでは、Cascadeが参照ファイルを必要とするような複雑なタスク向けにSkillsを挙げており、移行されたMemoriesのドキュメント上の保存先でもあります。
読みやすさを意識してフォーマットする。 Cascadeのベストプラクティス：ルールはシンプル、簡潔、かつ具体的に保つ。「良いコードを書く」といった一般的なルールは、すでに学習データに含まれているため省略する。長い段落ではなく、箇条書き、番号付きリスト、マークダウンを使用する。関連するルールはXMLタグでグループ化する。
これで、ツール内部で引き継がれるものは解決します。しかし、これらのコンテナ（RulesやAGENTS.md）のいずれにも保存されないのが、規約の背後にある理由（推論）です。なぜそのアプローチを却下したのか、どの制約によってその一見奇妙な決定が正しくなるのか、といった情報です。なぜなら、Rulesには文字数制限があり、AGENTS.mdは規約を記すファイルであって、議論を記録する場所ではないからです。
それこそがMemoryLakeの役割です。プロジェクトの永続的な知識をツールが読み取るレイヤーに配置することで、特定のマシンや特定のエージェントモードに依存しなくなります。セットアップは3つのステップで完了します。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ 2: 最初のメモリをアップロードする
ルールファイルには適さない内容に焦点を当て、1項目につき1つの主張を短いエントリとして登録します。
決定事項と、それを生み出した制約。 ルールに「キューアダプターを使用する」と書くことはできますが、来週また別の代替案が提案されるのを防ぐには、その「理由」が必要です。
すでに除外されたアプローチ。 リポジトリのどこにも記録されていないため、新しい会話が始まるたびに、AIはそれらのアプローチを提案してしまいます。
ワークスペースをまたぐ知識。 Memoriesは設計上ワークスペースに限定され、Rulesはリポジトリごとに設定されます。しかし、ドメインの用語集や標準規格はそのどちらにも収まりません。
これまでに繰り返した修正。 2回以上指摘したことは、知識として登録すべき項目です。その理由も一緒に記録しておきましょう。
ステップ 3: AIとエージェントを接続する
お使いのツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能です。そのため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定することで接続でき、その他のアシスタントはAPIを介して同じメモリを読み取ることができます。
ここで、3つの率直な制限事項があります。MemoryLakeは、RulesやAGENTS.mdを代替するものではありません。 これらはCascadeを制御するためのものであり、適切にセットアップする必要があります。また、自動生成されたMemoriesを移行することはできません（それは移行ウィザードの役割です）。MemoryLakeは、あなたやエージェントが書き込んだ内容のみを保持します。そして、何かを強制するものではありません。ルールはあくまでコンテキストであり、コンプライアンス（遵守）を保証するものではありません。
実務における変化
どのエージェントがタブを開いたかによって、記憶が保持されるかどうかが左右されなくなります。 AGENTS.mdやメモリレイヤーにある知識は、レガシーエージェントに限定されたMemories機能に依存しません。
2台目のマシンは、単なる2台目のマシンになります。 自動生成されたMemoriesは作成されたマシンにのみ存在しますが、コミットされたRulesや外部のメモリレイヤーはマシンに縛られません。
チームメンバーもあなたと同じコンテキストを共有できます。 Memoriesはリポジトリにコミットされませんが、RulesやAGENTS.mdはコミットされ、共有知識はそれらの外部に存在します。
常時オン（Always-on）の予算に余裕が戻ります。 アーキテクチャのメモなどを詰め込まなければ、本当に必要な制約を記述するのにグローバルルールの6,000文字は十分な容量です。
名称変更に振り回されなくなります。 WindsurfからDevin Desktopへ、.windsurf/から.devin/へ。エディタの外部にある知識レイヤーは、これらすべての変更に影響されません。この仕組みについては、永続メモリが実際に意味することで解説しています。
Cascade의コンテキストを保持するためのベストプラクティス
まず、タブがどのエージェントを使用しているか確認する。 MemoriesはレガシーなCascadeエージェントにのみ適用されます。これは最も効果的な診断方法です。
永続的な知識にはAGENTS.mdを優先する。 設定不要で、ルートでは常にオンになり、サブディレクトリでは自動的に適用（glob）され、バージョン管理も可能です。
新しいルールには.devin/rules/を使用する。 これが推奨される場所であり、優先されます。.windsurf/はフォールバックとして残されます。
triggerを意図的に設定する。 manualルールはシステムプロンプトに一切含まれません。意図しない場合は、そのまま放置しないでください。
ルーティング可能な説明（description）を書く。 model_decisionは、そのルールがいつ重要になるかをCascadeに伝える説明があって初めて機能します。
制限文字数を遵守する。 グローバルは6,000文字、ワークスペースルールファイルは1ファイルあたり12,000文字です。圧縮するのではなく、ファイルを分割してください。
ルールが保存された場所を確認する。 新しいルールは、必ずしもgitルートではなく、現在のワークスペースの.devin/rulesに保存されます。
ルールの「理由」はルールの外に置く。 規約はリポジトリに属しますが、その背後にある議論は、検索可能な別の場所に置くべきです。これはなぜRAGはメモリではないのかで説明されている一般的な問題です。
まとめ
まずはエージェントの確認から始めましょう。Devin DesktopのMemoriesはレガシーなCascadeエージェントにのみ適用され、新しいタブのデフォルトエージェントはこれらを保持しません。ドキュメントに記載されている解決策は、依存しているメモリをCascade Migration Wizardを使用してSkillsに移行することです。これだけで、突然のコンテキスト消失のほとんどを説明できます。
次に、開発元のアドバイスに従いましょう。永続的な知識は、1台のマシン、1つのワークスペースに留まり、コミットもされない自動生成されたMemoriesではなく、RulesやAGENTS.mdに記述すべきです。必要なときに読み込まれるようにルールを設定し、グローバルファイルは6,000文字以内に収め、意思決定、制約、却下されたアプローチなどの「理由」は、どのエージェントがタブを開いたか、あるいは今期エディタが何と呼ばれているかを気にしなくてよいレイヤーに配置しましょう。