Claude Code 長対話のクォータ制限？エンジニアの Nate Herk が明かす、一週間でキャッシュ機構により3億Token節約、1日の最大9100万。重要なのはどれだけコードを書いたかではなく、「キャッシュを壊さず」、繰り返しのコンテキストを無駄にしない方法。 （前提：Claude codeの高速化を狙ったbadclaudeオープンソースプロジェクトに対し、Anthropicから侵害通知が届いた話） （補足：Claude Codeにクラウド定期ジョブ機能追加！PC不要、AIがPR審査やアップグレード自動化）本文目次Toggle* キャッシュコストはわずか10%、9100万Tokenは900万に相当* 3層アーキテクチャ：システム、プロジェクト、対話、層層積み重ね* よくある「断緩」落とし穴：モデル切り替えと空白1時間* エンジニア自作ダッシュボード：Cache ReadとCreateを確認* 実戦の心法：Session Handoffは /compact よりコスト節約多くの開発者がClaude Codeでプログラムを書く際、最も頭を悩ませるのはTokenのクォータがあっという間に底をつき、長い対話はほぼ贅沢品になってしまうこと。しかし、コミュニティでAI活用テクニックを共有するインフルエンサー Nate Herkは、Xの投稿で**明かした**。実際のコスト削減の決め手はコード量ではなく、prompt caching（プロンプトキャッシュ）をいかに有効活用しているかだと。彼は一週間でキャッシュを駆使し、3億Token超を節約、1日あたり9100万Tokenをキャッシュで節約した。 キャッシュTokenのコストは通常入力Tokenの10%に過ぎず、この計算だと1日900万Token分のコストで済むため、「ほぼ無料」で長時間の対話延長が可能になる。* * *今週、私は3億Token節約し、1日最大9100万Tokenをキャッシュで節約した。設定変更は一切していない。これはprompt cachingが裏で正常に働いているだけ。しかし、キャッシュの仕組みとその回避方法を理解したことで、同じクォータ内でも会話を長く続けられるようになった。そこで、Claude Codeのprompt cachingの80/20入門ガイドを整理。APIの深い詳細には触れない。キャッシュTokenのコストは普通のTokenの10%。9100万TokenのキャッシュTokenは、実質約900万Token分の課金に相当。Claude Codeのサブスクリプション版のキャッシュTTLは1時間。APIはデフォルトで5分、サブエージェントは常に5分。キャッシュは3層：システム層、プロジェクト層、対話層。会話中にモデルを切り替えるとキャッシュは破壊される。たとえば「opus plan」モードの有効化も同様。> coding agents need glass boxes now> > jianshuo/ccglass> > > githubで111スター > > 昨日作成 > > MIT + JavaScript > > Claude code、Codex、DeepSeek-TUI、Kimi用のローカルプロキシ＋Webダッシュボード > > システムプロンプト、ツールスキーマ、メッセージ履歴、トークン／キャッシュ／コスト、画像も表示https://pic.twitter.com/Wot5SFV16N> > — Beau Johnson (@BeauJohnson89) 2026年5月24日### キャッシュコストはわずか10%、9100万Tokenは900万に相当キャッシュされたTokenはすべて、普通の入力Tokenの10%のコスト。つまり、私のダッシュボードである日「9100万Tokenがキャッシュヒット」したと表示された場合、実際の課金は約900万Token分だけ。これが、長時間Claude Codeを使うときに会話が「無料」に近い延長感をもたらす理由だ。ダッシュボードの注目ポイントは2つ：Cache create：内容を書き込む際の一時コスト。次の対話で役立つ。 Cache read：Claudeがキャッシュから再利用するToken。たとえばCLAUDE.mdやツール定義、過去のメッセージなど。再入力と比べてコストは10分の1。もしCache readの数字が高いなら、キャッシュを効果的に使っている証拠。低い場合は、同じコンテキストに何度も課金していることになる。AnthropicのThariqは一言、「prompt cacheのヒット率を監視している。ヒット率が低いとアラートやSEV級の事故を発生させる」と。彼は良いX記事も書いている。キャッシュヒット率が高いと、Claude Codeはより速く感じられ、Anthropicのコストも下がり、あなたのサブクォータも長持ちし、長時間のコーディング会話も現実的になる。逆にヒット率が低いと、みんな損をする。### 3層アーキテクチャ：システム、プロジェクト、対話双方のインセンティブは一致している：Anthropicはヒット率を高めたい、あなたも高めたい。実際の妨げになるのは、ちょっとした習慣の積み重ね。キャッシュはprefix matching（字首一致）に依存。深く技術的に理解しなくても良いが、ポイントは： ある位置までの内容と既存キャッシュが完全一致すれば、ClaudeはそのキャッシュTokenを再利用できる。新規会話の流れはおおむねこう：Claude Codeのファイルに基づき、新規会話はこう進む：第一ラウンド：キャッシュなし。システムプロンプト、プロジェクトコンテキスト（例：CLAUDE.md、メモリ、ルール）、最初のメッセージは再処理され、キャッシュに書き込まれる。第二ラウンド：一回目の内容はすべてキャッシュ済み。Claudeは新しい返信と次のメッセージだけ処理。コストは大幅に低減。第三ラウンド：同じく。過去の会話はキャッシュにあり、最新のやりとりだけ再処理。### よくある「断緩」落とし穴：モデル切り替えと空白1時間キャッシュは3層に分かれる：ThariqのX記事より：システム層（System layer）：基本指令、ツール定義（read、write、bash、grep、glob）、出力スタイル。全域キャッシュの対象。プロジェクト層（Project layer）：CLAUDE.md、メモリ、ルール。プロジェクトごとにキャッシュ。対話層（Conversation）：返信とメッセージ。会話ごとに増加。途中でシステム層やプロジェクト層の内容が変わると、すべての内容を最初から再キャッシュし直す必要がある。これが最もコスト高な操作。たとえば、16回目の会話中にシステムプロンプトを変更したり、1時間空白があったりすると、最初の1回目からやり直し。これが最も誤解されやすいポイント。Claude Codeサブスクリプション：デフォルトTTLは1時間。### エンジニア自作ダッシュボード：Cache ReadとCreateを確認Claude API：デフォルトTTLは5分。より高コストを払えば1時間に延長可能。 サブエージェントは常に5分。Claude.aiのWebチャット：公式には明記なし。サブスクリプションと同じかもだが未確認。数か月前、多くの人がClaudeのクォータ消費が早すぎると不満を漏らした。ある人は、AnthropicがこっそりTTLを1時間から5分に下げたと誤解したが、実際は違い、Claude CodeのTTLは依然1時間のまま。問題は、Claude CodeとAPIの設定が別管理されていること。これにより混乱が生じている。大量にSub-agentを使う場合やAPIを直に使う場合は5分が重要だが、95%のClaude Codeユーザーにとっては、実は1時間のウィンドウだけを気にすれば良い。以下は、日常的に役立つポイント。1時間以上放置した場合、以前の内容はほぼキャッシュから消えている。次のメッセージは新たにキャッシュを構築し直す。こういうときは、古い会話を無理に続けるよりも、きっぱり切り替えて新規会話を始めたほうがコストも低く済む。/compactや/clearはキャッシュ破壊コマンドなので、むしろこのタイミングで再構築を狙う。### 実戦の心法：Session Handoffは /compact よりコスト節約自分はSession Handoffのスキルを作った。これにより、/compactの代わりに、何をしたか、未解決の決定事項、重要なファイル、次に何をすべきかを要約し、それを貼り付けて続行できる。/clearを実行し、その要約を貼るだけ。中断なしに続けられる。/compactは時に遅いし、Handoffは通常1分以内に完了。Claude.aiのキャッシュ仕組みは詳細な公式説明は少ないが、Projectsは普通の対話と異なる最適化を採用している。大きなファイルを貼る場合は、対話に直接貼るよりもProjectに入れるほうが良い。キャッシュを無意識に全破壊する操作：モデル切り替え：キャッシュは字首一致に依存。モデルごとにキャッシュが分かれるため、モデルを変えると次回リクエストはキャッシュなしで全履歴を再読込。「Opus plan」モード：この設定はOpusを計画段階で使い、実行段階でSonnetを使う。以前の動画で推奨した理由もあるが、理解すべきは、プラン切り替え＝モデル切り替えと同じ。これもキャッシュ破壊を招く。長期的には会話クォータ延長に役立つが、底層の仕組みを理解しておく必要がある。会話途中でCLAUDE.mdを編集しても良いが、即時反映されず、次回再起動時に適用。現状のキャッシュには影響しない。前述のスクリーンショットは、トークンダッシュボードの例。> https://github.com/nateherkai/token-dashboard > これはシンプルなGitHubリポジトリ。リンクをClaude Codeに渡すと、ローカルlocalhost上で展開し、過去の会話履歴をすべて読み込み、空白から始めるのではなく、毎日の入力・出力・キャッシュ作成・キャッシュ読取データを表示できる。 > ただし注意点：このダッシュボードはローカル端末のTokenデータを集計している。デスクトップとノートPCを切り替えると数字が一致しないことも。各端末ごとに統計が異なる。Prompt cachingは奥深いテーマ。Thariqの解説はより詳細。全体像を知りたいなら読む価値あり。ただし、すべての詳細を理解しなくても恩恵は得られる。最も重要な80/20だけ押さえれば良い： キャッシュTokenは普通Tokenの10分の1コスト；Claude CodeのTTLは1時間；モデル切り替えはキャッシュ破壊；明確な引き継ぎを行えば、古い会話を「期限切れ」にして再利用するよりもコスト効率が良い。》原文リンク
Claude Code 節約費用の秘訣：エンジニアは一週間でキャッシュを利用して3億トークンを節約、鍵は中断しないこと
Claude Code 長対話のクォータ制限？エンジニアの Nate Herk が明かす、一週間でキャッシュ機構により3億Token節約、1日の最大9100万。重要なのはどれだけコードを書いたかではなく、「キャッシュを壊さず」、繰り返しのコンテキストを無駄にしない方法。
（前提：Claude codeの高速化を狙ったbadclaudeオープンソースプロジェクトに対し、Anthropicから侵害通知が届いた話）
（補足：Claude Codeにクラウド定期ジョブ機能追加！PC不要、AIがPR審査やアップグレード自動化）
本文目次
Toggle
多くの開発者がClaude Codeでプログラムを書く際、最も頭を悩ませるのはTokenのクォータがあっという間に底をつき、長い対話はほぼ贅沢品になってしまうこと。
しかし、コミュニティでAI活用テクニックを共有するインフルエンサー Nate Herkは、Xの投稿で明かした。実際のコスト削減の決め手はコード量ではなく、prompt caching（プロンプトキャッシュ）をいかに有効活用しているかだと。彼は一週間でキャッシュを駆使し、3億Token超を節約、1日あたり9100万Tokenをキャッシュで節約した。
キャッシュTokenのコストは通常入力Tokenの10%に過ぎず、この計算だと1日900万Token分のコストで済むため、「ほぼ無料」で長時間の対話延長が可能になる。
今週、私は3億Token節約し、1日最大9100万Tokenをキャッシュで節約した。
設定変更は一切していない。これはprompt cachingが裏で正常に働いているだけ。
しかし、キャッシュの仕組みとその回避方法を理解したことで、同じクォータ内でも会話を長く続けられるようになった。そこで、Claude Codeのprompt cachingの80/20入門ガイドを整理。APIの深い詳細には触れない。
キャッシュTokenのコストは普通のTokenの10%。9100万TokenのキャッシュTokenは、実質約900万Token分の課金に相当。
Claude Codeのサブスクリプション版のキャッシュTTLは1時間。APIはデフォルトで5分、サブエージェントは常に5分。
キャッシュは3層：システム層、プロジェクト層、対話層。
会話中にモデルを切り替えるとキャッシュは破壊される。たとえば「opus plan」モードの有効化も同様。
キャッシュコストはわずか10%、9100万Tokenは900万に相当
キャッシュされたTokenはすべて、普通の入力Tokenの10%のコスト。
つまり、私のダッシュボードである日「9100万Tokenがキャッシュヒット」したと表示された場合、実際の課金は約900万Token分だけ。これが、長時間Claude Codeを使うときに会話が「無料」に近い延長感をもたらす理由だ。
ダッシュボードの注目ポイントは2つ：
Cache create：内容を書き込む際の一時コスト。次の対話で役立つ。
Cache read：Claudeがキャッシュから再利用するToken。たとえばCLAUDE.mdやツール定義、過去のメッセージなど。再入力と比べてコストは10分の1。
もしCache readの数字が高いなら、キャッシュを効果的に使っている証拠。低い場合は、同じコンテキストに何度も課金していることになる。
AnthropicのThariqは一言、「prompt cacheのヒット率を監視している。ヒット率が低いとアラートやSEV級の事故を発生させる」と。
彼は良いX記事も書いている。キャッシュヒット率が高いと、Claude Codeはより速く感じられ、Anthropicのコストも下がり、あなたのサブクォータも長持ちし、長時間のコーディング会話も現実的になる。
逆にヒット率が低いと、みんな損をする。
3層アーキテクチャ：システム、プロジェクト、対話
双方のインセンティブは一致している：Anthropicはヒット率を高めたい、あなたも高めたい。実際の妨げになるのは、ちょっとした習慣の積み重ね。
キャッシュはprefix matching（字首一致）に依存。
深く技術的に理解しなくても良いが、ポイントは：
ある位置までの内容と既存キャッシュが完全一致すれば、ClaudeはそのキャッシュTokenを再利用できる。
新規会話の流れはおおむねこう：
Claude Codeのファイルに基づき、新規会話はこう進む：
第一ラウンド：キャッシュなし。システムプロンプト、プロジェクトコンテキスト（例：CLAUDE.md、メモリ、ルール）、最初のメッセージは再処理され、キャッシュに書き込まれる。
第二ラウンド：一回目の内容はすべてキャッシュ済み。Claudeは新しい返信と次のメッセージだけ処理。コストは大幅に低減。
第三ラウンド：同じく。過去の会話はキャッシュにあり、最新のやりとりだけ再処理。
よくある「断緩」落とし穴：モデル切り替えと空白1時間
キャッシュは3層に分かれる：
ThariqのX記事より：
システム層（System layer）：基本指令、ツール定義（read、write、bash、grep、glob）、出力スタイル。全域キャッシュの対象。
プロジェクト層（Project layer）：CLAUDE.md、メモリ、ルール。プロジェクトごとにキャッシュ。
対話層（Conversation）：返信とメッセージ。会話ごとに増加。
途中でシステム層やプロジェクト層の内容が変わると、すべての内容を最初から再キャッシュし直す必要がある。これが最もコスト高な操作。たとえば、16回目の会話中にシステムプロンプトを変更したり、1時間空白があったりすると、最初の1回目からやり直し。
これが最も誤解されやすいポイント。
Claude Codeサブスクリプション：デフォルトTTLは1時間。
エンジニア自作ダッシュボード：Cache ReadとCreateを確認
Claude API：デフォルトTTLは5分。より高コストを払えば1時間に延長可能。
サブエージェントは常に5分。
Claude.aiのWebチャット：公式には明記なし。サブスクリプションと同じかもだが未確認。
数か月前、多くの人がClaudeのクォータ消費が早すぎると不満を漏らした。ある人は、AnthropicがこっそりTTLを1時間から5分に下げたと誤解したが、実際は違い、Claude CodeのTTLは依然1時間のまま。
問題は、Claude CodeとAPIの設定が別管理されていること。これにより混乱が生じている。
大量にSub-agentを使う場合やAPIを直に使う場合は5分が重要だが、95%のClaude Codeユーザーにとっては、実は1時間のウィンドウだけを気にすれば良い。
以下は、日常的に役立つポイント。
1時間以上放置した場合、以前の内容はほぼキャッシュから消えている。次のメッセージは新たにキャッシュを構築し直す。こういうときは、古い会話を無理に続けるよりも、きっぱり切り替えて新規会話を始めたほうがコストも低く済む。
/compactや/clearはキャッシュ破壊コマンドなので、むしろこのタイミングで再構築を狙う。
実戦の心法：Session Handoffは /compact よりコスト節約
自分はSession Handoffのスキルを作った。これにより、/compactの代わりに、何をしたか、未解決の決定事項、重要なファイル、次に何をすべきかを要約し、それを貼り付けて続行できる。
/clearを実行し、その要約を貼るだけ。中断なしに続けられる。
/compactは時に遅いし、Handoffは通常1分以内に完了。
Claude.aiのキャッシュ仕組みは詳細な公式説明は少ないが、Projectsは普通の対話と異なる最適化を採用している。大きなファイルを貼る場合は、対話に直接貼るよりもProjectに入れるほうが良い。
キャッシュを無意識に全破壊する操作：
モデル切り替え：キャッシュは字首一致に依存。モデルごとにキャッシュが分かれるため、モデルを変えると次回リクエストはキャッシュなしで全履歴を再読込。
「Opus plan」モード：この設定はOpusを計画段階で使い、実行段階でSonnetを使う。以前の動画で推奨した理由もあるが、理解すべきは、プラン切り替え＝モデル切り替えと同じ。これもキャッシュ破壊を招く。長期的には会話クォータ延長に役立つが、底層の仕組みを理解しておく必要がある。
会話途中でCLAUDE.mdを編集しても良いが、即時反映されず、次回再起動時に適用。現状のキャッシュには影響しない。
前述のスクリーンショットは、トークンダッシュボードの例。
Prompt cachingは奥深いテーマ。Thariqの解説はより詳細。全体像を知りたいなら読む価値あり。
ただし、すべての詳細を理解しなくても恩恵は得られる。最も重要な80/20だけ押さえれば良い：
キャッシュTokenは普通Tokenの10分の1コスト；Claude CodeのTTLは1時間；モデル切り替えはキャッシュ破壊；明確な引き継ぎを行えば、古い会話を「期限切れ」にして再利用するよりもコスト効率が良い。
》原文リンク