Claude Code のトークン消費を減らす方法

コーディングエージェントが送るのはあなたの質問ではありません。あなたの質問に加えて、あなたが言いたかったはずだとエージェントが判断したものすべて、つまり開いたファイル、たどったディレクトリ一覧、実行した各コマンドの出力、そしてここまでの会話全体を、毎ターン送り直しています。質問そのものは端数です。その周りのコンテキストが請求額です。

だから、プロンプトを短く書くという定番の助言はほとんど効きません。文面を半分にしても合計は 1 パーセントしか動かないのです。以下の 7 項目は、実際の効き目の大きい順に並べています。

1. どのファイルかを言う

エージェントのセッションで最も大きい、避けられるはずのコストは探索です。あなたがすでに開いていたファイルに、エージェントが読み進めながらたどり着くまでの過程です。読み取りも検索もディレクトリ一覧も、すべてコンテキストに積まれ、そのセッションの残り全部にわたって居座ります。

ファイルを名指しすれば、検索は直接参照に変わります。これはどんなオプションよりも、どんな設定よりも、どんなプロンプト術よりも効きます。

$capsul ask 'リトライループが早々に諦めるのはなぜか' --open src/lib/retry.ts

2. 話題が変わったら新しいセッションを開く

会話履歴は毎ターン丸ごと送り直されます。40 通のやり取りを重ねたセッションは、41 通目でその 40 通分を支払います。そのうちどれだけがまだ関係あるかは関係ありません。

つまり最も高くつく習慣が、最も自然な習慣です。長いセッションを一日じゅう開いたままにすることです。無関係な 2 つの作業を 1 本のスレッドに入れれば、2 つ目が 1 つ目の分まで払います。話題が変わったら閉じて開き直してください。

3. コンテキストに上限を置く

予算とは、通してよいコンテキスト量に対する強制的な上限で、トークンで表します。情報が足りないと感じたエージェントが超えてよい目安ではありません。

$capsul ask 'ログインのルートにレート制限を追加して' --budget 3000

数値そのものより、上限が存在することのほうが重要です。上限のないエージェントは与えられたウィンドウを埋めます。止まる理由がどこにもないからです。

4. モデルを作業に合わせる

変数名を変えることと、マイグレーションを設計することは同じ仕事ではありません。同じモデルで走らせるべきものでもありません。多くのセッションが最大のモデルで最初から最後まで走るのは、それが既定値だからであって、誰かが選んだからではありません。

$capsul ask 'auth モジュール全体で userId を accountId に改名して' --model haiku

5. ツール出力を履歴に残さない

2000 行を出力するテスト実行は 2000 行分のコンテキストを消費し、そのセッションの以後のターンでも消費し続けます。冗長なビルド、全部入りの git log、絞り込みのない find も同じです。

うるさいものは、エージェントが目にする前に短くする何かを通してください。head、grep、--quiet、フィルタ付きの --json。どれも、ノイズを無視してくれとモデルに頼むより安上がりです。

6. 事後だけでなく事前も測る

同じ作業を同じモデルで対照して測っていないトークン削減の主張は、すべて当て推量です。実際にやっている作業を 2 回走らせて比べてください。

変更の前後で同じモデルに同じ作業を依頼し、プロバイダーの使用量レポートを記録してください。無関係な作業を 2 つ比べても、コンテキストの変化が結果に影響したかはわかりません。

7. ターンではなく傾向を見る

1 リクエストからは何もわかりません。トークン消費は本来ばらつくものです。探索の多いターンは編集中心のターンの 10 倍かかることがあり、どちらも異常ではありません。見るべきは週単位の線です。

$capsul stats

効かないこと

• →モデルに短く答えるよう頼むこと。出力トークンは請求のごく一部で、お金がかかるのは入力側です。
• →ツールを切ること。するとエージェントはファイルを貼ってくれと言い、あなたは必要以上に貼ることになります。
• →より大きいコンテキストウィンドウに移ること。倍の大きさのウィンドウは、同じ答えに対する倍の請求であって、節約ではありません。
• →会話の圧縮を遅らせること。圧縮が働くころには、そこに至るまでの全ターン分をすでに払い終えています。