/compactを7日計測、Opus4.7で0発火

Claude CodeのOpus 4.7で /compact を7日計測しました。560セッションで、auto-compactは1度も発火しませんでした。手動の /compact もゼロです。計測前の予想は「3日に1回は出るだろう」で、実測は「出なかった」でした。期待していた派手なイベントは、週をまたいでも姿を見せませんでした。

計測期間は2026-10-05 00:00 ~ 2026-10-12 11:00 (JST) の約7日間、母集団は ~/.claude/projects/**/*.jsonl に残っているすべてのセッションです。auto発火は isCompactSummary: true の行、手動 /compact は <command-name>/compact</command-name> の行で数えました。

結果はこの表のとおりです。

母数560セッションのうち、閾値付近に行ったものは1つもありません。P99で219K、最大で252K。公式ドキュメントが示すOpus 4.7のauto-compact閾値約967Kに対し、実測の最大でも4分の1強しか埋まっていませんでした。閾値まで3.8倍の余白を残したまま、ほぼ全部のセッションが終わっていた、ということです。

公式ドキュメントが言う閾値

前提の確認です。Claude Codeの /autocompact のドキュメントによると、auto-compactの発火閾値はモデルの実コンテキスト窓に対して決まります。

出典: Set the auto-compact window — Claude Code Docs。閾値は /autocompact 500k のようにセッション単位・モデル単位で縮められますし、CLAUDE_CODE_AUTO_COMPACT_WINDOW 環境変数で全プロセスに強制することもできます。

私は閾値を縮める設定を入れていません。それで967Kのままの運用になります。

なぜ発火しないのか

発火しない理由は、1つのセッションが短いからです。コンテキストが閾値に届く前にセッションが終わっています。

計測期間の1日あたりセッション数はこうでした。

1日40~110セッションです。母数が多いのは harness-ops 側で claude -p を使うcronジョブが毎日数十回走るためで、これらは1タスク完結の非対話ジョブです。往復が数回で終わるので、cronが生むセッションのmax contextは中央値86Kに引っ張られる側に落ちます。閾値には届きません。

対話セッションも、私は作業がひと段落すると /clear を打つか、新しいターミナルで起動し直す癖があります。これは意図した運用というより、個人の手癖に近いです。朝のPlan Modeから実装、テストで作業が切れたら、だいたい新しいセッションに移っています。

結果として、auto-compactが本来救うはずの「長時間同一セッション」そのものが、日常の中にほぼ存在しません。「発火してほしい」のではなく、「発火する条件に向かうセッションがそもそもない」が正しい表現でした。

30日に広げると60件、集中は3日

7日の母数で0回だと、「本当にauto-compactは機能しているのか」という疑いが出てきます。母数を広げてみました。

計測期間を2026-09-13 ~ 2026-10-12 (30日) にすると、こう変わります。

30日に広げると発火自体はあります。ただし分布が偏っていました。

30件のうち24件が2026-09-28〜30の72時間に集中していました。この3日間はiris-hubの長時間調査タスクを連続で走らせていた期間です。発火30件中29件がiris-hubプロジェクト、残り1件はworktreeで、プロジェクト分布でもほぼ単一のタスク群にまとまっています。auto-compactは「毎週定期的に出るイベント」ではなく、「特定の作業の密度を映す兆候」でした。

7日のゼロは「compactが壊れている」ではありません。「このウィンドウには対象の作業が入っていなかった」です。

「auto-compactが出た」を観測器として扱う

7日の0回と30日の集中を並べて、私の運用で /compact の位置が変わりました。auto-compactを「出てほしくないイベント」として警戒するよりも、「出たら作業密度を疑う計測器」として扱うほうが実態に合います。

• 1日に数回auto-compactが出た → 単一セッションを引き伸ばしすぎている、/clear の判断を遅らせている
• 週をまたいで一度も出ない → 短セッション運用が機能している。閾値を縮めても損はしない
• 突然出始めた → ワークフローの変化。前日何を変えたか見るとよい

自分では「auto-compactの手前で /compact を打つ」運用を意識していたつもりでした。計測してみたら「打つ」が0回で、むしろ /clear が本線になっていました。意識と実測の差は、2週間に1回くらいは棚卸ししてもいいかもしれません。

補足: 計測のうえでの注意

発火を数えるとき、~/.claude/projects/**/*.jsonl のmtimeで窓を区切るとズレます。古いセッションを claude --resume で再開するとファイルのmtimeは更新されますが、中身の isCompactSummary 行のタイムスタンプは発火した当時のままです。mtime基準で数えると、窓の前に起きた発火をカウントしてしまいます。

私は最初mtime基準で数えて、「窓内発火3件」と出ました。中身のタイムスタンプを見たら、3件とも窓の前 (2026-09-30 / 10-02 / 10-04) に発生していて、窓内で再開しただけでした。本記事の数字はすべて行のタイムスタンプ基準に揃えてあります。

参考までに、JST基準で窓を切る最小コードはこうです。

import json, glob
from datetime import datetime, timezone, timedelta

jst = timezone(timedelta(hours=9))
start = datetime(2026, 10, 5, 0, 0, tzinfo=jst)
end = datetime(2026, 10, 12, 11, 0, 0, tzinfo=jst)

sessions, fires = set(), 0
for f in glob.glob("/home/you/.claude/projects/**/*.jsonl", recursive=True):
    for line in open(f):
        try:
            d = json.loads(line)
        except Exception:
            continue
        ts = d.get("timestamp")
        if not ts:
            continue
        t = datetime.fromisoformat(ts.replace("Z", "+00:00")).astimezone(jst)
        if not (start <= t <= end):
            continue
        if d.get("sessionId"):
            sessions.add(d["sessionId"])
        if d.get("isCompactSummary") is True:
            fires += 1

print(len(sessions), fires)

手動 /compact を数えるときにも同じ罠があります。session_id (旧) と sessionId (新) が別の値になる履歴 (resume経由) があり、grep一発だと重複に見える重複でないケースが混ざります。sessionIdのユニーク化で素直に数えるのが安全です。

まとめ

• Opus 4.7で7日、560セッション、auto-compact 0回。手動 /compact も0回
• 公式ドキュメントの閾値約967Kに対し、実測最大252K。閾値まで3.8倍の余白
• 30日に広げると60件、うち24件が3日間に集中。auto-compactは作業密度のシグナル
• auto-compactを「警戒するイベント」から「観測器」に読み替えたほうが実態に合う

関連記事: Claude Codeを/clearせず9時間動かした日、コンテキストはどこで腐り始めたのか / compact-plus 派生 v0.2 リリース