Claude Code のトークン消費を1週間計測したら、思ってたのと違う場所で溶けてた

先月、Claude Code の使用量を見て「あれ、思ったより使ってるな」とちょっとビビった。普段は定額のプランで回してるから細かい数字を気にしてなかったんだけど、自動化のスクリプトを増やしてから、なんとなく消費が増えてる感覚があった。

で、感覚で語っても仕方ないので、1週間きっちり計測してみることにした。毎日どの作業に何トークン使ったかを手元のスプレッドシートに記録して、最後に集計した。結論から言うと、一番トークンを食ってたのは「コードを書く作業」じゃなくて、まったく別のところだった。

この記事は、その1週間の実測ログと、計測して初めて気づいた無駄、そして月額換算した数字をそのまま出す。Windows 11 + Node v24 で、Claude Code（CLI）を1日2〜3時間使う、個人ブログ運営者の使い方が前提。

どうやって計測したか

Claude Code は、セッション中に /cost を打つと、そのセッションで使ったトークン数と概算コストが出てくる。これを作業の区切りごとに記録した。

> /cost
Total cost: $1.24
Total duration (API): 8m 32s
Total tokens: 412,800 (in: 389,200, out: 23,600)

入力トークン（in）と出力トークン（out）が分かれて出るのがポイント。やってみて分かったのは、僕の使い方だと圧倒的に入力トークンが多いということ。出力（Claude が書くコード）は全体の5〜6%しかなくて、残りはほぼ入力、つまり「Claude に読ませているコンテキスト」だった。

記録のフォーマットはシンプルにして、日付 / 作業内容 / inトークン / outトークン / 概算$ の5列だけ。凝った計測ツールは使わず、セッションごとに /cost を見てメモするだけにした。続けられる粒度が一番大事だと思ったので。

1週間の実測値

7日間ぶんの集計がこれ。作業をざっくり4カテゴリに分けた。

作業カテゴリ	inトークン	outトークン	概算$
記事の自動生成・添削	2,140,000	198,000	$7.30
ブログのコード修正	1,420,000	86,000	$4.60
自動化スクリプトのデバッグ	3,680,000	71,000	$11.20
雑な質問・調べもの	540,000	31,000	$1.90
合計	7,780,000	386,000	$25.00

1週間で約780万トークン、概算で $25。月に換算するとだいたい $100 前後。定額プランの範囲には収まってるけど、従量課金で使ってたら地味に効いてくる金額。

一番予想外だったのが、トップが「自動化スクリプトのデバッグ」だったこと。記事の生成が一番食ってると思い込んでたのに、実際はその1.5倍くらいデバッグで溶けてた。コードの行数は記事より全然少ないのに、なんでこんなに食うのか。理由を掘ったら、計測してよかったと心から思った。

なぜデバッグが一番食ったのか（失敗談）

原因は、僕の投げ方が雑だったこと。これに尽きる。

自動化スクリプトがエラーで落ちたとき、僕はよく「直して」とだけ投げてた。すると Claude Code は、関連しそうなファイルを片っ端から読み込んで原因を探す。スクリプトが他のファイルを import してたり、設定ファイルを参照してたりすると、その芋づるで5ファイル、6ファイルと読み込んでいく。1ファイル2,000行あれば、それだけで数万トークン。これが入力トークンを爆発させてた。

しかも、エラーが直らないとき。僕は「まだ落ちる」「これでもダメ」とだけ返してた。そのたびに Claude は、それまでの会話の全コンテキスト（読み込んだ6ファイルぶん全部）を毎回読み直す。往復が5回続けば、同じファイルを5回読ませてるのと同じことになる。デバッグの1セッションで300万トークン超えてた日のログを見たら、9割が「同じファイルの再読み込み」だった。

つまり溶けてたのは、コードの難しさじゃなくて、僕のコミュニケーションの雑さだった。これは計測しないと絶対に気づかなかった。

計測後に変えた3つの習慣

原因が分かったので、翌週から運用を変えた。効果があったものを3つ。

1つ目：エラーが出たら、エラーメッセージと該当ファイルだけを最初から指定する。「直して」じゃなくて「sumi-news-monitor/index.js の42行目でこのエラー、原因はこのあたりだと思う」まで書く。Claude が探索でファイルを読み漁る量が一気に減った。同じデバッグ作業の入力トークンが、体感で3分の1になった。

2つ目：往復が3回を超えたら、いったんセッションを切って新しく開き直す。長いセッションは、過去の会話全部を毎回コンテキストに積むから、後半になるほど1回の応答が重くなる。区切りのいいところで /clear するか、新セッションにする。これだけで後半の消費がガクッと落ちた。

3つ目：定型作業はプロンプトをテンプレ化した。記事生成みたいに毎回同じ指示を出す作業は、長い指示文を毎回書くより、ファイルに置いた指示書（AGENTS.md とか）を参照させる方が、結果的にコンテキストが安定して消費が読める。これは前にAGENTS.md の実例記事でも書いたやつが効いた。

この3つで、翌週の同じような作業量で、合計が $25 → $16 まで下がった。約35%カット。やったことは「投げ方を丁寧にしただけ」で、ツールも設定も何も変えてない。

まとめ

1週間計測して一番の収穫は、「トークンを食ってるのはコードの複雑さじゃなくて、自分の雑な投げ方だった」と数字で突きつけられたこと。感覚では「記事生成が重い」と思い込んでたのが、実際はデバッグの再読み込みで倍以上溶けてた。

もし Claude Code のコストが気になってる人がいたら、まず1週間 /cost をメモするのをおすすめする。凝ったツールはいらない。日付と作業と数字を5列でメモするだけで、自分がどこで溶かしてるかが見える。たぶん多くの人が、僕と同じで「思ってたのと違う場所」で溶かしてるはず。

次は、プロンプトキャッシュを意識的に使ったら同じ作業がどれだけ安くなるか、もう1週間計測してみる。やったらまた数字を出す。