Anthropic 公式ガイド：Claude Code での会話中に Token を節約する方法

数行のコードを変更しただけなのに、なぜクレジットがすでに減っているのか

Claude Code に失敗したテストを修正させたとします。最終的な変更は三行かもしれません。しかし、その三行にたどり着くまでに、リポジトリを検索し、候補ファイルを開き、数百行のテストログを出力し、間違った方向で数ターン試行したかもしれません。

これらのプロセスは、Claude が答えを見つけた後も自動的には消えません。続行するたびに、モデルはそれまでに蓄積されたシステムプロンプト、プロジェクトルール、ファイル、コマンド結果、会話履歴を再度処理する必要があります。

このコスト構造は従来の開発ツールとは異なります。エディタは無料または月額・年額で、バグを修正してもソフトウェアの請求が増えることは通常ありません。しかし、プログラミングエージェントはタスクごとにモデル推論を実行します。最終的な変更が数行であっても、読み込んで生成する Token は GPU、TPU などの計算リソースを消費し、同じタスクでも使用方法によって消費量が異なります。

これにより、三つの直接的な問題が発生します：

1. クレジットがすぐ減るが、どこに使われたかわからない。サブスクリプションユーザーは通常、使用量の変化しか見えず、特定のファイル、ログ、検索に消費を対応付けるのは困難です。
2. セッションが長くなるほど、古い情報を排除しにくくなります。キャッシュにより繰り返し読み取りは安くなりますが、古いコンテンツは依然としてコンテキストを占有し、Claude の注意を無関係な方向に引っ張る可能性があります。
3. コマンドは知っていても、使用タイミングを間違えやすい。新しいタスクには /clear、同じタスクでの段階移行には /compact、末尾数ターンの誤りには /rewind が適しています。Subagent はノイズを分離できますが、新たなコストも発生します。

Anthropic はこのガイドを公開し、これらのセッション管理の問題に答えることを目的としています。読了後、現在の消費が主に長いセッション、無関係なコンテキスト、モデルと Effort の過剰、またはプロンプトキャッシュの失効のいずれに起因するかを判断できるはずです。また、ファイルを直接渡すべきか、ログを短くすべきか、履歴を切断すべきか、Subagent に作業を任せる価値があるかもわかるでしょう。

原文では、同じ失敗テストで二つの経路を示しています。テストファイルを直接指し示すと、Claude はテストと実装を読み、修正して検証し、五回のリクエストで完了します。「テストが失敗した」とだけ言うと、まずリポジトリを検索し、候補ファイルを開き、ログを読み、最終的に同じ修正にたどり着くまでに十八回のリクエストを使用します。

5 回と 18 回は図の特定のシナリオを表すだけで、固定コスト倍率に直接換算できません。これはより重要なことを示しています：コードの変更が同じでも、セッションに入るプロセス資料は完全に異なる可能性があります。ガイドの目的は、Token を必要なコード、推論、検証に集中させ、無関係な検索、ノイズ出力、クロスタスクの残骸を早期に遮断することです。

五回のリクエストの経路は、請求がどのように形成されるかも説明します。最初のターンでシステムプロンプト、CLAUDE.md、タスクを送信。Claude がテストファイルの読み取りを要求し、ファイル結果がセッションに追加されて再度送信。次に実装ファイルを読み、変更を提出し、テストを実行し、最後に短い要約を生成します。各ターンには以前の完全なセッションが含まれますが、通常の追記では、古い連続プレフィックスはキャッシュ読み取りで処理され、新しいツール呼び出し、新しいファイル、新しいテスト結果のみが通常の入力価格で Prefill されます。

したがって、典型的な呼び出しは数万の入力 Token になり、出力 Token は数百に過ぎないことがあります。数万の入力がすべて通常の入力価格で再計算されるわけではありません：各ターンのコストは、履歴のキャッシュ読み取り、新規コンテンツの通常入力価格、今回の出力価格で構成されます。これを理解すれば、無意味な検索を一回減らしたり、途中でモデルを切り替えないことが、最後の数十字を圧縮するより価値がある理由がわかります。

次に、最もよく使う六つのアクションを示し、その後それらがなぜ効果的なのかを説明します。