あなたはコンテキストとして200,000トークンに対して料金を払っています。しかし、それらのトークンのうち、実際に有用な作業をしているのはどれくらいですか？
私たちは ClaudeTUI — Claude Code のためのモニタリングツールのセット — を作成し、各トークンを追跡するために生の JSONL トランスクリプトデータを掘り下げました。私たちが見つけたことは私たちを驚かせました：トークンの使用には4つの明確なカテゴリがあり、そのうちの1つだけがあなたの実際の作業です。
Enterを押すと何が起こるか
多くの Claude Code ユーザーが気づいていないことがあります： Enterを押すたびに、会話全体が最初から送信されます。
Claude API はステートレスです。以前のメッセージは記憶していません。ですので、1文字打つたびに、以下を含む API 呼び出しがトリガーされます：
- システムプロンプト（約14kトークン） — Claude Code の指示、ツール定義、あなたの CLAUDE.md
- 完全な会話履歴 — 最後の圧縮以降のすべてのメッセージ、すべてのツール呼び出し、すべてのツールの結果
- 新しいメッセージ
ターン1では、それはおおよそ15kトークンです。ターン15では、100k。ターン30では167kとなり、そして圧縮が作動します。
これが、セッションを進めるにつれて Claude が遅くなり、費用がかさむ理由です。Enter キーを押すたびに、前回よりも多くのトークンを処理します。これが圧縮が存在する理由でもあります。これがなければ、200kの壁にぶつかり、セッションは単に停止してしまいます。
朗報：Anthropic の プロンプトキャッシュは、これを思ったよりも痛手にしません。しかし、どう機能するのかを理解する価値はあります。
キャッシュは Anthropic のサーバーに存在します
あなたのマシンは、要求ごとに完全な会話を送信します — 毎回ネットワークを通るバイト列は同じです。最適化はサーバー側で行われます：Anthropic は「この正確なトークンの接頭辞を最近見たことがありますか？」と検索します。もしそうなら、それらの再処理をスキップし、安価な キャッシュ読み取り 料金（Opus は $15/M の代わりに $1.50/M — 10倍の割引）を適用します。
157ターンのセッションでは、私たちは すべてのトークンの98%がキャッシュ読み取り であると測定しました。これは意味があります：ターン100までには、すでにキャッシュされている履歴のうち99ターンを再送信しています。最新のコンテンツだけが高価な cache_creation パスを通ります。
キャッシュには TTL があり、会話内容の場合はおそらく約5分です。ターンの間をあまり長く間を置くと、キャッシュが期限切れとなり、次の呼び出しはすべての入力に対して完全な料金を支払います。これが圧縮が高くつく理由でもあります：キャッシュされた会話全体を破棄し、最初から cache_creation を経由する新しい要約に置換します。
もう1つ：トークンはキャッシュされていても200kのコンテキスト窓のカウントに含まれます。キャッシュはコストを削減しますが、スペースを節約するわけではありません。
では、これらのトークンが実際には何であるかを見てみましょう。
4種類のトークン
Claude Code が行うすべての API 呼び出しには、トランスクリプトにトークン使用量の内訳があります。実際のセッションで数千件の呼び出しを解析することで、4つのカテゴリを特定しました：
1. システムプロンプト（約14kトークン）— 常時課税
すべての API 呼び出しには必ずシステムプロンプトが含まれます：Claude Code の内部指示、ツール定義、安全ガイドライン、あなたの CLAUDE.md ファイル。私たちのセッションでは、これが一貫して 約14,328 トークン でした。
これは回避できるものではありません。これはインフラです。しかし、それはあなたの200kの窓のうち、実際の会話に利用できるのは約186kだけであることを意味します。
これを、圧縮イベント後の cache_read_input_tokens を見て発見しました。値は毎回正確に14,328にリセットされる — これがシステムプロンプトの床です。通常の動作では、cache_read は会話がキャッシュに蓄積されるにつれて14kから167kへと増加します。
2. 圧縮サマリ（約11–19kトークン） — 再構築コスト
圧縮が作動すると、Claude Code はあなたの会話全体を要約に圧縮します。次の API 呼び出しは、その要約を読んで文脈を再構築する必要があります。これは 圧縮の実際のオーバーヘッド です。
実際の3回の圧縮セッションから：
| 圧縮 | 要約サイズ | コスト |
|---|---|---|
| #1 | 18.8k トークン | $0.47 (Opus) |
| #2 | 10.6k トークン | $0.22 (Opus) |
| #3 | 17.8k トークン | $0.37 (Opus) |
これらの要約はロスのあるものです。あなたの167kの豊富なコンテキスト — 正確なエラーメッセージ、ファイル内容、コードスニペット — は 11–19k トークンに圧縮されます。詳細は失われます。
3. 有用な作業 — 実際に支払った内容
これがそれ以外のすべてです：あなたのプロンプト、Claude の回答、ツール呼び出し、ファイル読み取り、コード編集、テストの出力。セッションの実際の生産的内容。
4. ヘッドルーム（約33kトークン） — 未使用のバッファ
Claude Code は200kに達してから圧縮を待つことはありません。おおよそ 容量の83%（約167kトークン） でトリガーされ、圧縮処理自体のバッファとして約33kトークンを確保します。
つまり、あなたのコンテキスト窓の約16.5%は有用な作業には決して利用できません。200kの料金を支払っているのに、実際には約167kしか得られません。
実際のセッション、分解して
以下は私たちのモニタリングデータからの実際の4セグメントセッションです:
Seg 1 ▒▒▓▓████████████████████████████████████████████████░░░░░ 200.0k
14.3k system │ 152.7k useful │ 33.0k headroom │ → compacted
Seg 2 ▒▒▓▓▓████████████████████████████████████░░░░░░░░░░░░░░░ 200.0k
14.3k system │ 18.8k summary │ 114.4k useful │ 52.5k headroom │ → compacted
Seg 3 ▒▒▓▓▓████████████████████████████████████████████████░░░ 200.0k
14.3k system │ 17.8k summary │ 141.2k useful │ 33.9k headroom │ → compacted
→ Seg 4 ▒▒▓▓██████ 44.8k
14.3k system │ 10.6k summary │ 12.7k useful
Efficiency: 76% │ Wasted: 166.5k/644.8k
76% の効率 は、総トークンの76% が有用な作業に使われたことを意味します。残りの24% は圧縮サマリとヘッドルームに使われました。
Seg 1 にはサマリがないことに注意してください — 最初のセグメントで、再構築の対象はありません。Seg 2 からは、各セグメントがサマリの税を支払います。
隠れた API 呼び出し
転写には見つからない1つの事実： 圧縮サマリ生成そのもの。 Claude Code はあなたの約167kのコンテキストを読み取り要約を作成する隠れた API 呼び出しを行いますが、この呼び出しは JSONL トランスクリプトには記録されません。
圧縮イベントで見つかった preTokens メタデータに基づくと、この隠れた呼び出しは完全な圧縮前のコンテキスト（約167k トークン）を読み取ります。 Opus の料金（$1.50/M のキャッシュ読み取り）では、サマリー生成だけで概ね $0.25 の圧縮ごとの追加費用 — 再構築コストの上に乗せられます。
あなたの財布に対する意味
長い Opus セッションで3回の圧縮がある場合の計算をしてみましょう：
トークン予算：総計644.8k
| カテゴリ | トークン | コスト（Opus） | 総計に対する割合 |
|---|---|---|---|
| 有用な作業 | 490k | ~$8.50 | 76% |
| 圧縮サマリ | 47k | ~$0.85 | 7% |
| ヘッドルーム（未使用） | 108k | $0（課金なし） | 17% |
| システムプロンプト（定数） | 約43k | ~$0.06（キャッシュ） | — |
| 隠しサマリー生成 | 約500k 読み取り | ~$0.75 | — |
ヘッドルーム トークンは直接請求されません — それらは使えなかった容量を表しています。しかし、要約と非表示の呼び出しは実際のコストです。
Sonnet 4.6 を使用すれば 同じセッションは劇的に安くなります。Sonnet は最大1Mのコンテキストをサポートするので、644kトークンならゼロ圧縮に達します：
- すべてのトークンは有用な作業です
- 効率: 100%
- コスト: 約$5.50（Opusでは約$10超と比べて）
システムプロンプトの発見
おそらく最も興味深い発見は、システムプロンプトが各セグメントに対して一定の約14kの税のようなものだということです。
調査の前は、圧縮後の全コンテキストを「再構築の廃棄物」として数えていました。セグメントが 33.1k rebuild を示すと、それは圧縮オーバーヘッドの33.1kのように見えました。しかし、そのうち14.3kはシステムプロンプトで — あなたはそれを常に支払うことになります。
実際の圧縮オーバーヘッド（要約）は 33.1k - 14.3k = 18.8k のみです。これは、無駄を測定する方法における43%の差です。
どのように検出したか:
After compaction #1: cache_read = 14,328 ← system prompt
After compaction #2: cache_read = 14,328 ← same
After compaction #3: cache_read = 14,328 ← same
During normal operation: cache_read grows from 14k → 167k
cache_read の値は、すでにキャッシュされているものを正確に教えてくれます。圧縮後はシステムプロンプトのみがキャッシュに生き残り、それ以外のすべて（圧縮要約）は cache_creation を通過します。
圧縮キャッシュの構造
以下は、圧縮境界をまたいだトークンキャッシュの動作です:
圧縮前（通常動作）:
cache_read: 166,575 ← almost everything is cached
cache_creation: 312 ← tiny new content
input_tokens: 3 ← negligible
output_tokens: 126
圧縮後の最初の呼び出し:
cache_read: 14,328 ← only system prompt survives
cache_creation: 18,793 ← compaction summary, written fresh
input_tokens: 3
output_tokens: 1,249
圧縮によってキャッシュは破棄されます。キャッシュされていたすべてのもの（あなたの会話、ツールの結果、ファイルの内容）は失われます。システムプロンプトだけが存続します。別個の、より長寿命のキャッシュ（おそらく1時間のTTL対して5分の会話キャッシュ）に格納されているからです。
今すぐできる7つのこと
1. 論理的な区切りで手動で /compact を使用
167kで自動圧縮を待たないでください。機能を完成させるか、バグを修正した後で自分で圧縮してください。保存するものを指示できます:
/compact Preserve all file paths, error messages, and the list of modified files
2. 異なるタスク間で /clear を使用
実装からデバッグへ切り替えますか？新機能を始めますか？新しいクリーンなコンテキスト186kは、無関係な履歴を含む80kの古いコンテキストより優れています。
3. 詳細な作業をサブエージェントに委任
各サブエージェントには独立した200kのコンテキストウィンドウが割り当てられます。サブエージェントでテストを実行したり、大規模なコードベースを検索したり、ドキュメントを取得したりすると、冗長な出力がメインセッションを膨らませるのを防ぎます。
4. 行範囲でファイルを読む
ファイル全体を読む代わりに、必要な部分を指定してください: 「handler.ts の40行目から90行目を読む」。繰り返し同じファイルを読む可能性があるデバッグループでは特に重要です。
5. 未使用のMCPサーバを無効化
各MCPサーバは、リクエストごとにツールスキーマ全体をコンテキストに読み込みます。20ツールのサーバは、存在するだけで5-10kトークンを消費します。これは14kのシステムプロンプトに上乗せされます。
6. CLAUDE.md を200行以下に保つ
CLAUDE.md は、その約14kのシステムプロンプトの一部です。すべてのAPI呼び出しごとに読み込まれ、すべての圧縮サイクルを通過します。膨張している場合、呼び出しごとに料金が発生します。
7. 効率をモニターする
ClaudeTUI をインストールして、リアルタイムで数値を監視します。圧縮後に「Efficiency: 76%」が「Efficiency: 68%」に低下するのを見ると、コンテキスト管理についての考え方が変わります。
自分でこれを確認する方法
ClaudeTUI をインストールする:
# Via Homebrew
brew install slima4/claude-tui/claude-tui && claudetui setup
# Or directly
curl -sSL https://raw.githubusercontent.com/slima4/claude-tui/main/install.sh | bash
別の端末を開いて実行します:
claudetui monitor # live dashboard
claudetui chart # efficiency chart (standalone)
効率チャートは、セッション内の各セグメントの4成分の内訳を表示します—作業中にリアルタイムで更新されます。モニターで w を押して開く、または v を押して水平表示と垂直表示を切り替えます。
結論
すべての Claude Code セッションには、4種類のトークン使用が存在します：
- システムプロンプト（約14k） — 一定の負担、回避できないが安価です（キャッシュされています）
- 圧縮要約（各約11k〜19k） — 圧縮の実際のコスト、作業の情報損失を伴う圧縮
- 有用な作業 — 実際に支払った作業
- ヘッドルーム（約33k） — 作業に使えないバッファ
典型的な 3 回の圧縮 Opus セッションでは、約 76% のトークンが有用な作業です。残りはオーバーヘッドです。これを可視化し、各コンポーネントが実際に何であるかを理解することは、トークンをより意図的に使う第一歩です。
ClaudeTUI はオープンソースで MIT ライセンスです。Stdlib のみの Python、外部依存関係ゼロ。
GitHub: github.com/slima4/claude-tui
