なぜ「Claude Code」で想定外のコストになるのか？ 「トークン浪費」を防ぐポイントまとめ：AI利用コストが増えるメカニズムをAnthropicが解説

Anthropicは、「Claude Code」でトークンを効率的に使用し、セッションから最大限の価値を引き出す方法を解説した。

[＠IT]

　Anthropicは2026年8月14日（米国時間）、エージェント型コーディングツール「Claude Code」でトークンを効率的に使用し、各セッションから最大限の価値を引き出す方法を解説したブログ記事を公開した。

　定額制や無料で利用できる従来の開発ツールとは異なり、エージェント型コーディングツールでは、個々のタスクごとにコストが発生する。課金はトークン単位で算出されるが、その金額は、ツールの利用方法に大きく依存する。

　Claude Codeが目的のファイルをすぐに見つけて修正を適用した場合、セッションは最小限のターン数で終了する。だが、リポジトリ全体を検索し、ファイルを多数読み込んだ場合、トークン数は大幅に増加する。これは後続のターンにも影響し、利用コストを継続的に膨らませてしまう。

　Anthropicは「トークンを効率的に使用することは、単にトークンを節約することではない。使用するトークンが、要求した処理に確実に割り当てられるようにする取り組みだ」と説明。その上で、トークン価格を決定する要因と、セッションで送信されるトークン数を決定する要因を整理し、効率的にセッションを運用するための実践的なノウハウを示している。

トークン価格を決定する3つの要因

　ユーザーは、トークン消費に基づいてエージェント型コーディングツールの料金を支払う。これは、推論の対価、すなわちGPU（やTPU〈Tensor Processing Unit〉など）がモデルを実行し、トークンを処理するのにかかる時間の対価だ。1つのトークンにかかる時間は、「どのモデルを実行するか」「入力トークンか出力トークンか」「トークンがキャッシュされていたかどうか」によって決まる。

モデル

　大規模なモデルは、入力トークンと出力トークンの両方に対してより多く処理する。そのため、困難な問題や曖昧な問題に適しているが、コストが高くなる。一方、小規模なモデルは定型作業に適している。

入力トークンと出力トークン

　リクエストは2つのフェーズでGPUを通過する。「プリフィル」（事前入力）では、モデルがリクエストとコンテキスト、システムプロンプト、「CLAUDE.md」、メッセージ、以降に会話に追加された全内容（Claudeが読み込んだファイル、実行したコマンドの出力）を、入力トークンとして読み込む。

　「デコード」では、出力トークン（思考、ツール呼び出し、テキスト）を1つずつ生成する。200トークンの応答は、モデルを200回実行することを意味する。デコードは、トークン当たりでGPUをはるかに長く占有するため、出力トークン価格は入力トークン価格の約5倍となる。

　出力トークンの多くは思考トークンであり、「/effort」で設定するエフォートレベルがターン当たりの思考量を制御する。モデルの選択と同様、この設定は次のセッションのデフォルト（既定）として引き継がれる。

プリフィルフェーズは入力トークンを読み込み、デコードフェーズは出力トークンを1つずつ生成する（提供：Anthropic）

　Anthropicは、新しいセッションの開始時に「/model」や「/effort」を実行し、意図した設定（モデルおよびエフォートレベル）が適用されているかどうか事前確認することを推奨している。

　なお、単純作業になることが事前に分かっているセッションでは、「MAX_THINKING_TOKENS=0」を付けて起動すると、そのセッションに限り思考をオフにできる（「Fable 5」を除く）。これは「/effort」の「低」（low）よりも低いレベルの設定だ。

プロンプトキャッシュの効果

　コスト削減につながる重要な仕組みがプロンプトキャッシュだ。これはリクエストの先頭が、サーバが直前に処理したものと完全に同じトークン列で始まる場合、サーバが前回の状態をキャッシュとして保持し、その後に続く部分だけを事前入力するというものだ。

　キャッシュからの読み出しには、入力コストの0.1倍のコストしかかからない。キャッシュへのトークン書き込みには、入力コストの最大2倍のコストがかかるが、これはトークンごとに1回しか発生しない。

　Claude Codeはキャッシュを自動管理しているが、ユーザーの特定の操作がキャッシュを破損させることがある。

　キャッシュはリクエストの最初との一致が必要となるため、以下のように、リクエストの先頭側を変更する操作や、キャッシュのキーとなる要素を変更する操作が、キャッシュを無効にしてしまう可能性がある。

• 「/model」：モデルごとにキャッシュが分かれているため、この操作により、次のターンで会話全体が通常価格で再び事前入力される
• 「/effort」：エフォートレベルもキャッシュのキーの一部であるため、同様の挙動となる
• 高速モード：これもキャッシュキーの一部であるため、途中で切り替えるとキャッシュが無効化され、会話全体が高速モード価格で再び事前入力される
• 「/compact」：会話がより短い要約に置き換わり、以降は一致しなくなる。要約の生成自体は、元の会話がキャッシュに残っているうちは安価だ
• 時間経過：キャッシュは、サブスクリプションで1時間後、APIキーで5分後に失効する。古いセッションを再開すると、ほぼ確実にセッション全体の事前入力を伴うためコストが増える

　「『この操作をしてはならない』という意味ではない。セッション開始時や「/clear」の直後は安価なタイミングとなり、会話の途中は高価なタイミングになる。直近の対話履歴を破棄したい場合は、『/compact』ではなく『/rewind』で直前のターンまで巻き戻すのが効果的だ。会話全体を再生成する『/compact』とは異なり、プロンプトキャッシュを維持したまま、無駄なターンのみを削減できる。巻き戻しは末尾のターンを切り落とすだけで、それ以前の内容はキャッシュされたままであり、コストはかからない。一方、『/compact』は会話全体を書き換えるため、必ずコストが発生する」（Anthropic）

セッションで送信されるトークン数を決定する要因

　1回だけ送信されて終わるデータは存在せず、対話履歴に含まれる全ての要素（Claudeが読み込んだファイルや実行したコマンドの出力など）は、以降の全てのターンで、セッションの終了まで繰り返し送信される。

　これらは、キャッシュされているため、再送信のコストは低いが、ゼロではない。また、モデルが各ターンで処理を走らせる際に考慮する必要があるコンテキストを占有し続ける。

　セッションのコストモデルでは、「コンテキストにどれだけのトークンが含まれるか」「それらのトークンがどれだけのターンにわたって、コンテキストに含まれるか」「どれだけのコンテキストが同時に実行されるか」によって、セッションで送信されるトークン数が決まる。

コンテキストに何が含まれるか

　コンテキストの一部は、ユーザーが入力をする前から存在する。それはツール定義、システムプロンプト、CLAUDE.md、起動時に読み込まれる他の要素だ。

　新しいセッションで「/context」を実行すると、ユーザーが入力する前のコンテキストの内容を確認できる。CLAUDE.mdには具体的な指示のみを記載し、ワークフロー固有の指示は、使用時にのみ読み込まれるスキルに移す。セッションで不要なMCP（Model Context Protocol）サーバがある場合は、「/mcp」でオフにする。

　セッション中に追加される他の要素のほとんどは、ツールの結果、つまりClaudeが読み込んだファイルと、実行したコマンドの出力などだ。

　Claudeが読み込むデータの量は、Claudeが自力で把握すべき情報の量に左右される。「テストが失敗している」と伝えると、grepを実行したり、関連ファイルを開いて確認したりするが、それらの結果は、役に立たなくなっても、コンテキストに長い間残る。例えば、「『utils.test.ts』の失敗テストを修正して」と指示すれば、検索を省略でき、Read呼び出し1回で済む。ファイルを＠メンションすれば、それも不要になる。

指示が具体的なほど、検索と読み込みに費やされるトークンは少なくなる（提供：Anthropic）

　ファイルを参照する際は、パスを入力する代わりに＠メンション機能を活用する。Claude Codeが送信前にファイルをメッセージに添付するため、ツールによるRead呼び出しの発生を防ぎ、トークン消費を抑えられる。

　Claudeが実行するコマンドの出力も、コンテキストに含まれる。3万文字を超えるコマンド出力はファイルに書き出され、会話にはプレビューだけが残る。そのため、これに満たない出力が問題となる。例えば、400行のテスト成功表示は、残りの全ターンに組み込まれてしまう。Claudeは、フラグや「tail」で出力を自動的に抑えることが多く、ドキュメントには、不要な出力を含むコマンドを調整するフックも記載されている。

　頻繁に実行するコマンドについては、quiet（静粛）フラグを含めた形式でCLAUDE.mdにあらかじめ定義しておく手法も有効だ。セッションごとに発生する無駄な出力ログ（コンテキスト占有）を削減できる。

セッションの長さ

　1回の長いセッションは、同じ作業を複数の短いセッションに分割して実行するよりもコストが高い。40ターン目は、それ以前の39ターンの内容も再読み取りするからだ。あるタスクのコンテキストを次のタスクに持ち込まず、新しい作業の開始時には「/clear」を実行し、同じタスクの前半が完了したら「/compact」を実行する。

1つの長いセッションは、同じ作業を複数の短いセッションに分けるよりコストが高い（提供：Anthropic）

　後でそのセッションを復元するなら、「/clear」の前に「/rename」しておく。「/compact」を実行する際は、残す内容を指示する。毎回同じなら、CLAUDE.mdに「Compact instructions」セクションを設ける。

　定期実行コマンドである「/loop」は、設定したセッションの対話履歴全体を引き継いで実行されるため、トークン消費が急増しやすい。Anthropicは、メインの対話セッションとは別に新しいターミナルで独立したセッションを起動し、そこでループ処理を実行することを推奨している

サブエージェント

　サブエージェントは、作業をメインのコンテキストから完全に切り離す。独自のコンテキストウィンドウ、システムプロンプト、ツールを持ち、CLAUDE.mdは引き継ぐが、会話は引き継がず、回答だけをメインセッションに返す。

　サブエージェントが効果を発揮するのは、ログ調査のように、保持する必要のない大量の出力を生成する作業だ。Claudeは自らサブエージェントを使うことが多いが、ユーザーがサブエージェントの使用を直接指示することもできる。メインセッションが受け取るのは、サブエージェントが報告することを選んだ内容のみだ。

　ノイズの多いジョブを繰り返し任せる場合は、「model: haiku」（またはsonnet）を指定して、専用のサブエージェント定義を作成する。そうしないと、メインセッションと同じモデルで実行されてしまう。

　Anthropicは、コストへの影響が大きい順に、注目すべき4つのポイントとして、「長いセッション」「コンテキスト過多」「タスクが必要とする以上に大規模なモデルや高いエフォートレベル」「プロンプトキャッシュの破損」を挙げている。

コストへの影響という観点から注目すべき4つのポイント（提供：Anthropic）

まとめ

　Anthropicは、全体を通じてトークンを最適化するポイントを以下のようにまとめている。

タスクごとに「/clear」を実行する

　無関係な過去のコンテキストがモデルに再送信されるのを防ぎ、トークン使用量を削減できる。

モデルとエフォートレベルは開始前に設定する

　会話の途中で変更すると、プロンプトキャッシュが無効になり、トークンコストが増加する恐れがある。

ファイル名を入力するのではなく、＠メンション機能を活用する

　ファイルがメッセージに直接添付され、Read呼び出しや検索が不要になる。

保存不要の内容が大量に出力されるジョブに気を付ける

　コマンド出力はファイルと同様に会話へ追加され、セッションの残りの間ずっと保持される。保存不要の内容が大量に出力されるジョブの場合は、quietフラグを付けるか、サブエージェントで実行する。

新しいセッションで「/context」を一度実行する

　CLAUDE.mdやMCPツール定義など、読み込まれている内容を確認し、不要なものを削除できる。

キーボードから離れる前に「/compact」を実行する

　プロンプトキャッシュは1時間で失効するため、会話の要約はキャッシュが残っているうちの方がはるかに低コストで済むという。