*【ポエム】 Claude トークン消費を制御する — 「長く使う」ためのコツ

トークン消費を制御する — 「長く使う」ためのコツ

本記事は三人称のメモ書き調で構成されている。業務でLLMを長時間回した際の観測と、公開されている料金体系の一般論をもとにまとめたもの。個別の単価は変動するため、実数は必ず公式の料金ページで確認すること。

前提：トークンとは何を数えているのか

まずここで躓く人を何人も見ている。トークンは「文字数」ではない。単語や部分文字列を単位とした分割の結果である。

英語: "tokenization"  -> ["token", "ization"]  = 2 tokens
日本語: "トークン化する" -> ["ト", "ーク", "ン", "化", "する"] = 5 tokens 程度

日本語は英語よりトークン効率が悪い。おおむね同じ意味内容で1.5〜2倍前後を見込むのが安全だと考えている。

余談
コード（特にJSONやYAML）は記号がトークンを食う。インデントの空白も例外ではない。整形済みJSONをそのまま貼るのと、ミニファイして貼るのとで2割近く差が出ることがある。

参考：作業別のトークン消費量（相対値）

実測感覚をもとに、最も重い作業を100とした相対値で並べたもの。絶対値ではなく桁感を掴むための表として見てほしい。

作業内容	相対トークン量	備考
大規模コードベース全体のリファクタ	100	数十ファイル読込＋書換。入力が支配的
長文PDF（100p超）の要約・分析	85	入力トークンが巨大。出力は小さい
議事録・文字起こしの構造化	60	入力多め。反復すると膨らむ
長編記事・技術ドキュメント執筆	45	出力単価は入力の4〜5倍なので侮れない
多段の調査＋Web検索を伴う質問	40	検索結果が全部入力に乗る
中規模スクリプトの新規作成	25	出力中心
バグ修正（該当箇所のみ提示）	12	範囲を絞ると激減する
翻訳（数百語）	8	入出力ほぼ同量
表・リストの整形	4	ほぼ固定コスト
単発の事実質問	1	基準値

備考
上位を占めるのはいずれも「入力が巨大な作業」であり、出力量ではない。前章で述べた通り出力単価は入力の数倍高いが、実運用で効いてくるのは入力側の物量である。単価の高さと総額の大きさは一致しない。

余談
最下段の「単発の事実質問」を1とすると、リファクタは概ね100倍。ただし同じリファクタでも、スレッドを分けて範囲を絞れば20〜30まで落ちる。作業の種類より運用の仕方で決まる幅の方が大きい。

消費の内訳：入力と出力は別勘定

多くの人が誤解しているのがここだ。課金は「入力トークン」と「出力トークン」で単価が別であり、出力の方が数倍高いのが通例である。

項目	相対単価の目安	メモ
入力トークン	1	大量に積める。ただし積むほど毎ターン再計上される
出力トークン	4〜5	「長く書かせる」が一番効く場所
キャッシュ読込	0.1 前後	同じ前置きを繰り返すなら劇的に効く
キャッシュ書込	1.25 前後	初回だけ割高。使い回して初めて元が取れる

最大の落とし穴：会話履歴は毎回まるごと再送される

これが最も見落とされる。チャット形式のインターフェースでは、20ターン目の1行の質問であっても、それまでの全履歴が入力として再計上される。

ターン1 : 入力 500      -> 累計 500
ターン2 : 入力 500+800  -> 累計 1,800
ターン3 : 入力 1,800+700-> 累計 4,300
...
ターン20:                 累計 数十万トークン

つまり会話は二次関数的に高くつく。「一行の質問だから安いはず」という直感を捨てるべきだと考えている。

備考
話題が切り替わったら新しいスレッドを立てる。これだけで消費が桁で変わることがある。「継続した方が文脈が伝わって効率的」というのは、コスト面では逆になりやすい。

節約のコツ：効果の大きい順

1. スレッドを切る

前述のとおり効果が最大。関連しない話題を1本のスレッドに積むのは最も高い使い方である。

2. 貼るファイルを絞る

# 悪い例：リポジトリ全体を投げる
cat src/**/*.ts

# 良い例：該当箇所だけ
sed -n '120,180p' src/services/auth.ts

「全部見せた方が正確な答えが返る」は半分正しいが、範囲が絞れているときは絞った方が答えも正確になる。ノイズが減るからだ。

3. 出力長を明示的に制限する

NG: 「この関数を改善して」
OK: 「この関数の問題点を3行で。コードは差分のみ」

出力単価は入力の4〜5倍。ここを削るのが単価効率としては一番おいしい。

4. モデルを使い分ける

用途	推奨クラス	メモ
定型整形・分類・抽出	軽量モデル	ここに高性能モデルを使うのは浪費
一般的なコーディング	中位モデル	大半のタスクはここで足りる
複雑な設計判断・長い推論	上位モデル	使いどころを絞る

「最新モデル＝常に最高コスト」ではない。同一クラスの世代更新では、性能が上がりつつ単価が据え置き、あるいは下がる例もある。世代ではなくクラス（軽量／中位／上位）で見るのが正しい。

5. プロンプトキャッシュを使う（API利用時）

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": long_system_context,   # 毎回同じ巨大な前置き
                "cache_control": {"type": "ephemeral"}
            },
            {"type": "text", "text": user_question}
        ]
    }
]

同じ前置きを何度も送る用途（社内ドキュメントQAなど）では効果が非常に大きい。ただし初回は割高なので、2回以上使い回す前提がなければ意味がない。

6. バッチ処理を使う

即時応答が不要なら、バッチAPIで大幅に安くなる提供形態が一般的である。夜間の一括分類などはこちらに寄せるべきだと考えている。

逆に、削ってはいけないところ

注意
節約を突き詰めて指示を削りすぎると、意図しない出力が返り、やり直しが発生する。やり直し1回分のコストは、丁寧な指示の追加分より大きいことが多い。ケチる場所を間違えると総額は増える。

削るべきは「冗長な文脈」であって「要求の明確さ」ではない。

削ってよい: 過去の無関係なやり取り、使わないファイル、装飾的な前置き
削ってはいけない: 制約条件、期待する出力形式、判断基準

運用フローとしてのまとめ図

まとめ

施策	効果	手間	優先度
話題ごとにスレッドを切る	大	極小	最優先
出力長・形式を明示する	大	小	最優先
貼付範囲を絞る	中〜大	小	高
モデルをクラスで使い分ける	中〜大	小	高
プロンプトキャッシュ	大（条件付き）	中	API利用なら高
バッチ処理	大（条件付き）	中	非同期用途なら高
日本語→英語でプロンプト	小〜中	中	低（可読性を損なう）
指示を削る	逆効果	―	やらない

結論として、「モデルを安くする」より「文脈を短く保つ」方が効くとされる。単価の差は数倍だが、履歴の積み上がりは数十倍になりうる。

情報ソース・参考リンク

本記事の相対値テーブルは実測感覚に基づく概算であり、公式に公表された数値ではない。単価・仕様は改定される

種別	内容	URL
公式	料金体系（モデル別の入出力単価）	https://www.anthropic.com/pricing
公式	API ドキュメント（全般）	https://docs.claude.com
公式	プロンプトキャッシュ	https://docs.claude.com/en/docs/build-with-claude/prompt-caching
公式	Message Batches API	https://docs.claude.com/en/docs/build-with-claude/batch-processing
公式	トークンカウント API	https://docs.claude.com/en/docs/build-with-claude/token-counting
公式	プロンプトエンジニアリング概要	https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview
公式	サポート・利用制限に関するFAQ	https://support.claude.com

用語補足

• 一次情報 — ベンダー自身が公開している資料。ブログ記事やまとめサイトは改定に追随していないことが多い。
• トークンカウントAPI — 実際に課金される前に入力トークン数を計測できるエンドポイント。見積もりを推測でやる必要はない。