なぜRoo Codeはプロジェクトのコンテキストを忘れるのか
現在のRoo Codeにおけるコンテキストの扱い方
セッション内では、Roo Codeは指示、読み込んだファイル、実行した計画など、すべてを保持します。これらはセッションのコンテキストウィンドウ内に存在します。しかし、セッションが終了するか、ウィンドウがいっぱいになって古いコンテンツがトリミングされると、作業コンテキストは失われます。次のセッションでは、リポジトリを再読み込みし、コードのみから「どこまで進んだか」を再構築します。しかし、コードだけでは「なぜそのコードがそのようになっているのか」という経緯までは分かりません。
コンテキストが定着しない技術的な理由
Roo Codeの永続的なメモリはファイルです。起動時に読み込まれるカスタム指示や .roo 形式のルールファイルがこれに該当します。これらは静的かつ手動で記述されるため、固定された規約には適していますが、動的な情報には一切対応できません。あなたが下した決定、却下したアプローチ、解決に3回かかったバグなど、それら自体が自動的に永続的な知識になることはありません。最近のセッションを再開することは1つのスレッドには役立ちますが、数週間分のプロジェクト履歴を検索可能にするわけではありません。
これによる損失
毎日プロジェクトの説明をやり直すことになります。Roo Codeは、先週あなたが明確に却下したアプローチを再び提案してきます。なぜなら、その却下の決定はすでに消えてしまったセッションの中にあったからです。また、修正方法が永続的な場所に書き残されていないため、繰り返し発生する問題がその都度ゼロから解決されることになります。これは、Roo Codeやより広範なコーディングエージェントのコミュニティで開発者が口にする「セッション間で何もかも忘れてしまい、常にプロジェクトのコンテキストを再説明しなければならない」という不満そのものです。
Roo Codeの組み込みの回避策（とその限界）
カスタム指示とルールファイル
技術スタック、スタイル、構造ルールなど、固定された規約を置くには最適な場所であり、各セッションの開始時に読み込まれます。限界は、これらが手動かつ静的である点です。誰かが教訓を整理して書き込む必要があり、動的な履歴が自動的に反映されることはありません。
モード
Roo Codeのモードは、特定のタスクに対するエージェントの振る舞いを決定し、セッションの焦点を維持するのに役立ちます。しかし、モードは振る舞いのプロファイルであり、メモリ（記憶）ではありません。過去のセッションで何が起こったかを保持することはありません。
セッションの再開
最近のタスクを再開すると、その1つの会話履歴が復元され、昨日の作業の続きを行うのに便利です。しかし、これはスケールしません。数ヶ月にわたる作業全体を検索することはできませんし、長い会話履歴はコンテキストの上限に達してトリミングされてしまいます。
共通の壁：上記のすべては、リポジトリごと、マシンごと、そして手動で管理されています。あなたのコンテキストは、2台目のマシンやチームメイト、あるいはスタック内の他のエージェントに引き継がれることはありません。これは、Cursorなどのコーディングエージェントが以前のセッションを忘れてしまう理由の背景にある根本的な課題と同じです。
解決策：Roo Codeに永続的なプロジェクトメモリを与える
永続的なセットアップとは、セッションの外部にメモリレイヤーを設け、決定事項、制約、解決済みの問題、およびその背景にあるドキュメントなど、重要な情報を蓄積することです。MemoryLakeはこれらを一度保存すれば、検索可能で、Gitスタイルのバージョン管理により決定がいつ変更されたかを追跡でき、エンドツーエンドで暗号化されるため、コードやプロジェクトの詳細はあなたのものとして安全に保護されます。
ステップ1：APIキーの作成
MemoryLakeにサインインし、キーを生成して、最初のリクエストを送信します。約30秒で完了します。
ステップ2：最初のメモリのアップロード
セッションが失い続けるプロジェクトの知識（アーキテクチャのメモ、決定記録、APIドキュメント、仕様書など）を投入します。ドキュメント、画像、その他のファイルすべてに対応しています。今後は、セッションで保存する価値のある決定が下されたら、それを1行のメモリとして記録します。
ステップ3：AIとエージェントの接続
Roo CodeはMCPをサポートしています。APIキーを使用してMemoryLakeをMCP設定に追加すると、エージェントはタスクの途中で過去の決定やプロジェクトの知識をクエリできるようになります。同じメモリは、MCPまたはAPIを介してClaude、Codex、OpenClaw、その他のエージェントからも利用可能です。すべてのツールとすべてのマシンで、1つのプロジェクトメモリを共有できます。
プロジェクトコンテキストの喪失がもたらす実際のコスト
再説明のコスト（税金）
1セッションあたり10分の再説明を1日に数回行うと、実際の作業を開始する前に週に数時間が失われることになります。さらに、Roo Codeがリポジトリを再読み込みし、すでに下された決定を再導出するために消費する計算リソースも加わります。従量課金制のエージェントでは、この「再発見」のプロセス自体がコスト項目になります。
再導出ではなく検索による解決
永続レイヤーがあれば、Roo Codeはコードや推測から再構築する代わりに、必要なときに関連する決定や仕様をオンデマンドで取得します。迅速なスタート、繰り返されるミスの削減、支出の抑制が実現します。MemoryLakeのトークン削減計算ツール（Token Saving Calculator）を使用すると、あなたの利用状況からその効果を予測できます。
Roo Codeメモリのベストプラクティス
決定が下された瞬間に記録する
「Zという理由でXを選択し、Yを却下した」という情報を保存する最適なタイミングは、それが決定された直後です。日付入りの1行の記録は、決して行われない振り返りよりも価値があります。そしてこれこそが、Roo Codeが却下されたアプローチを再提案するのを防ぐ確実な方法です。
規約と履歴を分離する
固定されたルールはRoo Codeのルールファイルに保持し、動的な履歴（決定事項、解決済みのバグ）はメモリレイヤーに保持します。これらは更新の頻度が異なるため、混在させると両方のメンテナンスが困難になります。
リポジトリごとにスコープを分ける
リポジトリごとに1つのメモリスコープを設定することで、検索の精度が維持され、各プロジェクトのRoo Codeセッションが、そのプロジェクトに適用される情報のみを取得できるようになります。
結論
Roo Codeは強力なエージェントですが、セッションの記憶力は金魚のように短期的です。説明を受ければ優秀ですが、再起動するたびに白紙に戻り、そのルールファイルは生きたプロジェクトの履歴を保持するようには設計されていません。その履歴を永続的なメモリに保存すれば、すべてのセッションがそれまでのすべてのコンテキストを蓄積した状態で開始されます。毎日の再説明も、決定済みの事項を再び議論する必要もなくなります。プロジェクトの再説明はやめて、メモリをワークフローの一部に組み込みましょう。