Claude Code のセッションは、最初の応答の時点でもう 7〜9 万トークンを入力しています。自分の書いた文書（CLAUDE.md・auto memory）を削って 79K まで下げた翌日、同じ依頼文で始めたら 86K、その翌日は 88K に戻っていました。何が戻したのか、要素ごとに測りました。

先に結論

1 応答目の入力（total input）は依頼文よりも土台で決まる。同じ定型作業で始めた 7 セッション（依頼文 79〜90 字・語尾と読点の違い）: 86.2K・86.6K・88.8K・89.5K → 79.4K → 85.8K → 88.0K（input + cache_creation + cache_read）。
要素ごとに測ると（claude -p・同一依頼文・再現 ±3 トークン）: この MEMORY.md（15,340 字・134 行）をほぼ空にした差＝11,722 トークン、MCP コネクタ一式（道具名 266 種＋指示文）を外した差＝8,439 トークン。両方同時に外すと 53,925＝加算の期待値 54,072 と −147。基準は D の直後に −154 漂っていた（A4＝74,079・転写の添付は git 状態の行だけが違う）ので、A4 基準では期待 53,918 と +7（独立に足せる）。
09-17 朝の −10.1K のうち、auto memory の削減（17,781→13,574 字）で説明できるのは 最大で約 3.2K（0.76 トークン/字で換算・削る前の版も全文読まれていた場合）。翌日の +6.3K は、その間に接続した MCP コネクタ（一式で 8.4K）と同じ区間に起きています——整合しますが、コネクタ単体は分離していません。
公式には「auto memory は先頭 200 行または 25KB まで」とあります。当方の生ファイルは 29,009 バイトでしたが、転写に記録された開始時の添付には最終行まで含まれていました（3・118・119・最終行で確認）。「生ファイルの先頭 25 KB で切る」という単純な解釈とは一致しませんでした。上限をどう判定しているか（文字数か・前処理後か）は未確認です。

測り方

時系列: プロジェクトの転写（~/.claude/projects/<dir>/*.jsonl）から、各セッションの最初の assistant 応答の usage を取る。総入力＝input_tokens + cache_creation_input_tokens + cache_read_input_tokens。依頼文とフック出力を含むので、同じ定型作業で始めた系列（毎朝の案件の洗い出し・7 本・依頼文 79〜90 字）を主に見る。
分解: claude -p "1+1 を数字だけで答えて" を同じ作業ディレクトリで。A1 現状 → B MEMORY.md を 1 行に（退避→測→復元・SHA256 で一致確認・窓 7 秒）→ A2 復元後 → C --strict-mcp-config（MCP を全部外す）→ A3 現状 → 追試 D（B と C を同時に）→ A4。--system-prompt-snapshot on で、何がシステムプロンプトに載ったかを転写に記録。

4 手順（読者の環境で同じことをするなら）: ①転写の添付（または /context）で何が載っているかを見る ②usage の 3 値の和で総入力を固定する ③要素を 1 つだけ外して測る ④元に戻して基準が再現することを確かめる（今回 ±3）。⚠ -p は MCP の道具一覧が揃う前に 1 応答目が走ることがある（下の「測っていないこと」）＝**cache_read が 0 の走は同じプレフィックスではないので捨てる**。

# 転写から 1 応答目の総入力を並べる（読み取りのみ）
import json, glob, io
for f in glob.glob("*.jsonl"):
    first = None; n = 0
    for line in io.open(f, encoding="utf-8", errors="replace"):
        if '"usage"' not in line: continue
        d = json.loads(line); m = d.get("message") or {}; u = m.get("usage")
        if not u or m.get("role") != "assistant": continue
        n += 1
        if first is None:
            first = (d["timestamp"][:16], u["input_tokens"] + u["cache_creation_input_tokens"] + u["cache_read_input_tokens"], d.get("version"))
    if first and n >= 3: print(first, f[:8])

結果 1: 同じ依頼文で 7 日

開始（UTC）	1 応答目の総入力	CLI	その日までに起きたこと
09-12	86,159	2.1.266	—
09-13	86,613	2.1.266	—
09-14	88,756	2.1.270	—
09-15	89,509	2.1.270	—
09-16 21:58（＝09-17 朝 JST）	79,440	2.1.271	auto memory 183→125 行（17,781→13,574 字）・ユーザー領域のスキル 9 本をプロジェクト側へ移動
09-17 21:43	85,765	2.1.271	09-17 12:58Z に MCP コネクタ（メール配信サービス）を接続
09-18 22:42	88,045	2.1.275	CLI 更新・auto memory 134 行（15,340 字）

CLI の版は 09-17 の戻り（85,765）の時点で 2.1.271 のまま＝版上げは最初の戻りの原因ではありません。
依頼文が違う他の 13 セッションも同じ形（86〜89K → 79K → 86〜88K・±1K）でした。

結果 2: 要素を外して測る（`claude -p`）

条件	総入力	A1 との差
A1 現状	74,233	—
B `MEMORY.md` を 1 行	62,511	−11,722
A2 復元後	74,234	+1
C MCP を全部外す	65,794	−8,439
A3 現状	74,236	+3
D B＋C を同時に	53,925	−20,308（加算の期待値 −20,161・差 −147／A4 基準では +7）
A4 復元後	74,079	−154（git 状態の行が 186 字減）

公開の再現キット（scripts/measure.py・実 MEMORY.md を触らない版）で同じ日の 15:10 に測り直した値を、上の数字と同じ定義で並べます。再現するとどの程度ずれるかまで含めて公開しています。

項目	14:01 原実験（記事の数字）	15:10 再測（公開の `measure.py`）	差	意味
MEMORY.md → 1 行	−11,722	−11,797	−75	索引が 219 B 増えた分（0.76 tok/字）
MCP を全部外す	−8,439	−8,439	0	同値
両方	−20,308	−20,233	+75	—
残差（A1 基準）＝両方 − (memory＋MCP)	−147	+3	—	—
残差（同時刻の基準 A4）	+7	+5	—	基準の漂い −154／−2 を引いた値

-p（CLI 2.1.266）の土台はデスクトップアプリ（88K・CLI 2.1.270〜275）より 14K 小さい（アプリ固有の道具と指示が無い）。ここで使うのは相対差だけです。
事前走（A1 の 2 分前・同じ現状）は 73,093 でした。転写の添付を見ると MCP の道具名が 221 種（A1 は 266 種）＝MCP の接続が揃う前に 1 応答目が走っていた。cache_read も 0。同じプレフィックスかは cache_read で見分けられる（A1〜A4 は全部 36,498）。
転写の添付（--system-prompt-snapshot on）に載っていた字数: MCP の道具名 266 種＝24,390 字／CLAUDE.md＋MEMORY.md＝26,812 字／スキル一覧 9,252 字／MCP の指示文 4,861 字／git の状態 3,466 字／固定部（システム指示 9,579 字＋組み込み道具 15 本のスキーマ 149,107 字）＝毎回キャッシュ読み 36,498 トークン。
換算 0.76 トークン/字（MEMORY.md 15,340 字→11,722）。この MEMORY.md では、削った 133 行あたり平均 88 トークン。内容依存の平均で、一般の 1 行単価ではありません。

分解表（削れる／削れない／必要なときだけ）

要素	数字	証拠レベル	扱い
この MEMORY.md をほぼ空にした差	−11,722	実測	削れる: 内容依存（当方は 133 行で平均 88/行）。トピックは別ファイルへ
MCP を全部外した差	−8,439	実測	削れる: 使わない接続を外す。道具のスキーマは遅延ロード（tool search）
両方同時に外した差	−20,308	実測（加算の期待 −20,161・差 −147／同時刻の基準 A4 では +7）	独立に足せる
`cache_read`	36,498	実測値（`-p` の同一プレフィックス内で不変）	—
「cache_read＝システム指示＋組み込み道具」	—	構造からの解釈（usage は要素別に分けない）	自分の文書ではない
その他（CLAUDE.md 11,108 字・スキル一覧 9,252 字・git 状態 3,466 字・依頼文）	17,574	算術残差（トークン未測）	CLAUDE.md は path-scoped rules・未コミットを減らす
コネクタ単体（Resend など）	—	未測	—

言わないこと・測っていないこと

「メールのコネクタが 6.3K 食った」とは言いません。測ったのは MCP 一式（8.4K）で、単体は分離していません。09-17 朝の −10.1K の残り約 7K も未分離です（同日にスキル 9 本を移動している）。
公式の「先頭 200 行または 25KB」と、当方の観測（生ファイル 29,009 バイト・添付は最終行まで）は「生ファイルの先頭 25KB」という解釈とは一致しません。文字数なのか、前処理後なのか、版で違うのかは確かめていません。
分解は CLI 2.1.266（-p）、時系列はアプリ 2.1.270〜275＝版が違います。MCP の載せ方が版で変われば 8.4K も動きます。
cache_read 36,498 は -p の同一プレフィックス内の値で、アプリの転写では 39.7K〜49.8K と走ごとに違います（直前のセッションとの共有量）。「固定」は -p の走の中だけの話です。
追試の 1 本（現状・フラグ指定なし＝snapshot は既定で on）は 67,373 と 6.9K 低く、添付ではスキル一覧が 14,573 字（他は 9,252）・cache_read 0＝別のプレフィックスでした。原因は未特定なので外れ値として除外し、表には入れていません（凍結の結果ファイルには残しています）。
「メモリを減らせば速くなる」とは言いません。土台は自分の文書だけでは決まらず、翌日に測り直さないと減ったままだと思い込む——それが本件の観測です。
料金には換算しません。n＝1 プロジェクト・1 人。

この記事の本家（セッション別の usage の凍結・実験の器と結果・検証の記録）は Sumitsuke Lab → Claude Code の開始時コンテキストを分解する——memory 11.7K・MCP 8.4K、翌日 6K 戻った

AI の利用について

転写の集計・実験の器・この記事の下書きには AI（Claude Code）を使っています。数字は転写の usage と実験の出力から写し、退避・復元と公開の判断は人が行いました。依頼文の本文・案件の情報は含みません。公開している再現スクリプトは環境依存の 2 行を環境変数に出した写しで、py_compile を通しています。自分の環境で同じ 7 走を行う器（scripts/measure.py・実 MEMORY.md を触らない）と原本・データは GitHub → https://github.com/sumitsuke/claude-code-startup-context（コード MIT／データ CC BY 4.0）。

関連

前編（1 依頼の中で何が消えたか・「基礎を 8K 削ると −2.7%」）→ Claude Code の 1 依頼で消えたトークンはどこへ行くか。本件はその後日談＝削った基礎が翌日に戻った話です。

この記事は Zenn にも同じ内容を掲載しています。