この記事は Zenn と note にも同じ内容を載せています。Zenn: https://zenn.dev/suisei498/articles/8b9b9edde7768b ／ note: https://note.com/suisei498/n/ne840430df72c

Claude Code で、同じ会話を何日も続けて作業しています。自宅のPCで動かしている自動売買や、動画の自動投稿の保守です。

長く続けると、ある時点で会話が自動で圧縮（それまでのやり取りが要約に置き換わる）されます。これが何トークンで起きるのかを、会話の記録ファイルから実測しました。3回分の記録と、それに備えて何をしているかを書きます。

※数字は私の環境での観測値です。モデルや設定で変わりうるので、目安として読んでください。

測り方：会話の記録ファイルの usage を足す

Claude Code は会話ごとに、記録を JSON Lines 形式で残しています。

~/.claude/projects/<プロジェクト>/<セッションID>.jsonl

アシスタントの各応答には usage があり、そのとき読み込んだトークン数が入っています。キャッシュから読んだ分も含めて3つを足すと、その時点で会話がどれだけ積み上がっているかになります。

import json

def ctx_series(path):
    rows = []
    for line in open(path, encoding="utf-8"):
        try:
            d = json.loads(line)
        except ValueError:
            continue
        if d.get("type") != "assistant":
            continue
        u = (d.get("message") or {}).get("usage")
        if not u:
            continue
        n = (u.get("input_tokens", 0)
             + u.get("cache_creation_input_tokens", 0)
             + u.get("cache_read_input_tokens", 0))
        rows.append((d.get("timestamp", ""), n))
    return rows

rows = ctx_series(r"C:\Users\<ユーザー>\.claude\projects\<プロジェクト>\<セッションID>.jsonl")
prev = None
for ts, n in rows:
    # 直前の半分以下に落ちたら、そこで圧縮が起きたとみなす
    if prev and n < prev[1] * 0.5:
        print("圧縮", prev[0], prev[1], "->", ts, n)
    prev = (ts, n)

実測：3回とも 93万〜98万トークンで起きた

日時（UTC）	圧縮の直前	圧縮の直後
2026-09-14 23:32	976,071	98,581
2026-09-24 08:03	937,609	81,560
2026-09-26 17:58	965,169	89,911

3回とも、93万〜98万トークンのあたりで起きていました
圧縮の後は 8万〜10万トークンから再開しています。要約と、毎回読み込まれる設定（CLAUDE.md など）の分です

画面の「%」と合わなかった

一方で、65万トークンの時点で、画面に「97%」と出たことがありました。実測の圧縮点（93万〜98万）から逆算すると、計算が合いません。

どちらが正しいのか、まだ説明できていません。なので、% では判断せず、トークンの生の数で判断することにしました。

圧縮で何が困るのか：要約は記録ではない

圧縮の後も会話は続けられます。要約には「何をしていたか」はかなり残ります。

困るのは、要約から落ちやすいものです。

測った値（何件だったか、何秒だったか）
ファイルの版を示す識別子（どの版を配ったか）
自分が間違えた記録（何を誤り、どう直したか）

どれも、後で「あのとき確かに測った」と言うための根拠です。要約に「確認済み」とだけ残ると、何をもって確認したのかが分からなくなります。

備え：引き継ぎ書と、2つの合図

1. 90万トークンで「引き継ぎ書を書け」と出す

上の測り方で、今の会話の大きさを測る小さなスクリプトを置いています。90万トークンを超えたら「引き継ぎ書を書く」合図を出します。圧縮点の実測（93万〜）より少し手前です。

引き継ぎ書には、要約から落ちる3つ（測った値・識別子・誤りの記録）を書きます。圧縮の前に書いておけば、圧縮の後で読める。これが唯一の、消えない記録です。

2. 圧縮が起きたら「引き継ぎ書を読め」と出す

同じスクリプトが、**前回測ったときより半分以下に落ちていたら「圧縮が起きた」**と判定し、その高さを台帳に残します。上の表の1行目と2行目は、この台帳から取りました。

3. CLAUDE.md に「圧縮の後はまず引き継ぎ書を読む」と書く

CLAUDE.md は会話の最初に毎回読み込まれるので、圧縮されても残ります。ここに「圧縮されたら、要約だけで続けずに、引き継ぎ書の最新の節から読む」と書いておきます。

CLAUDE.md 自体は短く保ちます。圧縮で落ちたら困ることだけを書き、細かいことは引き継ぎ書に置きます。

踏んだ穴：測る会話を取り違えていた

このスクリプトで、2回つまずきました。

1回目：最初の版は「直近30分に書き込まれた会話ファイル」だけを測る作りでした。席を外していると何も測れず、「測れません」と出て、合図が自動で出ない状態になっていました。直近30分に無ければ、全体で一番新しいものに落とすよう直しました。

2回目：その「一番新しい会話ファイル」は、同じPCで別の会話が動いていると、そちらを選びます。ある日「62万トークン、まだ余裕」と報告した数字が、実は別の会話のものでした。測り直すと、作業中の会話は44万トークンでした（このときは、どちらでも余裕がある範囲だったので実害はありませんでした）。

数字を出すときは、どの会話の数字かも一緒に出す。当たり前ですが、自分で作った見張りで、それを外していました。

まとめ

自動圧縮は、私の環境では 93万〜98万トークンで3回起きた。圧縮後は 8万〜10万から再開
画面の % とは合わないので、生のトークン数で見る
要約から落ちる「測った値・識別子・誤りの記録」は、圧縮の前に引き継ぎ書へ
合図は 90万で「書け」、半分以下に落ちたら「読め」。CLAUDE.md に「圧縮後はまず読む」
測るときは、どの会話を測ったかを必ず添える