Codex Memoriesに残す情報と、AGENTS.mdで共有するルールの使い分け
この記事で学べること
- Codex Memoriesに残す好みや注意点と、リポジトリで管理する必須ルールの違い
- メモリの利用・生成を止めたり、内容を見直したりする場面の判断基準
- スレッドごとのメモリ設定と、
AGENTS.mdなどのチーム規約を組み合わせる方法
Codex Memoriesと正式なルールの役割
Codex Memoriesは、過去の作業で得た情報を、次の作業でも参照するための仕組みです。同じリポジトリ（コードや文書をまとめて管理する場所）を繰り返し扱うとき、好みや注意点を毎回説明する負担を減らせます。
ただし、Memoriesに残すのは、繰り返し役立つ好みや注意点です。必ず守るチームルールや機密情報を、メモリだけに保存する運用は避けます。
チームが正式な参照先として管理する文書を、この記事では「正本」と呼びます。メモリを正本として扱うと、誰が更新を担当するのか、どの内容が現在も有効なのかを確認しにくくなります。
保存先は、誰が参照する情報か、誰が更新に責任を持つかを基準に分けます。個人の作業を助ける情報はMemories、チームの必須ルールはリポジトリ内の規約、その場限りの情報は一時的な会話で扱う、という考え方です。
この記事では、この区分をもとに、何をMemoriesに残し、何を正本で管理し、どのような場面でメモリを見直すかを整理します。
Memoriesに向く情報
Memoriesに向くのは、長く使えて、毎回説明し直すと作業効率が落ちる情報です。文体の好み、繰り返し使う作業手順、利用する技術、過去に起きた問題などが該当します。
ただし、同じ情報でも、個人の参考情報として扱うか、チームの正式なルールとして扱うかによって、保存先は変わります。
| 情報の種類 | Memoriesで参照する利点 | 正式に管理する場合の保存先 |
|---|---|---|
| 個人の文体の好み | 繰り返し使う好みを伝え直さずに済む。プロダクトの仕様とは分けて扱える | 必要に応じて、ブログの執筆ルール |
| よく使う検証コマンド | 作業開始時に、確認すべき対象やコマンドを見つけやすくなる | AGENTS.mdや、チームで共有する作業手順（shared workflow） |
| リポジトリ固有の注意点 | 同じ失敗を繰り返しにくくなる | 継続して守る内容なら、チームの共有ルール（shared rules） |
| 過去の判断の背景 | 次回の調査で、どこから確認を始めるかを決めやすくなる | 仕様や設計判断に関わる内容なら、Gitで管理する文書 |
この表は、保存する情報の用途に基づく本記事の分類です。OpenAIが公式に示した分類表ではありません。公式ドキュメントでは、Codexが過去の会話から有用な情報をメモリとして保存し、将来の作業へ引き継ぐ仕組みが説明されています。[1]
Memoriesだけに保存しない情報
失われると困る情報、誤ったまま残ると危険な情報、チーム全員に同じように適用したい情報は、Memoriesだけで管理しないようにします。
チームの必須ルール
たとえば「本番ビルドは明示的な承認があるときだけ実行する」「公開記事には架空の出典を入れない」といったルールは、個人のメモリだけに置かないほうが安全です。
こうしたルールは、AGENTS.md（Codexに作業上の指示を伝えるファイル）や共有ルールに記載します。自動で確認できる内容は、検証スクリプトにも組み込みます。誰が作業しても、同じルールを参照・確認できる状態にするためです。
秘密情報や顧客情報
秘密情報や顧客情報は、Memoriesに保存しない前提で扱います。
OpenAIの公式ドキュメントでは、Codexは生成するメモリから秘密情報を除去すると説明されています。それでも、Codex home（設定や作業状態を保存するディレクトリ）や、生成されたメモリファイルなどを共有する前には、内容を確認するよう案内されています。[1]
「自動で除去されるはず」と考えて、機密情報をメモリに残す運用は避けるべきです。
一時的な仮説や回避策
1回だけ使う仮説、検証途中の未確定情報、今日だけ有効な回避策も、Memoriesには向きません。こうした情報が残ると、次回のCodexが古い前提で作業を始める可能性があります。
一時的な調査メモは、その作業の会話内で扱い、将来の作業へ引き継ぐ情報とは分けておきます。
メモリの利用・生成を止める場面と、見直しの判断基準
プロジェクトの目的や構造が変わったとき、誤った記憶を繰り返し参照するとき、不要な情報が蓄積したときは、メモリの扱いを見直します。
ここでいう「リセット」は、メモリファイルを手作業で削除することだけを指すものではありません。スレッド（ひと続きの会話）でメモリの利用や生成を止める、設定を変更する、保存された内容を確認して不要な前提への依存を減らす、といった対応を含む運用上の表現です。利用・生成を止めることと、保存済みのメモリを削除することは区別します。
| 場面 | 対応の考え方 |
|---|---|
| Codexが古い前提を繰り返す | 関連するメモリを確認する。正しいルールはAGENTS.mdや共有ルールに記載する |
| プロジェクトの構造を大きく変えた | 旧ディレクトリ、旧コマンド、旧ワークフローを前提にしたメモリを見直す |
| 一時的な調査や外部情報を多く扱った | そのスレッドを、将来のメモリ生成に使わない設定にする |
| 機密性の高い情報を扱った | メモリ生成を止める。関連ファイルを共有する前に、~/.codex/memories/の内容を確認する |
| 個人の注意点がチームルールとして定着した | Git（変更履歴を管理する仕組み）で管理するルールや検証に反映する |
| Codexの提案が現在の仕様とずれている | メモリより、公式ドキュメントとリポジトリの現在の状態を優先して確認する |
注意したいのは、メモリによって作業開始が速くなっても、参照する前提が古ければ、誤った作業も速く進んでしまうことです。
見直しの目的は、単にCodexを初期状態へ戻すことではありません。現在の仕様や作業目的に合う情報を参照できるようにすることです。
スレッドごとのメモリ設定
Codexのローカルメモリを使うアプリやCLIには、現在のスレッドでの扱いを選ぶ機能があります。公式ドキュメントでは、ChatGPTデスクトップアプリとCodex TUI（ターミナル上の対話画面）で、/memoriesによる制御が案内されています。[1]
選べるのは、次の2点です。
- 現在のスレッドで、既存のメモリを使うか
- 現在のスレッドを、将来のメモリ生成に使うか
この選択はスレッド単位で適用され、全体のメモリ設定を変更するものではありません。[1]
顧客情報・未公開情報・認証情報を次の作業へ引き継ぐことを避けたい場合や、Web検索、MCP（外部のツールやデータをAIに接続する仕組み）などから取り込んだ一時的な情報を再利用したくない場合は、この制御が選択肢になります。ただし、メモリを止めることと、サービス側で情報が保存されないことは同じではありません。
失敗の原因を調べる過程で誤った仮説を数多く試す場合や、その場限りの検証で次回に残したくない判断が多い場合も、将来のメモリ生成に使うかを見直す場面です。
公式設定には、次のような項目があります。[1][2]
| 設定項目 | 制御する内容 |
|---|---|
memories.generate_memories | 新しく作成したスレッドを、メモリ生成の入力として保存するか |
memories.use_memories | 既存のメモリを、以後の作業で参照するか |
memories.disable_on_external_context | trueの場合、MCPやWeb検索などの外部情報を使ったスレッドを、メモリ生成の対象から外す |
memories.min_rate_limit_remaining_percent | メモリ生成を開始するために必要な、Codexの利用枠の残り割合 |
特に、外部情報を使ったスレッドをメモリ生成の対象から外したい場合は、memories.disable_on_external_contextの設定を確認する価値があります。
なお、ここで扱うローカルメモリと、ChatGPT WebやChatGPT Workのメモリは同じ仕組みではありません。利用している製品に合った設定を確認してください。[1]
自動生成されたメモリファイルの扱い
Codexは、Codex homeの配下にメモリを保存します。既定のCodex homeは~/.codexで、主要なメモリファイルは~/.codex/memories/にあります。[1]
公式ドキュメントでは、これらをCodexが生成・更新するファイルとして扱うよう説明しています。トラブルの調査や共有前の点検で内容を確認することはできますが、手作業での編集を、メモリを制御する主な方法にはしないよう案内されています。[1]
そのため、公式な履歴や規約を維持するには、次の扱いが考えられます。
| 管理したい内容 | 主な管理方法 |
|---|---|
| その場限りの作業情報 | スレッド単位で、メモリを使うか、生成に使うかを選ぶ |
| 継続して守るルール | AGENTS.mdや共有ルールに記載する |
| 変更された仕様 | リポジトリ内の文書や検証を更新する |
| 繰り返し参照される誤った記憶 | 生成されたメモリを確認し、利用設定と正式な参照先を見直す |
メモリファイルを、手作業で編集する設定ファイルのように扱うと、正式なルールと自動生成された情報の区別が曖昧になります。Memoriesは、Codexが過去の作業を思い出すための補助として使うほうが、管理しやすくなります。
リポジトリで共有する規約と、自動で確認する仕組み
チームで共有するコマンド、制約、検証手順、フォルダごとの担当範囲は、AGENTS.mdや、Gitで管理する共有ルールに置きます。AGENTS.mdは、そのリポジトリで作業するCodexに、最初に確認してほしい指示を伝えるためのファイルです。
機械的に確認できる内容は、レビュー用のコマンドやCI（GitHub Actionsなどでテストや検証を自動実行する仕組み）にも組み込みます。文書でルールを共有し、自動検証で守られているかを確認する、という役割分担です。
一方、Memoriesは個人の作業傾向を参照するために使います。たとえば「このユーザーは、日本語の文書を正式な参照先として扱うことが多い」「このリポジトリでは、変更した箇所に絞ったレビューを好む」といった傾向です。
その傾向が必須ルールになった時点で、リポジトリ内の文書や検証に反映します。メモリにだけ残したままにしないことが大切です。
重要な前提が文書や検証にも残っていれば、Memoriesの利用を止めたり、内容を見直したりしても、作業に必要なルールを確認できます。メモリへの依存を減らすことで、Codexの作業を安定させやすくなります。
まとめ：個人の好みはメモリ、チームの必須ルールは共有文書へ
Codex Memoriesは、個人の好みや繰り返し使う注意点を伝え直す負担を減らします。チームの必須ルールはAGENTS.mdや共有文書で管理し、機密情報や一時的な仮説はメモリに残さない前提で扱います。
保存先に迷ったら、その情報が「個人の好み」「チーム規約」「機密情報」「一時情報」のどれに当たるか、誰が参照し、誰が更新するかを確認します。古い前提が残っている場合は、現在の仕様を優先して見直します。利用・生成を止める際は、製品によって異なる現在の設定を確認してください。
参考文献
- OpenAI, Memories, ChatGPT Learn
- OpenAI, Configuration Reference, ChatGPT Learn
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。