この Issue を読んでまず思ったのは、「ログって便利だけど、やりすぎると普通に凶器になるんだな」ということです。ふだんログは、何か問題が起きたときに頼る“記録係”みたいな存在です。でも Codex のこの件では、その記録係がほぼ24時間、延々とメモを取り続けていたわけです。しかも保存先は SQLite データベース。これは軽く見えるけれど、書き込みが多すぎると話が変わります。
この Issue のタイトルはかなり直接的で、要するに「Codex の SQLite feedback logs が、年間約640TBもの書き込みを生み、SSD の耐久性を急速に消耗させる」という警告です。報告したユーザーは、実機で21日ほど動かしたところ、メインSSDの総書き込み量が約37TBに達していたと書いています。そこから単純に年換算すると、約640TB/年。1TB SSD なら“ドライブ全体を書き換える”レベルの動きが、年に何百回も起こりうる計算です。普通にぞっとします。
特に面白いのは、見た目のDBサイズだけでは本当の負荷が見えない点です。報告では、logs_2.sqlite の実サイズは約1.2GiBなのに、内部の row id は 55億を超えていました。つまり、最終的に残っているログはそこまで多くないのに、その裏で大量の挿入と削除が走っていた、ということです。SQLite はデータをただ1回書いて終わりではなく、WAL（書き込み先行ログ）やインデックス更新、チェックポイントなども絡むので、実際の書き込み量はかなり膨らみます。いわゆる書き込み増幅です。個人的には、ここがこの話のいちばん“本質的にイヤなところ”だと思いました。表面上は小さいのに、裏でずっと消耗している。
ログの中身も、かなり生々しいです。多かったのは TRACE レベルの超詳細ログや、OpenTelemetry 関連の鏡写しのようなログ、そして WebSocket や SSE の生データに近い記録でした。TRACE は一番細かいログで、開発者向けには便利ですが、常時保存するには重すぎることが多いです。しかも target=log のようなものが大量に残っていて、inotify のイベントや tokio-tungstenite の内部処理まで拾っていました。正直、ここまで行くと「デバッグのための観測」ではなく「観測そのものが仕事」になっています。
報告者は、残っているログの約70.7%が TRACE、さらに codex_otel.log_only と codex_otel.trace_safe がかなりの割合を占めると示しています。ざっくり言えば、ノイズの大半を絞るだけで、保存量を大きく減らせたはずだ、という指摘です。しかも WebSocket / SSE の生ペイロードをそのまま残すのではなく、イベント種別や成功・失敗、トークン使用量、サイズのような要約だけ保存すれば十分ではないか、という提案も出ていました。これはかなり筋がいいと思います。全部残せば安心、ではなく、必要なものだけ残すほうが運用には強いです。
この Issue が実務的にすごいのは、単なる文句では終わっていないところです。報告後、いくつかの修正PRがマージされ、2026年6月23日時点の更新では「フィードバックログの約85%を避けられるようになったので、このIssueを閉じる」と書かれています。具体的には、レスポンスの WebSocket イベントを全部ログしないようにする修正、うるさいターゲットを永続ログから除く修正、ブリッジされたログイベントを保存しない修正などが入っています。こういうのを見ると、OSSの強さって、派手な機能追加よりも、こうした地味だけど効く改善にあるのかもしれないと感じます。
それでも印象に残るのは、問題が発見されるまでのスケール感です。SSD の寿命というのは、一般の利用者だと普段まったく意識しません。壊れるのは突然に見えるし、ふつうは「そんなに書き込みはないだろう」と思いがちです。でも、エージェント型のツールや常時動く開発支援ソフトは、想像以上に裏でデータを吐きます。AI ツールが賢くなるほど、実は“観測量”も増える。このズレは今後もっと増えるはずで、似た問題は他の製品でも普通に起きるのではないかと思います。
この件で個人的にいちばん大事だと感じたのは、「ログは多ければ多いほどいい」という感覚を見直すきっかけになることです。ログは保険ですが、保険料を払いすぎると本体が傷む。だから、保存する対象を絞る、粒度を落とす、一定期間で切る、そして本当に必要なときだけ詳細を増やす、という設計が大事になります。便利なツールほど、裏側の静かな暴走を見逃しやすい。今回のIssueは、その典型例だったと思います。
