Codex Memoriesの使い方とリセットの判断基準
この記事で学べること
- Codex Memoriesへ残す補助情報と、リポジトリを正本にすべきルールの違い
- メモリを使わない、見直す、リセットする場面の判断基準
- スレッド単位の制御とAGENTS.mdなどの規約を分けて運用する方法
Codex Memoriesは正本と分けて管理する
Codex Memoriesへ残すべきなのは、繰り返し役立つ好みや注意点であり、必ず守るチームルールや機密情報ではありません。同じリポジトリを何度も扱う負担は減らせますが、メモリを正本にすると、誰が更新し、どの内容が有効かを確認しにくくなります。情報の共有範囲と更新責任を基準に、Memories、リポジトリの規約、一時的な会話へ保存先を分けます。
この記事では、「何をMemoriesへ残し、何を正本へ置き、いつ見直すべきか」という問いに焦点を当て、結論を分ける判断軸、適用条件、最初に確認する事項を扱います。
最後まで読むと、「何をMemoriesへ残し、何を正本へ置き、いつ見直すべきか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
Codex Memoriesで覚えさせるとよい情報
Memoriesに向くのは、安定していて、毎回説明すると作業効率が落ちる情報です。
| 情報の種類 | Memoriesに向く理由 | 正本にすべき場所 |
|---|---|---|
| 個人の文体の好み | 何度も出てくるが、プロダクト仕様ではない | 必要ならブログルール |
| よく使う検証コマンド | 作業開始時に確認する対象を見つけやすい | AGENTS.md、shared workflow |
| リポジトリ固有の注意点 | 同じ失敗を繰り返しにくくなる | 永続化するならshared rules |
| 過去に起きた判断の背景 | 次回の調査開始位置を決めやすい | 仕様・設計判断ならGit管理文書 |
この表は、私の運用上の分類です。OpenAI公式がこの分類表を示しているわけではありません。公式情報として確認できるのは、Codexがstable preferences、recurring workflows、tech stacks、known pitfallsのような文脈を将来の作業に引き継げるという点です。[1]
メモリを使わないほうがよい情報
Memoriesに置くべきでないものは、失われると困るもの、間違って残ると危険なもの、チーム全員に同じ形で適用したいものです。
まず、必須ルールはMemoriesだけに置かないほうが安全です。たとえば「本番ビルドは明示承認があるときだけ実行する」「公開記事には架空の出典を入れない」といったルールは、個人の記憶ではなく、AGENTS.md、shared rules、検証スクリプトに置くべきです。
次に、秘密情報や顧客情報は保存しない前提で扱います。OpenAIの公式ドキュメントでは、Codexは生成されたメモリフィールドからsecretを除去しようとすると説明されていますが、それでもCodex homeや生成されたメモリアーティファクト（ビルドや生成処理の結果として出力されるファイルや資料）を共有する前にはメモリファイルを確認するよう案内しています。[1] 「除去されるはず」と考えて機密情報を入力する運用は避けるべきです。
また、短期的な調査メモもMemoriesには向きません。1回だけ使う仮説、検証途中の未確定情報、今日だけ有効な回避策が残ると、次回のCodexが古い前提で作業を始める可能性があります。
Codex Memoriesは目的変更・誤記憶・不要情報の蓄積時にリセットする
ここでいうリセットは、必ずしもメモリファイルを手で削除するという意味ではありません。CodexのスレッドでMemoriesの利用や生成を止める、設定で使い方を変える、生成されたメモリを点検して不要な前提を取り除く、といった運用上のリセットを含めています。
| シーン | 推奨する対応 |
|---|---|
| Codexが古い前提を繰り返す | 該当する記憶を疑い、正しいルールを AGENTS.md やshared rulesへ移す |
| プロジェクトの構造を大きく変えた | 旧ディレクトリ、旧コマンド、旧ワークフローを前提にしたメモリを見直す |
| 一時的な調査や外部情報を多く扱った | そのスレッドを将来のメモリ生成に使わない |
| 機密性の高い情報を扱った | メモリ生成を止め、共有前に ~/.codex/memories/ を確認する |
| チームルールとして定着した | MemoriesからGit管理されたルールや検証へ昇格する |
| Codexの提案が現在の仕様とずれている | Memoriesより公式ドキュメントとリポジトリの現状を優先する |
特に重要なのは、メモリが「間違った便利さ」を作る場面です。Codexが素早く作業に入れるようになっても、参照している前提が古ければ、速く間違えるだけになります。メモリのリセットは、Codexを初期化するためというより、前提の鮮度を取り戻すために行います。
Codex Memoriesはスレッド単位で有効・無効を切り替える
Codex appとCodex TUIでは、/memories を使って現在のスレッドにおけるメモリの扱いを制御できます。既存メモリを使うか、現在のスレッドを将来のメモリ生成に使うかをスレッド単位で選べますが、この選択はグローバル設定を変更するものではありません。[1]
私は、次のような作業ではスレッド単位の制御を使うのがよいと考えています。
- 顧客情報、未公開情報、認証情報に近い文脈を扱う
- Web検索、MCP、外部ツールから一時的な情報を多く取り込む
- 失敗調査の途中で、誤った仮説を大量に試す
- その場限りの検証で、次回以降に残したくない判断が多い
公式設定には、memories.generate_memories、memories.use_memories、memories.disable_on_external_context、memories.min_rate_limit_remaining_percent などのメモリ関連項目があります。[1][2] 特に外部コンテキストを使ったスレッドをメモリ生成から外したい場合は、memories.disable_on_external_context のような設定を確認する価値があります。
自動生成されたCodex Memoriesは正本の代わりに直接編集しない
Codexは、メモリをCodex home配下に保存します。既定では ~/.codex がCodex homeで、主要なメモリファイルは ~/.codex/memories/ にあります。[1]
ただし、公式ドキュメントでは、これらを生成された状態として扱い、トラブルシューティングや共有前の確認では見てもよいが、手動編集を主な制御面にしないよう説明しています。[1] そのため、私は次の順番で扱うのがよいと考えています。
- その場限りなら、スレッド単位で使う・生成する範囲を制御する
- 恒久ルールなら、
AGENTS.mdやshared rulesに移す - 仕様変更なら、リポジトリ内のドキュメントや検証を更新する
- どうしても誤った記憶が残るなら、生成されたメモリを確認して整理する
Memoriesは便利ですが、編集可能な「裏設定ファイル」として扱うより、Codexが思い出すための補助レイヤーとして扱うほうが安定します。
リポジトリ規約とMemoriesを分ける
Codex運用では、Git管理されたリポジトリ規約とMemoriesの役割を分けることが重要です。
AGENTS.md は、リポジトリに入るCodexへ最初に読ませたい指示ファイルです。チームで共有するコマンド、制約、検証手順、フォルダの責任範囲は、ここかGit管理されたshared rulesに置きます。機械的に確認したい内容は、レビューコマンドやCI（GitHub Actionsなどでテストや検証を自動実行する仕組み）などの検証レイヤーにも移します。
Memoriesは、個人の作業文脈を思い出すための補助です。たとえば「このユーザーは日本語を正本として扱うことが多い」「このリポジトリでは変更後にtargeted reviewを好む」といった傾向はMemoriesに向きます。しかし、その傾向が必須ルールになった時点で、リポジトリ側の文書や検証に昇格すべきです。
この分離ができていると、Codexをリセットしても作業が壊れにくくなります。なぜなら、重要な前提はMemoriesだけでなく、リポジトリ内の文書や検証にも残っているからです。
まとめ：Codex Memoriesは共有範囲と更新責任で保存先を決める
Codex Memoriesは、同じ説明を何度も繰り返さないための有効な仕組みです。ただし、必須ルール、機密情報、短期的な仮説、古い仕様を残す場所ではありません。
私の判断基準は単純です。個人の好みや繰り返す注意点はMemoriesに置く。チームで共有するルールは AGENTS.md やshared rulesに置く。古くなった前提、機密性のある文脈、一時的な外部情報は、スレッド単位で使わない・生成しない・見直す。メモリを賢く使うより、メモリに依存しすぎない設計にしておくほうが、Codexとの作業は安定します。
最初の行動は、現在覚えさせたい情報を「個人の好み」「チーム規約」「機密情報」「一時情報」の4つへ分けることです。Codex Memoriesの設定や利用方法は更新される可能性があるため、実際に無効化や見直しを行う前に現在の製品設定を確認します。
参考文献
- OpenAI, Memories, ChatGPT Learn
- OpenAI, Configuration Reference, ChatGPT Learn
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。