Amazon Bedrockのプロンプトキャッシュ機能、入力トークン費用を最大90%削減 初回応答の高速化も実現
要点
-
米AWSが、Amazon Bedrockにおける「プロンプトキャッシュ」機能の仕様と活用法を解説した。
-
同一コンテキストの再計算を省くことで、キャッシュヒット時に入力トークン費用を最大90%削減できる。
-
最初のトークンが出力されるまでの時間（TTFT）を短縮し、モデルの推論品質を保ったまま高速化する。
-
最小トークン数はClaude Sonnet系で1,024、Opus系で4,096に設定され、有効期限は標準5分（最大1時間）となる。
-
米Amazon Web Services（AWS）は現地時間2026年9月15日、生成AIプラットフォーム「Amazon Bedrock」におけるプロンプトキャッシュ（Prompt caching）機能の仕組みと実践シナリオを公式技術ブログで公開した。
-
基盤モデルへ繰り返し送信される長文コンテキストの処理をインフラ側で効率化し、入力トークンコストを最大90%削減するとともに、初回応答までの遅延（TTFT）を短縮する構成について解説している。
重複コンテキストの処理負担と従来の課題
生成AIを活用した対話や分析システムでは、同じシステムプロンプトや長文ドキュメント、ツールの定義情報をリクエストごとに繰り返し送信するケースが多い。ブログ記事の例では、10,000トークンの契約書データに対して50件の質問を行う場合、キャッシュのない構成では同一データの処理を含め合計500,000トークン分の入力費用が毎回全額請求される。
この問題に対し、プロンプトの短縮やコンテキストウィンドウ（モデルが一度に処理できるテキスト容量）の縮小、応答結果を保存するレスポンスキャッシュなどの回避策が用いられてきた。しかし、プロンプトの切り詰めは推論精度を落とす恐れがあり、レスポンスキャッシュは「同じ前提文書に対して異なる質問を投げる」状況には対応できないという限界があった。
プロンプトキャッシュの仕組みと処理フロー
Amazon Bedrockのプロンプトキャッシュは、プロンプト処理の中間状態をスナップショットとして保持し、前方一致する後続リクエストでの重複計算を省くインフラ機能だ。
APIリクエスト内に「cachePoint」というマーカーを配置すると、システムはマーカー以前のテキストが既存キャッシュと一致するかを評価する。合致した場合（キャッシュヒット）は再計算を行わずに保存された状態から生成を開始し、一致しない場合（キャッシュミス）は全文を処理した上で結果をキャッシュへ書き込む。
この仕組みにより、プロンプトの品質やモデルの挙動を変えることなく、キャッシュヒット時の入力トークンコストを最大90%削減できるほか、最初のトークン出力までの所要時間であるTTFT（Time-to-First-Token）の短縮が期待できるという。
キャッシュの基本仕様と動作要件
解説記事では、プロンプトキャッシュを運用する上での主要な仕様や制約条件についても整理されている。
- キャッシュの適用範囲: データはAWSアカウントおよびAWSリージョンの単位ごとに分離して管理される。
- 最小トークン数の閾値: キャッシュを有効化するには、モデルごとに定められた最小トークン数を満たす必要がある。Anthropicの「Claude Sonnet 4.5」および「Claude Sonnet 4.6」では1チェックポイントあたり最低1,024トークン、「Claude Opus」モデルでは最低4,096トークンが求められる。
- 有効期限（TTL）: キャッシュの寿命はリクエスト時に指定するTTL（Time-to-Live）に基づき、標準設定は5分間で、対応モデルでは最大1時間まで指定可能となっている。
Converse APIによる6つの実践パターン
AWSは、Bedrockの会話型インターフェース「Converse API」を用いた6つの具体的な実装パターンを紹介している。
- メッセージ内容のキャッシュ: 長大なドキュメントを保持し、同一文書に対する複数回の質問応答を低コスト化する。
- システムプロンプトのキャッシュ: 対話全体で共通するペルソナ設定や基本指示をキャッシュ化する。
- ツール定義のキャッシュ: AIエージェントが使用するツールのスキーマ情報を保持し、ワークフローの負荷を抑える。
- 混合TTLキャッシュ: コンテンツの更新頻度に応じて異なるキャッシュ保持期間を割り当てる。
- テナント分離: マルチテナント環境でテナントごとにキャッシュ領域を独立させ、安全に運用する。
- LangChain統合: LLM開発フレームワーク「LangChain」と連携してキャッシュ機能を組み込む。