Prompt Cachingとは何ですか？通常の会話と何が違いますか？
Claudeと会話するたびに、APIは実際にはその会話全体——システムプロンプト、ツール定義、それまでのすべての会話履歴、今回新しく打ったメッセージ——を最初から再処理して初めて回答を生成する。システムプロンプトや参照文書が長く、しかもリクエストごとにほぼ同一である場合、同じ計算に対して繰り返し料金を払っていることになる。
Prompt Cachingは、プロンプトの中で「変わらない」部分を印付けできるようにし、Anthropicはその処理済みの計算結果を保存しておく。以降のリクエストがキャッシュされた内容と完全に一致する内容で始まる限り、Claudeはすでに計算済みの結果を直接読み込むことができ、再処理する必要がなく、読み込みの価格は標準の入力価格のわずか10分の1になる。相手に50ページのマニュアルを毎回コピーして見せる必要がなく、相手がすでに見て覚えているので「前回と同じもの」と言うだけでよい、とイメージすればわかりやすい。
Prompt Cachingという仕組みはなぜ設計され、どんな問題を解決していますか？
実際の多くのClaude活用シーンには共通の特徴がある——リクエストの大部分が実は重複した内容だということだ。カスタマーサポートボットは毎回同じ製品マニュアルを携えている。コーディングアシスタントは毎回同じCLAUDE.mdプロジェクト説明を携えている。RAG（検索拡張生成）アプリケーションは毎回同じナレッジベース文書群を携えている。キャッシュメカニズムがなければ、これらの重複した内容は毎回完全に再計算しなければならず、会話が長くなるにつれて計算量もコストも積み上がっていく。
Prompt Cachingが解決するのは、まさにこの「繰り返し支払う」という問題である。同じ内容がキャッシュの有効期限内で再利用される限り、毎回標準価格で再計算する必要がない。これこそが、公式ドキュメントがこれを利用可能なAPIコスト最適化の中で最も直接的に効果的なものの一つと表現している理由である——Claudeとの会話の仕方を変える必要はなく、どの内容が安定して変わらないかを印付けするだけで、コストの低下がすぐに見えてくる。
Prompt Cachingは具体的にどう設定し、どんな数字や閾値に注意すべきですか？
Anthropic APIでは、キャッシュしたいコンテンツブロックにcache_control: {type: "ephemeral"}というマーカーを追加する。通常はシステムプロンプト、長文の文書、ツール定義の後ろに配置する。最初のリクエストでは、その部分がキャッシュに書き込まれ、書き込みの価格は標準の入力価格の1.25倍（5分間有効）または2.0倍（1時間有効、拡張キャッシュのオプション）となる。以降、有効期限内でプレフィックスが完全に一致するリクエストであれば、追加の設定なしで標準価格のおよそ10分の1でキャッシュを読み込める。キャッシュ可能なコンテンツには最低閾値があり、通常はモデルによって多少異なるが1,024トークン程度からとなる。この閾値未満のコンテンツは、印付けしてもキャッシュ効果は生まれない。
特に知っておく価値があるのは、Anthropicが2026年初頭にデフォルトのキャッシュ有効期限（TTL）を1時間から5分にひそかに変更したことだ。この変化により、もともと1時間のキャッシュを前提に設計されていた少なくないアプリケーションが、気づかないうちにコストが30〜60%上昇し、開発者が請求書を注意深く比較して初めて問題に気づいた。これこそが、Prompt Cachingを有効にした後は、「リクエストとリクエストの間にどれくらい時間が空くか」が、無視してよい細部ではなく、真剣に計算すべきコスト変数になる理由である。
Prompt Cachingを理解することが、実際のClaude利用にどう役立ちますか？
claude.aiのウェブ版やアプリでClaudeとチャットしているだけなら、Prompt Cachingの設定はすでにプラットフォームが自動的に処理しており、一般ユーザーがキャッシュブロックを手動で印付けする必要はなく、そうすることもできない。この概念は主にAPIを通じてアプリケーションを構築する文脈に関わるものだ。
開発者であれば、この仕組みを理解することで実際にかなりの費用を節約できる。自分のアプリケーションに、重複していて内容が安定している大きなプロンプトのブロック（システムプロンプト、ナレッジベース、ツール定義）がないか確認し、それらをキャッシュ可能として印付けすることは、通常投資対効果が最も高い最適化の一つであり、Anthropicの公式ドキュメントもAPIコストを最適化する際に最初に確認すべき項目の一つとして推奨している。また、明らかなコード変更なしに最近アプリケーションの請求額が突然上昇した場合、TTLが1時間から5分に変わったことを理解していれば、トラフィックが急増した、あるいはモデルが値上がりしたと誤解することなく、問題を素早く特定できる。
複数の独立した技術ブログが、Anthropicが2026年初頭にClaude CodeとAPIのデフォルトキャッシュ有効期限を、もともとの1時間からひそかに5分に変更したことを記録している。あるブログでは、著者がある朝請求ダッシュボードを開いたところ、その日一日の費用が13.86ドルに跳ね上がっており、通常をはるかに超えていたことを記している。後で追跡調査した結果、TTLの変更が原因で、以前は確実にキャッシュにヒットしていたリクエストが、間隔が5分を超えていたためにすべて失効し、フルプライスで再計算を強いられていたことが判明した。これは、キャッシュ有効期限そのものがコストに影響する重要な変数であり、一度設定すれば永久に変わらない細部ではないことを浮き彫りにしている。
The advantage is roughly a 90% reduction in input cost on a cache hit, with especially large benefits for applications that repeatedly reuse large amounts of fixed content (system prompts, knowledge bases, tool definitions), and no impact on output quality. The drawback is that the first write costs 1.25 to 2 times more (though it typically pays for itself after just one or two hits), cache hits require an exact content match — any tiny difference invalidates it — and the TTL itself can shift as Anthropic adjusts its policy, requiring ongoing attention.