Codexコンテキスト画面の見方と使用量の確認・注意点・整理

Codexコンテキスト画面を今確認する理由

Codex CLIを使っていると、画面の下部に残りコンテキストが表示され、上部にはモデル名とディレクトリが表示されます。ここで目につく数字だけを見て「もう使えない」「まだ十分に余っている」と決めると、現在の作業場所やモデル設定を見落としがちです。コンテキストは会話に持ち込まれた指示、ファイルの内容、コマンド結果、ツールの応答などを扱う範囲に関係します。残量が多くても対象を間違えていれば結果は安定しませんし、残量が少なくても目的を絞れば次の確認に進める場合があります。

今この画面を読み直す価値が高いのは、2026年8月19日（日本時間）にCodex CLI 0.148.0が公開されたからです。公式リリースでは、TUI会話のMarkdown書き出し、セッションの分岐、再開画面でのアーカイブと復元、起動時のセッション状態表示に加え、対象ワークスペースのスレッド単位で推定クレジットまたは費用を表示する変更が案内されています。詳細は公式リリースノートにあります。

この更新によって、コンテキスト画面は「回答が返ってくるまで待つための表示」から、「次の作業の置き場所を決めるための表示」へ役割が広がりました。残量が減ってきたら会話を保存して枝を分ける、同じ論点を続けるなら前提を短くまとめる、利用量の目安を/statusで確認して重い依頼を小さくする、といった選択がしやすくなります。画面の数字を単独で評価せず、作業の状態を読む入口として使うのが基本です。

0.148.0で増えた表示と整理機能

0.148.0の変更で特に重要なのは、推定使用量の見え方とセッションを整理する手段が同じ版に入ったことです。使用量の表示は、対象となるワークスペースで現在のスレッドにどれくらいのクレジットまたは費用が見込まれるかを確認する材料です。実際の請求や契約上限を置き換える表示ではないため、請求情報は契約側の公式画面で別に確かめます。

一方、/exportは現在のTUI会話をMarkdownとしてクリップボードまたは新しいファイルへ書き出す機能です。書き出したからコンテキストが空になるわけではありませんが、次の会話へ渡す要点を整理する材料になります。codex exec forkは既存セッションから別の枝を作るための入口で、元の検討を残したまま別案を試すときに使えます。再開画面のアーカイブと復元は、一覧を整理しつつ後から戻れるようにする機能です。

コンテキスト画面で読む五つの表示

コンテキスト画面を読むときは、数字の大小よりも「その数字が何の範囲を表すか」を先に確認します。Codex CLI公式案内の起動画面には、モデル、ディレクトリ、/status、権限、レビューへの入口と、100% context leftのような表示例があります。これらは同じ画面に並びますが、意味はそれぞれ違います。次の五つに分けて見ると、設定の問題、会話の問題、対象ファイルの問題を切り分けやすくなります。

短い修正では作業場所と残量の確認で足りますが、調査や複数ファイルの変更では、表示を節目ごとに記録すると原因を追いやすくなります。ここでは画面に出る項目を、次の判断へつなげる順番で見ていきます。

モデル名と推論設定

モデル名は、どのモデルに応答やコード作業を任せているかを示します。推論設定が併記される場合は、同じモデルでも考え方の深さや応答時間の傾向が変わることがあります。コンテキストの残量が十分でも、依頼の性質に合わないモデルを選んでいれば、回答の精度や速度の印象は変わります。まずモデル名を記録し、前回と同じ条件かを確かめてから残量を読みます。モデルを変えた直後に反応が違っても、会話が長くなったせいだと決めつけないことが大切です。

作業ディレクトリ

ディレクトリ表示は、Codexが最初に作業の基準にする場所を示します。似た名前の複製、別ブランチ、親子フォルダーを行き来していると、読み込ませたいファイルが見つからない原因になります。残りコンテキストが多いのに「対象がない」「変更が違う場所に入った」と感じたときは、会話を整理する前にこの表示を見直します。公式CLI案内でも、起動画面に現在のディレクトリが表示される例が示されています。画面の場所と、依頼文で指定した場所を同じ記録に残してください。

コンテキスト残量

「context left」は、そのセッションで過去のやり取りや現在の入力をどれだけ文脈として扱える余地があるかを考えるための目安です。これは毎月の利用枠、1回の請求額、ディスク容量とは別の概念です。長いファイルを何度も貼り付けたり、コマンド出力を大量に会話へ残したりすると減りやすくなります。逆に、必要なファイルだけを指定し、調査結果を短くまとめれば、同じ作業でも消費を抑えられます。残量が減ったときは、ただ新しい会話へ移るのではなく、次に必要な前提を三つ程度に整理してから移すと、同じ情報を繰り返し読み込ませずに済みます。

セッション設定と権限

/statusは現在のセッション設定を表示する入口で、/permissionsはCodexに許可する範囲を選ぶ入口です。権限の表示はコンテキスト残量を増減させる数字ではありませんが、同じ依頼でもファイル編集やコマンド実行の確認回数が変わるため、作業時間と結果の確認方法に影響します。残量が減ったから権限を広げる、という考え方は避けてください。先に対象フォルダーと変更範囲を狭くし、必要な確認が終わったらレビューへ進むという順序が安全です。

推定クレジットと費用

0.148.0では、対象となる環境でスレッドの推定クレジットまたは費用を/status、状態行、端末タイトルから確認できるようになりました。これは現在の作業がどれくらい重いかを見積もる助けになりますが、表示対象外の環境や、契約画面の集計と完全に同じとは限りません。数字が出ない場合は、機能が壊れたと判断せず、公式リリースの対象条件と現在のログイン状態を確認します。

推定値は作業を止めるためだけに使うものではありません。長い調査を一つの会話へ集める代わりに、読み取り、変更、検証へ分ける判断材料にもできます。費用が高く見えるときは、モデルを変える前に、同じファイルを何度も読ませていないか、出力の大きいコマンドをそのまま残していないか、完了条件が広すぎないかを確認してください。

/statusを起点に現在の状態を固定する

コンテキスト画面を見たら、次は/statusでセッションの設定を確認します。OpenAIの公式CLI案内では、/statusは現在のセッション設定を表示するコマンドとして紹介されています。ここで大切なのは、表示された数字を保存することそのものではなく、モデル、作業ディレクトリ、利用中の権限、残りコンテキストを同じ時点の情報として並べることです。これをしておくと、作業後に応答が遅くなった、対象ファイルが変わった、表示が増えたという変化を比較できます。

最初に次のコマンドを順番に確認します。すべてを毎回実行する必要はありませんが、版を変えた直後、作業場所を変えた直後、長い依頼を送る前後には役立ちます。

/status
/model
/permissions
/review

/modelは選択するモデルと推論設定を確かめる入口、/permissionsは許可範囲を確認する入口、/reviewは変更内容をレビューする入口です。公式CLI案内の各コマンドの役割を混ぜずに扱い、/statusの数字だけで作業の安全性や品質を判断しないようにします。

Step 1: 上部のモデルと場所を記録する

Codexを起動した直後は、モデル名とディレクトリを画面から読み取ります。メモには「確認時刻」「モデル」「推論設定」「作業ディレクトリ」「残りコンテキスト」の順で書くと、後から差分を比較しやすくなります。別の端末や別の複製で確認した結果を一つにまとめないことも重要です。まず、いま見ている画面が、変更したいリポジトリのものかを確かめます。

Step 2: /statusでセッション設定を確認する

/statusを入力し、現在のセッション設定と推定使用量が表示されるかを確かめます。使用量が表示された場合は、コンテキスト残量とは別の欄として記録します。表示されない場合も、残量がゼロだと結論づけないでください。対象ワークスペースか、利用中の版か、表示対象の条件を順番に調べます。数字の出方が変わったときは、版番号と一緒に保存すると後で確認できます。

Step 3: モデルと権限を別に確かめる

次に/modelと/permissionsを確認します。モデルを選び直す場合は、残りコンテキストの変化とモデル変更の影響を同じものとして扱わないようにします。権限を見直す場合は、対象パスと実行してよい操作を狭く定めます。残量を使い切りそうだから許可を広げるのではなく、必要な作業を小さく分けて確認回数を減らす方が、原因を追いやすくなります。

Step 4: 変更をレビューしてから会話を整理する

ファイルを編集した後は、会話を続ける前に差分を確認します。公式CLI案内の/reviewは、未コミットの変更などをレビューする入口です。レビュー結果と手元の差分を分けて確認し、問題がなければ/exportで会話の記録を保存します。残量が少ない状態で先に会話を分けると、未確認の変更を次のセッションへ持ち越しやすいため、作業結果の確認を先に置きます。

残量と使用量を混同しない

コンテキスト残量と使用量は、どちらも画面に数字として出るため混同しやすいものです。前者は現在の会話が扱える文脈の余地を考える表示で、後者はスレッドのクレジットまたは費用の目安です。残量が少ないから請求額が高い、残量が多いから費用が安い、と単純には言えません。会話にどれだけの情報を持ち込んだか、どのモデルを使ったか、どの作業を依頼したかが別々に影響します。

0.148.0の公式リリースにある「eligible workspaces」という条件も見落とせません。すべての利用者に同じ欄が表示されるとは限らないため、画面に費用の目安がない場合は、非対応と障害を切り分けます。契約や請求の確認が必要なら、CLIの表示ではなくOpenAIのアカウント側の公式情報を使います。Codexの画面は作業中の判断に使い、月間の精算は別の場所で確認するという役割分担が適切です。

残量が減ったときに最初に見る場所

残量が減ってきたら、次の順番で原因を見ます。

1. 直前の依頼に、不要なファイル全文や大きなコマンド出力を含めていないか確認する。
2. 現在の作業に必要なファイルと、すでに結論が出た調査資料を分ける。
3. 同じ前提を何度も説明していないか確認し、決定事項を短くまとめる。
4. 変更前の調査と変更後の検証を別セッションへ分ける必要があるか判断する。
5. 分岐するならcodex exec fork、保存するなら/export、一覧を整理するならアーカイブを選ぶ。

この順番なら、数字を減らした原因を確かめないままモデルを変更したり、作業を最初からやり直したりする失敗を減らせます。会話を分ける場合は、「目的」「対象ファイル」「現在の差分」「未解決の確認」の四つを短く残してください。新しいセッションは過去の全履歴を持っているとは限らないため、必要な前提を自分で持ち運ぶことが大切です。

使用量の目安が増えたときの考え方

推定クレジットや費用が増えたときは、会話の回数だけを責めるのではなく、依頼の粒度を確認します。調査、実装、検証、説明を一つの依頼に入れると、読み取りと出力が広がりやすくなります。まず読み取りだけで対象を絞り、次に変更範囲を指定し、最後に検証結果を確認する三段階へ分けると、何に使用量がかかったのかを把握しやすくなります。

使用量の目安は採点ではありません。同じ修正でも、複雑な依存関係を調べる必要がある案件は重くなります。数字が高いことだけで内容を削りすぎると、必要な確認を省く結果になります。費用を抑える場合も、テストや差分の確認を削るのではなく、対象ファイル、説明の長さ、質問の回数を整理する方が安全です。

0.148.0のセッション整理を使い分ける

コンテキスト画面を確認した後に行う整理は、会話を消すことだけではありません。0.148.0では、会話をMarkdownへ書き出す、既存セッションから枝を作る、再開一覧をアーカイブする、アーカイブしたものを復元するという複数の選択肢があります。公式リリースは機能名を明示しているため、版番号を確認したうえで自分の端末に表示される操作を試してください。

目的ごとに使う機能を決めると、コンテキスト残量と記録を別々に管理できます。あとで根拠を読み返したいなら/export、別案を試したいならcodex exec fork、現在の一覧から一時的に隠したいだけならアーカイブ、再び続けたいなら復元です。保存と整理を同じ操作だと考えないことがポイントです。

/exportで会話を記録する

/exportはTUIの完全な会話をMarkdownとして書き出します。クリップボードへ送る方法と新しいファイルへ保存する方法が用意されています。書き出した記録は、次のセッションへ渡す要点を選ぶときに使えます。全履歴をそのまま貼り直すのではなく、結論、変更したファイル、未解決の点だけを抜き出せば、次の会話へ持ち込む文脈を小さくできます。

書き出しはバックアップと同じではありません。ファイルの差分やテスト結果は、会話の記録とは別に確認してください。また、記録へ不要な入力内容を残さないように、保存先と共有範囲も見直します。会話を保存した後に現在のセッションを閉じるかどうかは、未確認の変更があるかで決めます。

codex exec forkで別案を試す

既存の検討を残したまま別の実装方針を試したい場合は、codex exec forkが候補になります。元のセッションを基準に新しい枝を作るため、最初の調査結果をもう一度入力する手間を減らしつつ、案Aと案Bの差を比べられます。分岐した後は、どちらが採用候補か、変更したファイルは何か、検証はどこまで進んだかを各枝へ書き残してください。

分岐は残量を無限に増やす機能ではありません。枝を増やせば、それぞれに履歴と検証が必要になります。比較の目的が終わった枝は、差分を確認して記録を残し、一覧から整理します。目的のない分岐を続けないことが、表示と使用量を見通しやすくするコツです。

アーカイブと復元で一覧を整える

TUIの再開画面にあるアーカイブは、過去のセッションを一覧から整理するための操作です。公式リリースではアーカイブしたセッションを復元できることも案内されています。調査が終わった会話を一覧からいったん外し、後日必要になったら戻すという使い方ができます。削除と同じだと決めつけず、復元できる状態かを実際の画面で確認してください。

一覧を整理するときは、セッション名や最後の作業内容を手がかりにします。似た名前が並ぶ場合は、先に/exportで記録を残し、採用した枝と保留した枝を区別します。整理は表示を見やすくする操作であり、コンテキスト残量を回復させる操作とは別です。この違いを理解していれば、残量不足の対処と履歴の片付けを混ぜずに済みます。

実際の確認手順を一つの作業に組み込む

ここまでの内容を、Codexで一つの修正を行う場面へ落とし込みます。目的は、画面を何度も眺めることではなく、作業前後の条件をそろえて変化を判断できるようにすることです。小さな修正から始め、対象ファイルと完了条件が明確な案件で試してください。大きなリファクタリングをいきなり使うと、残量の変化と変更範囲の変化を分けにくくなります。

1. 作業場所を確認する。 Codexを対象リポジトリから起動し、上部のディレクトリが意図した場所かを確認します。似たフォルダーがある場合は、フルパスをメモします。
2. 初期表示を記録する。 モデル名、推論設定、残りコンテキストを作業前の状態として記録します。表示される範囲だけを書き、表示されない情報を推測しません。
3. /statusを実行する。 セッション設定と推定クレジット・費用が出る場合は、コンテキスト残量とは別の欄へ記録します。
4. 対象を一つに絞って依頼する。 変更するファイル、期待する動作、確認する方法を短く伝え、関係のないファイルを最初から読み込ませません。
5. 変更を確認する。 Codexが示した差分と、必要なら/reviewの結果を確認します。残量が減っていても、まず変更が正しいかを判断します。
6. 会話を保存する。 今後も根拠が必要なら/exportでMarkdownを保存し、次のセッションへ渡す要点を短くまとめます。
7. 続行方法を選ぶ。 同じ論点を続ける、別案を試す、一覧から片付ける、後日再開する、のどれかを選び、必要に応じて分岐、アーカイブ、復元を使います。

この手順では、モデル変更、コンテキスト残量、推定使用量、ファイル差分を別々の観測項目として扱います。たとえば、同じモデルなのに残量だけが大きく減ったなら、会話へ追加した資料やツール出力を調べます。残量は変わらないのに回答時間だけが伸びたなら、対象ファイルの読み取りや外部接続の待ち時間など別の要因を見ます。一つの数字で全体を説明しないことが、切り分けの基本です。

ケース別に見るコンテキスト画面

コンテキスト画面の読み方は、作業の長さによって変わります。短い修正なら、作業場所と差分の確認が中心です。長い調査なら、途中の決定事項を保存し、枝を分ける判断が必要です。利用量の目安を気にする案件でも、数字を下げることを目的にせず、依頼の範囲と確認方法を整えることを優先します。

同じ残量でも、初回の小さな編集、複数案を比べる調査、使用量を管理したい案件では取るべき行動が異なります。状況に応じた確認点を先に決めておくと、会話を分けるタイミングを感覚だけで決めずに済みます。

初めての小さな修正

初回は、モデル名、ディレクトリ、残りコンテキストを確認してから、対象ファイルを一つに絞った依頼を送ります。変更が終わったら差分を見て、/statusで状態をもう一度確認します。最初から大量の資料を貼るより、Codexに必要なファイルを探させ、見つけた場所を確認してから編集へ進む方が、会話の前提を保ちやすくなります。

長い調査と大きな修正

長い調査では、調べたことをすべて会話へ残し続けるより、節目ごとに結論を短く書き出します。変更案が複数になったら、元の調査を残して枝を分け、検証結果を比較します。残量が少なくなったときは、全履歴を新しい会話へ移すのではなく、目的、根拠、対象ファイル、未解決の点だけを移します。これにより、次の会話が古い仮説を無条件に引き継ぐことを防げます。

利用量が気になる案件

推定クレジットや費用が増えた場合は、まず作業を調査、変更、確認へ分けます。ファイル全文ではなく必要な範囲を指定し、出力が大量になるコマンドは要約してから次の判断へ進みます。モデルを変更する場合も、変更前のモデル名と残量を記録しておくと、速度や結果の違いを説明できます。数字を隠すのではなく、何に使ったかを確認できる状態にすることが大切です。

読めないファイルを残量不足と誤認しない

Codex CLI 0.148.0の公式リリースには、LinuxとWindowsで拒否されたパスや読めないパスに対して、制限を緩めずに失敗させる修正が含まれています。これはコンテキスト画面の数字とは別の話ですが、ファイルを読めなかったときに「残量が足りない」と誤認しないために重要です。対象パスが許可範囲外、存在しない、別の作業ディレクトリにある、読めない状態である、といった原因を順番に確かめます。出典は0.148.0公式リリースのBug Fixesです。

Windowsでは、PowerShellや別の端末から起動したときに、見ているフォルダー、パスの表記、改行コードが変わることがあります。公式リリースには、CRLFを含む貼り付けや長いURLの表示に関する修正も記載されています。表示の崩れとファイルの読み取り失敗を一つにまとめず、画面上のディレクトリ、対象ファイルの存在、差分の有無を別々に確認してください。

パスと権限を先に確かめる

ファイルが見つからないときは、まずCodexの画面に出ている作業ディレクトリと、依頼で書いた相対パスを照合します。次に、対象ファイルが本当にその場所にあり、現在の設定で読み取りや編集の対象になっているかを確認します。残量が十分でも、場所や許可範囲が違えば読み取れません。逆に、パスを正しく直すだけで同じ会話を続けられる場合があります。

表示の乱れと内容の乱れを分ける

日本語、改行、長いURL、貼り付けたログが画面上で乱れて見える場合、表示の問題と内容の問題を分けます。短い入力を一つ送り、画面上の表示とCodexが受け取った内容を確認します。表示だけが乱れていてファイルの差分が正しければ、会話を捨てる必要はありません。差分や対象パスまで違う場合は、作業場所と入力方法を見直してから続行します。

まとめ

Codexコンテキスト画面は、残りコンテキストの数字だけを読む場所ではありません。モデル名、作業ディレクトリ、セッション設定、権限、推定クレジット・費用を同じ時点の情報として確かめ、現在の会話を続けるか、整理して分けるかを判断する画面です。OpenAIの公式CLI案内にある/status、/model、/permissions、/reviewを役割ごとに使い分けると、数字の意味を取り違えにくくなります。

2026年8月19日（日本時間）に公開された0.148.0では、使用量の目安と、会話の書き出し、セッションの分岐、アーカイブと復元が一つの更新に含まれました。残量が減ったら、不要な入力を減らし、差分を確認し、必要な前提だけを次の会話へ渡します。記録を残したいときは/export、別案を比べたいときはcodex exec fork、一覧を整えたいときはアーカイブと復元を使う、という選び方を覚えておけば、長いコーディング作業でも画面の数字を実際の判断へ結びつけられます。

出典: https://github.com/openai/codex/releases/tag/rust-v0.148.0、https://developers.openai.com/codex/cli/、https://github.com/openai/codex/blob/main/docs/getting-started.md