先に結論
Amazon BedrockのPrompt Cachingは、同じ長い文脈を繰り返し使うワークロードに対して有効で、読み取り（cache read）時の入力トークンコストを最大90％削減できると同社は説明しています。同社によると、長文ドキュメントを多数の質問で繰り返し参照するRAGや会話型アシスタントの一部ワークロードでは、総入力コストで約75％程度の節約が見込めるケースがあります。導入判断のポイントは、（1）対象コンテンツの長さと再利用頻度、（2）TTLとキャッシュのスコープ、（3）モデルのトークン閾値の整合性、（4）誤ヒットや更新タイミングが運用負荷へ与える影響、の4点です。
GLOBAL AI BRIEF ・ COMPARISON
どのワークロードで有効か？
- 1長文を繰り返す高頻度の参照
- 2短文で頻度低効果は限定的
- 3TTLと閾値を事前に試算
一次情報：公式記事と確認日
一次情報：AWS Machine Learning Blog, Optimizing cost and latency with Amazon Bedrock prompt caching（2026年9月15日公開、2026年9月16日確認）
本稿は上記公開一次情報の記述を基に、同社によるとという帰属表現を用いて要点を整理し、日本企業が導入判断できる形で手順・比較・未検証事項を提示します。
Prompt Cachingとは何か（仕組みの要約）
Prompt Cachingは、モデルへ渡す入力の先頭（プレフィックス）を部分的に「事前処理済み」として保存し、次回以降のリクエストで再処理をスキップする仕組みです。同社によると、リクエスト内にキャッシュポイント（cachePoint）を置くことで、前方のコンテンツをキャッシュ書き込み／読み取りの対象にできます。
キャッシュはモデル実行側の中間状態に相当する情報を保存するため、同じプレフィックスを再送するたびに同社が示す「cacheReadInputTokens」が使われ、読取時は標準入力トークン請求より低い単価が適用されます。
この仕組みにより、長いシステムプロンプトや大きな参照ドキュメント、ツール定義などを一度だけ高コストで処理し、以降は低コストで再利用する運用が可能になります。
同社が公表した主な数値（そのままの帰属）
以下は一次情報からの引用的整理です（同社によると）。
・cacheReadInputTokensは標準入力より90％低い単価。
・cacheWriteInputTokensは、初回書き込みで標準入力の25％増しのコストが発生。
・1時間TTLでのキャッシュ書き込みは、書き込みコストが2倍（100％増）になる場合がある。
・モデル毎にキャッシュ発動の最小トークン閾値がある。例：Anthropic Claude Sonnet 4.5/4.6は最低1,024トークン、Opus系は4,096トークン。
・同社による概算例では、10,000トークンの文書を10回質問するケースで、初回書き込みを含めた総入力コストで約75％の削減が見込める、と示されています。
どんなワークロードで効果が出るか（適用条件）
効果が期待できる条件を整理します。ここは導入可否の第一関門です。
1) コンテンツが長く・頻繁に再利用される（例：RAGで同一文書を複数質問、システムプロンプトが大きいアプリ）
2) 同一のプレフィックスが短時間内に繰り返し使われる（TTL内にリクエストが固まる）
3) キャッシュのスコープ（アカウント／リージョン単位）と運用プロセスが、期待する再利用パターンと合致する
4) キャッシュ書き込みコスト（初回）を回収する程度の繰り返し回数が見込める
導入で注意すべき技術的・運用的制約
Prompt Cachingの導入には、次のような制約・副作用を事前評価する必要があります。
・閾値要件：モデルによってはキャッシュを有効化する最小トークン数があり、短文中心の対話では効果が出にくい点。
・TTLと一貫性：キャッシュの有効期間（TTL）が短いと頻繁に再書き込みが発生し、想定外のコスト増となる可能性があります。
・スコープの分離：キャッシュはアカウント／リージョン単位のスコープを持つため、マルチテナント設計では分離ポリシーを明確化する必要があります。
・誤ヒットのリスク：プレフィックス一致に依存するため、微妙に異なる前提（日時・ユーザー特化トークン等）が混在する場合、期待どおりの再利用にならないことがあります。
実務判断用の比較表：Cachingの方式と代表的導入条件
| 判断軸 | 導入条件・実務上の影響 |
|---|---|
| 文書長・再利用頻度 | 長文かつ短時間内で複数回参照される場面で効果が大きい。短文＋低頻度は不向き。 |
| TTL設定 | 短TTLは再書き込み増、長TTLは古い文書の参照リスク。運用で更新タイミングを管理する必要。 |
| 費用構造 | 初回書き込みでコスト上昇の説明を社内で合意。読み取り頻度で回収可能か試算する。 |
| スコープと分離 | マルチテナント環境ではテナント隔離設計を行い、誤参照を防止する。 |
PoC（概念実証）設計案：測るべき指標と手順
PoCは小さく始め、下記の指標を短期間で計測すると良いです。
必須指標：初回書き込みコスト、キャッシュ読み取り率、総入力トークンコスト、TTFTの改善、および期待外れのキャッシュミス件数。
手順の例：
1) 対象コンテンツ群を選定（例：サポートFAQの大文書10本）
2) 標準リクエストとキャッシュ有効リクエストでのコスト・レイテンシを比較
3) TTLを変えて再計測し、最適TTLを探索
4) 誤ヒットや更新タイミングの運用ルールを定める（更新時はフラグで強制再書き込み）
実装上の具体ポイント（API・運用）
同社の事例では、Converse APIの中にcachePointブロックを置くことでキャッシュ動作を制御します。システムプロンプト、ドキュメント、ツール定義のいずれにもcachePointを置けます。
また、ストリーミングvariantではメタデータイベントでキャッシュ使用量が返るため、計測と可視化が可能です。実運用ではキャッシュメトリクスを監視ダッシュボードへ送ることを推奨します。
コスト試算の考え方（簡易モデル）
一次情報の例をそのまま参考にすると、長文ドキュメントを多数質問するケースでは初回書き込みコストを残り読み取りで回収できると同社は示しています。重要なのはリクエストの分布です。読み取りが集中するほど投資回収は速くなります。
社内での試算では、（A）文書ごとの平均トークン数、（B）1時間あたりの参照回数、（C）TTLを仮定して、総コストを比較してください。
運用上のチェックリスト（導入前）
導入前に最低限確認すべき項目を挙げます。
・対象文書の平均トークン数がモデルの閾値を超えているか。
・同一プレフィックスの再利用頻度がTTL内に十分あるか。
・マルチテナントならキャッシュの分離方針を設計しているか。
・初回書き込みコストと読み取り単価差から回収期間を試算したか。
適用しない・効果が出にくいケース
以下のケースではPrompt Cachingは有効でないか、効果が限定的です。
・短文の対話が中心で、毎回異なる小さなコンテンツを使うボット。
・プレフィックスが動的に頻繁に変わるシステム（ユーザー固有トークンが多い場合）。
・読み取り頻度が低く、初回書き込みコストを回収できない想定のワークロード。
セキュリティ・ガバナンス上の留意点
キャッシュに保存されるのは中間状態であり、機密情報の取り扱い方針を定める必要があります。特にマルチリージョン／マルチアカウント環境では、どのアカウントがどのキャッシュにアクセス可能かを設計しておかないと情報分離が破られるリスクがあります。
また、キャッシュの有効期限（TTL）と更新ルールを明文化し、古い参照データを誤って提供しない運用を整備してください。
FAQ（現場でよく出る疑問と答え）
Q：短期間の改善だけで導入メリットは見込めますか？
A：同社によると、TTL内で高頻度利用がある場合にメリットが出ます。短期で利用頻度が低い用途では効果が限定的です。
Q：全てのモデルで同じ効果が出ますか？
A：いいえ。モデル毎に最低トークン閾値やTTL最大値、対応する料金表が異なります。一次情報にある閾値（例：Claudeは1,024トークン等）を必ず確認してください（同社によると）。
編集部の実務的勧め（短い判断基準）
PoCスタートは次の順序が合理的です。
1) 利用頻度と文書長で上位10件を選ぶ。
2) TTLを短・中・長で試し、総コストとTTFTを測る。
3) 誤ヒット、更新タイムラグ、スコープ問題を運用ルールで吸収できるか検討する。
ここでの中心判断は、「TTL内に十分な読み取り回数が期待できるか」です。
出典（一次情報のリンク）
一次情報：AWS Machine Learning Blog, Optimizing cost and latency with Amazon Bedrock prompt caching（2026年9月15日公開、2026年9月16日確認）
検証済みの範囲と未検証項目
検証済み：同社が公開した仕様説明と概算例、APIの使い方説明（cachePointの実装例）を確認しました（同社によると）。
未検証：実運用での長期的な総コスト効果、異なるワークロード下での誤ヒット頻度、マルチテナントでの運用負荷は第三者による検証が必要です。
まとめ（導入判断の要点）
Amazon BedrockのPrompt Cachingは、長文コンテンツを短時間に繰り返し参照するパターンで大きなコストとレイテンシの改善が期待できます（同社によると）。
ただし、効果はワークロード特性・TTL設計・モデルの閾値に強く依存するため、PoCでの定量検証が必須です。初回書き込みコストと読み取り頻度のバランスを試算・測定できる環境を用意してから本格導入してください。
出典・確認日
出典：AWS Machine Learning Blog, Optimizing cost and latency with Amazon Bedrock prompt caching（2026年9月15日公開、2026年9月16日確認）
検証範囲：同社が公開したドキュメント内の仕様・数値・コード例の確認。未検証：第三者環境での長期再現性と運用コスト。