なぜReplitはプロジェクトを最初からやり直してしまうのか
オンにするまでMemoryはオフになっている
Settingsを開き、Customizationを選択してからMemoryタブを選択します。ドキュメントによると、そこは「Memoryをオプトインし、後でオフにし、共同作業者と共有するかどうかを選択し、Memoryファイルを表示または更新する」場所です。2つのデフォルト設定が明記されています。「Memoryはデフォルトでプライベートであり、共同作業者との共有はデフォルトでオフになっています。」
したがって、新しいWorkspaceは設計上、何も記憶していません。他の原因を疑う前に、まずこれを確認する価値があります。
3つのメモリ・スコープがあり、重複しない
Memoryをオンにした後、何が保持されるかは、コンテンツがどのスコープに入るかによって異なります。ドキュメントでは以下のように区別されています。
User memoryは「永続的なワークスペースの好みや作業スタイル」をキャプチャし、「1人のビルダーとワークスペースに属します」。
Project memoryは「規約、注意点、修正方法」をキャプチャします。「1つのプロジェクト（Project）に留まり、関連性がある場合に取得されます」。
Custom memoryは「独自のアクセスおよび表示設定で定義するコンテキスト」であり、「定義されたアクセスおよび表示設定に従います」。
これをルーティングテーブルとして捉えると、多くのことが明確になります。あるプロジェクトで確立した規約は、次のプロジェクトには引き継がれません。Project memoryはそのプロジェクトに留まるからです。作業スタイルの好みは、1人のビルダーとWorkspaceに紐づいています。どちらかがユニバーサル（共通）であると期待していた場合、発生しているギャップはシステムの不具合ではなく、ドキュメントに記載されている仕様通りの境界線です。
Memoryが保持するのはコンテキストであり、指示ではない
この機能全体の前提を覆すのが、次の1文です。「Memoryは有用なコンテキストを保持するものであり、実行可能な指示（instructions）ではありません。」
また、優先順位も明記されています。「明示的なリクエストとCustom Instructionsは、Memoryよりも優先されます。」
つまり、MemoryはReplitが参照する「証拠」であり、従うべき「ルール」ではありません。もしMemoryに「常にリポジトリパターンを使用する」「許可なく新しい依存関係をインストールしない」といった指示を書き込んでいたなら、ルール用ではないレイヤーにルールを置いてしまっています。ドキュメントでは、Memoryを「実行可能な指示ではなく、文脈上の証拠」と呼んでいます。これらはCustom Instructionsに記述すべきものです。Custom Instructionsは「ReplitがそのWorkspaceのプロジェクトやセッションをまたいで使用する」ものであり、特に「ユーザーが記述し、Replitはそれを変更しない」という特徴があります。
共有プロジェクトは、再度オプトインしない限り除外される
チームが陥りがちなデフォルト設定：「デフォルトでは、Replitは他の共同作業者が編集できるプロジェクト（Projects）であなたのMemoryを使用しません。」
これはプライバシー保護の観点から賢明な設計です（蓄積されたコンテキストが他人の作業スペースに漏洩するのを防ぐため）。しかし、これは「共有コンテキストを最も必要とするプロジェクトが、それを全く受け取れていない」という状況を意味します。ドキュメントに記載されている切り替えスイッチは同じ場所にあります。「他の共同作業者が編集できるプロジェクトでReplitにMemoryを使用させたい場合は、Settings → Customization → Memoryでオンにしてください。」
個人プロジェクトは問題ないのに、チームプロジェクトが記憶喪失のように感じられる場合、ほぼ間違いなくこれが原因です。
Memoryは一部のカテゴリを意図的に除外する
実現しないことを期待して待つことがないよう、これも知っておく価値があります。ドキュメントによると、「Memoryは個人情報を保持しません」。具体的には「機密性の高い特性、第三者の個人データ、認証情報、またはプロジェクトの機密事項」は保持されません。Replitは、Memoryがワークスペースのアクティビティから派生するため、安全に処理していると説明しています。
これは正しい判断であり、これらのカテゴリに該当するものは、自身で管理できる場所に保管する必要があることを意味します。
Custom InstructionsとSkillsは、それぞれ異なる役割を持つ別個のレイヤーである
Replitは決定テーブルを公開しており、これがモデルの最も明確な説明となっています。
| 管理・維持する主体 | Replitが使用するタイミング | 最適な用途 | |
|---|---|---|---|
| Custom Instructions | あなたまたはチーム | 常に、セッションをまたいで | 一貫して適用したい安定した好みやルール |
| Skills | あなたまたはチーム | 特定のタスクに関連する場合 | 繰り返し実行可能な手順、ワークフロー、およびサポート資料 |
| Memories | Replit（あなたの監視のもとで） | 関連するコンテキストが有用な場合 | 過去の作業から得られた有用な好みの繰り返しを避ける |
それに続くガイダンスは、文字通りに受け取る価値があります。Custom Instructionsは「承認されたライブラリやデータ処理要件など、Workspace全体で常に真であるべきルール」のためのものであり、Workspace Settings → Customizationで管理し、「常に真である最小限のガイドライン」に留め、「目の前の作業の邪魔にならない」程度に短く保ちます。Skillsは「特定の種類の作業に対する再利用可能なアプローチ」のためのものです。なぜなら「安定した手順に関する知識はSkillsに属する」からです。そして、MCPは「ガイダンスやコンテキストを提供するのではなく」外部ツールを接続するためのものです。
3つのレイヤー、3つの管理者、3つの起動条件。「プロジェクトを忘れてしまった」という報告のほとんどは、ある項目が誤った見出しの下に分類されていることが原因です。
よく試されるアプローチ
会話の冒頭で毎回プロジェクトを再説明する。 永続的に機能しますが、コスト（手間）は変わりません。これはhow to stop re-explaining context to AIで説明されているループです。
Memoryファイルにルールを書き込む。 編集可能であることを考えれば理解はできます。しかし、Memoryは実行可能な指示ではなくコンテキストを保持するものであり、いずれにせよ明示的なリクエストやCustom Instructionsの方が優先されます。
すべてをCustom Instructionsに詰め込む。 これらはWorkspace全体で常にオンになります。だからこそ、ドキュメントでは短く具体的に保つよう指示されているのです。長い指示ブロックは、目の前の作業と競合してしまいます。
すべての作業を1つのプロジェクトにまとめる。 共有のProject memoryは得られますが、本来望んでいたプロジェクト間の分離が犠牲になり、保持されるコンテキストが無関係なビルド間で混ざり合って曖昧になります。
共有プロジェクトが自分のMemoryを引き継ぐと仮定する。 デフォルトでは引き継がれません。これはバグではなく設定によるものです。
リポジトリ内に決定事項のドキュメントを保管する。 直感としては正しいですが、コンテナとしては不適切です。何かでそこを指し示さない限り、誰もそれを読みません。これはwhy Replit Agent forgets task historyで説明されている一般的なパターンです。
解決策：Memoryをオンにし、各情報を適切なレイヤーに分類する
15分かけてルーティングを整理するだけで、大きな違いが生まれます。
Memoryをオプトインする。 Settings → Customization → Memory。その際、Memoryファイルを確認し（直接表示・更新できます）、古くなった情報を削除してください。
共同作業者との共有設定を意図的に決定する。 他のメンバーが編集できるプロジェクトでチームが作業しており、そこでReplitに自分のMemoryを使用させたい場合は、共有をオンにします。そうでない場合はオフのままにし、それらのプロジェクトは共有されている別のレイヤーからコンテキストを取得する必要があることを受け入れてください。
ルールをCustom Instructionsに移動する。 承認されたライブラリ、セキュリティ要件、データ処理ポリシーなど、常に真であるべき事項です。これらはあなたが記述し、Replitによって変更されることはなく、Workspaceのプロジェクトやセッション全体に適用されます。リストは小さく保ちましょう。
手順をSkillsに移動する。 リリースの準備、レビューのチェックリストなど、繰り返す複数ステップの作業です。安定した手順に関する知識はここに配置し、タスクに関連するときに呼び出されるようにします。
Memoryに本来の仕事をさせる。 過去の作業から学習できる好みや作業スタイルをMemoryに任せることで、同じことを繰り返す必要がなくなります。自分で執筆するのではなく、監視役に徹しましょう。
これで方向性と手順はカバーできました。しかし、どのレイヤーにも保持されないのが、プロジェクトの背後にある「理由（推論）」です。一見奇妙に見える選択を正当化する制約、2週目に試して失敗したアプローチ、構築するすべてのプロジェクトにまたがるドメイン知識などです。Custom Instructionsは短く保つ必要があります。Project memoryはそのプロジェクトに留まります。そして、Replitが意図的に除外するカテゴリについては、いずれにせよ別の保管場所が必要です。
それこそがMemoryLakeの役割です。単一のWorkspaceやプロジェクトに依存せず、ツールが読み取れるレイヤーに永続的な知識を保管します。セットアップは3つのステップで完了します。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ 2: 最初のメモリをアップロードする
1つのエントリーにつき1つの主張を含む、短いエントリーを作成します。登録すべき内容は以下の通りです。
制約が伴う決定事項。 「クライアントのバンドルサイズがすでに予算オーバーしているため、認証はサーバー側に留める。」 単なる「好み」ではこれを表現できませんが、メモリのエントリーであれば可能です。
何が壊れ、なぜ壊れたか。 Project memoryがうまくキャプチャできるような注意点（gotchas）を、1つのプロジェクトに限定されない場所に一度だけ書き留めておきます。
プロジェクトをまたぐ知識。 ドメイン用語、標準規格、統合時の特異な挙動など。Project memoryは設計上、そのプロジェクトに留まるため、これらは特定のプロジェクトに属すべきではありません。
Memoryに配置できない要件。 Replit's Memoryが意図的に除外する、機密情報や認証情報に近い制約事項も、エージェントが読み取れる場所に保管しておく必要があります。
ステップ 3: AIとエージェントを接続する
使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能です。そのため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定することで接続でき、その他のアシスタントはAPIを介して同じメモリを読み取ることができます。
3つの率直な制限事項があります。MemoryLakeはReplitのMemoryファイルへの書き込みは行いません。また、Custom InstructionsやSkillsの代わりになるものでもありません（これらはReplit内部でエージェントを制御するためのものです）。MemoryLakeは、あなたまたはエージェントが書き込んだ内容のみを保持するため、ステップ2は手動で行う必要があります。さらに、これはシークレットマネージャーではありません。認証情報は、いかなる種類のメモリではなく、シークレットストアに保管する必要があります。
実践における変化
新しいプロジェクトが最初から知識を持った状態でスタートする。 Project memoryはプロジェクト間を移動しません。しかし、プロジェクトの外部に保管された知識は移動するため、4回目のビルドは3回目のビルドが終了した時点から開始できます。
チームプロジェクトが記憶喪失にならなくなる。 共同作業者との共有をオンにしているかどうかにかかわらず、外部レイヤーにある共有知識は、そこで作業する全員が利用可能になります。
Custom Instructionsを再び短く保てる。 実質的な内容が別の場所に保管されていれば、常にオンになっているリストは、プロンプトと競合する長大なドキュメントではなく、一握りの真のルールだけで済みます。
除外されていたカテゴリの保管場所ができる。 Memoryはプロジェクトの機密事項を意図的にスキップします。しかし、それらの制約は依然として作業を方向付けるものであり、エージェントが読み取れる場所に記述できるようになります。
コンテキストがReplit専用の形式に縛られない。 同じ推論がCursorやClaude Codeでも役立ちます。この形式については、what persistent memory actually meansで詳しく説明しています。
Replit Agentのコンテキストに関するベストプラクティス
最初にMemoryのトグルスイッチを確認する。 オプトイン方式です。その他すべての設定は、これがオンになっていることが前提となります。
利便性ではなく、永続性に基づいてルーティングする。 常に真 → Custom Instructions。繰り返し実行する手順 → Skills。過去の作業から学習した内容 → Memory。
Memoryにルールを書き込まない。 Memoryは実行可能な指示ではなくコンテキストを保持するものであり、いずれにせよ明示的なリクエストやCustom Instructionsの方が優先されます。
Custom Instructionsは短く保つ。 ドキュメントには、目の前の作業の邪魔にならないようにと記載されています。常に真である最小限のガイドラインを目指しましょう。
共同作業者との共有設定を意図的に決定する。 デフォルトはオフです。どちらの設定にしたいか、そしてその理由を明確にしておきましょう。
Memoryファイルを定期的に見直す。 表示および編集が可能です。古くなった好み（preference）が残っていることは、何も記憶がないことよりも悪影響を及ぼします。
シークレット情報をメモリの近くに置かない。 Replitは認証情報や機密事項を意図的に除外しています。シークレットストアを使用してください。
ルールの隣に理由を書き添える。 ルールは1つのプロジェクトで終わるかもしれませんが、その理由は次の4つのプロジェクトでも生き続けます。これはwhy RAG isn't memoryで説明されている一般的なポイントです。
結論
Replit Agentはコンテキストを保持します。そうではないように見える原因は、通常、ドキュメントに記載されている4つの事実に集約されます。すなわち、Memoryはオプトイン方式であること、Memoryは実行可能な指示ではなくコンテキストを保持すること、3つのメモリ・スコープはビルダー、プロジェクト、または独自の表示設定に限定されていること、そして共有プロジェクトはデフォルトで除外されていることです。
Memoryをオンにし、ルールをCustom Instructionsに分類し、手順をSkillsに配置し、共同作業者との共有設定を意図的に決定してください。そして、これらのどのレイヤーにも収まらない情報（決定事項とその制約、失敗したこと、単一のプロジェクトよりも長生きするドメイン知識）を、エージェントがクエリできる場所に保管します。これにより、5番目のプロジェクトでも、最初のプロジェクトの終了時と同じように十分な知識を持った状態で作業を進めることができるようになります。