編集者注：Claude Code を使用する多くのユーザーは、トークンの消費が速く、長時間の会話で簡単にクォータを消費してしまうと感じています。しかし、Anthropic のエンジニアの視点から見ると、実際にコストに影響を与えるのは、書いたコードの量ではなく、システムが既に処理したコンテキストを継続的に再利用しているかどうかです。
本文の核心は、キャッシュメカニズムを通じてトークンを節約する方法です。著者は1週間で3億以上のトークンをキャッシュで再利用し、1日あたりのキャッシュ量は9100万に達しました。キャッシュトークンのコストは通常の入力トークンの10％に過ぎないため、9100万のキャッシュトークンは実質的に900万の通常トークンと同等の料金となります。Claude Codeの長時間セッションがより「持続可能」に見えるのは、モデルが無料で動作しているからではなく、多数の重複するコンテキストが成功裏に再利用されたためです。
プロンプトキャッシングの鍵は「キャッシュを中断しない」ことです。Claude Codeは、システムプロンプト、ツール定義、CLAUDE.md、プロジェクトルール、履歴会話を階層的にキャッシュします。後続のリクエストのプレフィックスが一致する限り、Claudeは全体のコンテキストを再処理するのではなく、キャッシュを直接読み取ります。Anthropicは、プロンプトキャッシュの再利用率を監視しており、これはユーザーのクォータに影響を与えるだけでなく、モデルサービスのコストと実行効率にも直接関係しています。
一般ユーザーにとって、すべての下層詳細を理解する必要はありません。以下の重要な習慣を身につけるだけで十分です：セッションを1時間以上空けないでください。タスクを切り替えるときはセッションの引き継ぎを行ってください。モデルを頻繁に切り替えないでください。大規模なドキュメントは対話に繰り返し貼り付けるのではなく、プロジェクトに格納してください。
この記事は、トークンを節約するテクニックについて語るというより、コンテキストを資産管理のように扱い、キャッシュを継続的に再利用し、長時間のセッションで重複した計算を減らすという、エンジニアに近いClaude Codeの使い方を提供している。
以下が原文です：
今週、私は3億トークンを節約しました。1日あたり9100万、1週間で3億以上です。
私は何も設定を変更していません。これは単にpromptキャッシュがバックグラウンドで正常に機能しているだけです。
しかし、キャッシュが何であるかを理解し、キャッシュを「切断」しない方法を学んだ後、同じ使用枠内でセッションをより長く継続できるようになりました。そこで、APIレベルの詳細には触れず、Claude Codeのプロンプトキャッシュに関する80/20入門ガイドをまとめました。
要約
キャッシュトークンのコストは通常の入力トークンの10％です。9100万のキャッシュトークンは、実際の課金額で約900万トークンに相当します。
Claude Code サブスクリプション版のキャッシュ TTL は 1 時間です。API のデフォルトは 5 分、サブエージェントは常に 5 分です。
キャッシュは三層に分かれています：システム層、プロジェクト層、対話層。
会話中にモデルを切り替えると、キャッシュが破壊されます。これには「opus plan」モードの有効化も含まれます。
キャッシュはどのように料金が計算されますか？
キャッシュされた各トークンのコストは、通常の入力トークンの10%です。
したがって、ダッシュボードに1日で9100万トークンがキャッシュにヒットしたと表示されても、実際の課金は約900万トークン分に相当します。これが、キャッシュなしと比較して、Claude Codeを長期間使用すると、セッションがほぼ「無料」で延長されるように感じる理由です。
ダッシュボードには注目すべき数字が二つあります：
キャッシュ作成：コンテンツをキャッシュに書き込む際に発生する一回限りのコストです。これは次の対話ラウンドで効果を発揮します。
キャッシュ読み取り：Claudeがキャッシュから再利用したトークン（例：CLAUDE.md、ツール定義、以前のメッセージなど）。再入力として処理するよりもコストが10分の1です。
キャッシュの読み取り数が高ければ、キャッシュを効果的に活用していることを意味します。この数が低ければ、同じコンテキストに対して繰り返し料金を支払っていることを示します。
AnthropicのThariqは、次の一言が印象的でした：「私たちは実際にprompt cacheのヒット率を監視しており、ヒット率が低すぎるとアラートが発生し、SEVレベルの事故とみなされることもあります。」
彼はまた、X 文章も優れたものを書きました。キャッシュヒット率が高い場合、以下の4つのことが同時に発生します：Claude Code がより速く感じられ、Anthropic のサービスコストが低下し、サブスクリプションのクォータがより長持ちし、長時間のコーディングセッションも現実的になります。
しかし、当選率が非常に低い場合、誰もが損をします。
したがって、両者のインセンティブは実際には一致しています：Anthropicはあなたのキャッシュヒット率を高めたいと考えており、あなた自身も同じくヒット率を高めたいと思っています。本当に問題となるのは、些細に見えるものの、キャッシュを静かにリセットしてしまうような習慣だけです。
キャッシュは各会話ラウンドごとにどのように増加しますか？
キャッシュはプレフィックスマッチ、つまり「前缀匹配」に依存しています。
深い技術的詳細にこだわる必要はありません。重要なのは、ある位置までの内容が既にキャッシュされた内容と完全に一致している場合、Claudeはその部分のキャッシュトークンを再利用できることです。
新たな会話は、このような形で展開されます：
Claude Codeのドキュメントによると、新しいセッションは次のように実行されます：
最初の会話：キャッシュはまだありません。システムプロンプト、プロジェクトコンテキスト（例：CLAUDE.md、memory、ルール）、およびあなたの最初のメッセージはすべて再処理され、キャッシュに書き込まれます。
第二ラウンドの会話：第一ラウンドのすべての内容はすでにキャッシュされています。Claudeは、あなたの新しい返信と次のメッセージのみを処理します。このラウンドのコストは大幅に低くなります。
第三回の会話：ロジックは同じです。以前の会話はキャッシュに保持されたままであり、最新の会話のみを再処理します。
キャッシュ自体は3層に分けられます：
ThariqのX投稿：
システム層（System layer）：基本コマンド、ツール定義（read、write、bash、grep、glob）および出力スタイルを含みます。この層はグローバルにキャッシュされます。
プロジェクト層（Project layer）：CLAUDE.md、memory、プロジェクトルールを含む。この層はプロジェクトごとにキャッシュされる。
対話層（Conversation）：返信とメッセージを含み、各ラウンドの対話とともに増加します。
セッションの途中でシステム層またはプロジェクト層のいずれかの内容が変更された場合、すべての内容を再び最初からキャッシュし直す必要があります。これが最も「コストがかかる」操作です。16番目のメッセージまで会話が進んだところで、システムプロンプトが突然変更されたり、1時間中断されたりした場合、1番目のメッセージからすべてのトークンを再処理しなければなりません。
1時間と5分の混同
これは最も誤解されやすい部分です。
Claude Code サブスクリプション版：デフォルトのTTLは1時間です。
Claude API：デフォルトのTTLは5分です。より高いコストを支払うことで、1時間に延長できます。
あらゆるプランにおけるサブエージェント：常に5分。
Claude.ai ワンタイムチャット：公式には明確に記録されていません。サブスクリプション版と同じ可能性がありますが、まだ確認していません。
数ヶ月前、多くのユーザーがClaudeのサブスクリプションクォータが早く消費されると不満を述べました。当時、AnthropicがTTLを1時間から5分に勝手に引き下げ、ユーザーに通知しなかったと考える人もいました。しかし、実際にはClaude CodeのTTLはまだ1時間です。
問題は、Claude Code と API のドキュメントが別々に提供されていることであり、これらは本来完全に異なるものであるため、多くの混乱を招いています。
大量のSub-agentワークフローを実行している場合、またはAPIを直接使用している場合、5分という数字は重要です。しかし、95%のClaude Codeユーザーにとって、実際に注目すべきなのは、1時間のウィンドウだけです。
95%のユーザーをカバーする3つの習慣
以下は、日常使用において本当に役立つ部分です。
あまり長く停止しないでください
1時間以上空いている場合、以前の内容はほぼキャッシュから期限切れになっています。次のメッセージでキャッシュが再構築されます。このような場合、「冷めてしまった」旧セッションを復元するよりも、明確に引き継ぎを行い、新しいセッションを開始した方が、通常コストが低くなります。
タスクを切り替えるときは、そのまま再開始してください
/compact または /clear は本来キャッシュを破壊するため、このタイミングで真正にリセットしてしまうのが良いでしょう。
私は /compact の代わりにセッションの引き継ぎスキルを自作しました。これにより、これまでに完了した内容、未決定の意思決定、最も重要なファイル、そして次にどこから継続すべきかを要約します。その後、/clear を実行してこの要約を貼り付けることで、中断されたように感じさせることなく作業を継続できます。
compact コマンドは時々非常に遅く実行されます。一方、この handoff スキルは通常1分以内で完了します。
Claudeチャットでは、大規模なドキュメントはProjectsにできるだけ入れてください。
Claude.ai のキャッシュメカニズムについては、公式による詳細な説明がありませんが、Projects は通常の対話スレッドとは異なる最適化手法を採用しているようです。したがって、大きなドキュメントを貼り付ける場合は、対話に直接挿入するのではなく、Projects に格納することをお勧めします。
どのような操作がキャッシュを静かに破壊しますか？
いくつかの操作では、明示的な通知なしにキャッシュがすべてリセットされます。
モデルの切り替え：キャッシュはプレフィックスマッチに依存しており、各モデルには独自のキャッシュがあります。モデルを切り替えると、次回のリクエストではキャッシュヒットがなく、完全な履歴を再読み込みします。
「Opus plan」モード：この設定では、計画段階でOpusを使用し、実行段階でSonnetを使用します。以前、いくつかのトークン最適化動画で推奨したのは、理由があります。ただし、プランを切り替えるたびに、本質的にはモデルの切り替えが発生し、キャッシュを再構築する必要があることを理解してください。長期的には、セッションクォータの延長に役立ちますが、その背後で何が起きているかを把握しておく必要があります。
会話中にCLAUDE.mdを編集することは可能です：この変更は即座には適用されず、次回の再起動時に反映されます。したがって、現在実行中のキャッシュには影響しません。
私の無料トークンドashboard
私が前に示したスクリーンショットは、あるトークンダッシュボードからのものです。
これは非常にシンプルなGitHubリポジトリです。リンクをClaude Codeに渡して、ローカルのlocalhostにデプロイさせると、空白状態からカウントするのではなく、過去のすべてのセッション履歴を読み取ります。最初から毎日のinput、output、cache create、cache readのデータが表示されます。
ただし、一点注意が必要です：このダッシュボードは、ローカルデバイス上のトークンデータを統計しています。デスクトップからノートパソコンに切り替えた場合、数字は完全には一致しません。各デバイスには独自の統計ビューがあります。
要約
プロンプトキャッシングは深く研究できるテーマです。Thariqの記事では、ここで述べられているよりもはるかに完全に説明されています。全体像を知りたい場合は、読む価値があります。
しかし、すべての詳細を完全に理解しなくても、そこから利益を得ることができます。最も重要な80/20ルールを押さえるだけで十分です：キャッシュされたトークンは通常のトークンより10倍安価です；Claude CodeのTTLは1時間です；モデルを切り替えるとキャッシュが破壊されます；タスク間で明確な引き継ぎを行うことが、古いセッションを「期限切れ」になるまで放置してから無理に継続するよりも通常、よりコスト効率が良いです。