自分は一般のclaude.aiユーザーで、プログラミングはしません。この記事は自分に関係がありますか？
実際の設定操作は直接関係がない——Prompt CachingはAPIレベルの機能であり、claude.aiのウェブ版やアプリのキャッシュロジックはプラットフォームが自動的に処理しており、一般ユーザーがキャッシュブロックを手動で印付けする必要はなく、そうすることもできない。
ただし、Claude APIに接続するサードパーティツール（カスタマーサポートシステム、社内ナレッジベースQ&Aボットなど）の評価や調達に関わる仕事をしているなら、この概念を理解しておくことで、ベンダーと料金について話し合う際に的確な質問ができる——「御社のシステムはPrompt Cachingが正しく設定されていますか」「最近キャッシュ有効期限の変化を確認しましたか」といった質問だ。こうした質問は、相手のコスト管理がしっかりしているかを判断する助けになることが多く、間接的に実際に支払うサービス料金に影響する。
自分のユースケースでは、ユーザーごとに会話がすべて異なりますが、それでもPrompt Cachingは使えますか？
使える。重要なのは「本当にユーザーごとに異なる内容」と「実は共有されている内容」を区別することだ。各ユーザーの具体的な質問が異なっていても、ほとんどのアプリケーションには依然として大きな共有ブロックがある——システムプロンプト（役割とルールの定義）、製品ナレッジベース、ツール定義は、通常すべてのユーザーに対して同一であり、キャッシュ可能だ。ユーザーの今回の入力メッセージそのものと、その会話の蓄積された履歴だけが、本当にユーザーごとに異なり、キャッシュを共有できない部分である。
実務上のやり方は、キャッシュ可能な共有部分をプロンプト構造の前段（システムプロンプト、ナレッジベース）に置き、ユーザーごとに異なる部分を後段（ユーザーメッセージ、会話履歴）に置き、共有部分のブロックにのみキャッシュマーカーを追加することだ。こうすれば、各ユーザーの質問が完全に異なっていても、その大きな共有ブロックは依然としてキャッシュにヒットし、節約額は通常かなり大きなものになる。
Prompt CachingはClaudeの回答の品質や速度に影響しますか？
品質には影響しない。キャッシュヒットで提供される内容は、再処理して得られる結果と意味的に同一であり、これは「品質を下げる」「簡略化する」仕組みではなく、単に重複した計算ステップをスキップしているだけだ。速度についてはむしろプラスに働くことが多い。すでに計算済みのキャッシュを読み込む方が、大きなコンテンツブロックを最初から処理するより理論上速いからだ。これが、一部の技術記事がキャッシュヒット率をコスト指標だけでなく、レイテンシとユーザー体験の間接的な指標としても言及する理由でもある。
本当に注意が必要なのはキャッシュミスの場合だ。内容が一致しない（キャッシュが失効した、あるいはプロンプトの一部が変わったなど）ためにキャッシュがヒットしなければ、そのリクエストは全く新しいコンテンツとして処理される。コストが標準価格、あるいは書き込みプレミアム価格になることに加え、処理時間も通常キャッシュヒット時よりやや長くなる。ただしこれは「品質の低下」ではなく、単にキャッシュによる高速化がない通常の処理速度に戻るだけである。
自分のアプリケーションがPrompt Cachingをうまく使えているか確認したい場合、実際に何をすればいいですか？
最も直接的な出発点は、APIレスポンスのcache_read_input_tokensとcache_creation_input_tokensという2つのフィールドを見ることだ。アプリケーションが継続的にcache_creation_input_tokens（絶えず書き込みが発生）ばかりでcache_read_input_tokens（ヒットがほとんどない）がほとんど見られない場合、キャッシュ設定に問題がある可能性を示している。よくある原因は、内容に毎回変わるもの（タイムスタンプなど）が混入していることや、リクエストの間隔が現在のTTLを頻繁に超えてキャッシュが失効し続けていることだ。
問題を見つけたら、まずシステムプロンプトとツール定義に不要な動的コンテンツがないか確認し、それらをキャッシュブロックの外に移す。次にリクエストの間隔パターンを評価し、現在使っている5分TTLが適しているか、それとも1時間の拡張キャッシュに切り替える必要があるかを判断する。この一連の確認を終えると、通常cache_read_input_tokensの割合が明らかに上昇するのが見え、これがキャッシュ設定が正しいかどうかを最も直接的に反映するシグナルとなる。
Claude APIで製品を構築していて、システムプロンプトや参照文書が決して短くないなら、Prompt Cachingはおそらく投資対効果が最も高い最適化だ——設定コストはほぼゼロだが、節約額は実質的なものになる。ただし、この仕組みには2026年に起きたある変更があり、少なくないエンジニアが無防備な状態で予想外の請求を受けることになった。特に取り上げる価値がある。
Claude APIを呼び出すたびに、システムは実際にその会話全体——システムプロンプト、ツール定義、それまでのすべての会話履歴、今回新しく打ったメッセージ——を最初から再処理して初めて回答を生成する。システムプロンプトやナレッジベース文書が長く、しかもリクエストごとにほぼ同一であれば、同じ計算に対して実質的に繰り返し料金を払っていることになる。
Prompt Cachingは、プロンプトの中で変わらない部分を印付けできるようにし、Anthropicはその処理済みの計算結果を保存しておく。以降のリクエストのプレフィックスがキャッシュされた内容と完全に一致する限り、Claudeはすでに計算済みの結果を直接読み込むことができ、価格は標準の入力価格のおよそ10分の1になる。実際の数字は直感的だ。8,000トークンのシステムプロンプトと文書セットを携えたカスタマーサポートボットは、Sonnetの標準入力料金で、繰り返される固定コンテンツだけで100万メッセージあたり24ドルかかる。キャッシュを有効にすると、この部分のコストは100万メッセージあたり0.3ドルまで下がる。
設定は簡単だ。キャッシュしたいコンテンツブロック（通常はシステムプロンプト、長文の文書、ツール定義）に`cache_control: {type: "ephemeral"}`というマーカーを追加する。最初のリクエストでは、その部分がキャッシュに書き込まれ、書き込みの価格は標準入力価格の1.25倍（5分間有効）または2.0倍（1時間有効、拡張キャッシュのオプション）となる。以降、有効期限内でプレフィックスが一致するリクエストであれば、標準価格の10分の1で読み込める。元を取るのは非常に速い——5分TTLなら、1回のヒットですでに書き込みプレミアムを回収でき、それ以降のヒットはすべて純粋な節約になる。
特筆すべきは、キャッシュ可能なコンテンツには最低閾値があり、通常はモデルによって多少異なるが1,024トークン程度からとなる点だ。この閾値未満のコンテンツは、印付けしてもキャッシュ効果は生まれず、印付けの手間が無駄になる。
これが本記事が特に指摘したい重要な点だ。Anthropicは2026年初頭、デフォルトのキャッシュ有効期限（TTL）を、もともとの1時間からひそかに5分に変更した。複数の独立した技術ブログがこの変化がもたらした実際の影響を記録している——あるエンジニアは、ある朝請求ダッシュボードを開いたところ、その日一日の費用が13.86ドルに跳ね上がっており、通常をはるかに超えていたことを記している。後で追跡調査した結果、もともと1時間の枠内で間隔が設計され、確実にキャッシュにヒットしていたリクエストが、新しい5分TTLのために大量に失効し、フルプライス（あるいは書き込みプレミアム価格）で再計算を強いられていたことが判明した。
もともと1時間のキャッシュを前提に設計されていたアプリケーションにとって、この変化は実質的なコストを何の前触れもなく30〜60%押し上げた。ここで最も重要な教訓は、「TTLが短くなった」という単一の事実そのものではなく、キャッシュの有効期限自体がAnthropicのポリシー調整とともに変動しうるパラメータであり、一度設定すれば永久に適用される定数ではないということだ。過去に検証したコスト見積もりは、時点を変えて再確認する価値がある。
シンプルな判断原則はこうだ。アプリケーションのリクエスト頻度が高く、リクエスト間の間隔が通常5分よりはるかに短い場合（リアルタイムのカスタマーサポート対話など）、標準の5分TTLで十分だ。キャッシュがほとんど失効する機会がないからだ。ユースケースがリクエスト間隔がより分散しているが、それでも1時間以内に少なくとも5〜7回はヒットするほど頻繁な場合（複数のユーザーが同じシステムプロンプトを共有しているが、個々のユーザーのリクエスト間隔が一定でない場合など）、1時間の拡張キャッシュは書き込みコストが高くても長期的には割に合う。
シンプルな判断基準はこうだ。「実質的な内容があり、頻繁には変わらない」ものはほぼすべてキャッシュに適している——システムプロンプト、長文のナレッジベース文書、ツール定義が典型例だ。逆に「メタデータのように毎回変わる」ものは適していない。最もよくある落とし穴は、エンジニアがシステムプロンプトに現在のタイムスタンプを習慣的に埋め込むことだ。これによりリクエストごとにプレフィックスの内容が異なることになり、キャッシュは永遠にヒットせず、この最適化の効果が完全に失われる上、書き込みの追加費用まで払うことになる。
チームが毎月Claude APIにかなりの予算を費やしているなら、Prompt Cachingがすでに有効になっているか、そして現在のTTL設定が実際の利用パターンに合っているかを確認することは、通常プロンプトのロジックを一切書き直すことなく、最も早くコスト低下を実感できるステップだ。もしアプリケーションの請求額が最近明らかなコード変更もなく上昇しているなら、まずキャッシュヒット率を確認する（APIが返す`cache_read_input_tokens`と`cache_creation_input_tokens`という2つのフィールドで観察できる）ことが、コードを一行一行チェックするより根本原因を早く見つけられることが多い——これはまさに本記事の冒頭で触れた、少なくないエンジニアが不意を突かれたあの落とし穴である。