Codex 容量確認|Windowsの保存場所と古い履歴の整理手順
Codexの容量確認では、PCに保存されたデータと、会話に使える情報量を分けて考えます。10月1日のCLI更新では履歴表示や再開時の設定保持が修正されました。本記事ではWindowsのCodex CLIを対象に、保存場所と大きなファイルを調べる方法、履歴の上限設定、整理前に残す記録を解説します。空き容量の不足を感じたときに、原因を絞り込める順序で確認します。
PCの空き容量、保存ファイルの大きさ、会話の情報量は別の指標です。ディスクの不足を調べる場合は、Codexの状態保存先と作業フォルダーを実際に測り、どちらが容量を使っているか確かめます。
保存先の基本はCODEX_HOMEで指定したフォルダー、未指定なら~/.codexです。ただし、別の場所へ保存する設定もあります。Windowsの通常の利用とWSLでの利用を混同せず、実際に使っている環境で場所を確認します。
history.max_bytesは履歴ファイルの上限を指定する設定です。Codexの保存データ全体を同じ大きさに抑えるものとは判断できません。容量の大きい場所を特定し、再開したい会話や設定を確認してから整理方針を決めます。
目次 (11)
Codexの容量確認を今行う理由
OpenAIの公式更新履歴では、2026年10月1日付のCodex CLI 0.160.0に、再開と分岐の履歴に適切なセッションを表示する修正と、設定保持に関する修正が記載されています。過去の会話を選び直して続ける使い方では、保存済みの記録がどこにあるかを把握しておくと、PCの整理時に必要なデータを判断しやすくなります。
この更新説明から、保存容量が増えた、あるいは減ったという結論は出せません。容量の問題は、利用期間、作業内容、保存先、手元の空き容量をそろえて調べる必要があります。本記事の確認手順は編集部が提案する調査方法で、更新による容量改善を測定した結果ではありません。
「Codexを入れた後にディスクが減った」と感じても、作業中に作った成果物や開発に必要なファイルが増えた可能性があります。Codex自身の保存データと、Codexが手伝ったプロジェクトのデータを別々に測れば、見当違いの場所を整理することを避けられます。
空き容量と会話の情報量を区別する
Windowsのストレージ画面が示す空き容量は、PCのドライブに追加で保存できるデータの量です。一方、Codexの会話で扱う情報量は、依頼文、読み込んだ資料、会話の記録などに関係します。どちらも「容量」と呼ばれることがありますが、確認する画面も対処の方法も異なります。
会話が長くなったときに情報をまとめる処理と、PCに残ったファイルを整理する操作も別です。会話が短く見えるようになっただけで、保存済みの記録がディスクから消えたとは判断できません。また、古いファイルを取り除けば、現在の会話で読み込める情報量が増えるという関係もありません。
| 確かめたいこと | 見る対象 | 記録する単位 |
|---|---|---|
| PCに新しいファイルを保存できるか | 利用中のドライブ | 空きGBなど |
| Codexの記録がどれだけ場所を使うか | 状態保存先のファイル | バイト、MiB、GiBなど |
| 作業の成果物が大きくなっているか | 作業フォルダー | ファイル別・フォルダー別の大きさ |
| 会話に資料を入れすぎていないか | 現在の会話と参照資料 | 表示される会話の情報量 |
以下はPC側の保存容量を確認する手順です。利用上限や残高についての表示が出ている場合は、表示文をそのまま控え、保存容量の不足と同じ原因だと決めつけないことが出発点になります。
Windowsで保存先とファイルの大きさを調べる
公式の保存先に関する資料は、Codexの状態保存先をCODEX_HOME、初期値を~/.codexとしています。ここには設定やログ、セッションなどの状態が置かれます。Windowsで通常のユーザーとしてCLIを利用している場合は、ユーザーフォルダー配下の.codexを候補として確認します。
以下のコードは、手元で容量を調べるための読み取り用の例です。記事作成時に読者のPCを測定した結果ではありません。Codex CLIを普段使っているPowerShellで実行してください。WSLの中で使っているCodexについては、Windows側で選んだ場所が同じ保存先とは限らないため、その環境の保存先を別に調べます。
Step 1: 実際の保存先を確かめる
まず、現在のPowerShellでCODEX_HOMEが指定されているかを調べ、未指定ならユーザーフォルダー配下を候補にします。フォルダーが存在することも確認します。存在しない場合は、別の利用環境や設定が考えられるので、そのまま新しい保存先を作らず、Codexを起動している環境を見直してください。
$codexStatePath = if ($env:CODEX_HOME) {
$env:CODEX_HOME
} else {
Join-Path $env:USERPROFILE '.codex'
}
$codexStatePath
Test-Path -LiteralPath $codexStatePath
この例は現在のPowerShellに引き継がれた値を使います。別のアプリから起動したCodexが違う値を受け取っていれば、同じ結果にならない可能性があります。普段の利用環境と同じ場所で確認することが、測定の前提です。
Step 2: 全体の大きさと大きなファイルを確認する
保存先が確認できたら、配下のファイルの大きさを合計し、大きい順に上位を表示します。以下では内容を開かず、名前と大きさを調べます。読み取りに失敗した表示があれば、合計に含まれていないファイルがある可能性を記録してください。エラーを無視した数値を、保存先の完全な測定結果として扱わないことが大切です。
$codexStateFiles = @(
Get-ChildItem -LiteralPath $codexStatePath -File -Recurse -Force
)
$codexTotalBytes = (
$codexStateFiles | Measure-Object -Property Length -Sum
).Sum
[math]::Round($codexTotalBytes / 1GB, 3)
$codexStateFiles |
Sort-Object Length -Descending |
Select-Object -First 15 FullName, Length, LastWriteTime
PowerShellの1GBは1,073,741,824バイトなので、ここで算出する値はGiB相当です。合計はファイルの論理的な長さを足したもので、ドライブ上で実際に占める領域と完全に一致するとは限りません。Windowsのフォルダーのプロパティにあるサイズ表示も合わせて確認すると、違いを把握しやすくなります。
Step 3: 保存先の外側にあるデータも確認する
保存先の合計が小さいのにドライブの空きが少ない場合は、作業フォルダーを次の対象にします。ダウンロードした資料、生成した画像、開発に必要な追加ファイルなどは、Codexの状態保存先とは別の場所にあることがあります。対象を切り替える際はフォルダーを明示して、同じ方法で大きなファイルを調べます。
公式資料には、データベースの保存場所を指定するCODEX_SQLITE_HOMEも記載されています。さらにsqlite_homeの設定が優先されるため、状態保存先だけを測って全データを確認できたと断定しないでください。指定がある場合は、その保存先も測定対象に加えます。
履歴とセッションは保存場所ごとに確認する
公式のトラブル対応資料では、セッションの記録がCODEX_HOME/sessions、アーカイブしたセッションがCODEX_HOME/archived_sessionsにあると案内されています。容量の内訳を調べるときは、これらが存在するか、上位の大きなファイルがどちらに属するかを確認します。
アーカイブした会話が一覧で見えにくくなったことと、PCの保存容量が減ったことは同じではありません。公式資料がアーカイブ済みの保存場所を別に案内している以上、整理後の空き容量は実測で確かめる必要があります。見た目の会話数を容量の代わりに数えると、保存データの増減を見落とします。
また、詳細設定の資料では、状態保存先にconfig.tomlや、履歴保存が有効な場合のhistory.jsonl、ログやキャッシュなどがあると説明されています。すべてを同じ種類の「不要な履歴」と扱うと、設定や再開に必要な情報まで失うおそれがあります。
大きなファイルの名前と更新日時を見た後は、どの作業で増えたかを記録します。会話の本文やログを共有する必要がある場合は、業務資料や個人情報が含まれていないか確認してください。容量相談だけなら、まずは本文を含めない一覧と合計値で状況を説明できます。
履歴ファイルに上限を設ける場合の手順
今後の履歴ファイルの増加を抑えたい場合は、公式のhistory.max_bytesを検討できます。設定リファレンスでは、指定したバイト数を上限に、古い項目を落とす設定として説明されています。対象は履歴ファイルであり、セッションの保存フォルダーや作業成果物を含む全体の上限ではありません。
この設定は、履歴ファイルが容量の問題に関係していると確かめた後に選びます。大きいファイルが別の場所に集中している場合、履歴の上限を変えても期待した空き容量を得られない可能性があります。設定を変える理由と、変えた後に確認する数値を先に決めておきます。
Step 4: 残したい履歴と現在の設定を確認する
上限を設けると古い項目が残らない場合があるため、後から参照したい依頼や判断を確認します。必要な記録を保管するなら、保存先と扱える人を決めておきます。次に利用中のconfig.tomlを開き、すでに[history]があるか調べます。同じ見出しを重ねて追加せず、既存の設定を読んだうえで値を調整してください。
Step 5: 上限の値を指定して結果を観察する
公式資料には100 MiBを指定する例があります。以下はその値を使った設定例です。100 MiBは全員に必要な推奨容量ではありません。残したい履歴と手元の保存容量に応じて判断します。設定後は通常の利用を通じて履歴ファイルの変化を確認し、保存データ全体の合計も再測定します。
[history]
max_bytes = 104857600
履歴保存を止めるpersistence = "none"も公式に案内されていますが、これを指定しただけで既存データの全削除や全セッションの容量削減が行われるとは読めません。記録を残す必要と、今後の増加を抑える必要を比較して選びます。設定変更の前後に同じ測定方法を使うと、効果の有無を確かめやすくなります。
整理する前に残す記録と判断基準
保存容量を調べた後は、全体の大きさ、主な保存場所、特に大きなファイル、再開したい作業の有無を記録します。以下は未記入の確認表です。公式の必要容量や測定済みの結果ではなく、手元の状況を整理するためのひな形として使えます。測定できなかった場所も残すことで、調査の範囲を後から説明できます。
| 記録項目 | 手元で確認した内容 |
|---|---|
| 測定日時と利用環境 | 未記入 |
| Codexの状態保存先 | 未記入 |
| 別に指定された保存先 | 未記入 |
| ドライブの空き容量 | 未記入 |
| 状態保存先のファイル合計 | 未記入 |
| 大きいファイルの名前と大きさ | 未記入 |
| 測定時の読み取りエラー | 未記入 |
| 残したい会話や設定 | 未記入 |
| 次に確認する場所 | 未記入 |
整理が必要かどうかは、空き容量と必要な記録の両方から判断します。保存先全体の削除を初手にすると、容量の原因を特定できないまま設定や記録を失う可能性があります。大きい場所が分かっても、名前だけで不要と判断せず、用途と保管の必要性を確認してください。
容量が十分にある場合でも、同じ方法で数日後に測れば、増加している場所を見つけやすくなります。作業内容が違う日の数値はその違いも記録します。Codexの容量確認で役立つのは、保存先を特定し、ファイルの大きさを測り、履歴設定の対象を理解したうえで、必要な記録を残す判断につなげることです。