Codex を継続的に使うと、「この repo の事情を覚えていてほしい」という要求がすぐ出ます。build が特殊、PR review の基準がある、SEO automation では毎回同じ確認をする、昔失敗した手順を避けたい。memory を使えば、この説明の繰り返しは減ります。
ただし、memory は便利な一方で、古い前提、秘密情報、個人の癖、外部 tool で読んだ一時情報を次回以降へ持ち込む入口にもなります。特に Codex は AGENTS.md、local memories、skills、plugins、MCP、browser、Computer Use、Chronicle が同じ作業面に並ぶため、何をどこに置くかを決めないと、文脈が増えるほど判断が濁ります。
この記事では、Codex の memories governance に絞って整理します。AIエージェント全体の memory 設計は AIエージェントメモリ設計ガイド、常時指示と Claude 固有文脈の分担は AGENTS.md と CLAUDE.md の違い、再利用手順は Codex Skills 設計入門、plugin / app permission の統制は Codex plugin governance 設計ガイド に分けています。
今回は「Codex に覚えさせる方法」ではなく、何を memory にしてよく、何を AGENTS.md や audit log や retrieval に逃がすべきかを扱います。
先に結論: memory はルールでもログでもない
私なら、Codex の文脈は次の5層に分けます。
| 層 | 置くもの | 置かないもの |
|---|---|---|
AGENTS.md | 毎回守る repo ルール、検証コマンド、禁止事項 | 個人の癖、一時的な調査結果 |
| local memory | 次回も役立つ短い運用学習、好み、既知の落とし穴 | 秘密情報、raw log、承認済み例外 |
| skill | 特定タスクでだけ使う再利用手順 | 常時読ませるべきルール |
| session | 今回の依頼、現在の diff、直近 tool result | 長期保存したい決定事項 |
| audit / catalog | 承認、tool 実行、plugin / MCP の許可状態 | 回答品質を上げるための補助文脈 |
memory は「次回の判断を少し安定させる短い補助文脈」です。hard rule でも、監査ログでも、ナレッジベース全文でもありません。
ここを間違えると、memory が暗黙の policy になります。「前回この write tool は許可した」「この顧客データは読んでよい」「この workaround を続ける」といった情報が memory に残ると、次回の task で違う前提なのに同じ判断をしてしまいます。
Codex local memory の性質を理解する
OpenAI の Codex memory docs では、local memories は有効化後に eligible な過去 chat から生成され、Codex home directory の ~/.codex/memories/ 配下に置かれると整理されています。active すぎる session や短命 session は対象外になり、secret は生成 field から redaction されますが、それでも人間の review は必要です。
実務で重要なのは、次の4点です。
- memory は即時更新とは限らない
- local file は生成状態であり、手編集を主制御面にしない
- chat ごとに
/memoriesで利用・将来保存への寄与を切り替えられる - rate limit が低いと memory generation が後回しになることがある
つまり、「さっき言ったのに覚えていない」は仕様上あり得ます。memory を業務の唯一の状態管理に使うと壊れます。重要な判断は memory ではなく、repo 内の文書、issue、PR、audit log、catalog に残します。
AGENTS.md と memory を分ける
Codex は作業前に AGENTS.md を読みます。global、project、directory の順に instruction chain を作り、近いディレクトリの指示ほど後ろに入ります。さらに project_doc_max_bytes や project_doc_fallback_filenames で、読み込み量や代替ファイルを調整できます。
この仕組みは memory と似ていますが、責務が違います。
| 判断 | AGENTS.md | local memory |
|---|---|---|
| チーム合意済みの作業ルール | 置く | 置かない |
| build / test / format command | 置く | 補足だけなら可 |
| この repo の過去の落とし穴 | 短い禁止事項なら置く | 再利用メモとして置く |
| 個人の文章スタイル | 原則置かない | 必要なら置く |
| 一時的な PR 状態 | 置かない | 原則置かない |
| 秘密情報 / token / cookie | 置かない | 置かない |
私なら、AGENTS.md には「破ると困ること」だけを書きます。たとえば、このブログなら pnpm seo:update-llms と pnpm run build は AGENTS.md 向きです。一方、「fresh worktree では root の node_modules/.bin を PATH に足すと通りやすい」は memory 向きです。前者はルール、後者は運用上の学びだからです。
AGENTS.md が太りすぎる場合は memory に逃がすのではなく、まず skill、docs、下位ディレクトリの AGENTS.md、または project_doc_max_bytes の見直しを考えます。memory は instruction overflow の退避場所ではありません。
memory に残してよい情報を5種類に絞る
最初から自由記述で許可すると、memory は増え続けます。私は保存してよい情報を先に絞ります。
codex_memory_policy:
allowed:
- repo_workflow_hint
- recurring_user_preference
- stable_role_boundary
- known_build_or_test_quirk
- stale_plan_warning
forbidden:
- secrets
- customer_personal_data
- raw_logs
- one_time_approval
- external_context_summary_without_source
- temporary_incident_workaroundたとえば、保存してよいのはこの程度です。
HPrepo では root が dirty なら checkout / pull せず worktree を使う- 新規記事では既存記事と open PR の検索意図重複を先に見る
- OpenAI product 記事では公式 docs を一次情報にする
- fresh worktree build では root
node_modules/.binを PATH に入れることがある - broad な一般語は keyword-plan に昇格させない
逆に、保存してはいけないのは次です。
- API key や cookie
- 顧客名、個人名、未公開案件名
- PR review comment 全文
- Datadog / GitHub / MCP から読んだ raw response
- 「今回は owner が承認した」という事実
- 期限付きの workaround
memory に残すべきなのは「次回も同じ判断に使える短い原則」です。証拠や詳細は別の場所に置きます。
外部 context を memory に入れない設定を検討する
Codex memory settings には、外部 context を使った chat を memory generation から外すための memories.disable_on_external_context があります。対象には MCP tool calls、web search、tool search のような外部文脈が含まれます。
私は、組織利用では最初からこの設定を強めに検討します。
[features]
memories = true
[memories]
use_memories = true
generate_memories = true
disable_on_external_context = true
min_rate_limit_remaining_percent = 20理由は単純です。外部 tool で読んだ情報は、所有者、保持期限、再利用許可、機密度が揃っていないことが多いからです。
たとえば GitHub MCP で private issue を読み、Google Drive plugin で社内ドキュメントを読み、browser で外部 docs を見た chat から memory が作られると、どの source の情報をどの範囲で再利用してよいか曖昧になります。ChatGPT / Codex 側の data controls と、接続先 service の permission は別物です。
外部 context を使った run で得た学びを残したいなら、memory に自動保存させず、人間が次のように要約してから保存します。
OK: GitHub MCP write action は approval 付き lane に分ける。
NG: customer-a の private issue 123 では billing API が壊れていた。source 固有の詳細は issue、PR、audit log、catalog に置き、memory には一般化した判断だけを残します。
Chronicle は便利だが、最初は個人検証に留める
Chronicle は、画面上の最近の文脈から Codex memories を補強する desktop-only の opt-in research preview です。macOS の ChatGPT Pro 向けで、画面 capture を使うため、見えている情報が memory の材料になり得ます。OpenAI docs でも、秘密情報や同意のない会議・通信を記録しないこと、覚えさせたくない内容を見ているときは pause することが強調されています。
これはかなり強い機能ですが、組織 rollout では慎重に扱うべきです。
私なら、初期 rollout は次に限定します。
| 条件 | 判断 |
|---|---|
| 個人の local project 検証 | 可 |
| 顧客データや未公開売上資料が画面に出る業務 | 不可 |
| 会議やチャットを表示したままの利用 | 不可 |
| pair debugging の画面共有中 | 原則 pause |
| memory review の担当がいる team pilot | 条件付き |
Chronicle の screen captures は一時保存で、古い capture は削除される設計ですが、「一時保存なら安全」とは見ません。重要なのは、画面に何を出した状態で Codex に context を取らせるかです。
実務では、Chronicle を使う人向けに次の短いルールを置くだけでも事故率は下がります。
Chronicle rule:
- customer data、secrets、private chat、meeting を表示中は pause する
- memory に残す価値がある作業だけで使う
- 週次で generated memory を review する
- 画面から得た情報を team rule として扱わないchat-level controls を運用手順に入れる
Codex desktop app や Codex TUI / CLI では、/memories で現在の chat が既存 memory を使うか、将来 memory generation の input になるかを切り替えられます。これは細かい機能に見えますが、実務では重要です。
私は task の種類ごとに、memory の扱いを分けます。
| task | 既存 memory を使う | 将来 memory に使う |
|---|---|---|
| 通常の repo 実装 | 使う | 使う |
| 公開記事の定型 publish | 使う | 使う |
| 顧客ログ調査 | 原則使わない | 使わない |
| 秘密情報を含む incident 対応 | 使わない | 使わない |
| 外部 docs を読むだけの research | 使ってよい | 原則使わない |
| 一時的な workaround | 必要なら使う | 使わない |
大事なのは、「memory を使う」と「この chat を将来 memory の材料にする」を分けることです。既存の repo ルールを参照したいが、今回のログや調査内容は保存したくない、という task はよくあります。
automation prompt にも、この区別を書けます。
Use existing local memories for repo workflow conventions.
Do not turn this run's external tool results, customer data, or one-time approvals into future memories.
Return any reusable learning as a separate candidate for human review.memory は自動化ほど便利ですが、自動保存まで許すかは別判断です。
memory review を PR review と同じ扱いにする
local memories は生成状態なので、放置すると必ず古くなります。私は memory review を PR review より軽いが、完全に任意ではない作業として扱います。
最小の review 表はこれで足ります。
memory_review:
cadence: weekly
owner: developer-productivity
scope:
- "~/.codex/memories/"
checks:
- secret_or_token
- customer_or_personal_data
- stale_workflow
- duplicated_with_AGENTS_md
- one_time_exception
- external_context_without_source
action:
- keep
- shorten
- move_to_AGENTS_md
- move_to_docs
- delete特に見るべきなのは、AGENTS.md との重複です。同じ rule が AGENTS.md と memory の両方にあると、片方だけ更新されます。合意済み rule は AGENTS.md、作業から得た補助文脈は memory に寄せる。これを崩さない方が長く運用できます。
よくある失敗
1. memory を増やせば精度が上がると思う
memory が増えると、古い前提や関係ない好みも増えます。重要なのは量ではなく、次回の判断に効く短い情報だけを残すことです。
2. hard rule を memory に置く
「本番 DB に書かない」「secret を外部送信しない」は memory では弱いです。AGENTS.md、permission、approval、CI、MCP scope、plugin controls のような強い層へ置きます。
3. 外部 tool の結果をそのまま memory 化する
MCP、web search、tool search、browser、Computer Use で読んだ情報は source と permission が違います。一般化できない情報は memory に入れません。
4. Chronicle を常時 ON にする
画面 context は強力ですが、画面には task と無関係な情報も映ります。使うなら、覚えてよい画面だけを対象にします。
5. AGENTS.md の肥大化を memory でごまかす
AGENTS.md が大きすぎるなら、下位 AGENTS.md、skills、docs に分けるのが先です。memory は instruction の overflow 置き場ではありません。
導入チェックリスト
Codex memories を team で使う前に、最低限これだけ決めます。
- memory を有効にする対象 repo / user を決めたか
/memoriesの使い分けを task template に入れたかAGENTS.mdと memory の責務表を作ったかdisable_on_external_contextを使うか判断したか- Chronicle を許可する surface と禁止画面を決めたか
- secrets / PII / raw logs / one-time approval を保存禁止にしたか
- 週次または隔週の memory review owner を決めたか
- stale memory の削除手順を決めたか
この8項目を決めずに memory を広げると、最初は便利でも、数週間後に「なぜ Codex がその前提で動いたのか」を説明しにくくなります。
まとめ
Codex memories は、過去の作業から学べる便利な仕組みです。ただし、組織で使うなら「何でも覚える」ではなく、AGENTS.md、local memory、skill、session、audit log、plugin / MCP catalog の役割を分ける必要があります。
私なら、まず memory を小さく始めます。保存してよい情報を5種類に絞る。外部 context 由来の chat は原則 memory generation から外す。Chronicle は個人検証から始める。週次で generated memory を review する。
memory は、Codex を賢くするための補助文脈です。ルール、証跡、許可、秘密情報を背負わせない。これが、Codex memories を長く安全に使うための一番現実的な設計です。