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

まず、この六つを行う

Token の仕組みを詳しく調べたくない場合は、まず以下の六つの使用方法を調整してください。

1. 最初にモデルと Effort を選択。機械的な修正には十分なモデルを使い、曖昧な障害やアーキテクチャ判断には能力と作業深度を上げます。長いセッションの途中で頻繁に切り替えないようにしましょう。
2. 既知の範囲を直接 Claude に渡す。対象ファイル、失敗テスト、期待結果、検証コマンドを指定。インターフェースがサポートする場合は、最初から @ファイル名 で参照します。
3. コマンド出力を制御する。関連テストのみ実行し、quiet reporter、エラーフィルタ、tail を使用して、数百行の成功ログが後続の数十ターンに残らないようにします。
4. 最近のターンで間違えた場合は /rewind を使用。セッション末尾から誤ったブランチを切り取り、以前のキャッシュプレフィックスは保持される可能性があります。
5. 新しいタスクを始める前には /clear を使用。古いタスクを後で復元する必要がある場合は、先に /rename してからコンテキストをクリアします。
6. プロセスが非常にノイズが多く、メインセッションが結論だけを必要とする場合のみ Subagent を使用。長いログのスキャン、完全なテスト出力、Git 履歴の検索は分離に適しています。小さな問題を渡すと、かえってコストが高くなることがあります。

原文の最後の図は影響の順序を示しています：まず長いセッション、次にコンテキストの過多、その後にモデルまたは Effort が過剰、そしてプロンプトキャッシュの無効化です。この順序により、小さなところで節約を繰り返しながら、古いタスク履歴を毎ターン再送信することを防げます。

以下の決定図は、混同しやすい四つのアクションを区別するためのものです。四つの適用境界はデフォルトで全て表示されます。シナリオを選択すると、履歴がクリア、圧縮、トリミング、分離されるかの変化がわかります。

第一優先：一つのセッションに複数のタスクを入れない

Claude Code の各リクエストは、その時点までのセッション内容を保持します。最初のタスクで残ったファイル、ログ、ツール結果が、二番目、三番目のタスクに残っていると、後続のリクエストで繰り返し出現します。

累積負担は次の近似式で理解できます：

セッション負担 ≈ コンテキスト内の累積コンテンツ × そのコンテンツが今後経験する後続ターン数 × 同時に実行される独立コンテキスト数。

最後にモデル、出力、キャッシュ倍率を考慮します。これは理解のための近似式であり、Anthropic が正確な請求式として公開したものではありません。

原文の三タスク図はこの累積を示しています。最初の履歴は三ターン、二番目は二ターン、三番目は一ターン持ち込まれます。すべてを一つの長いセッションに入れると、図の Token 量は分割セッション方式の 1.9 倍に達します。この数字は図の条件に固有であり、持ち帰るべきは「古いコンテンツは、その後生き残るターン数で乗算される」という点です。

したがって、/clear はタスクの境界で使用します。正確なタイミングは新しいタスクを始める準備ができたときであり、コンテキストがほぼ満杯になるまで待つ必要はありません。古いセッションへの入り口を保持する必要がある場合は、/rename してから /clear します。

/loop にも同じ判断が適用されます。各ループは完全なリクエストです。周期監視が非常に長いメインセッションにぶら下がっていると、定期的に履歴全体を運びます。新しいセッションを個別に開始し、ループに本当に必要な材料だけを入れる方が適切です。

第二優先：無関係なコンテンツをセッションに早期に入れない

セッションの初期負担は、最初のタスクメッセージの前に形成される可能性があります。ツール定義、システムプロンプト、CLAUDE.md、有効な MCP サービスがコンテキストに入ることがあります。新しいセッションでは、まず /context を実行して起動時に何が読み込まれたかを確認します。現在使用していない MCP サービスは、/mcp で確認して無効にします。

長期的に適用され、十分に短いプロジェクトルールは CLAUDE.md に適しています。特定のフローのみで使用する長い説明は、オンデマンド読み込みが適しています。判断基準は簡単です：常駐コンテンツは毎ターン出現する価値があるかどうか。

タスクの説明も、Claude が既知の範囲を再発見する必要があるかどうかを決定します。「テストが失敗した」は検索と候補ファイルの読み取りをトリガーします。「utils.test.ts を修正」はほとんどの検索を省略できます。ファイル参照をサポートするインターフェースで @utils.test.ts を使用すると、ファイルは最初のメッセージとともにコンテキストに入り、Read ツール呼び出しが一回減ります。

ファイルはセッションに入るとそこに残ります。@ファイル名 は検索、読み取り、往復を省きますが、ファイル自体のコンテキスト占有は減りません。後続のターンで同じファイルを繰り返し @ しないでください。二番目のコピーが追加される可能性があります。CLI、Desktop、IDE、リモート環境でのファイル参照のサポートは同じではないため、現在のインターフェースに従ってください。

コマンド出力はより制御不能になりがちです。テスト、ビルド、git log、デバッグログはすべてファイルと同様に履歴に追加されます。原文公開時、30,000 文字を超える出力はファイルに書き込まれ、プレビューとパスのみがコンテキストに戻されました。この閾値は BASH_MAX_OUTPUT_LENGTH で調整可能で、バージョンによって変わる可能性があります。より一般的な問題は、保護をトリガーしない中程度のノイズが数百行あることです。

この場合、最も効果的なアクションは：関連テストファイルのみ実行、quiet reporter の使用、エラー近傍のみ返す、ログレベルでフィルタ、tail で行数を制限などです。例えば npx vitest run <file> --reporter=dot のような高頻度コマンドを、簡潔なパラメータとともにプロジェクトの説明に書くと、コマンドを推測するターンを省き、数百行のパスログがセッションに入るのを防げます。統一的な制約が必要な場合は、Claude Code ドキュメントに従って Hook を設定し、高ノイズコマンド実行前にパラメータを自動的に書き換えることもできます。

以下のスライダーは、無関係なコンテンツがセッションに早期に入ると、「コンテンツ量 × 後続ターン数」で増幅される様子を示しています。これは構造を示すもので、Claude Code の請求計算機ではありません。

第三優先：モデル、Effort、キャッシュは最初に決める

一回のリクエストの価格は三つの変数に影響されます：モデル、入力と出力のフェーズ、プロンプトキャッシュの状態。

モデルはタスク完了の総コストで選ぶ

大きなモデルは通常、Token 単価が高くなります。明確な小さな修正、機械的な名前変更、フォーマット調整には、十分なモデルが適しています。アーキテクチャ判断、曖昧な障害、クロスシステム推論には、より強力な能力に投資する価値があります。

Token の単価だけを見ると誤判断します。難しいタスクでは、小さなモデルはより多くの検索、再試行、検証を必要とし、最終的に同じ品質に達しないことがあります。選択時には、許容可能な結果に達するために必要な総作業量を比較する必要があります。

Effort は、モデルが読み取るファイル数、呼び出すツール数、検証する程度に影響します。モデルが能力範囲を決定し、Effort がこのターンに投入する作業量を調整します。機械的なタスクでは Effort を下げ、追跡や判断が必要なタスクでは十分な深さを維持します。

原文では、MAX_THINKING_TOKENS=0 を一回のセッションで Thinking をオフにできると述べていますが、Fable 5 は例外です。これらの環境変数とモデル動作は急速に変化するため、現在のバージョンで確認された高度な設定として使用し、すべてのセッションで共通のデフォルト推奨にすべきではありません。

入力は全体読み取り、出力はトークンごとの生成

リクエストはまず Prefill で、モデルがツール定義、システムプロンプト、CLAUDE.md、メッセージ、ファイル、コマンド結果を読み取ります。この計算はモデルが実行される GPU、TPU などのハードウェアで行われます。その後、Decode に入り、思考、ツール呼び出し、可視応答をトークンごとに生成します。

Anthropic が現在リストしている主要な Claude モデルでは、出力 Token 単価は入力の約 5 倍です。Agent が不要な説明を少なく出力することは役立ちます。長いセッションでは、より大きな部分は依然として毎ターン再送信される入力履歴です。

プロンプトキャッシュは自動で機能するが、履歴をクリアしない

Claude Code はプロンプトキャッシュを自動的に管理し、ユーザーが有効にする必要はありません。それでも完全なセッションを再送信します。リクエストの先頭が前のターンと一致する場合、サーバーはキャッシュ状態を再利用できます。Anthropic の現在の API 価格では、キャッシュ読み取りは通常の入力価格の約 0.1 倍です。五分キャッシュ書き込みは 1.25 倍、一時間キャッシュ書き込みは 2 倍です。

キャッシュはリクエストプレフィックスが先頭から連続して一致する必要があります。リクエストは通常、ツール定義、システムプロンプト、会話履歴の順に組み立てられ、CLAUDE.md は会話の前部にあります。前の部分が変わると、後で Prefill する必要がある量が増えます。ファイルやツール結果を通常に追加する場合、古いプレフィックスは 0.1 倍の読み取りでヒットする可能性があります。途中でモデル、Effort を変更したり、Fast Mode をオンにしたり、/compact を実行したり、キャッシュの期限が切れてから戻ったりすると、関連履歴が再び Prefill される可能性があります。opusplan は Plan Mode に入るときと出るときにモデルを切り替えるため、これも該当します。原文は特に、Fast Mode をオフにして元の状態に戻しても、キャッシュレベルでは同じ再計算コストは発生しないと述べています。

サブスクリプションセッションと API のデフォルト TTL も異なります。主資料が示す現在の境界は、サブスクリプションシナリオでは一時間、API キーではデフォルトで五分です。API は一時間キャッシュを選択できます。会話を続けるたびに TTL タイマーはリセットされます。長時間後に古いセッションを再開すると、キャッシュは通常期限切れで、起動時のシステムプロンプトも再構築されます。具体的な実装と価格は、使用時の製品説明に従ってください。

/model と /effort は前回の選択を記憶しており、新しいセッションが必ずしもデフォルト値に戻るわけではありません。したがって、最初に実際の設定を確認します。切り替える必要がある場合は、新しいセッションの開始時または /clear 直後に優先して行い、長い履歴が形成されてから切り替えないでください。

キャッシュは繰り返し計算の価格を節約しますが、古いファイルやログがコンテキストから消えるわけではなく、モデルの判断に影響を与えるのを防ぐわけでもありません。したがって、無関係な履歴をクリーンアップすることは、キャッシュテクニックを追い求めることよりも重要です。

/compact と /rewind も用途が異なります。同じタスクで新しい段階に入り、古い詳細が価値を失った場合は、/compact で履歴を要約に書き換えます。末尾の数ターンだけ間違えた場合は、/rewind を優先します。誤ったブランチだけを切り取り、前のキャッシュプレフィックスは保持される可能性があるからです。

長時間離れて、戻って同じタスクを続ける場合は、キャッシュ有効期限内に先に /compact します。要約生成は現在のキャッシュを利用できるため、キャッシュ期限切れ後に古いセッションを完全に読み直してから圧縮するよりも、通常はお得です。

Subagent はノイズ分離に適しているが、すべての複雑なタスクには適さない

Subagent は独立したコンテキストを使用します。独自のシステムプロンプト、ツール、CLAUDE.md を持ち、メインセッションの全履歴を継承しません。タスクが終了すると、通常は答えや要約のみがメインセッションに戻り、途中で読んだログや試行はメインタスクに引き継がれません。メインセッションは、Subagent がレポートに積極的に書いたものだけを受け取るため、見逃した詳細は自動的に戻りません。

長いビルドログのスキャン、巨大な出力を持つ完全なテストの実行、大量の Git 履歴の検索は、このような分離に適しています。メインセッションは結論を必要とし、すべてのプロセス資料をタスク終了まで背負う必要はありません。

コストも明確です：Subagent は独自の起動コンテキストを再読み込みし、メインセッションが既に読んだファイルを再読する可能性があり、独立した複数ターンのリクエストを生成します。数十行のコードを読むだけの問題は、渡すと通常はコストが増えるだけです。

高ノイズタスクが繰り返し発生する場合は、専用の Subagent を作成し、小さくて安いモデルを明確に指定できます。原文では Haiku または Sonnet を例に挙げています。個別に指定しない場合、メインセッションの現在のモデルを使用します。これにより、繰り返される汚れ仕事の単回コストを制御できます。ただし、メインセッションが最終レポートのみを必要とする場合に限ります。

判断は一言で十分です：この作業の中間プロセスは、メインセッションが後で必要ですか？結論だけが必要でプロセスが非常にノイズが多い場合は、分離に価値があります。プロセス自体が後続の判断の根拠になる場合は、メインセッションに残します。

このガイドを使用する際の四つの境界

第一に、これは Anthropic が Claude Code ユーザー向けに公開した公式実践ガイドです。製品の現在のメカニズムと推奨事項を説明できますが、Claude Code が他の Agent ツールよりもコスト効率が良いとか効率的であると証明するものではありません。

第二に、サブスクリプションクレジットと API 請求は二つの異なるコスト表面です。サブスクリプションユーザーはトークンごとの金額を見られないかもしれませんが、同じコンテキストが依然として使用クレジットを消費します。API ユーザーは入力、出力、キャッシュ倍率に直接直面します。

第三に、モデル、価格、キャッシュ TTL、インターフェース機能、コマンド、環境変数はすべて変更される可能性があります。この記事の倍率と操作境界は、Anthropic が 2026 年 8 月に公開した記事と当時の公式ドキュメントに基づいています。

第四に、5 対 18 のリクエスト数、6/1/0 のツール呼び出し、1.9 倍の Token はすべて説明用のシナリオであり、それぞれの図の条件にのみ適用されます。

本当に役立つ目標は、Token をタスクに必要なコード、推論、検証に集中させることです。最初にモデルと Effort を決定し、既知の範囲を与え、ログを短くします。末尾で間違えたら /rewind、タスクを切り替えるときは /clear、高ノイズプロセスは Subagent に任せます。これにより、すべてのタスクが安くなることが保証されるわけではありませんが、セッションで最も一般的な非効率な負担を減らすことができます。