公開：2026年9月16日, 最終更新：2026年9月16日
30秒サマリー
- 同じコンテキストを繰り返し送る場合、入力トークンコストを最大90%削減できる
- AWSがConverse APIで使える6つの実践シナリオをブログで詳解
- キャッシュの仕組み・価格体系・コード実装例まで網羅した技術解説
何が起きたか
AWS Machine Learning Blogは、Amazon Bedrockのプロンプトキャッシュ機能の実装方法を公式ブログで詳説した。同機能は、システムプロンプトや長文ドキュメントなど繰り返し送信する静的コンテンツをキャッシュし、後続リクエストでのトークン再処理をスキップすることで、入力トークンコストをキャッシュヒット時に最大90%削減できるとしている。
ブログでは、Converse APIを使った6つの実践シナリオを順番に解説している。具体的には、長文ドキュメントのキャッシュ、システムプロンプトのキャッシュ、ツール定義のキャッシュ、コンテンツ階層ごとに異なるキャッシュ有効期限（TTL）を設定する混合TTL、マルチテナント環境でのテナント分離、LangChainとの統合の6パターンだ。
価格体系については、キャッシュへの書き込みトークン（cacheWriteInputTokens）は標準入力より25%高くなる一方、読み込みトークン（cacheReadInputTokens）は90%安くなる。1時間TTLを選ぶ場合は書き込みコストが標準の2倍となる。たとえば1万トークンのドキュメントに10の異なる質問を送る場合、最初のリクエストがキャッシュ書き込み、残り9回が読み込みとなり、入力トークンコストの正味節約率は約75%になると試算されている。
技術的な制約として、Anthropic Claude Sonnet 4.5/4.6はキャッシュポイントごとに最低1,024トークン、Opusモデルは4,096トークンが必要。デフォルトのTTLは5分で、一部モデルは最大1時間をサポートする。キャッシュスコープは個別のAWSアカウントおよびAWSリージョンに限定される。
原典ハイライト
10,000トークンのドキュメントと50の質問を組み合わせると、キャッシュなしでは50万入力トークン分がフルコストで課金されるが、プロンプトキャッシュを使えばこの反復コストを大幅に削減できる、というのがブログの核心的な主張。実装にはcachePointマーカーを静的コンテンツと動的質問の間に挿入するだけで済み、Anthropic ClaudeとAmazon Novaで同一の構文が使える点も強調されている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
生成AIのAPIコストは「同じコンテキストを何度も送る」設計になりがちなRAGやエージェント型ワークフローで急増しやすい。プロンプトキャッシュはモデルや出力品質を変えずにインフラレベルでこの問題を解決する手段であり、大量のAPI呼び出しを前提とするプロダクト運用において費用対効果を大きく改善できる可能性がある。
日本企業への示唆
RAGシステム、社内文書Q&A、コーディングアシスタントなど長い共通コンテキストを繰り返し送る用途を持つ日本企業は、Converse APIのcachePointを実装するだけで入力コストを最大75〜90%削減できる可能性がある。まず既存ワークフローのトークン使用量を計測し、静的コンテンツが1,024トークン以上あるAPIコールを特定するところから費用対効果の試算が始められる。また1時間TTLと5分TTLの使い分けは書き込みコストと節約率のトレードオフになるため、リクエスト頻度に応じた設計が必要だ。マルチテナントSaaSを開発する場合はテナント分離シナリオも参考になる。
背景・経緯
プロンプトキャッシュはAmazon Bedrockが提供している機能だが、原文はサービス新規リリースを告知するものではなく、実装パターンを体系的にまとめた技術解説ブログとして公開されたもの。取得日は2026年9月16日。対応モデルや最新の提供リージョンについては原文が公式ドキュメントを参照するよう案内しており、詳細は変動する可能性がある。
