CodexとClaude Codeのメモリはどう違う？保存・読み込み・設定の仕組み

AIアシスタントとの過去のやり取りやプロジェクトの文脈を記憶し、次回の作業へ引き継ぐメモリ機能は非常に強力な補助となります。しかし、CodexとClaude Codeでは、どのタイミングで情報をファイルへ保存し、次回の会話でどのように読み込んで作業へ作用させるのかという独自の仕組みがそれぞれ異なります。また、会話の中で自動的に蓄積されていくメモリと、人間が明示的にルールを定める指示ファイルを適切に使い分けることが、期待通りの成果を安定して得るための鍵となります。本記事では、両ツールの自動メモリが保存と読み込みの経路でどう違うのかをファイル構成から整理し、記憶機能と規約の仕組みを区別して活用する手順を解説します。

Codexはどの会話を、いつ記憶に残すのか

Codexのローカルメモリ機能は、デフォルトでは無効に設定されているため利用者が設定などから明示的に有効化する必要があります。公式のドキュメントによれば、機能が有効であっても、会話が終わるたびにすべての情報が即座に記録されるわけではありません。まず、現在進行中の会話や一時的な短いやり取り、またサブエージェントとして実行された会話などは記憶の対象から除外されます。それ以外の条件を満たした過去の会話が終了し、その対象の会話が十分に待機状態(idle)になったことを契機として、背景で処理が開始されます。ただし、システムの利用枠の残量が一定のしきい値を下回っている場合には、この背景処理自体がスキップされる仕組みです。

記憶を生成する処理は、大きく情報の抽出と統合の2段階に分かれています。オープンソースとして公開されているメモリ機能の実装説明によれば、ルートセッションの開始をきっかけとしてパイプラインが動き出します。第一段階では対象となる過去の会話から文脈や重要な情報を抽出してデータベースへ保存し、第二段階でそれらを一つの記憶体系として統合します。

v1実装の代表的なファイル構成

統合された記憶データは、ユーザーのローカル環境にある~/.codex/memories/ディレクトリへ保存されます。公開されたソースコードにはv1形式とv2形式の両方が存在しており、利用環境やバージョンによって構成は異なります。ここではv1形式における代表的なディレクトリツリーの例を示します。以下はすべてのファイルが常に揃っているわけではなく、生成される記憶の構成の一例です。

~/.codex/memories/
├── memory_summary.md
├── MEMORY.md
├── raw_memories.md
├── rollout_summaries/
│   ├── 00042_database_migration.md
│   └── 00043_api_error_fix.md
└── skills/
    └── csv-parser/
        └── SKILL.md

これらのファイルはそれぞれ役割が異なります。memory_summary.mdは起動時にまず読み込まれる全体要約であり、MEMORY.mdは詳細な知識を探すためのインデックスとして機能します。raw_memories.mdは一時的な統合入力データ、rollout_summariesフォルダ配下の各ファイルは会話ごとの詳細な要約です。skillsフォルダには任意の再利用可能な手順が格納されます。

ファイルに記録される内容の架空例

AIが記憶を作成する際、過去の会話の実行ログや巨大な出力結果をそのまま丸写しするわけではありません。v1の記憶統合に向けた指示に基づいて、情報は根拠のある反復知識として蒸留されます。

たとえば、起動時に読み込まれるmemory_summary.mdには、ユーザーの好みや全体的なヒント、そしてどのようなプロジェクトがメモリに含まれているかという案内が記されます。説明のための架空の例として、以下のような内容が記述されます。

v1

## User preferences
- 常にPython 3.11以上の型ヒントを使用する。

## What's in Memory
- Project: DataImporter
  CSVのパース処理とエラーハンドリングに関する記憶。検索用語: "csv", "encoding"

より詳細なMEMORY.mdには、関連する会話の要約ファイルへのパスや過去の失敗から得た教訓が記載されます。これも架空の抜粋例を示します。

# Task Group: CSV Data Processing

- Scope: DataImporterプロジェクトにおける文字コード対応
- Task: ユーザーから提供されるShift-JISのCSVを読み込む処理の実装
- rollout_summary_files: rollout_summaries/00042_database_migration.md
- keywords: csv, encoding, shift-jis, error
- Failures and how to do differently:
  標準のUTF-8で読み込もうとしてUnicodeDecodeErrorが発生した。次回からはファイルを開く前にエンコーディングを判定するか、明示的にShift-JISを指定する。

このように、過去のエラーそのものの長いログを保存するのではなく、次回どう違ったアプローチをするかという再利用可能な知識に変換して記録しています。

記憶を検索して作業へ反映する経路

保存された記憶が次回の会話でどのように読まれるかについても、モデルへの指示が実装されています。v1の記憶を読み込む経路では、新しい会話が起動した際、全体の概要であるmemory_summary.mdは最初からシステムへ渡された状態になります。

ユーザーが新しく質問をすると、モデルは入力内容に関連するプロジェクト名やキーワードを手掛かりに、MEMORY.mdのテキストを文字列検索します。検索によって関連しそうなトピックが見つかると、そこが指し示している個別の要約ファイルを1件から2件ほど選択して読み込みます。モデルは過去の全履歴を最初からすべて読むようなことはせず、文字列検索で参照先を絞り込み、必要性が高い場合のみ元の証拠となる会話要約を確認します。

また、記憶を読んだからといって無条件にその情報が作業へ反映されるわけではありません。ファイルのパスやコードの実装状況など、過去の会話時点から現在までに状況が変わっている可能性がある事項については、メモリの内容だけを頼りにせず、実ファイルなどを調べて再確認するようモデルへ指示されています。記憶から情報を得ることと、それを現在の指示に採用して正しい出力を生成することは、それぞれ別の段階として処理されます。

v2実装による記憶構造の簡素化

公開されている同じコミットのソースコードにはv2の統合指示も含まれており、v1とは異なる簡素化された経路が用意されています。公開コードのバージョンと実際の端末リリースは異なるため、常に複雑なv1ツリーを全端末が生成すると断定することはできません。

第一段階の出力を処理する内部実装の裏付けを見ると、v1では生の記憶データを含む複数の情報が出力されていましたが、v2では生の記憶データをデコードせず、会話の要約とその識別子のみを利用する仕組みに変わっています。

v2の統合フェーズでは、提供された会話の要約から直接memory_summary.mdを更新します。ユーザーの好みや各要約への直接のポインタを一つのファイル内にまとめ、全体のファイルサイズを10,000 UTF-8バイトよりも十分に小さく保つように指示されています。これにより中間インデックスや個別のスキルファイルを探索する手間が省かれ、概要ファイルから必要な要約だけを直接参照して読む動きとなります。

手動制御と必須規約の分離

Codexのメモリはバックグラウンドで自動的に生成や更新が行われる状態ファイルであるため、ユーザー自身がエディタでファイルを直接書き換えることは主な制御方法として想定されていません。会話の記憶をどのように扱うかは、専用のコマンドを通じて行います。

/memoriesコマンドを使うと、現在の会話において過去の記憶を利用するかどうか、また現在の会話内容を将来の記憶生成へ提供するかどうかを別々に制御できます。これにより、一時的なテストコードの作成など、将来の生成データに混入させたくないやり取りを個別に除外することが可能です。

最後に、自動的に蓄積されるメモリは過去の文脈を再利用するための強力な機能ですが、公開コードがモデルへ与える指示がすべての依頼で必ず機械的に実行されるアルゴリズムとは限りません。検索手順や条件によって常に完璧な情報を想起し、確実に読み込むことは保証されません。そのため、プロジェクト内で絶対に守らなければならない規約については、メモリ機能に依存するべきではありません。必ず読み込んでほしいルールは、AGENTS.mdという必須規約の仕組みなどを通じて明示的に指定する必要があります。自動的な記憶と明示的な指示ファイルを使い分けることで、期待通りの成果を得やすくなります。

Claude Codeは会話中に何を覚え、次回どう読むのか

Claude Codeにおけるメモリ機能は、Codexのように対象の会話が終了して待機状態に入ってから一括でバックグラウンド処理されるのではなく、会話の進行中に必要に応じて読み書きが行われるという大きな特徴があります。公式ドキュメントによると、通常のローカル環境で起動されたセッションでは、自動メモリ機能があらかじめ有効に設定されています。アシスタントは現在のやり取りが将来の作業において有益であるかどうかを動的に判断し、必要と認めた場合にのみ情報を保存します。

会話中での自動記録と保存される4つの分類

アシスタントは会話の履歴を毎回無条件に記録するわけではなく、保存する情報を主に4つの種類に分類して整理します。

1つ目は利用者に関する情報であるuserです。ここには利用者が担っている役割や専門とする技術分野、あるいはコードを書く際の全体的な好みなどが分類されます。 2つ目はアシスタントの対応に対するfeedbackです。会話の中でアシスタントが提示したコードに対して、利用者が訂正を求めたり、逆にその対応で正しいと確認したりした結果の学びが対象となります。 3つ目はプロジェクトの文脈を示すprojectです。ソースコードの現状やバージョン管理システムを直接見ても読み取れないような、作業の背後にある進行状況や設計上の決定事項が残されます。 4つ目は外部情報を参照するためのreferenceです。イシュートラッカーの特定の課題や、確認すべきダッシュボードなど、作業に関連する外部の参照先URLなどが該当します。

一方で、ソースコードそのものやリポジトリの履歴からファイル検索ツール等を用いて容易に再取得できるファイル構造やパス、一時的なデバッグのための修正履歴は記憶の対象から意図的に外されます。また、プロジェクト全体へ常時適用する明示的な指示ファイルであるCLAUDE.mdにすでに記載されている内容についても、記憶へ重複して保存しない方針が取られています。これらは、限られた文脈の枠を無駄に消費しないための仕組みです。

フォルダ構成とインデックス、トピックファイルの役割

保存された記憶データは、作業中のパソコン内にある~/.claude/projects/<project>/memory/というディレクトリ配下にテキストファイルの形式で格納されます。このファイル群はリポジトリごとに紐づいて管理されるため、同じリポジトリであれば別のワークツリーやサブディレクトリから開いた場合でも情報が共有されます。ただし、これらはあくまで現在作業しているマシンのローカル環境内に留まり、別のパソコンやクラウド環境には自動で共有されません。

フォルダの内部は、全体の目次となる索引ファイルと、個別の詳細な情報を持つトピックファイルに分かれています。 索引の役割を持つMEMORY.mdには、1つの記憶に対して1行のマークダウン形式のリンクが記載されます。そこから参照されるトピックファイルは、情報の分類ごとにuser_role.mdやfeedback_testing.mdといった名前で個別のファイルとして作成されます。

トピックファイルの先頭には、YAML形式で分類や説明などを記述する設定ブロックを付けられます。Claude Codeが先頭に設定ブロックのあるファイルへ情報を書き込む際には、ファイルの最終更新を示すためにISO8601形式の時刻情報が付けられます。この挙動はバージョン2.1.214以降で導入されました。公式の実装例では分類を示すtypeなどが指定されますが、特定の設定名や説明文が必須の構成要素として常に固定されていると断定するものではありません。

記憶ファイルの実例と適用場面

ここで、自動メモリがどのような形で記憶を残すのかを理解するための架空の例を紹介します。以下のファイル本文ややり取りは、実ユーザーの個人メモリを転載したものではなく、仕組みを説明するための説明用架空例です。

たとえば、過去の会話でCSVファイルを読み書きする際に「取引先コードである00042という値は、数値として扱うと先頭のゼロが消えてしまうため、文字列として保持しなければならない」というやり取りがあったとします。

このとき、索引であるMEMORY.mdには以下のように1行の簡潔なリンクが追加されます。

- [取引先コードの扱い](feedback_customer_code.md)

そして、リンク先となるfeedback_customer_code.mdのトピックファイルには、以下のような内容が書き込まれます。

---
type: feedback
modified: "2023-11-20T14:30:00Z"
---
取引先コードは数値でなく文字列として扱う。
00042のような先頭のゼロを残すため。理由は計算値ではなくシステム間の識別子であるため。
次回のCSV読み書き時に元の値と比較する際に注意する。

ここで重要なのは、アシスタントが過去の実行ログや文字列表現をそのまま丸暗記するわけではないという点です。ファイルの先頭にある分類情報と、本文に書かれた学びや適用場面を組み合わせて情報を保持します。そのため、次回以降の会話で「00042」という同じ単語が偶然登場したからといって、文脈を無視して無条件にこのルールが適用されるわけではなく、CSVの読み書きという関連する状況に合致したときに参照されるようになります。

次回の会話への読み込み経路と会話圧縮の違い

保存された記憶が次回の起動時にどのように読み込まれ、実際の作業へ作用するのかについても独自の経路が設定されています。

新しくClaude Codeを起動した際、システムはまず索引であるMEMORY.mdの先頭200行、またはファイルサイズが25キロバイトに到達する部分までのどちらか早い方までを読み込みます。このとき、フォルダ内にあるすべてのトピックファイルを最初から全件読み込むわけではありません。会話を進める中で、索引の内容から詳細な情報が必要だとアシスタントが判断した場合にのみ、ファイル読み込みのツールを使用して該当のトピックファイルの本文を追加で取得します。

現在の文脈を構成する仕組みとして、起動時には指示ファイルや自動メモリの索引、利用できる手順の説明などが文脈に載り、そこから必要に応じて読んだファイルの本文が追加されていくことになります。これはAIモデル自体の重みを追加で学習しているわけではなく、保存されたテキストデータを入力の文脈へ戻している状態です。

また、同じ会話が長くなった際に実行できる/compactというコマンドは、現在の会話を圧縮して文脈を整理するものであり、将来の会話に向けた永続的なメモリを作成する自動メモリの機能とは全く異なります。

会話中に過去の情報を記録したり読み出したりすると、画面上には保存や呼び出しを示す表示が出ます。会話中に/memoryコマンドを実行することで、ファイルの閲覧や直接の編集、そして自動メモリ機能のオン・オフの切り替えが可能です。さらに、起動時にどの指示ファイルが読み込まれたかは/contextコマンドを実行することで確認できますが、これはあくまで構成要素の確認であり、トピックファイル全件を読んだ証明ではありません。そして、画面上でファイルの読み書きが成功したことと、アシスタントがその記憶を現在の課題の指示として実際に採用したこと、さらには最終的な出力が正しく動くコードであることは、それぞれ別の段階として切り離して考える必要があります。

自動メモリと指示ファイルをどう使い分けるか

自動的に蓄積されるメモリ機能は、過去の文脈を復元するための強力な補助機能です。しかし、いつ、どの記憶が検索されて適用されるかを正確に予測することは困難です。そのため、プロジェクト内で常に守るべきコーディング規約や、特定の作業に対して確実に行わせたい手順については、自動メモリに依存するのではなく、明示的な指示ファイルやスキルという仕組みを利用して使い分ける必要があります。

Codexにおける階層的な指示の連結とスキルの配置

Codexでは、自動生成されるメモリ群とは別に、チーム全体で共有すべき規約を人間が直接定義する仕組みが用意されています。具体的には、プロジェクトの規約をファイルに記載して配置することで、新しく起動した時に一度だけ構築される指示の連鎖として読み込まれます。

この指示ファイルは、AGENTS.mdという名前で作成します。設定は階層的に適用されるようになっており、プロジェクトのルートディレクトリから、現在作業しているカレントディレクトリに向かって各ディレクトリのAGENTS.mdが順番に連結されていきます。より現在作業している場所に近いディレクトリにある指示が後から追加されるため、優先的に扱われます。また、これらのリポジトリ設定とは別に、ユーザーの端末全体に適用されるグローバルな設定があり、これは~/.codexにあるファイルで上書きすることが可能です。

なお、指示チェーンとして読み込めるファイル容量にはproject_doc_max_bytesという制限があり、既定では32KiBに設定されています。これは前節で解説したメモリインデックスの200行制限とは全く別の仕組みです。再起動したり新しい実行を開始したりするたびに、この指示チェーンは再構築されます。

さらに、一連のまとまった作業手順を登録する専用のスキル機能もあります。リポジトリ側に共有手順として配置する場合、.agents/skills/<name>/SKILL.mdというパスに保存します。このファイル内には、スキルの名前と説明文のほか、実際の手順本文や実行に必要なスクリプト、参照リソースが記載されます。これは、自動メモリ機能が過去の会話から記憶を統合してmemories/skills配下へ作成する手順候補のファイルとは管理範囲が明確に分かれており、チームで確実に適用したい手順はこちらのリポジトリ側のスキル機能に預けることになります。

Claude Codeにおける全体指示と条件付きルールの分離

Claude Codeでも同様に、常に適用したいプロジェクト全体の指示と、状況に応じて必要な手順を明確に切り分ける仕組みがあります。

リポジトリ全体に適用する常設の指示は、CLAUDE.mdまたは.claude/CLAUDE.mdというファイルに記述します。サブディレクトリごとに個別のCLAUDE.mdを置くこともでき、そのディレクトリで作業が必要になったときに読み込まれます。指示ファイル内で利用できる@ファイルパスという記法は、起動時に外部ファイルの中身をその場へ展開して読み込ませるものであり、限られた文脈の枠そのものを節約する仕組みではないことに注意が必要です。

全体指示とは別に、特定のファイル形式や特定のパスを操作するときにだけ読み込ませたい規約は、ファイルのパスで対象を限定したルールとして分離します。ルールファイルは.claude/rules/ディレクトリの直下にマークダウン形式で配置します。

ここで、前節の架空例で扱ったCSVの読み書きに関するルールを、自動メモリではなく明示的なルールファイルとして作成する例を示します。以下はデータディレクトリ配下のCSVファイルに対して読み込み、書き込み、編集などの操作が行われる場合にのみ文脈へ追加される説明用架空例です。

---
paths: ["data/**/*.csv"]
---
取引先コードは数値ではなく文字列として扱う。
00042のような先頭のゼロを欠落させないため。
計算対象ではなくシステム間の識別子であるため、必ず元の値のまま保持すること。

ファイルの先頭にフロントマターと呼ばれる形式でpathsの配列を指定することで、条件に合致するファイルをアシスタントが操作したときにこのルールが読み込まれます。常設のCLAUDE.mdにすべての規約を詰め込むのではなく、このように対象を限定して分離することで、関係のない作業をしているときの文脈をきれいに保つことができます。

また、まとまった作業手順を任意のタイミングで呼び出すためのスキル機能の保存先は、.claude/skills/<name>/SKILL.mdという構成になります。アシスタントが自身の判断で説明文から適切なスキルを選択して実行することもあれば、利用者が会話の中で/skill-nameと入力して明示的に呼び出すことも可能です。スキルの自動生成手順や、外部の操作と連動するフックの実装については、すでに別記事の「会話からルールやスキルを自動生成するには？」で解説しているため、ここでは設定ファイルの保存先と使い分けのみを扱います。

読み込みの確認と作用する段階の区別

これらの指示ファイルやルール、スキルを配置したあとは、新しい会話を開始して期待通りに動作するかを確認します。たとえば先ほどのCSVに関する架空例であれば、新しい実行環境で00042という値を含む架空のデータを渡して出力を照合し、先頭のゼロが消えていないかテストします。

このとき、ファイルがどのように読み込まれ、結果に結びつくかを3つの段階に分けて捉えることが重要です。

第1段階は、ファイルが読み込まれて文脈を構成した状態です。指示ファイルに書かれた内容はあくまで入力の一部としての文脈であり、システムの設定値を変更して動作を縛るような強制実行の設定ではありません。

第2段階は、AIモデルがその文脈の中から指示を作業方針として実際に採用した状態です。ルールが文脈に入っていても、他の強い指示と矛盾している場合や、関連性が薄いと判断された場合は採用されないことがあります。

第3段階は、採用した方針に基づいて生成された最終的な出力が正しく動く状態です。

画面上のメッセージでファイルの読み込みが確認できたとしても、それは第1段階を通過したことに過ぎません。自動メモリに頼らず明示的な指示ファイルを用いる最大の利点は、AIモデルへ与える第1段階の文脈を人間が直接管理し、第2段階で参照する規約を明確にできる点にあります。常設の規約と必要時のみ読み込まれる手順を正しく配置することが、期待する出力を安定して得るための前提条件となります。

会話からルールやスキルを自動生成するには？CodexとClaude Codeで残す手順

よくある質問

別のPCで作業するとき、Claude Codeのメモリは引き継がれますか

標準機能では引き継がれません。メモリの保存先は現在作業しているマシンのローカル環境に限られるため、クラウドや別のPC間で自動共有される仕組みではありません。同一マシンの環境内であれば、同じリポジトリの別のワークツリー間で共有されます。複数の開発環境で確実に共有したい重要な規約や手順は、自動メモリに頼らずリポジトリへコミットできるCLAUDE.mdなどの明示的な指示ファイルへ直接記載してください。

Codexのメモリファイルを手動で直接書き換えることはできますか

Codexのローカルメモリは、人間がファイルを手動で編集することを主な制御方法として設計されていません。特定の一時的なやり取りを将来の記憶生成から除外したい場合や、現在の作業において過去の記憶を利用したくない場合は、会話中に/memoriesコマンドを実行します。このコマンドを使用することで、記憶の利用と将来の生成への提供をそれぞれ別々に切り替えて制御することができます。

Claude Codeで記憶が正しく読み込まれたか確認する方法はありますか

会話中に/contextコマンドを実行することで確認できます。この一覧を見ることで、起動時の文脈へ記憶の構成要素が追加されたかを把握できます。ただし、画面上で確認できるのはあくまで第1段階の文脈に載ったという事実だけであり、詳細なトピックファイルを全件読み込んだ証明ではありません。さらに、AIモデルがその記憶の内容を作業方針として実際に採用したことや、最終的な出力が正しく動作することは、それぞれ切り離された別の段階となります。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/