コスト90%削減!Claude AIのPrompt caching(プロンプト キャッシュ)機能を徹底解説
AI開発系の記事生成AI (Generative AI)系の記事

コスト90%削減!Claude AIのPrompt caching(プロンプト キャッシュ)機能を徹底解説

Anthropicの Prompt caching は、長い共通コンテキストを毎回フル課金で送り直さずに済ませるための重要機能です。旧リリース時は「最大90%のコスト削減」で注目されましたが、2026年6月時点ではより正確に、5分TTL・1時間TTL・キャッシュヒット単価を前提に見積もるべき機能になっています。

この記事では、Claude 3.5/3.7時代の説明をそのまま信じず、現行ドキュメントでPrompt cachingをどう理解するかを整理します。API実装の基本、どのモデルで使えるか、どの案件で効くか、そして見積もりの考え方までまとめます。

Prompt caching(プロンプト キャッシュ)とは:Claude AIの新機能の概要

Prompt cachingは、同じプレフィックスを何度も送るAPIワークロード向けの仕組みです。公式ドキュメントでは、tools、system、messagesを含むプロンプトの先頭部分をキャッシュし、次回以降はその再利用によって処理時間と費用を下げると説明されています。特に、多数の例示、長い背景知識、繰り返しの多いタスク、長いマルチターン会話で効果を発揮します。

現在の標準TTLは5分で、キャッシュされた内容が再利用されるたびに追加料金なしで更新されます。5分では短い場合は、cache_controlに ttl: "1h" を指定して1時間キャッシュを使えます。これにより、数十分おきに再開されるエージェント処理や、返答待ちを挟む長い商談支援フローでも、共通文脈を安く維持しやすくなります。

また、実装方法も進化しています。いまはトップレベルに cache_control を1つ置く自動キャッシュが最も簡単で、会話が伸びるたびに最後のキャッシュ可能ブロックまで自動でキャッシュ境界が前進します。厳密にどこまでをキャッシュしたいか制御したい場合は、ブロック単位の明示的ブレークポイントも使えます。

block-level caching を使う場面は、キャッシュしたい範囲がはっきり決まっているときです。たとえば system prompt と長い社内ルール集だけを固定でキャッシュし、毎回変わる添付要約やユーザー質問はキャッシュ対象から外したい場合、各コンテンツブロックに cache_control を付けて境界を明示できます。自動キャッシュは会話型ワークロードに向き、block-level caching はテンプレート化された処理パイプラインで有効、と覚えておくと設計しやすくなります。

Prompt caching(プロンプト キャッシュ)がもたらす具体的なメリット

最大のメリットは、長い共通コンテキストを使うほど費用対効果が見えやすくなることです。プロダクト仕様書、社内ルール、FAQ、長い会話履歴を毎回フル入力する代わりに、一度キャッシュ書き込みを行い、その後はキャッシュヒット単価で再利用できます。

現行の価格表では、Claude Sonnet 4.6の基準入力単価は3ドル/MTok、5分キャッシュ書き込みは3.75ドル/MTok、1時間キャッシュ書き込みは6ドル/MTok、キャッシュヒットは0.30ドル/MTokです。つまり、最初の書き込み時は少し上乗せがあるものの、繰り返し利用で差が一気に開きます。キャッシュヒット単価は基準入力の10%なので、同一プレフィックスを何度も読む構成では非常に効率的です。

  • 長いsystem promptを使う社内アシスタント
  • 多数のfew-shot例を毎回添える抽出・分類パイプライン
  • 検索・ツール実行をまたぐ長いエージェントループ
  • ユーザーごとの会話履歴を保ちながら再入室を許すチャット体験

さらに現在は、Batch API割引やデータレジデンシーなど他の価格修飾と組み合わせて考える余地もあります。公式ドキュメントでは、prompt cachingの倍率は他の価格修飾と積み上がると説明されています。単純な「最大90%削減」という宣伝文句より、実際の利用頻度・TTL・モデル単価で試算した方が失敗しません。

Prompt caching(プロンプト キャッシュ)の実装方法とベストプラクティス

最初の実装は自動キャッシュから始めるのが安全です。トップレベルに {"cache_control": {"type": "ephemeral"}} を置くだけで、システムは最後のキャッシュ可能ブロックまでを自動で管理します。マルチターン会話では、この境界が会話の成長に合わせて動くため、都度マーカーを更新する必要がありません。

1時間TTLは、5分以内にほぼ確実に再利用されるケースでは不要です。公式ガイドでも、5分を超えても1時間以内には再利用されるプロンプト、あるいはフォローアップが5分を超えて飛んでくる可能性があるがレイテンシを抑えたいケースに向くと説明されています。反対に、数十秒ごとに連続再利用するだけなら5分TTLで足ります。

実装時の注意点として、キャッシュはプレフィックス一致が前提なので、再利用したい部分を前方に固定し、変動しやすいユーザー入力を後ろに寄せる設計が重要です。システムプロンプトや共通知識、長い例示を先に置き、毎回変わる質問や添付要約は末尾に置く構成にするとヒット率が上がります。

また、異なるTTLを混在させる場合は長いTTLを先に置くという制約があります。1時間TTLのキャッシュブロックは5分TTLより前に配置しなければならず、設計を雑にすると期待どおりに課金が最適化されません。複雑化する前に、自動キャッシュ一本で十分かを先に検証するのが実務的です。

最後に、旧モデル前提の実装例を流用しないことも大切です。Prompt caching自体は全アクティブモデルで使えますが、実運用の主軸モデルはすでにSonnet 4.6やOpus 4.8へ移っています。モデル単価もトークナイザも更新されているため、過去の削減率ではなく現在の価格表で見直してください。

まとめとして、Prompt cachingは「長い共通文脈を何回使い回すか」が明確な案件ほど威力を発揮します。まずはSonnet 4.6で自動キャッシュを有効にし、5分TTLでヒット率を確認し、それでも再利用間隔が長いなら1時間TTLへ広げる順序がおすすめです。

Claude APIのコスト最適化や、Prompt cachingを前提にしたエージェント設計を進めたい場合は、 numomentにご相談ください 。ユースケースごとに、モデル選定・TTL・プロンプト構造まで含めて設計を支援します。

コスト試算をする際は、キャッシュ書き込み回数とヒット回数を分けて考えるのが重要です。初回の5分書き込みは通常入力より高く見えますが、その後に同じプレフィックスを何度も読むならヒット単価との差分で十分に回収できます。逆に、一度しか使わない長文を何でもキャッシュしても効果は薄く、ヒット前提の設計こそが重要になります。

典型的な設計パターンは、system prompt、固定ルール、長い例示、共通知識ベースを前半にまとめ、毎回変わるユーザー入力や検索結果を後半に置くことです。この順番にするだけでプレフィックスの再利用率が上がり、キャッシュ恩恵が出やすくなります。Prompt cachingは単なるAPIオプションではなく、プロンプト構造の設計ルールだと考えると使いどころを判断しやすくなります。

また、エージェント系ワークロードではツール利用後の追加入力が増えやすいため、キャッシュ前提でない設計だと入力費用が想像以上に膨らみます。長い共通文脈を維持しながら何度も検索・コード実行・要約を繰り返すなら、最初に自動キャッシュを入れておく方が安全です。

開発現場では、Prompt caching の有無でレイテンシ体感も大きく変わります。長い system prompt や多数の例示を毎ターン送り直す構成では、モデルが毎回同じ前提を読み込むため待ち時間が伸びがちです。キャッシュヒットが続く構成に変えるだけで、ユーザー体験だけでなく、バッチ処理全体の所要時間も読みやすくなります。

実装を始めるときは、まず usage フィールドの cache_read_input_tokens と cache_creation_input_tokens を観測し、どこでキャッシュが効いているかを把握すると改善が進めやすいです。ヒット率が低い場合は、キャッシュしたい前半部分に毎回小さな差分が紛れ込んでいないかを確認します。ほんの少し順序を変えるだけで、ヒット率が大きく改善するケースもあります。

また、block-level caching を使う場合でも、最初から複雑にしすぎない方が安全です。共通テンプレートが厳密に決まったバッチ処理や抽出パイプラインでは効果的ですが、会話が伸び縮みする対話型アプリでは自動キャッシュの方が保守しやすいことが多いです。設計自由度より運用安定性を優先するなら、まずは自動キャッシュで十分かを確認してください。

最後に、Prompt caching を導入したら終わりではなく、モデル変更時に再試算することも忘れないでください。Anthropicは価格表、モデル世代、トークナイザ、thinking仕様を継続的に更新しています。キャッシュ戦略はモデル単価と一体で見直すものなので、四半期ごとにでも設定とコストを棚卸しすると無駄が出にくくなります。

要するに、Prompt caching は高額モデルだけの話ではなく、Sonnetクラスを反復利用する現場ほど効きやすい最適化です。

実測で確認しながら設計する姿勢が、最終的には一番大きな節約につながります。

関連記事

→ 企業のClaude導入完全ガイド

→ Claude Codeで生産性を3倍にする方法

Claudeの業務活用・社内研修について、 numomentにご相談ください 。企業規模に合わせたClaude研修プログラムを提供しています。