Amazon Bedrockのプロンプトキャッシングは、キャッシュされたプレフィックスの読み取りをおよそ90%割引にするが、キャッシュの書き込みは通常の入力トークンより高くつく。つまり、一度もヒットしないキャッシュは請求額を改善するどころか悪化させる。この機能は2025年4月から一般提供されており、2026年1月に登場した1時間のキャッシュ持続時間により、セッション全体やバッチジョブでも実用的になった。それでもほとんどのチームはこの機能をオフのままにしているか、間違った場所で有効にして気づかぬうちにプレミアムを払い続けている。割引そのものは本物だ。それを実際に得られるかどうかは、キャッシュのブレークポイントをどこに置くかに完全にかかっている。

人がつまずきやすい思い込みは、キャッシュを「かければ効く無料の高速化装置」として扱ってしまうことだ。実際は無料ではない。すべてのキャッシュチェックポイントは、その手前のトークンがキャッシュの有効期限内に、変更されずに再送されるという賭けである。賭けに勝てば読み取り価格の10分の1で済む。負ければ、何の見返りもなく書き込みプレミアムを払っただけになる。

実際の料金の仕組み

重要なのは3種類のトークンで、それぞれ異なる価格が設定されている。

  • キャッシュ書き込み: Bedrockが初めてプレフィックスを保存するとき、そのトークンは通常の入力レートより高く課金される。Anthropicのモデルでは、短いキャッシュ持続時間の場合で書き込みは基本入力の約1.25倍、1時間の持続時間では約2倍になる。
  • キャッシュ読み取り: 保存済みのプレフィックスと一致する後続のリクエストは、およそ0.1倍で読み取られる。これが謳い文句の90%節約だ。
  • 非キャッシュ入力: 最後のキャッシュチェックポイント以降のすべてであり、毎回通常レートで課金される。

書き込みプレミアムがすべての鍵を握る。将来の読み取りを安くするために前払いしているのだ。損益分岐点は単純で、書き込みに払った追加分を取り戻すだけのヒット数がキャッシュされたプレフィックスに必要になる。1回の書き込みと1回の読み取りだけなら、通常の呼び出し2回より高くつくこともある。節約効果は、同じプレフィックスが何度も読み取られて初めて積み上がる。

ブレークポイントはどこに置くか

キャッシュチェックポイントは「この地点より前は安定しているので保存せよ」という意味を持つ。だから、呼び出しごとに変わらない部分の後、変わる部分の前に置く。典型的なアシスタントでは、その順序は次のようになる。

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

システムプロンプトとツール定義はどの呼び出しでも同一なので、キャッシュされるプレフィックスの内側に属する。新しいユーザーターンは決して繰り返されないので、外側に属する。取得されたコンテキストは中間にあり、同じドキュメントがセッション内で再利用されるならキャッシュし、毎回新しいものを取得するならキャッシュしない。この順序を誤って、ツール定義より前にチェックポイントを置くと、ほとんど何もキャッシュされないのに書き込み代金だけは払うことになる。

ミスがキャッシュなしより高くつくとき

キャッシュヒットにはプレフィックスがバイト単位で完全一致していること、かつエントリがまだ生きていることが必要だ。この賭けに負けるよくある3つのパターンがある。

  • プレフィックスを変化させてしまう。システムプロンプトの冒頭近くにタイムスタンプ、リクエストID、ユーザーごとの挨拶を注入するとバイト列が変わり、毎回新規書き込みになって読み取りは一度も発生しない。これが最もよくある自滅パターンだ。
  • トラフィックがTTLに対して疎すぎる。リクエストの間隔がキャッシュの寿命より長いと、それぞれが書き込まれて次のリクエストが来る前に失効する。1時間の持続時間はこの窓を大きく広げたが、トラフィックの少ないエンドポイントでは依然として毎回ミスすることがある。
  • プレフィックスが最小値を下回っている。Bedrockはモデルごとのトークン下限を超えたプレフィックスしかキャッシュしない。短いシステムプロンプトはそもそもキャッシュ対象にならず、チェックポイントは無視されて何も得られない。

いずれの場合も、読み取りで償却されることのない書き込みプレミアムを払うか、追加費用は発生しないが最適化したつもりで実は何も節約していないかのどちらかになる。どちらも、そのパスではキャッシュをオフにすると明確に判断するより悪い結果だ。

機能しているかを素早く知る方法

キャッシュがホットだと決めつけてはいけない。ConverseおよびInvokeModelのレスポンスは、usageフィールドにキャッシュ読み取りとキャッシュ書き込みのトークン数を報告する。それをログに記録し、比率を監視する。健全にキャッシュされたパスでは、少数で安定した書き込みと大量の読み取りが見られる。書き込みと読み取りが1対1で連動しているなら、プレフィックスが安定しておらず、誰にもヒットされないキャッシュにプレミアムを払っていることになる。プレフィックスを修正するか、チェックポイントをオフにしよう。

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

まとめ

Bedrockのプロンプトキャッシングは、切り替えるだけで無料の90%オフが得られるスイッチではない。前払いの割引であり、書き込みプレミアムを先に払い、変化しないプレフィックスの繰り返し読み取りを通じて取り戻す仕組みだ。安定したシステムプロンプトとツール定義の後にチェックポイントを置き、変化しやすいものはキャッシュ領域の外に保ち、読み取り対書き込み比率をログに残して賭けが成功しているか証明できるようにしよう。正しく行えば、Bedrockで得られる最も安価で大きな節約になる。雑に行えば、最適化に見えて実は請求額を悪化させる項目になる。

次に読むべき記事

AWS全体にわたるより広いコスト最適化のプレイブックについては、クラウド分野のフィールドノートをercan.cloudで、ハブをercanermis.comで公開している。