Codex CLIで長いセッションを回していて、コンテキストウィンドウのエラーに遭遇したことがあります。これは5時間・週間の使用量上限とは別の問題です。上限は料金プランで決まる時間単位の制限です。このエラーは、1つのセッションに溜まったトークンがモデルの処理できる量を超えたときに起きます。
/compactを実行しても、いつも解決するわけではありませんでした。そのとき実際に何をしたか、そしてresume・fork・new・clearの4つを今どういう基準で使い分けているかを以下にまとめます。
Codexのコンテキストウィンドウエラーはいつ起きたか
Codexのコンテキストウィンドウエラーは、短い会話の途中で突然出るものではありません。複数のモジュールを行き来する長いリファクタリングセッションで、後半になるほどコンテキストが溜まって起きます。
私が遭遇したのは、Java/Springのマルチモジュールリポジトリで既存のロジックを整理する作業でした。最初はファイル2〜3個の修正から始めましたが、調べる範囲が広がり続け、読み込んだファイルとdiffが積み上がっていきました。テスト実行 → 失敗原因の確認 → コード修正 → 再実行を何度も繰り返しました。
いきなり落ちたわけではありません。後半になるにつれ、前に決めた内容をもう一度確認したり、コンテキストを整理したりする場面が増えていきました。その前兆が何度か繰り返されたあと、最終的にエラーになりました。
単一ファイルのスクリプト作業なら、ここまで早くは溜まらなかったと思います。複数のモジュールとテストファイルを同時に参照する構造そのものが、コンテキストの消費を速めています。
5時間・週間の使用量上限と混同しない
このエラーは使用量上限の消化とは別物です。上限は時間が経てばリセットされます。一方、コンテキストウィンドウはセッション内に溜まったトークン量の問題なので、使用量が残っていても発生します。
/compactで実際に何が残り、何が消えるか
/compactは以前の会話をそのまま覚えておくチェックポイントではありません。セッションを続けられるようにコンテキストを整理する手段です。
compactのあとも、大きな目標、主要なファイル、すでに決めたことは残りました。ただ、細かい判断の背景はもう一度伝え直す必要があることが多かったです。
/compactをしてもすべて解決したわけではありませんでした。セッションがすでに長くなりすぎていたり、作業の方向が何度も変わっていたりした場合は、compactのあとも説明を付け直す必要がありました。今は/compactを何度も繰り返して最後まで粘るより、コンテキストを説明するコストがまた大きくなってきたと感じた時点で新しいセッションに移っています。
/compactが毎回自動で走るとも限りません。GitHub issueに報告されているエラーメッセージは次のとおりです。「Codex ran out of room in the model’s context window. Start a new thread or clear earlier history before retrying.」（GitHub issue #19269、2026年4月24日）。OpenAI Developer Communityにも同じメッセージの再現例が投稿されています。OpenAI_Supportアカウントはバージョン・モデル・ログを求める返信をしただけで、根本的な解決策はまだ示されていません。
compact後に私が固定し直す5項目
compactのあとは、次の5つをそれぞれ一文ずつ付け直しています。
- 今の作業の最終目標
- このセッションで触る修正範囲
- まだ失敗しているテスト
- 試して捨てたやり方
- 触ってはいけない領域
resume・fork・new・clearの違いと使いどころ
resumeは同じ判断をそのまま続け、forkは同じコンテキストから別の判断を試し、newは確定した事実だけを持って最初からやり直す選択です。
これらを区別せずに使うと、かえってコンテキストがこじれます。状況別に整理するとこうなります。
| コマンド | 役割 | 使うタイミング | 残るもの・消えるもの |
|---|---|---|---|
/compact |
同じセッション内でコンテキストを圧縮 | セッションはまだ生きていて、コンテキストを説明し直すコストが増え始めたとき | 大きな目標・主要ファイル・決定事項は残る。細かい背景は説明し直しが必要な場合がある |
codex resume --last |
同じセッションをそのまま続ける | 判断の方向は合っていて、細部の作業だけを進めるとき | 以前の履歴は残る。ただしコンテキストがすでに一杯なら再発しうる |
codex fork --last |
同じコンテキストから新しい分岐を始める | ここまでのコンテキストは保ったまま、別のやり方を試したいとき | 既存のコンテキストは残り、その後の進行は分岐ごとに分かれる |
/new |
新しいセッションを始める | 仮説や失敗したやり方が溜まり、コンテキスト自体が汚れたとき | 以前の細かいコンテキストは消える。確定した事実だけを人が入れ直す必要がある |
/clearは、私が実際によく使うコマンドではありません。具体的な事例を持っていないので、使用頻度が低いことだけ記しておきます。
新しいセッションに移る判断基準
コンテキストを説明し直すコストが、圧縮して維持するコストを上回ったとき。それが新しいセッションに移るサインです。コンテキストが長いこと自体は問題ではありません。
コンテキストを多く保つほど得だとは考えていません。特にリファクタリングのように途中の判断が変わり続ける作業では、古いコンテキストを圧縮して持ち続けるより、どこかの時点で確定した事実だけを抜き出して新しいセッションに移すほうが安定していました。
その時点を測る基準はシンプルです。
compactしたあとも説明を付け直す頻度が増えているなら、維持するコストはすでに新しく始めるコストを超えています。
自動圧縮を100%は信用しない理由（2026年9月時点）
自動圧縮（auto-compact）の信頼性は、バージョンによって変わってきました。いま起きている症状が既知のリグレッションかどうか、先にGitHub issueで確認するほうがよいです。
自動圧縮のしきい値は公式ドキュメントの数値ではなく、GitHub issueで確認できる内部動作です。GitHub issue #11805によると、v0.100.0以降、ユーザーが指定した圧縮しきい値はコンテキストウィンドウの90%に強制的に制限されます（2026年2月14日起票、現在は「not planned」でクローズ）。自動圧縮がまったく実行されないリグレッションも別に報告されています。v0.42.0で大規模な変更セットがあるとcompactが自動実行されないというissueがその例です。
この部分は執筆時点（2026年9月）の情報です。その後安定したかどうかは、改めて確認が必要です。
よくある質問
/compactを実行してもコンテキストウィンドウエラーが続く場合は？
自動圧縮が走らないリグレッションの可能性があります。その場合はcompactを繰り返すより、目標・修正範囲・失敗中のテストを一文ずつまとめて新しいセッションに移るほうが安定します。
codex resume --lastやfork --lastに切り替えると、以前の作業内容はそのまま残りますか？
resumeは履歴をそのまま引き継ぎますが、コンテキストがすでに一杯なら再発することがあります。forkは既存のコンテキストを保ったまま新しい分岐を作ります。細かいコンテキストまで完全に保持されるわけではありません。
自動圧縮（auto-compact）があるのに、なぜ手動で対応するのですか？
バージョンによって自動圧縮が発動しないケースが報告されています。まず今の症状が既知のリグレッションかどうかを確認し、自動圧縮に頼らず手動での対応を基本にしておくほうがよいです。
参考資料
- GitHub issue #19269：「Codex ran out of room…」エラーメッセージの一次情報としての再現報告（2026年4月24日、Codex CLI v0.124.0）
- OpenAI Developer Communityのスレッド：同じエラーの再現例とOpenAI_Supportの返信（根本的な解決策は未提示）
- GitHub issue #11805：v0.100.0以降、自動圧縮のしきい値がコンテキストウィンドウの90%に強制制限されることの根拠（2026年2月14日起票、not plannedでクローズ）
- GitHub issue #4363：v0.42.0で大規模な変更セットがあるとcompactが自動実行されないリグレッションの報告
この記事は韓国語の原文をもとにローカライズしたものです: https://jjeongil.tistory.com/3568。