Anthropicのエンジニアが実際にトークンを節約する方法
原文作者：Nate Herk
編集：Peggy、BlockBeats

編集者注：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 のドキュメントが別々に提供されていることであり、これらは本来完全に異なるものであるため、多くの混乱を招いています。

サブエージェントワークフローを大量に実行している場合、またはAPIを直接使用している場合、5分という数字は重要です。しかし、95%のClaude Codeユーザーにとって、実際に注目すべきなのは、1時間のウィンドウだけです。

95%のユーザーをカバーする3つの習慣

以下は、日常使用において本当に役立つ部分です。

1時間以上空いている場合、以前の内容はほぼキャッシュから期限切れになっています。次のメッセージでキャッシュが再構築されます。このような場合、「冷めてしまった」古いセッションを復元するよりも、明確に引き継いで新しいセッションを開始した方が、通常コストが低くなります。

/compact または /clear は本来キャッシュを破壊するため、このタイミングで真正にリセットした方が良いです。

私は /compact の代わりにセッションハンドオフのスキルを自分で作成しました。これにより、これまでに完了した内容、未決定の意思決定、最も重要なファイル、そして次にどこから継続すべきかを要約します。その後、/clear を実行してこの要約を貼り付けることで、中断されたように感じさせずに作業を継続できます。

compact コマンドは時々非常に遅く実行されます。一方、この handoff スキルは通常1分以内で完了します。

Claude.ai のキャッシュメカニズムについては、公式による詳細な説明がありませんが、Projects は通常の対話スレッドとは異なる最適化手法を採用しているようです。したがって、大きなドキュメントを貼り付ける場合は、対話に直接挿入するのではなく、Projects に保存することをお勧めします。

どのような操作がキャッシュを静かに破壊しますか？

いくつかの操作では、明示的な通知なしにキャッシュがすべてリセットされます。

モデルを切り替える：キャッシュはプレフィックス一致に依存しており、各モデルには独自のキャッシュがあります。モデルを切り替えると、次回のリクエストではキャッシュヒットがなく、完全な履歴を再読み込みします。

「Opus plan」モード：この設定では、計画段階でOpusを使用し、実行段階でSonnetを使用します。以前、いくつかのトークン最適化ビデオでこの設定を推奨した理由があります。ただし、プランを切り替えるたびに、本質的にはモデルの切り替えが発生し、キャッシュを再構築する必要があることを理解してください。長期的には、セッションクォータの延長に役立ちますが、その背後で何が起きているかを把握しておく必要があります。

会話中に CLAUDE.md を編集することは可能です：この変更は即座には適用されず、次回の再起動時に反映されます。したがって、現在実行中のキャッシュには影響しません。

私が前に示したスクリーンショットは、あるトークンダッシュボードからのものです。

https://github.com/nateherkai/token-dashboard

これは非常にシンプルなGitHubリポジトリです。リンクをClaude Codeに渡して、ローカルのlocalhostにデプロイさせると、空白状態から数えるのではなく、過去のすべてのセッション履歴を読み取ります。最初から、毎日のinput、output、cache create、cache readのデータが表示されます。

ただし、一点注意が必要です：このダッシュボードは、ローカルデバイス上のトークンデータを統計しています。デスクトップからノートパソコンに切り替えた場合、数字は完全には一致しません。各デバイスには独自の統計ビューがあります。

要約

プロンプトキャッシングは、深く研究できるテーマです。Thariqの記事では、ここで述べられているよりもはるかに完全に説明されています。全体像を知りたい場合は、読む価値があります。

しかし、すべての詳細を完全に理解しなくても、そこから利益を得ることができます。最も重要な80/20を把握すれば十分です：キャッシュされたトークンは通常のトークンより10倍安価です；Claude CodeのTTLは1時間です；モデルを切り替えるとキャッシュが破壊されます；タスク間で明確な引き継ぎを行うことが、古いセッションを「期限切れ」になるまで放置してから無理に継続するよりも通常、コスト効率が良いです。

[原文リンク]

動きのあるBlockBeatsの採用ポジションを詳しく見る

律動 BlockBeats 公式コミュニティへようこそ：

Telegram サブスクリプショングループ：https://t.me/theblockbeats

Telegram交流グループ：https://t.me/BlockBeats_App

Twitter公式アカウント：https://twitter.com/BlockBeatsAsia