原文タイトル：How Anthropic Engineers Actually Save Tokens原文作者：Nate Herk編訳：Peggy，BlockBeats原文作者：律動BlockBeats原文来源：転載：火星财经編者按：多くの人がClaude Codeを使用する際、最も直感的に感じるのはTokenの消費が速すぎることや、長い会話が容易にクォータを使い果たすことだ。しかし、Anthropicのエンジニアの視点から見ると、実際にコストに影響を与えるのは、あなたがどれだけコードを書いたかではなく、システムが既に処理したコンテキストを継続的に再利用できているかどうかだ。この記事の核心は、キャッシュメカニズムを通じてTokenを節約する方法についてだ。著者は一週間で3億以上のTokenをキャッシュで再利用し、1日のキャッシュ量は9100万を超えた。キャッシュされたTokenのコストは通常の入力Tokenの10%しかかからないため、9100万のキャッシュTokenは実質的に約900万の普通Tokenと同じ料金になる。長い会話が「耐久性」を持つように見えるのは、モデルの無料運用によるものではなく、多くの重複したコンテキストが成功裏に再利用されているからだ。Prompt cachingの鍵は、「キャッシュを中断しないこと」だ。Claude Codeは、システムプロンプト、ツール定義、CLAUDE.md、プロジェクトルール、過去の対話履歴を層別にキャッシュしている。後続のリクエストのプレフィックスが一致していれば、Claudeはキャッシュを直接読み込み、全体のコンテキストを再処理しない。Anthropic内部でもprompt cacheの再利用率を監視しており、それはユーザのクォータに影響するだけでなく、モデルサービスのコストや運用効率にも直結している。一般ユーザにとっては、すべての底層の詳細を理解する必要はなく、いくつかの重要な習慣を身につけるだけで十分だ：会話を1時間以上放置しないこと；タスク切り替え時にセッションの引き継ぎをきちんと行うこと；モデルの頻繁な切り替えを避けること；大きなドキュメントはProjectsに入れ、何度も貼り付けるのを避けること。この記事は、Tokenを節約するテクニックというよりも、エンジニアの思考に近いClaude Codeの使い方を提案している：コンテキストを資産管理とみなしてキャッシュを持続的に再利用し、長い会話の中で無駄な計算を減らすことだ。以下は原文の内容だ。今週、私は3億Tokenを節約し、1日で9100万を節約した。一週間で合計3億を超えた。設定を一切変更していない。これはPrompt cachingが裏で正常に働いているだけだ。しかし、キャッシュが何であるか、そしてどうやって「中断」させないかを理解したことで、同じクォータ内でも会話をより長く続けられるようになった。そこで、Claude Codeのprompt cachingの80/20入門ガイドを整理した。APIの深い詳細には触れない。TL;DRキャッシュされたTokenのコストは、普通の入力Tokenの10%しかかからない。9100万のキャッシュTokenは、実質的に約900万Tokenと同じ料金。Claude Codeのサブスクリプション版のキャッシュTTLは1時間；APIのデフォルトは5分；Sub-agentは常に5分。キャッシュは3層に分かれる：システム層、プロジェクト層、対話層。会話中にモデルを切り替えるとキャッシュが破壊される。たとえば「opus plan」モードの有効化も同様。キャッシュの料金計算はどうなる？キャッシュされたTokenのコストは、普通の入力Tokenの10%だ。したがって、ダッシュボードにある「ある日、9100万Tokenがキャッシュされた」と表示されても、実際の請求は約900万Token分に相当する。これが、長時間Claude Codeを使うと会話がほぼ「無料」に近いと感じられる理由だ。ダッシュボードの2つの数字に注目すべきだ：Cache create：キャッシュに内容を書き込む際の一時的コスト。次の対話で役立つ。 Cache read：Claudeがキャッシュから再利用したToken数。たとえばCLAUDE.mdやツール定義、過去のメッセージなど。再入力として処理するよりもコストは10倍安い。この数字が高い場合、キャッシュを効果的に利用している証拠だ。低い場合は、同じコンテキストに対して繰り返し課金していることになる。AnthropicのThariqは次のように言う：「私たちはprompt cacheのヒット率を実際に監視しており、ヒット率が低すぎると警報を出し、SEVレベルの事故を宣言することもある。」彼はまた、非常に良いX記事も書いている。キャッシュのヒット率が高いとき、次の4つのことが同時に起きる：Claude Codeの体感速度が向上し、Anthropicのサービスコストが下がり、あなたのサブスクリプションのクォータが長持ちし、長時間のコーディング会話も現実的になる。しかし、ヒット率が低いと、皆が損をする。したがって、双方のインセンティブは一致している：Anthropicはあなたのキャッシュヒット率を高めたいし、あなたも高めたい。実際に足を引っ張るのは、見た目は些細だが、静かにキャッシュをリセットしてしまう小さな習慣だ。キャッシュは各ラウンドの会話でどう増えるのか？キャッシュはプレフィックスマッチング、つまり「前方一致」に依存している。深く技術的な詳細に踏み込む必要はない。理解すべきポイントは、ある位置までの内容と既にキャッシュされた内容が完全に一致すれば、Claudeはその部分のキャッシュTokenを再利用できるということだ。新規の会話はおおよそ次のように展開される：Claude Codeのドキュメントによると、新規会話は次のように動作する：第1ラウンド：キャッシュは何もない。システムプロンプト、プロジェクトのコンテキスト（例：CLAUDE.md、memory、ルール）、最初のメッセージはすべて再処理され、キャッシュに書き込まれる。第2ラウンド：第1ラウンドのすべての内容がキャッシュ済み。Claudeは新しい返信と次のメッセージだけを処理すればよい。このラウンドのコストは大幅に低減。第3ラウンド：同様に、過去の会話はキャッシュに残っており、最新のやりとりだけを再処理。キャッシュは3層に分かれる：ThariqのX記事より：システム層（System layer）：基本指示、ツール定義（read、write、bash、grep、glob）、出力スタイル。これはグローバルキャッシュ。プロジェクト層（Project layer）：CLAUDE.md、memory、プロジェクトルール。これはプロジェクトごとにキャッシュ。対話層（Conversation）：返信やメッセージ。各ラウンドごとに増加。会話中にシステム層やプロジェクト層の内容が変わると、すべての内容を最初から再キャッシュし直す必要がある。これが最も「高価」な操作だ。たとえば、16回目のメッセージまで進んだ後にシステムプロンプトを変更したり、1時間放置したりすると、最初のメッセージからのすべてのTokenが再処理される。1時間と5分のTTLの混乱これは最も誤解を招きやすい部分だ。Claude Codeのサブスクリプション版：デフォルトTTLは1時間。Claude API：デフォルトTTLは5分。より高いコストを払えば1時間に延長可能。どのプランでもSub-agentは常に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コマンドは時々遅いこともあるが、この引き継ぎスキルは通常1分以内に完了する。Claudeのチャットでは、大きなドキュメントはProjectsに入れるのが望ましいClaude.aiのキャッシュメカニズムについて公式の詳細な説明はないが、Projectsは明らかに普通の対話スレッドとは異なる最適化を採用している。したがって、大きなドキュメントを貼り付ける場合は、直接対話に貼るのではなく、Projectsに入れるのが良い。キャッシュを静かに破壊する操作は何か？いくつかの操作は、明示的な警告なしにキャッシュを完全にリセットしてしまう。モデルの切り替え：キャッシュはプレフィックスマッチングに依存しているため、モデルを切り替えると次回のリクエストはキャッシュヒットせず、全履歴を再読み込みする必要がある。「Opus plan」モード：この設定は計画段階でOpusを使い、実行段階でSonnetを使う。以前の動画で推奨したこともあるが、理解すべきは、計画を切り替えるたびにモデルも切り替わり、キャッシュも再構築されるということだ。長期的には会話クォータの延長に役立つが、その仕組みを理解しておく必要がある。会話途中でCLAUDE.mdを編集しても良いが、その変更は即座には反映されず、次回の再起動まで適用されない。したがって、現在動作中のキャッシュには影響しない。私の無料Tokenダッシュボード前述のスクリーンショットは、Tokenダッシュボードからのものだ。これは非常にシンプルなGitHubリポジトリで、リンクをClaude Codeに渡すと、ローカルのlocalhost上で展開され、過去の会話記録を読み取り、空白から始めるのではなく、毎日の入力、出力、キャッシュ作成、キャッシュ読み込みのデータを見ることができる。ただし注意点は、このダッシュボードはローカルデバイス上のTokenデータを集計していることだ。デスクトップからノートブックに切り替えると数字が一致しない場合もある。各デバイスごとに統計ビューが異なる。まとめPrompt cachingは深く研究できるテーマだ。Thariqのその記事はより詳細に解説しているので、全体像を知りたいなら読む価値がある。しかし、すべての詳細を理解しなくても、恩恵を受けることはできる。最も重要な80/20のポイントは次の通りだ：キャッシュされたTokenは普通のTokenの10倍安い；Claude CodeのTTLは1時間；モデル切り替えはキャッシュを破壊する；タスク間の明確な引き継ぎを行うことで、古い会話を「期限切れ」にして再利用するよりもコストを抑えられる。
1週間で3億トークン節約、AnthropicエンジニアのClaude Codeキャッシュガイド
原文タイトル：How Anthropic Engineers Actually Save Tokens原文作者：Nate Herk編訳：Peggy，BlockBeats
原文作者：律動BlockBeats
原文来源：
転載：火星财经
編者按：多くの人がClaude Codeを使用する際、最も直感的に感じるのはTokenの消費が速すぎることや、長い会話が容易にクォータを使い果たすことだ。しかし、Anthropicのエンジニアの視点から見ると、実際にコストに影響を与えるのは、あなたがどれだけコードを書いたかではなく、システムが既に処理したコンテキストを継続的に再利用できているかどうかだ。
この記事の核心は、キャッシュメカニズムを通じてTokenを節約する方法についてだ。著者は一週間で3億以上のTokenをキャッシュで再利用し、1日のキャッシュ量は9100万を超えた。キャッシュされたTokenのコストは通常の入力Tokenの10%しかかからないため、9100万のキャッシュTokenは実質的に約900万の普通Tokenと同じ料金になる。長い会話が「耐久性」を持つように見えるのは、モデルの無料運用によるものではなく、多くの重複したコンテキストが成功裏に再利用されているからだ。
Prompt cachingの鍵は、「キャッシュを中断しないこと」だ。Claude Codeは、システムプロンプト、ツール定義、CLAUDE.md、プロジェクトルール、過去の対話履歴を層別にキャッシュしている。後続のリクエストのプレフィックスが一致していれば、Claudeはキャッシュを直接読み込み、全体のコンテキストを再処理しない。Anthropic内部でもprompt cacheの再利用率を監視しており、それはユーザのクォータに影響するだけでなく、モデルサービスのコストや運用効率にも直結している。
一般ユーザにとっては、すべての底層の詳細を理解する必要はなく、いくつかの重要な習慣を身につけるだけで十分だ：会話を1時間以上放置しないこと；タスク切り替え時にセッションの引き継ぎをきちんと行うこと；モデルの頻繁な切り替えを避けること；大きなドキュメントはProjectsに入れ、何度も貼り付けるのを避けること。
この記事は、Tokenを節約するテクニックというよりも、エンジニアの思考に近いClaude Codeの使い方を提案している：コンテキストを資産管理とみなしてキャッシュを持続的に再利用し、長い会話の中で無駄な計算を減らすことだ。
以下は原文の内容だ。
今週、私は3億Tokenを節約し、1日で9100万を節約した。一週間で合計3億を超えた。
設定を一切変更していない。これはPrompt cachingが裏で正常に働いているだけだ。
しかし、キャッシュが何であるか、そしてどうやって「中断」させないかを理解したことで、同じクォータ内でも会話をより長く続けられるようになった。そこで、Claude Codeのprompt cachingの80/20入門ガイドを整理した。APIの深い詳細には触れない。
TL;DR
キャッシュされたTokenのコストは、普通の入力Tokenの10%しかかからない。9100万のキャッシュTokenは、実質的に約900万Tokenと同じ料金。
Claude Codeのサブスクリプション版のキャッシュTTLは1時間；APIのデフォルトは5分；Sub-agentは常に5分。
キャッシュは3層に分かれる：システム層、プロジェクト層、対話層。
会話中にモデルを切り替えるとキャッシュが破壊される。たとえば「opus plan」モードの有効化も同様。
キャッシュの料金計算はどうなる？
キャッシュされたTokenのコストは、普通の入力Tokenの10%だ。
したがって、ダッシュボードにある「ある日、9100万Tokenがキャッシュされた」と表示されても、実際の請求は約900万Token分に相当する。これが、長時間Claude Codeを使うと会話がほぼ「無料」に近いと感じられる理由だ。
ダッシュボードの2つの数字に注目すべきだ：
Cache create：キャッシュに内容を書き込む際の一時的コスト。次の対話で役立つ。 Cache read：Claudeがキャッシュから再利用したToken数。たとえばCLAUDE.mdやツール定義、過去のメッセージなど。再入力として処理するよりもコストは10倍安い。
この数字が高い場合、キャッシュを効果的に利用している証拠だ。低い場合は、同じコンテキストに対して繰り返し課金していることになる。
AnthropicのThariqは次のように言う：「私たちはprompt cacheのヒット率を実際に監視しており、ヒット率が低すぎると警報を出し、SEVレベルの事故を宣言することもある。」
彼はまた、非常に良いX記事も書いている。キャッシュのヒット率が高いとき、次の4つのことが同時に起きる：Claude Codeの体感速度が向上し、Anthropicのサービスコストが下がり、あなたのサブスクリプションのクォータが長持ちし、長時間のコーディング会話も現実的になる。
しかし、ヒット率が低いと、皆が損をする。
したがって、双方のインセンティブは一致している：Anthropicはあなたのキャッシュヒット率を高めたいし、あなたも高めたい。実際に足を引っ張るのは、見た目は些細だが、静かにキャッシュをリセットしてしまう小さな習慣だ。
キャッシュは各ラウンドの会話でどう増えるのか？
キャッシュはプレフィックスマッチング、つまり「前方一致」に依存している。
深く技術的な詳細に踏み込む必要はない。理解すべきポイントは、ある位置までの内容と既にキャッシュされた内容が完全に一致すれば、Claudeはその部分のキャッシュTokenを再利用できるということだ。
新規の会話はおおよそ次のように展開される：
Claude Codeのドキュメントによると、新規会話は次のように動作する：
第1ラウンド：キャッシュは何もない。システムプロンプト、プロジェクトのコンテキスト（例：CLAUDE.md、memory、ルール）、最初のメッセージはすべて再処理され、キャッシュに書き込まれる。
第2ラウンド：第1ラウンドのすべての内容がキャッシュ済み。Claudeは新しい返信と次のメッセージだけを処理すればよい。このラウンドのコストは大幅に低減。
第3ラウンド：同様に、過去の会話はキャッシュに残っており、最新のやりとりだけを再処理。
キャッシュは3層に分かれる：
ThariqのX記事より：
システム層（System layer）：基本指示、ツール定義（read、write、bash、grep、glob）、出力スタイル。これはグローバルキャッシュ。
プロジェクト層（Project layer）：CLAUDE.md、memory、プロジェクトルール。これはプロジェクトごとにキャッシュ。
対話層（Conversation）：返信やメッセージ。各ラウンドごとに増加。
会話中にシステム層やプロジェクト層の内容が変わると、すべての内容を最初から再キャッシュし直す必要がある。これが最も「高価」な操作だ。たとえば、16回目のメッセージまで進んだ後にシステムプロンプトを変更したり、1時間放置したりすると、最初のメッセージからのすべてのTokenが再処理される。
1時間と5分のTTLの混乱
これは最も誤解を招きやすい部分だ。
Claude Codeのサブスクリプション版：デフォルトTTLは1時間。
Claude API：デフォルトTTLは5分。より高いコストを払えば1時間に延長可能。どのプランでもSub-agentは常に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コマンドは時々遅いこともあるが、この引き継ぎスキルは通常1分以内に完了する。
Claudeのチャットでは、大きなドキュメントはProjectsに入れるのが望ましい
Claude.aiのキャッシュメカニズムについて公式の詳細な説明はないが、Projectsは明らかに普通の対話スレッドとは異なる最適化を採用している。したがって、大きなドキュメントを貼り付ける場合は、直接対話に貼るのではなく、Projectsに入れるのが良い。
キャッシュを静かに破壊する操作は何か？
いくつかの操作は、明示的な警告なしにキャッシュを完全にリセットしてしまう。
モデルの切り替え：キャッシュはプレフィックスマッチングに依存しているため、モデルを切り替えると次回のリクエストはキャッシュヒットせず、全履歴を再読み込みする必要がある。
「Opus plan」モード：この設定は計画段階でOpusを使い、実行段階でSonnetを使う。以前の動画で推奨したこともあるが、理解すべきは、計画を切り替えるたびにモデルも切り替わり、キャッシュも再構築されるということだ。長期的には会話クォータの延長に役立つが、その仕組みを理解しておく必要がある。
会話途中でCLAUDE.mdを編集しても良いが、その変更は即座には反映されず、次回の再起動まで適用されない。したがって、現在動作中のキャッシュには影響しない。
私の無料Tokenダッシュボード
前述のスクリーンショットは、Tokenダッシュボードからのものだ。
これは非常にシンプルなGitHubリポジトリで、リンクをClaude Codeに渡すと、ローカルのlocalhost上で展開され、過去の会話記録を読み取り、空白から始めるのではなく、毎日の入力、出力、キャッシュ作成、キャッシュ読み込みのデータを見ることができる。
ただし注意点は、このダッシュボードはローカルデバイス上のTokenデータを集計していることだ。デスクトップからノートブックに切り替えると数字が一致しない場合もある。各デバイスごとに統計ビューが異なる。
まとめ
Prompt cachingは深く研究できるテーマだ。Thariqのその記事はより詳細に解説しているので、全体像を知りたいなら読む価値がある。
しかし、すべての詳細を理解しなくても、恩恵を受けることはできる。最も重要な80/20のポイントは次の通りだ：キャッシュされたTokenは普通のTokenの10倍安い；Claude CodeのTTLは1時間；モデル切り替えはキャッシュを破壊する；タスク間の明確な引き継ぎを行うことで、古い会話を「期限切れ」にして再利用するよりもコストを抑えられる。
彼らのキャッシュ戦略の詳細が気になる。