CodexとClaude Codeのメモリー管理を徹底比較――保存場所・圧縮方法・メリット・デメリットまで実践解説

この記事の要点

Codexのローカルメモリーはデフォルトで~/.codex/memories/に保存され、過去チャットから有用な情報を自動抽出する。
Codexでは必須ルールをMemoryだけに保存せず、AGENTS.mdやGit管理された文書へ昇格させることが推奨されている。
Claude CodeのAuto memoryは~/.claude/projects/<project>/memory/に保存される。
Claude CodeはMEMORY.mdの先頭200行または25KBの小さい方までをセッション開始時に読み込む。
Claude CodeのAuto memoryは通常のMarkdownなので、人間が直接編集・削除・圧縮できる。
メモリー圧縮で重要なのはZIP圧縮ではなく、重複・一時情報・古い状態を除去する「意味圧縮」である。
メモリーには現在の本番状態を保存しすぎず、Git・DB・DevQA・Productionを現在状態の正本にする方が安全である。
大規模プロジェクトでは「絶対ルール」「実行手順」「経験メモリー」「現在状態」を別レイヤーに分離すると誤判断を減らせる。

1. なぜAIコーディングのメモリー管理が重要なのか

CodexやClaude Codeを数回使う程度なら、メモリー管理を深く考える必要はありません。

しかし同じプロジェクトを数か月触り続けると、

過去に直したバグ
独自のテスト方法
Worktreeの使い方
本番デプロイ手順
「このファイルは丸ごとコピー禁止」といった事故防止策
未デプロイの機能
過去の本番バージョン
過去のコミット
AIへのユーザー指示

などが蓄積します。

100件近いメモリーを持つようになると、今度は**「覚えていること」そのものがリスク**になります。

典型例は、

6月
未デプロイ

7月
本番デプロイ済み

8月
別ブランチで追加改修、こちらは未デプロイ

という状態です。

この3つが全部Memoryに残っていると、

この機能はデプロイ済みなのか？

という単純な質問ですら、Memoryだけでは答えられません。

そこで重要になるのが、

Memory = 現在の事実ではなく、再調査を速くするためのキャッシュ

という考え方です。

メモリー圧縮の最大のメリットは「トークン消費を抑えられること」

CodexやClaude Codeのメモリーを圧縮する最大の実務メリットの一つが、AIへ渡すコンテキスト量を減らし、トークン消費を抑えられることです。

AIコーディングでは、ソースコードだけがコンテキストを消費するわけではありません。

例えばClaude Codeでは、

システム指示
CLAUDE.md
.claude/rules/
Auto memory
読み込んだソースコード
Toolの実行結果
それまでの会話

などがコンテキストを使用します。

そのため、過去の作業履歴を大量に記録したMemoryを毎回読み込ませると、本来コード理解に使いたいコンテキストを過去情報が消費します。

例えば100行の知識を20行にできれば、その分だけ軽くなる

次のようなMemoryがあったとします。

2026-06-10に実装
commit abc123
テスト55件PASS
worktreeは...
デプロイ時に...
最初は失敗して...
修正1...
修正2...
再テスト...
HTTP200...

将来必要なのが、

productionとdev2で配置が異なる
丸ごとコピーは禁止
migrationはproduction leafを確認
HTTP200だけで完成判定しない

の4点だけなら、それ以外を毎回AIへ読ませる必要はありません。

つまりMemory圧縮とは単なる整理ではなく、

過去ログ 100
      ↓
再利用知識 20

へ変換することで、同じ判断材料をより少ないトークンでAIへ渡す最適化でもあります。

今回の圧縮でも大幅に情報量を削減した

今回、実際にCodex・Claude CodeのMemoryを整理したところ、多くの個別Memoryで50～90%程度の文字量を削減できました。

削除した中心は、

過去のcommit hash
一時worktree名
過去のテスト件数
当時のHTTP結果
重複したデプロイ手順
途中経過
後続修正ですでに無効になった古い状態

です。

逆に、

アーキテクチャ
正本となるファイル
事故原因
再発防止
未deploy
未push
未検証
ユーザーが指定した境界

は残しました。

このため、知識量そのものを失うというより、判断に必要な情報密度を上げています。

Claude Codeでは特に効果を理解しやすい

Claude CodeのAuto memoryでは、MEMORY.mdの先頭200行または25KBまでがセッション開始時に読み込まれ、その他のtopic memoryは必要になったときに読み込まれます。

したがってtopic memoryが、

10KB

から、

2KB

になれば、そのMemoryを参照するタスクではAIへ追加されるコンテキストも小さくできます。

特に、

MyRoom
SecOps
Diary
NoFake
Deployment

のように複数のMemoryを横断する大型タスクほど効果が期待できます。

コンテキストを空けるとコードへ使える余裕も増える

これは単なる料金の問題だけではありません。

コンテキストウィンドウには上限があります。

Memoryが大量の過去ログで埋まると、

Memory
Memory
Memory
過去ログ
過去ログ
過去ログ
ソースコード

となります。

圧縮後は、

重要Memory
ソースコード
関連ファイル
テスト結果

へ比重を移せます。

つまりMemory圧縮によって、

過去を読むためのトークンを減らし、現在のコードを理解するためのトークンを増やせる

という効果があります。

これは大規模リポジトリでは非常に重要です。

応答速度にも良い影響を与える可能性がある

入力コンテキストが小さくなれば、モデルが処理する入力tokenも減らせるため、条件によっては応答開始や処理時間にも良い影響を与える可能性があります。

ただし、

Memoryを70%削減
=
必ず応答速度70%改善

ではありません。

モデル、Prompt Cache、Tool呼び出し、読み込んだコード量などにも左右されます。

したがって記事では、

「改善する可能性が高い」「入力コンテキストを減らせる」

と表現するのが正確です。

API課金型ならコスト削減にも直結しやすい

入力トークンに応じて課金されるAPI型のAIでは、毎回渡す固定コンテキストを削減することは、そのまま入力tokenコスト削減につながります。

例えば毎回、

20,000 tokens

の固定Memoryを送っていたものを、

5,000 tokens

へ削減できれば、1回あたり15,000 tokens分の固定入力を減らせます。

100回実行すれば、

15,000 × 100
= 1,500,000 tokens

の差になります。

実際のCodexやClaude Codeの利用枠・Prompt Cache・内部処理は単純なAPI課金モデルと同じではありませんが、不要な固定コンテキストを削ることが効率向上につながるという原理は同じです。

ただし「圧縮率＝トークン削減率」ではない

ここは注意が必要です。

Memoryファイルを80%短くしたからといって、

総トークン使用量も80%減る

わけではありません。

総トークンには、

会話履歴
ソースコード
Tool結果
システムプロンプト
Memory
CLAUDE.md / AGENTS.md

などが含まれるからです。

正しい表現は、

Memory由来の入力コンテキストを削減でき、そのMemoryを参照するタスクほどトークン節約効果が大きくなる。

です。

メモリー圧縮は「節約」ではなくコンテキスト配分の最適化

最終的には、

不要な過去情報
        ↓ 削る

必要なルール・設計
        ↓ 残す

空いたコンテキスト
        ↓

現在のコード
テスト
ログ
本番状態

へ使えるようにすることが目的です。

そのため、Memory圧縮の最大の価値は単にファイルサイズが小さくなることではありません。

AIが現在の問題を考えるために使えるトークンを取り戻せること

にあります。

2. CodexのMemoryはどこに保存される？

OpenAIの現在の公式ドキュメントでは、ローカルCodexのホームディレクトリはデフォルトで、

~/.codex

です。

その中の主要Memoryは、

~/.codex/memories/

に保存されます。OpenAIはここに、過去のチャットから生成された要約、長期的に有用な情報、最近の入力、裏付けとなるEvidenceなどが保存されると説明しています。

Windowsなら通常、

C:\Users\<ユーザー名>\.codex\memories\

です。

PowerShellでは、

$HOME\.codex\memories

で参照できます。

Codexのユーザー設定ファイルは、

~/.codex/config.toml

です。プロジェクト単位ではリポジトリ内の、

.codex/config.toml

も利用できます。

3. Codex Memoryの中身を確認する

Windows PowerShellなら、まず次で一覧を取得できます。

Get-ChildItem $HOME\.codex\memories -Recurse -File |
    Select-Object FullName, Length, LastWriteTime

サイズ順で調べるなら、

Get-ChildItem $HOME\.codex\memories -Recurse -File |
    Sort-Object Length -Descending |
    Select-Object FullName, Length, LastWriteTime

Markdownだけ調べるなら、

Get-ChildItem $HOME\.codex\memories -Recurse -Filter "*.md" -File |
    Select-Object FullName, Length, LastWriteTime

Linux/macOSなら、

find ~/.codex/memories -type f -print

や、

du -ah ~/.codex/memories | sort -h

で確認できます。

ただし重要な注意があります。

OpenAIは~/.codex/memories/配下をgenerated stateとして扱うよう案内しており、手作業で編集することを主要な管理方法にはしないよう推奨しています。

つまり、

ファイルだから好きに編集してよい

というより、

内容の監査やトラブルシューティングはできるが、本当に守らせたい規則は別レイヤーへ移す

という思想です。

4. CodexではAGENTS.mdをどこに置く？

ここは非常に重要です。

OpenAIは、常に守る必要があるチームルールをMemoryだけに依存させず、AGENTS.mdやGit管理されたドキュメントへ置くことを明確に推奨しています。

グローバルなCodex指示は、

~/.codex/AGENTS.md

に置けます。

Windowsなら、

C:\Users\<ユーザー名>\.codex\AGENTS.md

です。

プロジェクト単位なら、

my-project/
├── AGENTS.md
├── src/
└── ...

のように置けます。

Codexはプロジェクトルートから現在の作業ディレクトリまで下りながらAGENTS.mdを探し、より近いディレクトリの指示を後ろへ連結します。グローバル側ではAGENTS.override.mdが存在すればそちらが優先されます。既定ではプロジェクト指示の読込量に32KiBの上限があります。

したがって、

AGENTS.md
    絶対ルール

Codex Memory
    過去の経験・発見・履歴

と分けるのが安全です。

5. Codex Memoryを有効化する設定

CodexのローカルMemoryは現在デフォルトOFFです。

設定ファイルで有効化するなら、

[features]
memories = true

を~/.codex/config.tomlへ追加します。

さらに細かく、

[memories]
generate_memories = true
use_memories = true

のような設定もあります。

現在の公式Config Referenceでは主に、

memories.generate_memories
memories.use_memories
memories.disable_on_external_context
memories.max_raw_memories_for_consolidation
memories.max_rollout_age_days
memories.max_rollouts_per_startup
memories.max_unused_days
memories.min_rate_limit_remaining_percent
memories.min_rollout_idle_hours
memories.extract_model
memories.consolidation_model

などが公開されています。

特に面白いのが、

memories.disable_on_external_context = true

です。

これを有効にすると、Web検索、MCP、tool searchなど外部コンテキストを使ったチャットをMemory生成対象から外せます。

一時的なWeb調査結果を長期Memoryへ大量混入させたくない場合に有効です。

6. Claude CodeのMemoryはどこに保存される？

Claude Codeには、

人間が書くCLAUDE.md
Claude自身が書くAuto memory

の2種類があります。

Auto memoryはプロジェクトごとに、

~/.claude/projects/<project>/memory/

へ保存されます。

公式ドキュメントでは、同じGitリポジトリに属するworktreeやサブディレクトリは同じAuto memoryディレクトリを共有します。

Windowsの~/.claudeは、

%USERPROFILE%\.claude

です。

したがって通常は、

C:\Users\<ユーザー名>\.claude\projects\<project>\memory\

になります。

典型的な構造は、

memory/
├── MEMORY.md
├── debugging.md
├── deployment.md
├── api-conventions.md
├── studyquest.md
├── secops.md
└── ...

です。

なお保存先はautoMemoryDirectory設定で変更できます。

7. Claude CodeのCLAUDE.mdはどこに置く？

Claude Codeは複数階層のCLAUDE.mdを使えます。

公式仕様では主に、

~/.claude/CLAUDE.md

ユーザー全体設定。

./CLAUDE.md

または、

./.claude/CLAUDE.md

プロジェクト設定。

./CLAUDE.local.md

個人用プロジェクト設定です。

Windowsの組織管理用ファイルは、

C:\Program Files\ClaudeCode\CLAUDE.md

です。

大規模プロジェクトなら、

.claude/
├── CLAUDE.md
└── rules/
    ├── testing.md
    ├── deployment.md
    ├── security.md
    ├── frontend.md
    └── backend.md

という構造にもできます。

.claude/rules/はpath指定による条件付き読込もできるため、巨大モノレポでは非常に便利です。

8. Claude Codeで現在読み込まれているMemoryを確認する

Claude Code内では、

/memory

を実行します。

Auto memoryのON/OFF、現在読み込まれているCLAUDE.md、rules、Auto memoryフォルダーなどを確認できます。

また、

/context

を利用すると、どのMemory/Instructionが現在のコンテキストへ入っているか確認できます。

Windows PowerShellから直接探すなら、

$ClaudeHome = if ($env:CLAUDE_CONFIG_DIR) {
    $env:CLAUDE_CONFIG_DIR
} else {
    Join-Path $HOME ".claude"
}

Get-ChildItem "$ClaudeHome\projects" -Recurse -File -ErrorAction SilentlyContinue |
Where-Object {
    $_.FullName -match '\\memory\\.*\.md$'
} |
Select-Object FullName, Length, LastWriteTime

サイズの大きいものから確認するなら、

Get-ChildItem "$ClaudeHome\projects" -Recurse -File -ErrorAction SilentlyContinue |
Where-Object {
    $_.FullName -match '\\memory\\.*\.md$'
} |
Sort-Object Length -Descending |
Select-Object FullName, Length, LastWriteTime

とします。

9. Claude CodeはMEMORY.mdを全部読むわけではない

Claude CodeのAuto memoryではここが特に重要です。

公式仕様では、

MEMORY.mdの先頭200行、または先頭25KBのどちらか早い方まで

がセッション開始時に読み込まれます。

それより後ろは起動時には入りません。

一方、

debugging.md
deployment.md
patterns.md

のようなtopic fileは起動時に全部読み込まず、必要になった際にClaudeが通常のファイルツールで読みます。

そのため、

MEMORY.md = 詳細本文

ではなく、

MEMORY.md = 重要ルール + 索引

にする方が合理的です。

私は運用上、安全マージンを持たせて、

120〜180行程度
20KB以下

を目安にするのが扱いやすいと考えています。

これはAnthropicの公式上限ではなく、200行/25KBへ近づきすぎないための運用上の目安です。

10. 「Memoryを圧縮する」とは何をすることか

ここでいう「圧縮」はZIP圧縮ではありません。

100KB → ZIPで20KB

にしてもAIが読む文章量は変わりません。

重要なのは意味圧縮です。

例えば元Memoryが、

2026-06-10
commit abc123
テスト55件PASS
本番HTTP200
migration0031
worktree xxx
その時点の本番HEAD yyyy
...

だったとします。

将来本当に必要なのが、

- この機能はserver-authoritative
- productionとdev2で配置が違う
- migrationはproduction leafから確認する
- HTTP200だけで完成判定しない

なら、こちらだけを残します。

これがSemantic Compressionです。

11. Memory圧縮の前に必ずバックアップする

Claude CodeはAuto memoryを直接編集してよいと公式に案内されていますが、圧縮前のバックアップは強く推奨します。

WindowsならClaude Code Memoryを、

Copy-Item `
    "$HOME\.claude\projects\<project>\memory" `
    "$HOME\Desktop\claude-memory-backup" `
    -Recurse

でコピーできます。

ZIPバックアップなら、

Compress-Archive `
    -Path "$HOME\.claude\projects\<project>\memory\*" `
    -DestinationPath "$HOME\Desktop\claude-memory-backup.zip"

Codexの場合は、

Copy-Item `
    "$HOME\.codex\memories" `
    "$HOME\Desktop\codex-memories-backup" `
    -Recurse

または、

Compress-Archive `
    -Path "$HOME\.codex\memories\*" `
    -DestinationPath "$HOME\Desktop\codex-memories-backup.zip"

です。

Codexについては公式がgenerated stateとして扱うよう案内しているため、原本を直接破壊的に編集するより、バックアップ→監査→必要情報をAGENTS.md等へ昇格という順序が安全です。

12. 実際のMemory圧縮手順

私は次の7段階が安全だと考えています。

STEP 1：ファイル一覧を取得する

まず、

ファイル名
サイズ
更新日時

を一覧化します。

大きいMemoryから順番に監査します。

STEP 2：内容を4種類に分類する

各文章を、

RULE
PROJECT
HISTORY
EPHEMERAL

へ分類します。

RULE

毎回守るもの。

例：

settings.pyを丸ごと本番へコピーしない
テスト依頼だけではdeployしない

これはMemoryよりAGENTS.mdやCLAUDE.mdへ昇格する候補です。

PROJECT

プロジェクト固有の再利用知識。

このAPIの正本
このアプリの配置
この機能の設計制約

これはMemoryへ残します。

HISTORY

過去の事故・調査記録。

以前pointer captureでbutton clickが死んだ
過去にmigration branchが衝突した

原因と再発防止だけ残します。

EPHEMERAL

一時情報です。

commit hash
当時のHTTP応答時間
テスト件数
当時のIP
一時worktree
現在では古いversion

通常は削除、または「過去時点」と明記します。

13. 一番削るべきものは「成功ログ」

大量Memoryで意外に容量を使うのが、

48 tests PASS
HTTP200
commit abcdef
deploy success
migration OK

です。

これらは当時の証拠としては重要ですが、3か月後のAI判断には使いにくい情報です。

将来必要なのは、

検証方法:
- exact route
- persistence
- static identity
- browser E2E

という検証の型です。

つまり、

結果を保存する

より、

次回も再現できる検証方法を保存する

方がMemoryとして価値があります。

14. 圧縮してはいけない情報

一方で削ってはいけない情報もあります。

特に、

未デプロイ
未push
未検証
partial
blocked
ユーザー承認待ち

です。

例えば、

42 tests PASS

だけ残して、

まだ本番には出していない

を消すと危険です。

AIが次回、

これは完成済みです

と誤認する可能性があります。

そこで私はMemoryへ状態を付ける方法を使います。

---
name: example-feature
type: project
status: undeployed_at_capture
---

これはCodex/Claude Codeの公式必須フォーマットではなく、人間とAIが状態を誤認しにくくするための運用上の規約です。

候補は、

deployed
undeployed_at_capture
unpushed_at_capture
partial
handover_unverified
ambiguous_recheck
historical
rule

程度で十分です。

15. 矛盾したMemoryは勝手に統合しない

例えば同じMemoryに、

本番デプロイ済み

と、

未デプロイ

が両方書かれていることがあります。

これはAIが勝手に、

新しい方が正しいだろう

と解決すべきではありません。

圧縮時には、

status: ambiguous_recheck

として、

Git history
migration
live route
DevQA
production DB

を確認するまで断定しないようにします。

これが長期運用では非常に重要です。

16. Claude Code向けの理想的なMEMORY.md

大量Memoryを持つなら、

MEMORY.md
├── MUST
├── RECHECK FIRST
├── Memory routing index
└── Supersession policy

という構造が扱いやすいです。

例：

# MEMORY.md

## MUST

- テスト依頼はdeploy許可ではない
- Production HTTP200だけで完成判定しない
- 現在状態はGit/DB/Productionで再確認する

## RECHECK FIRST

- feature-a.md — unpushed
- feature-b.md — ambiguous
- security-c.md — host patch status要再確認

## Memory routing

### Deployment
- deploy-method.md
- worktree-trap.md

### Security
- ips.md
- cve-response.md

### StudyQuest
- town.md
- dungeon.md

これなら最初の200行以内に、

何を守り、どこを読めばいいか

が収まります。

Claude Codeの200行/25KBという読込仕様と非常に相性が良い構成です。

17. Claude Codeのtopic memoryを圧縮する方法

例えば元Memoryが50行ある場合、

実装経緯
commit
テスト
worktree
トラブル
デバッグ
修正
再テスト
デプロイ

を全部残すのではなく、

---
name: studyroom-3d
type: project
status: deployed
---

# StudyRoom 3D

- Slides本文はHTTP、index同期だけWS。
- 大payloadをChannels group_sendへ乗せない。
- pointer captureはbutton/select上では開始しない。
- HTML cacheとasset cache-bustを両方確認する。
- migrationはproduction leafを正本にする。

のようにします。

重要なのは、

何をしたかではなく、次回何を知っていれば事故を防げるか

です。

18. 半自動でAIに圧縮させるプロンプト例

大量MemoryならAI自身に意味圧縮を依頼できます。

例えば次のようにします。

次のAI Auto Memoryを意味圧縮してください。

目的:
将来のセッションで再利用価値のある情報だけ残す。

必ず保持:
- 恒久的なアーキテクチャ
- ユーザーが明示した境界
- 再発防止策
- 未完了状態
- deploy/push未実施状態
- 特殊なテスト方法
- 正本となるファイル/ディレクトリの違い

原則削除:
- 一回限りのcommit hash
- 一時worktree名
- 過去のテスト件数
- 一時的なHTTP応答値
- 一時的なIP/メトリクス
- 重複する手順
- 別Memoryにもある共通ルール

禁止:
- 現在状態を推測しない
- 矛盾を勝手に解決しない
- 未デプロイをデプロイ済みにしない
- 秘密情報を残さない

矛盾時:
status: ambiguous_recheck

ファイル名は変更しない。

この形式ならかなり安全に圧縮できます。

19. CodexとClaude Codeでは圧縮戦略を変える

Codex

CodexのMemoryはOpenAIがgenerated stateとして位置付けています。

したがって優先順位は、

1. バックアップ
2. Memoryを監査
3. 絶対ルールをAGENTS.mdへ移動
4. secrets/古い一時情報を確認
5. 必要に応じてgenerated memoryを整理

です。

手動Memory編集をシステム設計の中心には置きません。

Claude Code

Claude CodeのAuto memoryは通常のMarkdownで、人間が直接編集・削除してよいと公式に説明されています。

そのため、

1. MEMORY.mdを索引化
2. topicごとに個別memory
3. 重複削除
4. status追加
5. 古い状態をhistorical/recheck化
6. 絶対ルールをCLAUDE.md/rulesへ昇格

という積極的な整理が可能です。

20. CodexとClaude Codeの比較

項目	Codex	Claude Code
Memory保存先	`~/.codex/memories/`	`~/.claude/projects/<project>/memory/`
Windows	`%USERPROFILE%\.codex\memories\`	`%USERPROFILE%\.claude\projects\...\memory\`
人間の恒久指示	`AGENTS.md`	`CLAUDE.md`
詳細ルール	nested AGENTS / Rules	`.claude/rules/*.md`
Auto memory	あり	あり
Memory初期設定	OFF	ON
Memory手動編集	generated state。主制御手段には非推奨	Markdownを直接編集・削除可能
Worktree	Codex hostのlocal memory	同一Git repoでmemory共有
起動時Memory制限	内部統合方式	MEMORY.md先頭200行または25KB
圧縮のしやすさ	中程度	高い
人間による監査性	中程度	高い
自動管理の楽さ	高い	高い
大量Memoryの手動整理	やや不向き	非常に向く

CodexのMemoryはデフォルトOFF、Claude Code Auto memoryはデフォルトONです。

21. 私なら最終的にこう分ける

CodexとClaude Codeを同じプロジェクトで使うなら、

Git repository
│
├── AGENTS.md
│     Codexも含めた共通の絶対ルール
│
├── CLAUDE.md
│     @AGENTS.md
│     Claude Code固有の補足
│
├── .claude/
│   ├── rules/
│   │   ├── security.md
│   │   ├── testing.md
│   │   └── deployment.md
│   └── skills/
│
├── docs/
│   └── architecture/
│       人間向け正本
│
└── Source code

そしてローカル側は、

~/.codex/memories/
    CodexのRecall Layer

~/.claude/projects/<project>/memory/
    Claudeの経験・索引

とします。

Claude Code公式も、既にAGENTS.mdを使っているリポジトリなら、

@AGENTS.md

をCLAUDE.mdからimportして共通化する方法を案内しています。Windowsではsymlinkよりimport方式が扱いやすいと説明されています。

22. 最も重要なのは「Memoryを現在状態のDBにしない」こと

最終的な優先順位は、

現在のユーザー指示
        ↓
AGENTS.md / CLAUDE.md
        ↓
現在のGit
現在のDevQA
現在のDB
現在のProduction
        ↓
Memory
        ↓
過去ログ

にします。

Memoryに、

本番はDjango X.Y

と書いてあっても、現在は違う可能性があります。

Memoryに、

未デプロイ

と書いてあっても、別のAIが翌日にデプロイしたかもしれません。

したがってMemoryの理想的な役割は、

前にここで問題があったので、この場所を確認してください。

までです。

23. 結論

Codexは、

「人間が細かく管理しなくても、過去の経験を自動的に再利用してくれる」

点が強みです。

一方でMemoryはgenerated stateなので、人間が巨大なKnowledge Baseとして細かく編集・構築する設計にはClaude Codeほど向きません。

Claude Codeは、

「Auto memoryを人間が普通のMarkdownとして監査・圧縮・分類できる」

点が大きな強みです。

ただし自由に編集できるため、100ファイルを放置すれば100ファイル分の古い情報も残ります。

そこで重要になるのが意味圧縮です。

削る:
commit
一時値
重複
古いmetrics

残す:
設計
境界
事故原因
再発防止
未完了状態
正本の場所
検証方法

という基準で整理します。

そして、

Memoryは「覚えておくためのデータベース」ではなく、「次に何を確認すべきかを教える索引」として使う。

これが、CodexやClaude Codeを長期間・大規模プロジェクトで使う場合の安全なMemory管理方法です。

参考情報

OpenAI / Codex

Memories

CodexのMemoryの仕組み、保存場所、/memories、generated state、設定項目などの公式説明。

https://developers.openai.com/codex/memories

AGENTS.md

Codexに恒久的なプロジェクト指示を与えるAGENTS.mdの探索順序、グローバル/プロジェクト階層、サイズ上限など。

https://learn.chatgpt.com/docs/agent-configuration/agents-md

Codex Config basics

~/.codex/config.toml、.codex/config.toml、設定優先順位など。

https://learn.chatgpt.com/docs/config-file/config-basic

Codex Configuration Reference

memories.generate_memories、memories.use_memories、memories.disable_on_external_contextなどの詳細。

https://learn.chatgpt.com/codex/config-file/config-reference

Anthropic / Claude Code

How Claude remembers your project

CLAUDE.mdとAuto memory、保存場所、200行/25KB制限、/memory、rulesなど。

https://code.claude.com/docs/en/memory

Explore the .claude directory

Windowsの~/.claude、settings、rules、skills、Auto memory、session dataなどの配置。

https://code.claude.com/docs/en/claude-directory

Claude Code documentation index

Claude Code公式ドキュメント全体をAIや検索ツールから参照するときのインデックス。

https://code.claude.com/docs/llms.txt

参考リンクを読む際の注意

Codex・Claude Codeとも更新速度が速いため、この記事に掲載したフォルダー構成や設定項目は将来変更される可能性があります。

特に、

MemoryのデフォルトON/OFF
設定キー
読込上限
CLIコマンド
保存場所

については、実際に設定を変更する直前に上記公式ドキュメントを再確認してください。