Amazon Bedrockのプロンプトキャッシュとは｜仕組み・対応モデル・料金・実装方法【2026年最新】

Amazon Bedrockのプロンプトキャッシュ（Prompt Caching）は、毎回同じ長い前置き（システムプロンプトや参照ドキュメント、ツール定義）を再計算せずに使い回す機能です。狙いは2つ、入力トークン課金の削減と応答レイテンシの短縮で、AWSは条件次第でコスト最大90%・レイテンシ最大85%の削減を示しています。ただし効果が出るのは「静的な長い前置きを何度も送る」ワークロードに限られ、置き方を誤ると一切キャッシュされず書き込み料金だけ乗ることもあります。この記事では、キャッシュチェックポイントの仕組みから対応モデル・料金・Converse／InvokeModel APIでの実装、ヒット率を上げる設計と失敗パターンまでを、2026年時点の公式情報で整理します。

まとめ：この記事の結論（先に要点）

• 正体：プロンプトの静的な先頭部分（プレフィックス）に「キャッシュチェックポイント」という印を置き、次回以降はその再計算を省く仕組み。裏でモデルの推論を丸ごと省くわけではなく、共通プレフィックスの処理コストを下げる。
• 効くワークロード：長い共通コンテキストを繰り返し送る用途（チャットボット、ドキュメントQ&A、RAG、エージェント）。1回きりの短いプロンプトでは効果がなく、むしろ書き込み分だけ割高になる。
• 料金：キャッシュ読み取りは通常入力より大幅に安く（Claudeで約90%割引）、キャッシュ書き込みは通常入力より高い（Claudeで約1.25倍）。だから「1回書いて何度も読む」形にできて初めて黒字化する。
• 最低トークン：モデルごとに最小トークン数がある。Claude Opus 4.5／Sonnet 4.5／Haiku 4.5は4,096トークン、Claude 3.7 SonnetやNovaは1,024トークン。満たさないと推論は成功するがキャッシュされない。
• 実装：Converse APIならcachePoint、InvokeModel（Claude）ならcache_controlを静的コンテンツの直後に置くだけ。オンデマンド推論専用で、バッチ推論では使えない。

プロンプトキャッシュの仕組み｜キャッシュチェックポイントとTTL

プロンプトキャッシュの中心概念は「キャッシュチェックポイント（cache checkpoint）」です。これはプロンプトの中で「ここまでの連続した先頭部分をキャッシュする」と宣言するマーカーで、対象になる先頭部分をプロンプトプレフィックスと呼びます。

プレフィックスは静的でなければ当たらない

キャッシュが再利用されるのは、チェックポイントより前のプレフィックスがリクエスト間で完全に一致したときだけです。1文字でも変えればプレフィックスのハッシュが変わり、キャッシュミスになって書き込みからやり直しになります。そのため「変わらない内容（指示・参照文書・ツール定義）を前に、毎回変わる内容（ユーザーの入力）を後ろに」置くのが鉄則です。この順序を守れないと、キャッシュは構造的に効きません。

キャッシュヒットとTTL（5分・1時間）

キャッシュには有効期限（TTL）があります。多くのモデルの既定は5分で、TTLはキャッシュヒットのたびにリセットされます。つまり5分以内に同じプレフィックスへのリクエストが続く限りキャッシュは生き続け、途切れると失効します。2026年1月からはClaude Opus 4.5・Sonnet 4.5・Haiku 4.5で1時間TTLが選べるようになり、数分おきには呼ばれないが1時間以内には再利用される用途（長時間のエージェント実行、ユーザーの返信待ちが長い会話）で書き込み回数を減らせます。

最小トークン数と最大チェックポイント数

チェックポイントを作るには、プレフィックスの累積トークンがモデルごとの最小値に達している必要があります。最小に満たない位置に置いても推論自体は成功しますが、その部分はキャッシュされません（料金削減もされない）。チェックポイントは1リクエストあたり最大4個まで置け、変化頻度の異なるブロック（ほぼ不変の指示と、たまに変わる参照文書）を分けてキャッシュしたいときに使い分けます。

プロンプトキャッシュの料金とコスト削減効果

プロンプトキャッシュは「安くなる魔法」ではなく、読み取りが安い代わりに書き込みが高いトレードオフです。損益分岐を理解しないと逆に高くつきます。キャッシュを含めた費用の抑え方をどの順に実行するかは、AWS Bedrockの料金はいくら？課金方式4種と月額試算・費用を下げる順番で扱っています。

読み取りは割安、書き込みは割高

Claudeモデルの場合、キャッシュ読み取りトークンは通常の入力トークンより大幅に安く（おおむね約90%割引＝通常入力の1割程度）、キャッシュ書き込みトークンは通常入力より高い（おおむね約1.25倍）のが基本体系です。したがって、1回の書き込み（割高）を何回の読み取り（割安）で回収できるかが採算を決めます。共通プレフィックスを2〜3回以上再利用できる見込みがあれば黒字化しやすく、1回で終わる呼び出しではキャッシュを使わない方が安いこともあります。単価はモデル・リージョンで異なるため、実際の数値はAmazon Bedrock公式の料金ページで必ず確認してください。

inputTokensの数え方に注意

キャッシュを有効にすると、レスポンスのinputTokensはキャッシュに読み書きされなかった分だけを表すようになります。実際に送った総入力トークンは次の式で求めます。

総入力トークン = inputTokens + cacheReadInputTokens + cacheWriteInputTokens

コスト計算やログ集計でこの内訳を混同すると、削減効果を過大・過少に見積もります。書き込み（初回）と読み取り（2回目以降）を分けて集計し、cacheReadInputTokensが期待どおり伸びているかで効果を判定します。トークン単価だけでなく、まとめて課金対象を下げたい場合はAmazon Bedrockのプロンプト最適化機能と併用し、プロンプト自体を短くする手も有効です。

対応モデルとリージョン｜2026年最新の対応表

プロンプトキャッシュは、対応モデルが提供されている全AWSリージョンで使えます（リージョン別の可否は各モデルの提供状況に従います）。対応モデルと制限値は次のとおりです（2026年時点、公式の対応表より抜粋）。

※Amazon Novaはtoolsのキャッシュに非対応（system・messagesのみ）。GPT-5.6はConverse／InvokeModelではなくResponses API（bedrock-mantleエンドポイント）でprompt_cache_breakpointを使います。

ClaudeとNovaで挙動が違う

Claudeは明示的なチェックポイント（cachePoint／cache_control）を置く方式で、system・messages・toolsの各フィールドに置けます。一方Amazon Novaはテキストプロンプトを自動でキャッシュし、繰り返しの先頭部分があればレイテンシ面の恩恵を受けられますが、確実なコスト削減を得るには明示的キャッシュ（Explicit Prompt Caching）へのオプトインが推奨されます。最小トークンが4,096のモデル（Opus 4.5・Sonnet 4.5・Haiku 4.5）では、短い指示だけではチェックポイントが成立しない点に注意してください。

使える推論方式・使えない方式

プロンプトキャッシュはConverse／ConverseStream、InvokeModel／InvokeModelWithResponseStream、クロスリージョン推論、Bedrockのプロンプト管理で利用できます。オンデマンド推論エンドポイント専用で、バッチ推論APIでは使えません。クロスリージョン推論と併用すると、需要が高い時間帯には最適化のためキャッシュ書き込みが増えることがあります。

実装方法｜Converse APIとInvokeModel APIでの書き方

実装はチェックポイントを1つ置くだけで、コードの大部分は通常の推論呼び出しと変わりません。ここではAWS公式のサンプルに沿ってboto3での書き方を示します。

Converse APIで cachePoint を置く

Converse APIでは、system・messages・toolsのいずれかにcachePointを差し込みます。静的な指示（system）の直後に置くのが基本形です。

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="anthropic.claude-sonnet-4-5-20250929-v1:0",
    system=[
        {"text": "長い共通の指示や参照ドキュメントをここに置く（静的な内容）"},
        {"cachePoint": {"type": "default"}}
    ],
    messages=[
        {"role": "user", "content": [{"text": "1件目の質問"}]}
    ],
)

usage = response["usage"]
print(usage["inputTokens"])            # キャッシュ対象外の入力だけ
print(usage["cacheWriteInputTokens"])  # 初回: キャッシュに書き込んだ量
print(usage["cacheReadInputTokens"])   # 2回目以降: キャッシュから読んだ量

2回目以降、同じsystemを送ればcacheReadInputTokensが増え、cacheWriteInputTokensはゼロになります。1時間TTLを使うならcachePointに"ttl": "1h"を加えます。チェックポイントはtools → system → messagesの順に処理され、最小トークンは3セクションの累積で判定される点、前のセクションを変えると後ろのキャッシュも無効になる点を押さえておきます。ツール利用と組み合わせる実装はAmazon Bedrock Converse APIとTool Useの実装ガイドが参考になります。

InvokeModel API（Claude）で cache_control を使う

InvokeModelではキャッシュはデフォルトで有効で、リクエストボディ内にcache_controlを置きます。Claudeでは先頭からそのcache_controlを付けたブロックまでがキャッシュ対象になるため、静的な参照コンテキストを先頭に置いてそこにcache_controlを付け、毎回変わる質問文はその後ろに置きます（順序を逆にすると変数がプレフィックスに入りキャッシュミスになります）。

body = {
    "anthropic_version": "bedrock-2023-05-31",
    "system": "簡潔に回答してください",
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "最小トークン数を満たす長い参照コンテキスト（静的・毎回同じ）",
                    "cache_control": {"type": "ephemeral", "ttl": "1h"}
                },
                {"type": "text", "text": "毎回変わる質問文をここに書く（キャッシュ対象外）"}
            ]
        }
    ],
    "max_tokens": 2048
}

ttlを省くと既定の5分になります。Converseの{"type": "default"}に対し、InvokeModelのClaudeでは{"type": "ephemeral"}と表記が異なる点に注意してください。

キャッシュが効いているかの確認

効果検証はレスポンスの3フィールドで行います。初回はcacheWriteInputTokensが立ち、2回目以降はcacheReadInputTokensが立ってcacheWriteInputTokensが0になれば、完全なキャッシュヒットです。cacheReadInputTokensが常に0のままなら、プレフィックスが一致していない・最小トークンに届いていない・TTLが切れている、のいずれかを疑います。

キャッシュヒット率を高める設計と、効かない失敗パターン

プロンプトキャッシュは「置けば効く」ものではありません。順位や体感速度に効くのは、ヒット率を高く保つプロンプト設計です。ここは公式サンプルに載りにくい実務の勘所なので、条件付きで言い切ります。

静的→可変の順と、チェックポイントの位置

最も効くのは、ツール定義・システム指示・参照ドキュメントを前半に固め、ユーザー固有の入力を末尾に置く構成です。Claudeには「簡易キャッシュ管理」があり、静的コンテンツの末尾にチェックポイントを1つ置けば、システムが直近およそ20ブロックまで遡って最長一致するプレフィックスを自動で探します。まずはこの単一チェックポイント方式から始め、変化頻度の違うブロックを個別制御したくなったら複数チェックポイント（最大4）に分けるのが実務的な順序です。

1時間TTLと5分TTLの使い分け

5分以内の間隔で繰り返し呼ばれる用途（頻繁に使うシステムプロンプト）は5分TTLのままで十分で、ヒットのたびに無償で延長されます。1時間TTLが向くのは、呼び出し間隔が5分〜1時間程度に空くケース（長時間動くエージェントの補助処理、返信が遅いユーザーとの会話）です。1時間と5分を1リクエストに混在させることもできますが、その場合はTTLの長いエントリを先に、短いエントリを後に並べる制約があります。なお1時間TTLでもキャッシュ読み取りはレート制限（1分あたり入力トークン数）に算入されないため、スループット改善にも寄与します。長時間動くエージェント用途はAmazon Bedrock AgentCoreと組み合わせると効果を測りやすくなります。

キャッシュが効かない典型パターン

次のいずれかに当てはまると、料金は減らず（むしろ書き込み分だけ増え）ます。実装後にcacheReadInputTokensが伸びないときは、まずここを疑ってください。

• プレフィックスに動的値が混入：システムプロンプトの先頭に現在時刻・ユーザー名・ランダムIDを埋め込むと毎回ミス。動的値は必ずチェックポイントより後ろへ。
• 最小トークン未満：Opus 4.5・Sonnet 4.5・Haiku 4.5は4,096トークン必要。短い指示だけではチェックポイントが成立しない。
• 再利用が1回で終わる：単発の呼び出しは書き込み（割高）だけ発生して回収できない。2回以上再利用する見込みがある箇所に絞る。
• バッチ推論で使おうとする：オンデマンド専用。バッチ推論APIでは無効。
• tools/systemを毎回変更：処理順が tools → system → messages のため、前段を変えると後段のキャッシュまで無効化される。

よくある質問（FAQ）

プロンプトキャッシュとAmazon ElastiCacheのようなキャッシュは何が違いますか？

別物です。ElastiCache等はアプリ側でレスポンスやデータを保存する汎用キャッシュで、プロンプトキャッシュはBedrock内部で「プロンプトの先頭部分の計算結果」を再利用する機能です。同じ質問に同じ回答を返す用途ならアプリ側のレスポンスキャッシュ、同じ長い前置きに異なる質問を投げる用途ならプロンプトキャッシュが適します。

プロンプトキャッシュを有効にすると回答内容は変わりますか？

回答の品質・内容は変わりません。キャッシュされるのは入力プレフィックスの処理結果で、モデルの出力生成そのものは通常どおり行われます。変わるのは課金対象トークンの内訳（inputTokens／cacheReadInputTokens／cacheWriteInputTokens）と応答速度です。

bedrock cacheの最小トークン数はどれくらいですか？

モデル依存です。Claude Opus 4.5・Sonnet 4.5・Haiku 4.5は1チェックポイントあたり4,096トークン、Claude 3.7 Sonnet・Claude Sonnet 4.6・Amazon Novaは1,024トークンが目安です。累積プレフィックスがこの値に達しない位置のチェックポイントは無視されます。

キャッシュの利用状況はどこで確認できますか？

APIレスポンスのusageに含まれるcacheReadInputTokens・cacheWriteInputTokensで確認します。Bedrockコンソールのプレイグラウンドでもプロンプトキャッシュをオンにすると、読み書きしたトークン数がキャッシュメトリクスとして表示されます。

プロンプトキャッシュはどのモデルでも使えますか？

いいえ。2026年時点でClaude系（Opus/Sonnet/Haikuの4.x世代・3.7 Sonnet等）、Amazon Nova系、GPT-5.6系などが対応します。対応可否と制限値はモデルごとに異なるため、利用前に公式の対応表で確認してください。

関連記事

• Amazon Bedrock超入門：初心者向けの完全ガイド
• Amazon Bedrock Converse APIとTool Useを利用したチャットアプリの実装ガイド
• Amazon Bedrockのプロンプト最適化機能の詳細と利用方法
• Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ
• Knowledge Baseを使った社内RAGチャットシステムの実用例