Codex 0 context leftの意味と作業を引き継ぐ確認手順

0 context leftが出たときに最初に読むもの

コンテキストは、モデルが応答を作る際に扱う指示や会話、参照したコード、作業結果などの文脈です。CLIの残りコンテキスト表示は、いまの会話にどれだけ余地があるかを判断する手掛かりになります。ただし「0」という数字だけから、停止の原因や復旧方法までは確定できません。回答がまだ返っているのか、処理中なのか、具体的なエラーが出ているのかで、次に行う確認は変わります。

OpenAIのCLIコマンド公式文書では、/statusでセッションの設定とトークン使用量を確認でき、モデルや残りコンテキスト容量を確かめる用途が説明されています。表示の場所や項目は使っている版によって変わるため、まず自分の環境に表示された項目を読みます。別の端末の画面例と数字の位置が違っていても、それだけで異常とは判断しません。

時事的な背景として、公式変更履歴には2026年10月29日のCodex CLI 0.166.0公開が掲載されています。この記事の確認日は2026年10月31日です。この公開事実は、残容量ゼロの不具合がその版で修正されたことを意味しません。版の変更と現在の会話の状態を別々に記録し、更新だけで直ると決めつけずに原因を絞ります。

会話の容量と利用上限を切り分ける

残りコンテキストと利用上限は、似た場所に表示されても判断の対象が違います。前者は現在の会話に持ち込む文脈の容量に関係し、後者はサービスを利用できる枠やその回復時刻に関係します。会話が長くなったときの整理と、利用上限に達したときの対応を混ぜると、不要な設定変更や待機につながります。契約を変更する前に、何の上限を示しているのかを確認しましょう。

たとえば、画面下部に残りコンテキストが表示されている一方で、エラー本文には利用上限と回復時刻が書かれている場合があります。この場合は二つの情報をそのまま残し、どちらか一方だけを原因と決めません。公式のスラッシュコマンド一覧でも、/statusは会話のコンテキスト使用量と利用上限を示すものとして案内されています。デスクトップアプリ向けの一覧とCLIの一覧は対象が異なるため、使っている画面に合う文書を参照します。

通信が切れた、処理が失敗した、回答が返らないといった現象も、残容量の表示だけでは説明できません。直前に出たメッセージ、最後に成功した操作、未完了の操作を分けて記録します。表示がゼロでも応答が続いているなら、長い追加依頼を重ねる前に作業を整理します。応答できない場合は、会話に要約を頼むことに固執せず、人が確認できるファイルと作業記録から引き継ぎを組み立てます。

復旧を試す前に作業内容を残す手順

ここで紹介する順番は、特定のエラーを必ず解消する公式の修復手順ではなく、作業の取り違えを防ぐための実務上の進め方です。会話の履歴と、ディスクに保存された変更は分けて扱います。「先ほど直したはず」という記憶だけで進まず、ファイルが保存されているか、検証がどこまで終わったかを確認してから、会話の圧縮や切り替えへ進みます。

特に、途中で止まったテストや処理は、開始したという記録だけでは完了と判断できません。最後に見えた出力と完了結果を区別して残します。また、もともと人が編集していた箇所がある場合は、その変更も識別します。復旧を急いでファイルを元に戻すと、会話の問題とは別に必要な編集まで失うおそれがあるため、現状の確認を先に行います。

Step 1: 表示と直前のエラーを記録する

まず「0 context left」が出ている場所と、直前のエラー本文を記録します。操作できる場合は/statusを開き、モデル名、現在の作業場所、使用量に関する項目を確認します。表示の数字だけを抜き出すより、何を依頼した直後に起きたかまで書いておくと、同じ症状が再発したときに比較できます。共有する記録には、公開してよい情報だけを残してください。

Step 2: 保存された変更と未完了の処理を確認する

対象ファイルをエディターで開き、意図した修正が保存されているかを確かめます。作業中の処理がある場合は、その結果が返ったかも確認します。ここでは新しい修正を広げず、現在地を把握することに集中します。「ファイルは変更済み、テストは開始したが完了結果なし」のように書けば、次の会話が未確認の結果を完了扱いすることを防ぎやすくなります。

Step 3: 引き継ぎ文を短く作る

引き継ぎには、目的、対象ファイル、現在の変更、確認済みの結果、残っている課題を入れます。長い会話を丸ごと貼り直すと、新しい会話でも文脈を多く使います。必要な事実とファイルの場所を中心にまとめ、細かな経緯は求められたときに補います。会話が応答できるなら要約を依頼できますが、その内容を人が現物と照合してから使うことが大切です。

/compactと/newを作業の状態で選ぶ

OpenAIのCLI公式文書では、/compactは会話を要約してトークンの余地を作る機能、/newは同じCLIセッションの中で新しい会話を始める機能として説明されています。いまの課題を続けたいのか、前提から整理し直したいのかで選びます。表示を消すことだけを目的にすると、再開後に何を確認すべきかが曖昧になります。

同じ不具合を調べ続けていて、重要な前提がまとまっているなら、会話が操作可能な状態で/compactを検討します。要約後には、目的と未完了事項を短く再確認します。要約に過去のすべての細部が残るとは想定せず、テストの完了状態や変更禁止箇所のような重要事項は、ファイルや明示した記録から読み直せるようにしておきます。

話題が変わった、長い調査が積み重なった、説明が食い違うといった場合は、引き継ぎ文を用意して/newへ進む方法があります。公式文書が説明するのは会話のリセットであり、ファイルの変更を元に戻す機能ではありません。新しい会話では対象フォルダーと実ファイルを確認し、短い依頼から始めます。/compact自体が失敗した場合は、同じ操作を何度も繰り返すより、表示されたエラーを残して引き継ぎ可能な状態を作ります。

/forkは別の方針を試すために会話を分岐する機能です。公式文書では元の履歴を失わずに別案を調べる用途が示されており、文脈を空にする手段としては案内されていません。履歴を残して分岐したいのか、空の会話から始めたいのかを混同せず、容量を整理したい場合は/compactと/newの説明を先に確認しましょう。

引き継ぎ文に書く内容と再開時の確認

引き継ぎ文は、過去の会話を再現するためではなく、次に何を確かめればよいかを伝えるために作ります。たとえば「一覧画面の並び順を修正中。変更したのは表示用ファイルと関連テスト。通常の表示は確認済み。空データ時のテストは未確認。現在の差分を読んで、未確認の条件だけを検証してほしい」と書けば、目的と残作業の境界が伝わります。

この例は依頼の書き方であり、実際にテストが成功したことを示すものではありません。自分の作業に合わせ、確認していない事実を混ぜないようにします。ファイル名が曖昧なら、分かる範囲で場所を明記します。対象外の変更がある場合は、それに触れないことも書きます。「続きからお願い」だけでは、どの状態を起点にすべきかを次の会話が判断できません。

再開したら、最初の依頼は読み取りと現在地の確認に絞ると進めやすくなります。引き継ぎ文と現物が食い違っていたら、追加の編集より先に差を整理します。修正済みと書かれていてもファイルに反映されていない場合や、テスト済みと書かれていても条件が違う場合があります。新しい会話が文章を理解したことと、正しい状態から作業を再開したことは、別々に確認する必要があります。

同じ表示を繰り返すときの見直し方

短い会話でもすぐに残容量が減るなら、毎回渡している入力を見直します。大きなファイルの全文、長い検証出力、課題に関係の薄い説明を重ねると、必要な文脈を見分けにくくなります。ファイルは対象を指定し、エラーは関連する部分と再現条件を示します。情報を削るときも、期待する動作や失敗条件まで消さず、判断に必要な内容を残すことが重要です。

モデルや設定の変更を同時に行うと、何が影響したか追いにくくなります。まず同じ条件で小さな依頼が通るかを確かめ、必要に応じて版番号や設定の確認へ進みます。容量に関する設定値を大きくすれば必ず解決するとは限りません。モデルが扱える範囲と、画面に示される残量の関係を確認せずに数字だけを変えることは避けます。

最後に確認するのは、表示が回復したかだけではありません。対象ファイルが期待どおりか、未完了の検証が終わったか、依頼と関係のない変更が増えていないかを確かめます。復旧の記録には「会話を切り替えて応答を確認」「ファイルの変更を確認」「特定のテストは未実施」のように結果を分けて書きます。これにより、会話が使える状態に戻ったことと、開発上の課題が解決したことを取り違えずに扱えます。