AI 注目記事

【2026年9月2日】SSD問題は改善したものの、別のストレージ問題が明らかに

記事内に広告・プロモーションを含む場合があります。

logs_2.sqliteは削除しても小さくならない場合がある

CodexのSSD高負荷問題について、その後も継続して状況を追っています。

2026年9月2日時点の結論としては、当初問題となっていた極端なSSDへの書き込みは大幅に改善されていますが、Codexのローカルデータ保存に関する問題がすべて解決したわけではありません。

むしろ調査が進んだことで、単純な「SSDへの大量書き込み」だけではなく、SQLite・WAL・JSONLなど複数の問題が関係していることが分かってきました。

以前から紹介しているCodexのSQLiteログ、

C:\Users\ユーザー名\.codex\logs_2.sqlite

について、新たな問題が明らかになっています。

Codex側で古いログを削除しても、SQLite内部で解放された領域がWindowsへすぐ返却されるわけではありません。

そのため、

ログを書き込む
↓
logs_2.sqliteが大きくなる
↓
古いログを削除
↓
SQLite内部では空き領域になる
↓
しかしファイル自体は小さくならない

という状態になることがあります。

つまり「古いログが削除されている＝SSD容量も元に戻っている」とは限らないということです。

DesktopとVS Code版Codexの同時利用にも注意

8月末には、Codex DesktopとVS CodeのCodex拡張を同時に使用した環境で、SQLiteのWALファイルが異常に大きくなったという報告も出ています。

問題となるのはこちらです。

C:\Users\ユーザー名\.codex\logs_2.sqlite-wal

報告された環境では、

logs_2.sqlite       約40KB
logs_2.sqlite-wal   約415MB

という状態になっていました。

DesktopとVS Code側のCodexが同じ .codex ディレクトリを共有し、複数のプロセスからSQLiteへアクセスしたことが関係している可能性が指摘されています。

Codex DesktopとVS Code拡張を併用している場合は、logs_2.sqlite-walの容量も確認しておいた方がよさそうです。

rollout-*.jsonlの巨大化も未解決

私の環境でも以前確認した、

C:\Users\ユーザー名\.codex\sessions

に保存される

rollout-*.jsonl

の巨大化についても、問題がなくなったわけではありません。

最近の報告では、長期間使用したセッションだけでなく、画像や大量のコマンド出力を含むセッションでJSONLが急激に大きくなるケースも確認されています。

さらに、コマンドの実行結果が複数の形式で保存され、同じようなデータが重複してディスク容量を消費している可能性も指摘されています。

そのため、

「SQLiteログだけ確認すれば大丈夫」

という状況ではありません。

新たにthread_history_1.sqliteも確認対象に

最近の報告では、

C:\Users\ユーザー名\.codex\thread_history_1.sqlite

という履歴データベースの肥大化についても指摘されています。

今後Codexの使用容量を調べる場合は、

sessions\rollout-*.jsonl
logs_2.sqlite
logs_2.sqlite-wal
thread_history_1.sqlite

あたりを確認しておいた方がよさそうです。

.codex全体の容量を確認する方法

PowerShellから次のコマンドを実行すると、.codex全体の使用容量を確認できます。

$size = (Get-ChildItem "C:\Users\ユーザー名\.codex" -Recurse -File |
Measure-Object Length -Sum).Sum

"{0:N2} GB" -f ($size / 1GB)

さらに、大きなファイルを容量順に確認する場合はこちらです。

Get-ChildItem "C:\Users\ユーザー名\.codex" -Recurse -File |
Sort-Object Length -Descending |
Select-Object @{Name="SizeGB";Expression={[math]::Round($_.Length/1GB,3)}},
              FullName |
Format-Table -AutoSize

これならSQLiteだけでなく、巨大化したJSONLなどもまとめて発見できます。

重要なセッションは削除前にバックアップを

以前の記事では、不要になった巨大なJSONLセッションを整理する方法についても紹介しました。

しかし、その後の状況を踏まえると、重要なセッションについては削除する前にバックアップすることをおすすめします。

rollout-*.jsonlは単なる一時キャッシュではなく、過去のCodexセッションを復元するための重要なデータでもあります。

容量が大きいからといって無条件で削除するのではなく、

不要なセッション → 整理を検討

重要なセッション → バックアップ

現在使用中のセッション → 基本的に触らない

という運用の方が安全です。

9月2日時点での結論

今回の問題を最初に調べ始めた頃は、

「CodexがTRACEログを大量にSSDへ書き込んでいる」

という比較的単純な問題だと思っていました。

しかし、その後の調査やアップデート、ユーザーからの報告を見ると、

TRACEログ
↓
logs_2.sqlite
↓
SQLite WAL
↓
rollout JSONL
↓
thread_history
↓
長期間利用によるローカルデータ肥大化

と、Codexのローカルデータ管理全体に関係する問題であることが分かってきました。

当初のような極端なTRACEログ書き込みについては大幅に改善されています。

そのため、現在のCodexを「常にSSDへ異常な量を書き込むソフト」と評価するのは正確ではありません。

しかし、2026年9月2日時点でもSQLite/WALの肥大化、巨大なJSONLセッション、履歴データの増加などについては注意が必要です。

長時間Codexを利用している方は、時々

C:\Users\ユーザー名\.codex

の容量を確認しておくことをおすすめします。

私自身も今後のCodexアップデートを引き続き確認し、ストレージ問題について大きな改善や正式な修正が確認できた場合は、この記事へ追記していく予定です。

それではここまでご覧いただきありがとうございます！

次回もよろしくお願いします


-AI, 注目記事