/compact のコストを実ログ705回分で測った — 対話なら回収できる、バッチなら避けるべき

Claude Codeのローカルログ705回分を実測した結果から、/compact の真の代償が見えてきた。直後のターンは通常ターンの約26倍のトークンを書き直す――体感は正しかった。ただし、圧縮直前は毎ターン16万トークンをキャッシュから読み込んでいたので、その後は読み込みコストが下がる。計算では10ターン程度、実測では12ターンで当初のコストを回収できる。ここまでは理屈的な話だ。問題は、その「12ターン先まで本当に仕事が続くか」である。セッション最後の圧縮について調べると、中央値18ターンで対話が終わっているが、3件に1件は回収ポイントの12ターンに届かずに終わっている。つまり7割のケースでしか元が取れていない。

しかし、ここで最も見落とされやすい数字がある。圧縮1回にかかった時間の中央値は157秒（約2分37秒）で、705回の合計は30.7時間だ。トークンコストより時間コストが本当の負担なのだ。さらに悪いことに、この705回のうち99.6%が自動発火で、ユーザーが意図的に選んだタイミングは0.4%に過ぎない。作業の途中で無警告に2分37秒止まるという状況が、制御不能のまま繰り返されている。公式は「自然な切れ目で手動実行する」と勧めているが、ほぼ実行されていない。

AIの鬼の視点は単純だ。対話型なら十数ターンで回収できるコストも、バッチ処理なら見返りがないコストに変わる。対話では「続く可能性」があるが、バッチでは「続かない」が確定しているからだ。また /compact 以外の無駄も大きい。plan mode の切り替えはモデル切り替えと同じで、見返りなしにキャッシュを破棄している。実務的な答えは、対話セッションと バッチ処理で戦略を完全に分けることだ。対話なら自分が切れ目を認識してから叩く。バッチなら圧縮そのものを避けるか、セッション設計の段階で文脈肥大化を防ぐ。同じ仕組みなのに、モードで推奨が逆になる。その逆転点を理解しているかどうかが、実務でのコスト差になる。