Codexがプロジェクトのコンテキストを忘れる理由と、その解決策（2026年）

現在のCodexにおけるコンテキストの処理方法

Codexは、ファイルの読み込み、依存関係の追跡、コンテキストウィンドウ内でのコードベースの動作モデルの構築といった「探索」からセッションを開始します。このモデルはセッション状態（ステート）です。会話が進むにつれて、古いコンテンツはスペースを確保するためにコンパクション（要約および破棄）されます。この理解はどこにも保存されず、セッションが終了するかウィンドウが埋まると消滅し、次のタスクでは再び探索からやり直すことになります。

定着しない技術的な理由

コンパクションは設計上、情報の損失を伴うものであり、開発者が重要だと考えるものを考慮しません。CodexリポジトリのGitHub Issueでは、タスクの途中でコンパクションによってAGENTS.mdのルールが破棄され、エージェントが従っていた要件を見失ったために、報告された進捗が97%から42%に逆戻りした事例が報告されています。また、セッションの途中でモデルを切り替えた際にコンテキストが失われるという報告もあります。さらに、デフォルトの入力ウィンドウが約4分の1削減されたことで、これらのコンパクションは以前よりもタスクの早い段階で発生するようになりました。AGENTS.mdは起動時に読み込まれるため役立ちますが、手動で管理する静的なファイルであり、他のコンテンツと同様にアクティブなウィンドウからコンパクションによって押し出される可能性があります。

これによるコストと損失

すべてのセッションは、アーキテクチャ、主要なファイル、依存関係、すでに下した決定事項などの「再発見」から始まります。開発者たちはOpenAIのフォーラムでまさにこの問題を説明し、大規模なコードベースにおいてCodexのセッション間でプロジェクトのコンテキストを維持する方法を尋ねています。さらに、タスク途中の失敗モードもあります。進捗80%の時点で要件を忘れてしまったエージェントは、一行ずつレビューしなければならない成果物を出力します。ウィンドウが小さくなったことで、この問題が発生する可能性は低くなるどころか、むしろ高まっています。

AGENTS.md

規約、コマンド、制約などの安定した指示を記述するには最適な場所です。しかし、2つの限界があります。手動で管理されているため、下された決定、却下されたアプローチ、解決されたバグなどの動的な知識が反映されることはありません。また、コンパクションの影響を受けないわけでもありません。報告された97%→42%への逆戻りは、まさにそのことを示しています。

コンパクションと再読み込み

コンパクションは、長いセッションを強制終了させることなく維持するために非常に有用です。しかし、スペースを確保するために詳細を犠牲にします。正確なコマンド、特定の要件、以前の決定事項などが要約されて消えてしまいます。その後、エージェントは失った情報を回復するためにファイルを再読み込みし、すでに知っていたことを再構築するためにトークンを消費します。

新しいセッションの開始

セッションのパフォーマンスが低下したときの一般的な解決策は、セッションを再起動することです。これにより、セッションが学習したすべてを破棄してウィンドウのスペースを回復します。コンテキストを犠牲にすることで、一時的な明瞭さを得ているに過ぎません。

共通の壁：これらのいずれも、セッションの境界やコンテキストウィンドウの変更を越えて存続する、プロジェクト知識の永続的かつクエリ可能なストレージではありません。これは、Claude Codeがプロジェクトのコンテキストを忘れる理由の背後にある根本的なギャップと同じです。

永続的なアプローチは、セッションの外部にメモリレイヤーを構築し、コンパクションによって破棄され続けるアーキテクチャ、決定事項、制約、解決済みの問題などを保持することです。MemoryLakeはこれらを一度保存すれば、検索可能で、Gitスタイルのバージョン管理により決定がいつ変更されたかを追跡でき、エンドツーエンドで暗号化されるため、コードやインフラの詳細な情報が外部に漏れることはありません。知識はウィンドウの外部に存在するため、コンテキストウィンドウが小さくなってもメモリが縮小することはありません。

ステップ1：APIキーを作成する

MemoryLakeにサインインし、キーを生成して最初のリクエストを送信します。これには約30秒しかかかりません。

ステップ2：最初のメモリをアップロードする

セッションが再発見しがちなプロジェクトの知識（アーキテクチャのメモ、決定記録、APIやデータフローのドキュメント、長期タスクで失ってはならない要件など）を投入します。ドキュメント、画像、その他のファイルすべてに対応しています。セッション中に保存する価値のある決定がなされたら、それを1行のメモリとして記録します。

ステップ3：AIとエージェントを接続する

APIキーを使用してMCP経由でMemoryLakeをCodexに追加します。これにより、エージェントはコンパクションが発生するウィンドウ内に情報を保持する代わりに、必要に応じて要件や過去の決定事項をオンデマンドで取得できるようになります。同じメモリは、MCPまたはAPIを介してClaude、OpenClaw、その他のエージェントからも利用できます。コーディングに使用するすべてのツールで、1つのプロジェクトメモリを共有できます。

縮小するウィンドウの「税金」

デフォルトのウィンドウが小さくなると、単に早い段階で途切れるだけでなく、コンパクションによって失われた情報を回復するためにエージェントがより頻繁に再読み込みを行うようになります。そして、再読み込みのたびに、作業を進める代わりに既知のコンテキストを再構築するためにトークンが消費されます。大規模なコードベースにおいて、この再発見はセッションの中で最もコストがかかる部分であり、それがより早い段階で発生するようになっています。

再要約ではなく検索を利用する

永続レイヤーを使用すると、Codexはプロジェクト全体を保持しきれないウィンドウに詰め込もうとするのではなく、タスクに必要な特定の決定事項や要件をプルします。これにより、コンパクションの圧力が軽減され、タスク途中の逆戻りが減少し、コストが削減されます。MemoryLakeのトークン削減計算ツール（Token Saving Calculator）を使用すると、使用状況からその効果を予測できます。

コンパクションが届かない場所に要件を配置する

要件を長期のタスクを通じて維持する必要がある場合、それはプロンプトやAGENTS.mdだけでなく、検索可能なメモリに配置すべきです。これが、仕事を完遂するエージェントと、80%の段階で逆戻りしてしまうエージェントの差になります。

決定が下された瞬間に記録する

日付入りの1行（決定事項、理由、却下された代替案）を記録しておくことは、結局行われない振り返り作業よりもはるかに価値があり、エージェントがすでに却下した案を再提案するのを防ぎます。

リポジトリごとにスコープを分ける

リポジトリごとに1つのメモリ・スコープを設定することで、検索の精度が維持され、各プロジェクトのCodexセッションが該当する情報のみを取得できるようになります。

Codexの物忘れが激しくなったのは偶然ではありません。デフォルトのウィンドウが小さくなったことでコンパクションがより早く発生するようになり、コンパクションは常に要件や決定事項が静かに消え去る場所でした。AGENTS.mdでは動的な知識を保持できず、セッションの再起動はコンテキストを犠牲にして一時的な明瞭さを得ているだけです。プロジェクトの真のメモリをウィンドウの外部に配置すれば、ウィンドウのサイズによってエージェントの知識量が左右されることはなくなります。コンテキストは縮小しても、メモリを縮小させる必要はありません。