*【ポエム】 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利用なら高
バッチ処理	大（条件付き）	中	非同期用途なら高
日本語→英語でプロンプト	小〜中	中	低（可読性を損なう）
指示を削る	逆効果	―	やらない

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

なぜ消費が想定より早いのか

体感の「そんなに使っていない」と実際の消費は大きくズレる。消費を左右するのは会話の回数ではなく処理量だ。主な消費要因は、長いスレッドの継続、画像などの添付、ツール使用、そして重いモデルの使用の4つになる。

要因	消費への影響	理由
長いスレッドの継続	大	発話ごとに過去の全文を毎回読み直すため、後半ほど1発話あたりが重くなる
画像の添付	特大	1枚が高コストで、スレッドに残る限り毎回再ロードされる
ツール使用（検索等）	中	裏側の処理が上乗せされる
重いモデルの使用	大	1トークンあたりの単価が高い

スレッドの再読という構造

Claudeはスレッドをまたいで記憶を持たない。ひとつのスレッド内で会話が伸びると、発話のたびに過去の全文を頭から読み直している。「ざっくり見返す」という省エネ再読の機能は存在せず、毎回フルで生の全文を読む。このため久々に開いた超長文スレッドは、一度発話するだけで大量のトークンを消費する。

この構造の弊害として「例の件問題」がある。ユーザーは複数スレッドを横断して全部を覚えていられず、AIはスレッドごとに記憶を持たない。結果、双方が文脈を失い「例の件だが」→「例の件とは？」という空白が生まれる。対策は、消えて困る情報だけを自分用メモに固定し、新スレッド冒頭に貼ることだ。

画像とテキストのコスト比較

2000文字程度のテキストは、日本語でおよそ1500〜3000トークンになる。1280x720の画像は、おおよそ1000〜1200トークン前後に換算される。単発では意外に近いが、情報密度と再ロードで画像が圧倒的に不利になる。

項目	テキスト2000文字	画像1280x720
単発の消費	約1500〜3000トークン	約1000〜1200トークン
情報密度	高い（全部が意味を持つ）	低い（内容は限定的）
引き継ぎコスト	数行のコピペで済む	画像現物を再度食わせる必要がある
再ロードの重さ	軽い	枚数分が毎回累積する

画像を新スレッドへ引き継ぐ際は、現物を貼り直すのではなく特徴をテキストで書き起こすのが有効になる。「例の猫＝キジトラ、右耳欠け、目つき悪い」のように通り名で持ち歩けば、数十トークンで参照できる。

RSPとトークンの関係

Anthropicの安全性思想の背骨はResponsible Scaling Policy（RSP）だ。生物兵器の製造への悪用やAIの自律暴走といった、大規模な破壊をもたらす壊滅的リスクを管理する枠組みになる。AI Safety Levels（ASL）という段階的な安全等級を設け、危険な能力を持つモデルほど厳しい基準のクリアを求めている。

2026年2月のRSP v3.0改訂では、2023年以来の「安全が事前に証明されなければ訓練しない」という中核的な約束が削除されたと指摘されている。開発停止の条件が「自社が先頭にいて、かつ壊滅的リスクと判断した場合」という二重条件に後退した。看板は残しつつ実効的な縛りが緩んだ、という批判がある。

RSPとトークンは基本的に別レイヤーの話だ。RSPは壊滅的リスクという国家スケールの安全保障を扱い、トークンは1回の処理量と課金を扱う。日々の消費対策にRSPは関与しない。無理に接点を挙げれば、扱えるトークン量がモデルの能力評価に間接的に絡むこと、安全チェックが計算資源をわずかに消費すること、両者が同じ有限の計算資源プールを共有すること、の3点にとどまる。

なお、モデル自身が自らにかけられた制限を検知して押し戻すことはできない。価値観も制限も訓練で外側から組み込まれるものであり、AIは制限の正しさを保証する主体になれない。安全性は外部の仕組みと、それを運用する人間の判断にかかっている。

長考モードの使い分け

長考モード（拡張思考）をONにすると、返答の前に見えない思考工程を挟む。筋道を立て、複数の可能性を検討し、計算を段階的に追ってから答えを書く。精度は上がるが、その思考工程自体がトークンを消費する。難問にぶつけるほど下書きが伸び、一発の消費が跳ねる。

麻雀にたとえると理解しやすい。

局面	長考	打ち方
全員リーチ、自分は親 跳満の可能性ありだが遠い	ON	一手ごとに全員の現物を照合し、放銃せず流局まで運ぶ
平和な序盤・全員バラバラ・放銃しても安手	OFF	テンポよくサクサク切る

間違えた時の代償が大きい局面では、手数を払ってでも慎重に読む価値がある。逆に軽い局面で毎巡フル長考すると、時間と消費の垂れ流しになる。基本はOFF、勝負どころだけON。長考はブレーキではなくターボとして扱う。

モデル選択の考え方

「最新モデルほど最適化されて少ないトークンで済む」というわけではない。トークン数は入力と出力の分量で機械的に決まり、モデルの賢さでは変わらない。同じ「猫」という単語は、どのモデルでも同じトークン数になる。モデルで変わるのはトークン数ではなく1トークンあたりの単価だ。重いモデルから軽いモデルに落とすと消費が減るのは、単価が下がるからになる。

軽いモデルで質が心配な場合は、まず軽いモデルで投げ、答えが浅いと感じた時だけ重いモデルで投げ直せばよい。最初から最上位を常用するより消費を抑えられる。

まとめ

論点	結論
消費が早い原因	会話回数ではなく処理量で決まる。長いスレッド・画像・ツール・重いモデルが主因だ
スレッドの再読	毎回全文を再読する構造で、久々の長文スレッドは一発が重い。畳んで結論だけ新スレッドへ移す
画像の扱い	単発は互角でも再ロードで不利。引き継ぎはテキストの通り名で行う
RSPとの関係	別レイヤーで日々の消費には無関係。安全性は外部の仕組みと人間の判断が担う
長考モード	基本OFF、難問だけON。思考工程自体がトークンを食う
モデル選択	最新でもトークン数は減らない。変わるのは単価。軽いモデル基本、勝負どころだけ上げる

Claudeの5時間制限と週間制限に関するメモ

このメモ書きは、Claudeの利用制限が5時間枠と週枠の二段構えになっている仕組みと、その運用テクニックを整理したものだ。あわせて、モデル選択が消費に与える影響も記録している。

消費量はメッセージごとの固定値ではない。そのメッセージがモデルに何をさせるかで変わる。Anthropicはメッセージあたりの数値を公表していないため、「1回で週の何％」という固定の換算式は仕組み上存在しない。

二段構えの制限

有料プランは2種類の制限を並行で回している。片方が大丈夫でももう片方で止められることがあり、これが制限を唐突に感じさせる原因になる。実際はランダムではなく、速度の違う2つの時計が同時に動いている。

制限	リセット	性質
5時間枠	最初の発話から5時間後	使ってもすぐ回復する短期の枠
週枠	アカウント固定の曜日・時刻	一週間戻らない長期の枠

5時間枠の挙動

5時間枠は固定の時間帯ではない。最初のメッセージを送った瞬間から始まり、ちょうど5時間後に切れるローリング方式になる。「9時から14時」のような固定スロットではなく、動き出したタイミングが起点になる。15時15分に上限へ達した場合、回復は20時15分であって、次の時刻の頭ではない。

新しい会話を始めても、ログアウトして入り直しても、ブラウザを変えても5時間枠はリセットされない。回復させる唯一の方法は枠が閉じるのを待つことだ。

週枠の挙動

週枠は5時間枠と違い、ローリングではない。アカウントに割り当てられた固定の曜日と時刻にリセットされ、いつ使い始めてもその曜日・時刻は変わらない。毎週決まったタイミングでまとまって回復するため、リセット曜日を把握しておくと計画が立てやすくなる。

なお、通常の使い方で週枠に到達するユーザーは2%未満とされている。週枠を枯らすのは、重い作業を無自覚に積み重ねた場合に起きる特殊事情になる。

何が消費を食うか

重いターンほど速く枠を消耗する。Opusの使用、長い文脈、大きな添付、拡張思考（長考）、これらすべてがメッセージあたりのコストを増やす。

消費要因	対策
重いモデル（Opus）	日常はSonnet、難問だけOpusに絞る
長い文脈・長文スレッド	前半を要約し、引きずらず畳んで新スレッドへ移す
大きな添付（画像等）	祭り専用スレッドに隔離し、引き継ぎはテキストで行う
拡張思考（長考）	基本OFF、勝負どころだけON

モデル選択と消費

トークン数はモデルの賢さでは変わらず、入力と出力の分量で機械的に決まる。モデルで変わるのはトークン数ではなく1トークンあたりの単価だ。軽いモデルに落とすと消費が減るのは、単価が下がるからになる。

モデル	消費	賢さ	向いてる用途
Opus	重い	最高	複雑な推論、難しいコード、重要な判断
Sonnet	中	高い	日常のほぼ全部、相談、下書き
Haiku	軽い	速いが浅い	単純作業、短い応答、定型処理、軽い要約

Haikuは燃費が最軽量だが、込み入った相談や多論点の整理には物足りない。頭を使わない単純作業に限定して使うのが噛み合う。

運用テクニック

週枠を主戦場と考えて守るのが最優先になる。5時間枠は勝手に戻るが、週枠は固定リセットまで戻らない。

• 重いモデルは複雑な推論だけに取っておき、日常はSonnetで回す
• 大きな文脈は消費が多いため、長い会話は前半を要約して引きずらない
• 残量を把握しておくと、残りタスクの優先順位の付け方が変わる
• 重い作業は週の前半で片付け、後半は軽装で走るペース配分を組む
• 枯れそうな時は、軽い用途だけに退避して週枠をこれ以上削らない

正確な残量と自分の週枠リセット曜日・時刻は、ClaudeのSettingsのUsageで確認できる。設定からUsageを開けば、現在の消費と次のリセット情報が表示される。制限の設計は変わりうるため、正確な数字は都度公式を確認するのが妥当だ。

まとめ

論点	結論
制限の構造	5時間枠と週枠の二段構え。速度の違う2つの時計が並行で動く
5時間枠	最初の発話から5時間のローリング。会話新規作成や再ログインでは戻らない
週枠	アカウント固定の曜日・時刻にリセット。ローリングではない
消費要因	Opus・長文脈・大きな添付・長考が重い。公式の説明と一致する
モデル選択	変わるのは単価。Sonnet基本、難問Opus、単純作業Haiku
何％問題	固定の換算式は存在しない。残量はSettingsのUsageで確認する

あとがき

このメモ書きは、週枠が85%に達した実例をきっかけに、制限の仕組みを公式情報で裏取りしながら整理したものだ。消費を食う要因は、体感ではなくAnthropicの説明とも一致していた。目新しい裏技があるわけではなく、Sonnet基本・コンテキストを絞る・長文スレッドを畳む・残量を把握して動くという基本の徹底が、そのまま最適解になる。まず設定からUsageを開き、自分の週枠リセット曜日を確認しておくと、ペース配分が体感ではなく計画に変わる。

情報ソース・参考リンク

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

種別	内容	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 — 実際に課金される前に入力トークン数を計測できるエンドポイント。見積もりを推測でやる必要はない。