powered by TechFeed
表示モード
Deep Dive

Claude Codeのトークン代が高い理由と、それを抑える4つのポイント — Anthropic公式が解説したコスト構造の話

8月14日、Anthropicが「Maximizing the value of your Claude Code sessions」と題した記事を公開した。Claude Codeのセッションにおけるトークン消費の仕組みと、コストを抑えながら効率よく作業するための実践的なテクニックを公式が詳しく解説した内容だ。出力トークンの単価が入力の約5倍、逆にキャッシュ読み出しは入力の0.1倍という非対称な料金構造を理解しているかどうかが、コストに大きく影響する。

8月14日、Anthropicが「Maximizing the value of your Claude Code sessions」と題した記事を公開した。Claude Codeのセッションにおけるトークン消費の仕組みと、コストを抑えながら効率よく作業するための実践的なテクニックを公式が詳しく解説した内容だ。出力トークンの単価が入力の約5倍、逆にキャッシュ読み出しは入力の0.1倍という非対称な料金構造を理解しているかどうかが、コストに大きく影響する。


Claude Codeは現在、AIコーディング支援ツールとして急速に普及しているが、長いセッションになるほど意図せずトークンを大量消費してしまう。ユーザーからコスト増への不満の声が上がる中、Anthropicが公式にその仕組みを解説した珍しいガイドであり、「なぜ高くなるのか」「どこを直せば安くなるのか」が具体的に書かれている。

トークン消費の基本構造を知る

リクエストはGPU上で2段階で処理される。

  • プリフィル(入力): モデルがシステムプロンプト、CLAUDE.md、会話履歴、読み込んだファイルなどを読み込む
  • デコード(出力): モデルが1トークンずつ応答を生成する

重要なのは出力トークンの単価が入力の約5倍という点だ。1回の応答が200トークンなら、モデルは200回動く。思考(thinking)トークンも出力扱いになるため、/effortコマンドで制御できる思考量は直接コストに響く。

Tip: 新しいセッションを開いたら /model/effort を一度実行し、意図した設定になっているか確認する。どちらも前回の設定を引き継ぐため、知らない間に重いモデル・高い思考量で動いていることがある。

ルーティンな作業だとわかっている場合は MAX_THINKING_TOKENS=0 claude で思考を完全にオフにできる。

プロンプトキャッシュの仕組みと「壊し方」

Claude Codeはプロンプトキャッシュを自動管理している。リクエストの先頭部分が前回と完全一致していれば、その部分はキャッシュから読み出される。キャッシュ読み出しのコストは通常入力の0.1倍だ。

1回の「テスト修正」作業でも、内部では5回のリクエストが発生する。各ターンで会話全体が送信されるが、キャッシュが効いていれば既存部分は0.1倍で読み出され、新しい部分だけが全額課金される。

問題は、このキャッシュを意図せず破棄してしまう操作が複数ある点だ:

  • /model の切り替え: モデルごとに独立したキャッシュを持つため、切り替えた次のターンで会話全体が再プリフィルされる
  • /effort の変更: エフォートレベルもキャッシュキーの一部
  • Fastモード: 同様にキャッシュキーに含まれる。途中で有効にすると再プリフィルが発生し、しかもFastモード料金がかかる
  • /compact: 会話が要約に置き換わるため、キャッシュがすべて無効になる
  • 時間切れ: サブスクリプションでは1時間、APIキーでは5分でキャッシュが失効する

Tip: 直前の数ターンを取り消したい場合は /compact より /rewind を使う。/rewind はターンを末尾から切り落とすだけなので、それ以前のキャッシュはそのまま生きている。/compact は会話全体を書き直すため、必ずコストが発生する。

モデルやエフォートを変えるなら、セッション開始直後か /clear の直後がコスト的に正しいタイミングだ。

コンテキストを膨らませない工夫

セッション中にコンテキストへ追加されたものは、その後のターン全体で毎回送信される。キャッシュが効いていても「ゼロ」ではない。

ファイル参照には @メンション を使う

「テストが失敗している」と書くとClaudeはまず原因を探すために grep を走らせ、複数のファイルを開く。それらの結果はすべてコンテキストに残り続ける。

utils.test.ts の失敗しているテストを修正して」と書けばReadコール1回で済む。さらに「@utils.test.ts の失敗しているテストを修正して」と@メンションすれば、Readコール自体が不要になる。ファイルが最初のリクエストに直接添付されるためだ。

Tip: 同じファイルを後のターンで再度@メンションすると2つ目のコピーが添付される。1会話中に1回だけメンションすれば十分だ。

コマンド出力のノイズを減らす

テストランナーが400行の結果を出力すれば、その400行が残りの全ターンに乗り続ける。30,000文字を超える場合はClaudeが自動でファイルに書き出してくれるが、それ未満は全量がコンテキストに入る。

CLAUDE.md によく使うコマンドを静音フラグ付きで書いておく(例:npx vitest run <file> --reporter=dot)のが有効だ。

セッションを短く保つ

ターン40は、それ以前の39ターンを毎回再読み込みしている。 1つのタスクが終わったら /clear、同タスクの前半が不要になったら /compact でコンテキストを切る。

サブエージェントの活用

ログ解析のような大量出力を生むタスクには、サブエージェントが有効だ。サブエージェントは独自のコンテキストウィンドウで動き、メインセッションに返すのは最終的な回答だけだ。繰り返し発生するノイズの多い作業には、model: haiku を指定したサブエージェント定義を用意しておくとよい。

まとめ:まず見るべき4点

記事では「コストへの影響が大きい順」に以下の4点を挙げている:

  1. 思考トークン量/effort/model の設定)
  2. キャッシュの維持(途中でのモデル・エフォート変更を避ける)
  3. コンテキストサイズ(不要なファイル読み込みや大量出力の抑制)
  4. セッションの長さ/clear/compact の適切な使用)

見方を変えると、これらはすべて「Claudeに余計な仕事をさせない」という一点に収束する。コードを書かせる前に、何をコンテキストに乗せるかを意識する習慣が、長期的なコスト管理の要になるだろう。

※編集部の考察:Claude Codeは現時点でトークン単価が非公開の従量課金制APIを通じて利用するケースも多く、コスト感覚が掴みにくいツールでもある。公式がここまで踏み込んでコスト構造を説明したこと自体、ユーザーの不満に正面から向き合おうとする姿勢の表れと読める。

詳細はMaximizing the value of your Claude Code sessionsを参照していただきたい。