なぜCodexは依然として期待通りに記憶しないのか
記憶は2つの場所のいずれかで有効化するまでオフのまま
ドキュメントにははっきりと「ローカルのCodex記憶はデフォルトでオフです」と記載されています。
これらを有効化する方法は2つあります。ChatGPTデスクトップアプリでは、設定 > パーソナライズを開き、記憶を有効にするをオンにします。設定ファイルベースのセットアップでは、config.tomlに以下の機能フラグを追加します。
[features]
memories = trueデスクトップアプリ、CLI、IDE拡張機能にわたってCodexを使用している場合、IDE拡張機能は「接続されているCodexホストのローカル記憶ストアを使用する」ため、独自のストアは維持しない点に注意してください。ホスト側で有効化すれば、拡張機能もそれに従います。
人々を混乱させるもう一つの違いは、ウェブ版のChatGPTが別システムである点です。「ChatGPTウェブ版はChatGPTの記憶を使用しますが、ローカルのCodexクライアントは別のローカル記憶ストアとコントロールを使用します。」また、ChatGPT Workは「ローカルのCodex記憶ストアやローカル記憶コントロールを一切使用しません。」一方をオンにしても、他方がオンになるわけではありません。
書き込みは遅延され、スキップされることもある
記憶をオンにしていても、チャットが終了した瞬間に何かが表示されるわけではありません。「チャット終了時に記憶がすぐに更新されない場合があります。Codexは、進行中の作業の要約を避けるため、チャットが十分にアイドル状態になるまで待ちます。」また、Codexは「アクティブなセッションや短時間のセッションをスキップ」します。
これは合理的な設計ですが、使い始めの初日には混乱を招きます。機能を有効化し、セッションを終え、記憶を探しても、何も見つからないからです。
より重要な、しかし目立たない側面があります。「Codexのレート制限の残り割合が設定されたしきい値を下回っている場合、記憶の生成はバックグラウンドパスをスキップすることもあります。これにより、制限に近いときにCodexがクォータを消費するのを防ぎます。」
これがいつ実行されるかという観点から考えてみてください。スキップされる可能性が最も高いセッションは、忙しい一日の終わりにある、長くて濃密で困難なセッションです。まさに最も記憶に値するセッションです。しきい値は memories.min_rate_limit_remaining_percent で設定可能ですが、デフォルトの挙動では、最も忙しい作業ほど記録されにくくなります。
書き込まれる内容は生成された状態であり、編集しないよう指示されている
ストアはデフォルトでCodexのホームディレクトリである ~/.codex の下に存在し、「メインの記憶ファイルは ~/.codex/memories/ の下にあり、以前のチャットからの要約、永続的なエントリ、最近の入力、および裏付けとなる証拠が含まれています。」
そして、この機能全体の役割を定義する指示があります。「これらのファイルは生成された状態（ステート）として扱ってください。トラブルシューティングの際や、Codexホームディレクトリを共有する前にこれらを検査することはできますが、主要なコントロール手段として手動で編集することに依存しないでください。」
つまり、検査は可能ですが、手動で執筆するものではありません。Codexがなぜそう信じているのかを知るために読み取ることはできますが、プロジェクトの動作方法の正式な記録として維持することはできません。これは意図的な境界線であり、ドキュメントが数行後で再び描いている境界線と同じです。
外部の上下文は記憶生成から完全に除外できる
これは、この設定群の中で最も興味深いキーです。memories.disable_on_external_context は、「true の場合、MCPツール呼び出し、ウェブ検索、ツール検索などの外部の上下文（コンテキスト）を使用したチャットを記憶生成から除外します。」古いキーである memories.no_memories_if_mcp_or_web_search も、依然としてエイリアスとして受け入れられます。
外部の影響を受けたセッションを記憶ストアから除外するスイッチをベンダーが提供しているということは、これらのシステムがどのように失敗するかについての重要なシグナルです。エージェントが他の場所から取得したコンテンツは、永続的な記憶に入り込むもっともらしい経路であり、OpenAIはそれを遮断する方法を提供したのです。
しかし、トレードオフは現実的です。これをオンにすると、調査中心のセッション（多くの場合、最も純粋に新しい情報が含まれるセッション）が記憶に寄与しなくなります。オフにすると、エージェントが読み取ったすべての内容が、その記憶に影響を与える可能性があります。
その他のキーの簡単な説明
さらに知っておくべきキーが4つあります。memories.generate_memories は「新しく作成されたチャットを記憶生成の入力として保存できるかどうかを制御します。」 memories.use_memories は「Codexが既存の記憶を将来のセッションに注入するかどうかを制御します。」この2つの方向は分かれているため、書き込まずに読み取る、または読み取らずに書き込むことが可能です。そして、memories.extract_model と memories.consolidation_model は、それぞれチャットごとの抽出とグローバルな統合に使用されるモデルをオーバーライドします。
チャット単位では、デスクトップアプリやCodex TUIの /memories が、そのチャットが既存の記憶を使用できるか、また将来の記憶にフィードできるかを制御します。「チャットレベルの選択によってグローバルな記憶設定が変更されることはありません。」
よくある試みと誤解
Codexには記憶がないと結論づける。 無理もありません。ストアはデフォルトでオフになっているため、最も一般的な誤解です。まずは「設定 > パーソナライズ」を確認してください。
すべてを AGENTS.md に書き込む。 これは機能し、ドキュメントでも特定のカテゴリに対して積極的に推奨されています。しかし、肥大化する指示ファイルはリクエストごとに上下文（コンテキスト）を圧迫し、推論に適した形状ではありません。
~/.codex/memories/ を手動で編集する。 明確に非推奨とされています。これらは生成されたファイルであり、Codexの統合パスがそれらを維持します。手動での編集はコントロール手段ではありません。
記憶を有効化し、それですべて解決したと思い込む。 遅延書き込みやレート制限によるスキップがあるため、カバー範囲は設計上、不完全なものになります。特定のセッションが痕跡を残したという保証はありません。
disable_on_external_context をオンにして忘れてしまう。 安全なデフォルトですが、最も情報密度の高いセッションがサイレントに除外されてしまいます。
すべてのセッションの開始時に上下文（コンテキスト）を貼り付ける。 確実で手動ですが、忘れてしまう日がいずれ訪れます。
解決策：必ず保持すべきルールと、思い出せると便利な情報を切り分ける
ドキュメントにはその切り分けが示されており、ベンダーがこれについて発表した中で最も明確な記述であるため、全文を引用する価値があります：
「チームに必要なガイダンスは AGENTS.md またはチェックインされたドキュメントに保管してください。記憶は、常に適用されるべきルールの唯一のソースとしてではなく、役立つ想起レイヤーとして扱ってください。」
つまり、3つの階層があります。常に適用されるべきルールは AGENTS.md またはチェックインされたドキュメントに入ります。好みの設定や出力の形式など、あると便利な想起情報はローカルストアの役割であり、自動的に機能させることが目的です。その中間に位置するのが、指示でも「あると便利」なものでもない、永続的なすべての情報です。決定事項とその理由、除外されたアプローチ、明らかな答えを誤りにする制約などです。この階層は、レート制限に近づいたときにパスをスキップするようなストアに置くべきではなく、リクエストごとに読み込まれる指示ファイルに置くべきでもありません。
これこそが MemoryLake が保持するレイヤーです。ツールが意図的にクエリする永続的なプロジェクト知識であり、これにより AGENTS.md は短く保たれ、ローカルストアは便利な機能のまま維持されます。セットアップは3つのステップです。
ステップ 1: APIキーを作成する
サインインしてAPIキーを作成します。接続するツール間で共通の1つの認証情報です。
ステップ 2: 最初の記憶をアップロードする
短いエントリで、1つの主張につき1つ。役立つテスト方法として、それを失った場合にキーストロークではなく、議論のコストが発生するかどうかで判断します：
理由を伴う決定事項。 「コネクションプールが同時接続数200で飽和するため、書き込みをバッチ処理しています。」ルールは AGENTS.md に記述できますが、その理由こそが、次の四半期にそれが元に戻されるのを防ぐものです。
すでに除外されたアプローチ。 指示ファイルにもコミットメッセージにも現れず、新しいセッションのたびに再提案されるカテゴリです。
誰もアナウンスしない環境の事実。 ドキュメント化されていないレート制限、順序の依存関係、CIでのみ失敗するテストなどです。
スキップされたパスによって失いたくないすべてのもの。 それが重要であり、ローカルストアのカバー範囲がベストエフォートであるなら、ベストエフォートに依存してはいけません。
ステップ 3: AIとエージェントを接続する
使用しているものを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能であり、CodexはMCPサーバーをサポートしています。なお、memories.disable_on_external_context を true に設定したままにすると、MCPツールを使用するセッションはCodex自身のローカル記憶に寄与しなくなる点に注意してください。これは、どのストアに何を保持するかを慎重に決定すべき理由であり、どちらかを避けるべき理由ではありません。
3つの率直な制限事項。MemoryLakeは ~/.codex/memories/ を読み取り、書き込み、削除しません。 これはOpenAIが維持する生成された状態であり、外部ツールが編集すべきではありません。AGENTS.md への書き込みも行いません。 これは引き続きCodexを制御するための手段です。そして、あなたやエージェントがそこに置かない限り、何も記憶に残りません。 そのため、ステップ2は意図的に行う必要があります。
実践においてこれがもたらす変化
「Codexは記憶しているか？」に対する本当の答えが得られます。 はい、有効化されていれば記憶しています。そして、ファイルの場所も把握できます。
バックグラウンドパスのスキップによって重要なものを失うことがなくなります。 永続的な階層は、スキップが発生するストアには置かれていません。
AGENTS.md の肥大化が止まります。 指示は指示のままであり、推論プロセスは外部に移動します。
編集することなく検査できます。 ~/.codex/memories/ を読み取ってその認識を理解し、永続レイヤーを変更してそれを修正します。
調査中心のセッションを安全に実行できます。 重要な結論が意図的に書き留められている場合、Codex独自のストアから外部の上下文（コンテキスト）を除外することによる損失は少なくなります。
Codexローカル記憶のベストプラクティス
明示的に有効化し、実際に使用しているインターフェースを確認する。 デフォルトでオフです。IDE拡張機能はホストに従います。ChatGPTウェブ版は別システムです。
disable_on_external_context を慎重に決定する。 これは記憶への現実的な経路を遮断し、最も情報密度の高いセッションを除外します。理解した上で選択してください。
記憶に機密情報を入れない。 ドキュメントには「記憶に機密情報を保存しないでください」と直接記載されています。Codexは生成されたフィールドから機密情報を編集（マスク）しますが、Codexホームディレクトリを共有する前にファイルを確認してください。
機能が間違っていると結論づける前に、ファイルを読み取る。 検査はサポートされていますが、コントロール手段としての手動編集はサポートされていません。
必要なガイダンスは AGENTS.md に保管する。 ベンダー自身の推奨事項であり、ローカルストアはこれの代わりにはなりません。
読み取りと書き込みを分離する。 use_memories と generate_memories は独立したキーであり、共有作業や機密性の高い作業で役立ちます。
蓄積された内容を定期的に監査する。 一般的な実践方法は AIが記憶している内容を監査する方法に記載されています。
永続レイヤーを小さく保つ。 エントリが多ければ良いというわけではありません。その理由は エージェントの記憶は少なく保つべき理由に記載されています。
結論
Codexは、ほとんどのユーザーが考えている以上に記憶しており、「記憶」という言葉が暗示するほどには記憶していません。~/.codex/memories/ には、要約、永続的なエントリ、最近の入力、および裏付けとなる証拠を保持するドキュメント化されたローカルストアが存在します。これはデフォルトでオフになっており、「設定 > パーソナライズ」または config.toml の機能フラグから有効化でき、チャットごとの制御は /memories を通じて行い、その背後には半ダースほどの設定キーが用意されています。
そのカバー範囲は意図的にベストエフォートとなっています。書き込みはチャットがアイドル状態になるまで待機し、短いセッションはスキップされ、残りのレート制限が設定されたしきい値を下回るとバックグラウンドパスが完全にスキップされることもあります。ファイルは生成された状態であり、検査は推奨されますが手動での編集は推奨されません。そして、disable_on_external_context は、MCPやウェブ検索に触れたセッションを記憶生成から完全に除外します。これは本当に優れたコントロールであると同時に、本当に大きな除外でもあります。
これらは欠陥ではなく、スコープ（適用範囲）です。ドキュメント自体がそのスコープを名指ししています。必要なガイダンスは AGENTS.md またはチェックインされたドキュメントに保管し、記憶は常に適用されるべきルールの唯一のソースとしてではなく、役立つ想起レイヤーとして扱ってください。ストアをオンにし、便利な機能はそれに任せ、議論の対象となるような決定事項は、忙しいときにパスをスキップしないような場所に置いてください。上下文（コンテキスト）だけではこれを解決できないより広範な理由は、長い上下文が記憶ではない理由に記載されています。