Amazon Bedrockのプロンプトキャッシュを有効にしても、同じ質問を送れば必ずキャッシュヒットするわけではありません。確認する値は、Converse APIの場合はレスポンスのcacheReadInputTokensとcacheWriteInputTokensです。
cacheReadInputTokensが0のときは、「キャッシュ機能が壊れている」と決めつけず、対象モデル・API、キャッシュ対象の長さ、プロンプト前半の一致、TTL、実際のレスポンスを順に確認します。
プロンプトキャッシュが向いている処理
プロンプトキャッシュは、複数のリクエストで繰り返し使う長いコンテキストの処理量を減らす機能です。例えば、長いシステム指示、ツール定義、参照文書を毎回送り、最後の質問だけが変わるチャットやエージェント処理に向いています。
最初のリクエストでは対象のプレフィックスを処理してキャッシュへ書き込みます。後続リクエストで同じプレフィックスを再利用できればキャッシュから読み取られ、入力トークンの処理コストと最初のトークンが返るまでの時間を減らせます。
最初にレスポンスの3項目を確認する
Converse APIのレスポンスでは、次の値を記録します。
| 項目 | 確認できること |
|---|---|
inputTokens |
キャッシュから読み書きされなかった入力トークン |
cacheWriteInputTokens |
今回キャッシュへ書き込まれたトークン |
cacheReadInputTokens |
既存キャッシュから読み取られたトークン |
総入力トークンは、これら3項目の合計で確認します。1回目にcacheWriteInputTokensが増え、同じキャッシュ対象を使う後続リクエストでcacheReadInputTokensが増えるかを比較します。料金や応答時間だけからヒットを推測しません。
cacheReadInputTokensが0になる確認ポイント
1. モデルとAPIが目的の方式に対応しているか
Bedrockには、サービスやモデルが自動的に再利用を試みるImplicit Prompt Cachingと、キャッシュポイントを指定するExplicit Prompt Cachingがあります。対応方式はモデルとAPIで異なります。利用中のモデルカードとAWS公式の対応表で確認します。
2. キャッシュポイントまでのトークン数が足りているか
Explicit Prompt Cachingでは、モデルごとにキャッシュポイントまでの最小トークン数があります。条件を満たさない位置にキャッシュポイントを置くと、推論が成功しても、そのプレフィックスはキャッシュされない場合があります。文字数ではなく、利用モデルのトークン条件で確認します。
3. 固定部分が同じ順序で並んでいるか
キャッシュは、プロンプトの連続した前半部分であるプレフィックスを再利用します。時刻、リクエストID、会話ごとに変わる文、並び順が変わるツール定義などを固定部分に混ぜると、後続リクエストで一致しにくくなります。
変わらないシステム指示・ツール定義・参照文書を前に置き、利用者の質問など変化する内容を後ろに置く構成にします。固定部分の末尾にキャッシュポイントを置ける方式では、その境界も確認します。
4. TTL内に後続リクエストを送っているか
キャッシュには有効期間があります。利用するモデルのTTLを過ぎた後のリクエストは、新しい書き込みになる可能性があります。検証時は、1回目と2回目の時刻を記録し、対応するTTLの範囲内で比較します。
5. 同一プロンプトでもヒットは保証されない
Bedrockの公式資料では、対応条件を満たしていてもキャッシュヒットは保証されないと説明されています。Implicit Prompt Cachingはベストエフォートです。Cross-region inferenceでは、需要が高いときにキャッシュ書き込みが増える可能性もあります。
再現試験の進め方
- 対応モデル・リージョン・API・キャッシュ方式を記録する。
- 固定する長いコンテキストと、毎回変える短い質問を分離する。
- 1回目のレスポンスで書き込みトークンを確認する。
- TTL内に固定部分を変えず、質問だけを変えて2回目を実行する。
- 読み取り・書き込み・通常入力の各トークンと応答時間を並べる。
- 読み取りが0なら、トークン最小条件と固定部分の差分を調べる。
検証ログにはプロンプト本文をそのまま残せない場合があります。その場合も、固定部分のハッシュ、モデルID、API、キャッシュ方式、キャッシュポイント、各トークン数、実行時刻を記録すると比較できます。
料金は読み取りだけで判断しない
キャッシュから読まれたトークンはモデルのキャッシュ読み取り料金で課金されます。一方、モデルによってはキャッシュへの書き込みが通常の入力より高い場合があります。短いプレフィックスを少数回しか再利用しない処理では、期待した削減にならない可能性があります。
見積もりでは、通常入力、キャッシュ書き込み、キャッシュ読み取りの量と単価を分けます。単価や対応モデルは変わるため、実装時点のAmazon Bedrock料金ページで確認してください。
まとめ
プロンプトキャッシュの効果は、「同じ質問を送ったか」ではなく、再利用対象のプレフィックスが条件を満たし、実際にキャッシュから何トークン読まれたかで判断します。
cacheReadInputTokensが0の場合は、対応モデルとAPI、最小トークン数、固定部分の一致、TTLを順に確認します。運用開始後も、読み取り量に加えて書き込み量を記録し、コストとレイテンシーの両方で効果を評価します。
