何が不足していたか

トークンの量を測って、それをコストの大きさとして語っていました。

単価が違います。

入力（非キャッシュ）   1.0     ← これを基準にすると
キャッシュ書込        1.25
キャッシュ読出        0.1     ← **1/10**
出力                 5.0

キャッシュ読出は入力の1/10、出力に対しては1/50の単価です。
量で何倍あっても、金額はその比では効きません。

この点は、@Tsutomu_eng さんが
「キャッシュ読出がトークンの81倍」はコストの話ではなかった
で明示的に指摘されています。トークンで81倍のものが、金額では1.62倍だったという測定です。

私はこの型を踏んでいました。

自分のログで測り直した

Claude Code はセッションごとの usage を手元に保存しています。推測せずに数えられます。

対象   ~/.claude/projects/**/*.jsonl   167ファイル
       usage を持つターン **25,574**（claude-opus-5 / claude-sonnet-5）

結果です。

種別                    トークン        量の%     額の%
入力（非キャッシュ）          51,126     0.0%     0.0%
キャッシュ書込         224,263,066     3.4%    **27.7%**
キャッシュ読出       6,402,387,834    96.3%    **63.2%**
出力                  18,607,112     0.3%     9.2%

キャッシュ読出は、出力の344倍（トークン量）。金額比では6.88倍。

344倍 → 6.88倍   **50倍の開きがある**

「344倍」を根拠に何かを削っていたら、50分の1の効果しか出ない場所を削っていました。

そして、結論が分かれた

同じ測定を、別の環境でやると、こうなります。

                読出（額）   書込（額）   その人の結論
@Tsutomu_eng     41.6%      32.7%      「コストの話ではなかった」
こちら           63.2%      27.7%      **読出が依然として最大**

**どちらの計算も正しいはずです。**環境が違うだけです。

分かれた理由は、使い方だと考えています。

長いセッションを少数   読み直す量が積み上がる  → **読出が効く**
短いセッションを多数   毎回書き直しが発生する  → **書込が効く**

キャッシュ書込は、assistant のターンのほぼ毎回発生します。
セッションを短く切れば書込の回数が増え、長く続ければ読出の量が増える。
どちらが効くかは、その人の回し方で決まります。

だから、両方に共通することだけが持ち出せる

環境をまたいで成り立ったのは、この2つでした。

1  **トークン量の構成比 ≠ 金額の構成比**
   こちら 96.3% → 63.2% ／ 向こう 81倍 → 1.62倍
   **どちらも、量で見ると大きく外す**

2  **キャッシュ書込は、量に対して金額が重い**
   こちら 量3.4% → 額27.7%（**8倍**）
   向こう 量6.3%（読出比） → 額32.7%

「どちらが最大か」は環境依存です。「量では測れない」は環境依存ではありません。

手元で測る

外部データを使いません。自分のログを読むだけです。

# -*- coding: utf-8 -*-
"""自分のセッションログから、トークンの内訳と金額の構成比を出す。"""
import collections, io, json, os, sys

sys.stdout.reconfigure(encoding="utf-8", errors="replace")

ROOT = os.path.expanduser("~/.claude/projects")
KEYS = ("input_tokens", "cache_creation_input_tokens",
        "cache_read_input_tokens", "output_tokens")
LABEL = {"input_tokens": "入力(非キャッシュ)",
         "cache_creation_input_tokens": "キャッシュ書込",
         "cache_read_input_tokens": "キャッシュ読出",
         "output_tokens": "出力"}
# **単価は「比」だけを使う。**絶対額はモデルとプランで変わる
RATIO = {"input_tokens": 1.0, "cache_creation_input_tokens": 1.25,
         "cache_read_input_tokens": 0.1, "output_tokens": 5.0}

tot, turns, files = collections.Counter(), 0, 0
for root, _dirs, names in os.walk(ROOT):
    for n in names:
        if not n.endswith(".jsonl"):
            continue
        files += 1
        for line in io.open(os.path.join(root, n), encoding="utf-8", errors="ignore"):
            if '"usage"' not in line:
                continue
            try:
                o = json.loads(line)
            except Exception:
                continue
            u = (o.get("message") or {}).get("usage") or o.get("usage")
            if not isinstance(u, dict):
                continue
            turns += 1
            for k in KEYS:
                tot[k] += int(u.get(k) or 0)

S = sum(tot[k] for k in KEYS)
cost = {k: tot[k] * RATIO[k] for k in KEYS}
C = sum(cost.values())
print(f"ファイル {files} / usage を持つターン {turns}\n")
print(f"{'種別':<18}{'トークン':>16}{'量の%':>9}{'額の%':>9}")
for k in KEYS:
    print(f"{LABEL[k]:<18}{tot[k]:>16,}{100*tot[k]/S:>8.1f}%{100*cost[k]/C:>8.1f}%")
print(f"\n読出は出力の {tot['cache_read_input_tokens']/max(tot['output_tokens'],1):.1f} 倍（量）"
      f" / {cost['cache_read_input_tokens']/max(cost['output_tokens'],1):.2f} 倍（額）")

**単価は比だけを使っています。**絶対額はモデルとプランで変わるうえ、
この記事の主張に絶対額は要らないからです。構成比だけで結論が出ます。

定額プランを使っている場合、この金額比はそのまま請求額にはなりません。
測っているのは消費の構成であって、課金の仕組みではありません。
それでも「どこを削ると効くか」の判断には、量ではなく額の構成比を見る必要があります。

訂正したこと

前の記事に追記を入れました。

残した   結論の向き ―― **読出が金額でも最大（63.2%）**。これは自分の環境では正しかった
直した   倍率の書き方 ―― 344倍ではなく **6.88倍**
足した   量と額は別物である、という但し書き

結論が間違っていたのではなく、根拠の単位が間違っていました。
そして単位が間違っていると、たまたま結論が合っていても、次で外します。

まとめ

1  トークン数はコストの代理変数にならない。**単価が50倍違うものを足している**
2  自分のログで測ると、量96.3% のものが額では63.2% だった
3  **同じ測定でも、環境が違えば結論が分かれる**（読出が最大か、書込が重いか）
4  環境をまたいで成り立つのは「**量では測れない**」のほうだけ
5  代理変数を、本体として語らない

5番目が、この件で足した検査です。
トークン数を根拠に何かを主張するときは、必ず単価を掛けてから書く。

この連載は、実際に測った数字だけで書いています。
同じことを試す人の役に立ちそうなら、ストックしておいてください。

この連載

AIエージェントを実際に回して、かかった費用と壊れた箇所を測って書いています。推測は書きません。実測値だけです。

Claude Code のトークン使用量を実測したら1ターン23万 ― 節約に効いたのは「セッションを切る」だった
https://qiita.com/manabu49-ai/items/2598a30d5140e4445ab6
57分間、死んだジョブを誰も見ていなかった ― AIエージェントの見張りを機械に渡す
https://qiita.com/manabu49-ai/items/5c7506c94b5be58c040e
AIに100通り試させたら、効果ゼロなのに5個が「有意」だった
https://qiita.com/manabu49-ai/items/397a018948e1ab7ef29e
仕様書は2日前から手元にあった ― 読まずに実装した対処が、データを永久に失う設計だった
https://qiita.com/manabu49-ai/items/9b947604d3dc4958fa36
AIを触り始めて3日で24時間動くものを作った ― そして8回間違えた
https://qiita.com/manabu49-ai/items/acd01b13abe9c8cbea16
同じデータを2つのAIに測らせたら、中央値が5通り出た ― 全部、計算は正しかった
https://qiita.com/manabu49-ai/items/dc699a8458b129d6be39
本記事 ― トークン数はコストの代理変数にならない
次 ― 「できました」の的中率を測り続けた結果（未公開）

番外 ― Qiitaで何が読まれるかを3,478本から探した ― 106通り掃いて、残ったのは6つだけだった
https://qiita.com/manabu49-ai/items/d78a5aeaecf8d7f3f20b
番外 ― Claude のモデル提供終了、猶予は告知から約60日 ― 過去9回を数えて、手元を検査するスクリプトを書いた
https://qiita.com/manabu49-ai/items/bc2a7be2a6ee4ceb6185

**無料記事は結論まで全部書きます。**出し惜しみはしません。