翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
モデル推論を高速化するためのプロンプトキャッシュ
プロンプトキャッシュは、Amazon Bedrock でサポートされているモデルで使用できるオプション機能であり、推論レスポンスのレイテンシーと入力トークンのコストを削減できます。コンテキストの一部をキャッシュに追加することで、モデルはキャッシュを使用して入力の再計算をスキップできるため、Bedrock はコンピューティングの節約を共有し、レスポンスのレイテンシーを短縮できます。
プロンプトキャッシュは、長さと繰り返しがあり複数のクエリで頻繁に再利用されるコンテキストのワークロードがある場合に役立ちます。例えば、ユーザーがドキュメントをアップロードして質問できるチャットボットがある場合、ユーザーが入力するたびにモデルがドキュメントを処理すると時間がかかる可能性があります。プロンプトキャッシュを使用すると、ドキュメントをキャッシュでき、そのドキュメントを含む将来のクエリを再処理する必要がなくなります。
プロンプトキャッシュを使用する場合、キャッシュから読み取られたトークンに対して割引料金で課金されます。モデルによっては、キャッシュに書き込まれたトークンは、キャッシュされていない入力トークンよりも高い料金で課金される場合があります。キャッシュとの間で読み書きされないトークンは、そのモデルの標準入力トークン料金で課金されます。詳細については、「Amazon Bedrock の料金ページ
仕組み
プロンプトキャッシュを使用する場合、Amazon Bedrock はキャッシュチェックポイントで構成されるキャッシュを作成します。これらは、キャッシュするプロンプトの連続するサブセクションを定義するマーカーです (多くの場合、プロンプトプレフィックスと呼ばれます)。これらのプロンプトプレフィックスはリクエスト間で静的である必要があり、後続のリクエストでプロンプトプレフィックスを変更すると、キャッシュミスが発生します。
キャッシュチェックポイントには、使用している特定のモデルに応じて、トークンの最小数と最大数があります。キャッシュチェックポイントは、合計プロンプトプレフィックスがトークンの最小数を満たしている場合にのみ作成できます。たとえば、 Claude 3.7 Sonnetではキャッシュチェックポイントごとに少なくとも 1,024 トークンが必要で、Claude Opus 4.5、Claude Haiku 4.5、、 ではキャッシュチェックポイントごとに少なくとも Claude Opus 4.64,096 トークンClaude Sonnet 4.5が必要です。つまり、1,024 トークン以上のモデルの場合、最初のキャッシュチェックポイントは 1,024 トークンの後に定義でき、2 番目のキャッシュチェックポイントは 2,048 トークンの後に定義できます。トークンの最小数を満たす前にキャッシュチェックポイントを追加しようとすると、推論は成功しますが、プレフィックスはキャッシュされません。キャッシュには有効期限 (TTL) があり、キャッシュヒットが成功するたびにリセットされます。この期間中、キャッシュ内のコンテキストは保持されます。TTL ウィンドウ内でキャッシュヒットが発生しない場合、キャッシュは期限切れになります。多くのモデルは 5 分の TTL をサポートしています。モデルのモデルカードをチェックして、正確な TTL 条件を確認します。
プロンプトキャッシュは、サポートされているモデルの Amazon Bedrock でモデル推論を取得するたびに使用できます。プロンプトキャッシュは、次の Amazon Bedrock 機能でサポートされています。
- Converse API と ConverseStream API
-
プロンプトでキャッシュチェックポイントを指定して、モデルと会話を続けることができます。
- InvokeModel API と InvokeModelWithResponseStream API
-
プロンプトキャッシュを有効にしてキャッシュチェックポイントを指定する、単一のプロンプトリクエストを送信できます。
- クロスリージョン推論を使用したプロンプトキャッシュ
-
プロンプトキャッシュは、クロスリージョン推論と組み合わせて使用できます。クロスリージョン推論は、推論リクエストを処理するために地域内の最適な AWS リージョンを自動的に選択し、利用可能なリソースとモデルの可用性を最大化します。需要が高い場合、この最適化によりキャッシュ書き込みが増加する可能性があります。
- Amazon Bedrock Prompt Management
-
プロンプトを作成または変更するときに、プロンプトキャッシュを有効にするように選択できます。モデルに応じて、システムプロンプト、システム手順、メッセージ (ユーザーとアシスタント) をキャッシュできます。プロンプトキャッシュは無効にすることもできます。
注記
プロンプトキャッシュは、オンデマンド推論エンドポイントでのみサポートされています。バッチ推論 API ではサポートされていません。
API を使用すると、プロンプトキャッシュを最も柔軟かつきめ細かく制御できます。プロンプト内で個々のキャッシュチェックポイントを設定できます。特定のモデルで許可されているキャッシュチェックポイントの最大数までキャッシュチェックポイントをさらに作成することで、キャッシュを追加できます。詳細については、「サポートされているモデル、リージョン、制限」を参照してください。
サポートされているモデル、リージョン、制限
プロンプトキャッシュは、サポートされているモデルが利用可能なすべての AWS リージョンで使用できます。リージョン別にモデルの可用性を確認するには、「」を参照してくださいモデル別のリージョンの可用性。
次の表は、サポートされているモデルとそのトークンの最小値、キャッシュチェックポイントの最大数、キャッシュチェックポイントを許可するフィールドの一覧です。
プロンプトキャッシュをサポートするモデルを確認するには、「Models at glance」を参照してから、関心のあるモデルを選択してください。次の表は、一目でわかるモデルに存在しないmodels-at-a-glanceプロンプトキャッシュを示しています。
| モデル名 | モデル ID | リリースタイプ | キャッシュチェックポイントあたりのトークンの最小数 | リクエストあたりのキャッシュチェックポイントの最大数 | サポートされている TTL | プロンプトキャッシュチェックポイントを受け入れるフィールド |
|---|---|---|---|---|---|---|
Claude Opus 4.5 |
anthropic.claude-opus-4-5-20251101-v1:0 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 4.6 |
anthropic.claude-opus-4-6-v1 |
一般提供 |
4,096 |
4 |
5 分 |
「system」、「messages」、「tools」 |
Claude Sonnet 4.5 |
anthropic.claude-sonnet-4-5-20250929-v1:0 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Sonnet 4.6 |
anthropic.claude-sonnet-4-6 |
一般提供 |
1,024 |
4 |
5 分 |
「system」、「messages」、「tools」 |
Claude Haiku 4.5 |
anthropic.claude-haiku-4-5-20251001-v1:0 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 4 |
anthropic.claude-opus-4-20250514-v1:0 |
一般提供 |
1,024 |
4 |
5 分 |
「system」、「messages」、「tools」 |
Claude 3.7 Sonnet |
anthropic.claude-3-7-sonnet-20250219-v1:0 |
一般提供 |
1,024 |
4 |
5 分 |
「system」、「messages」、「tools」 |
Claude 3.5 Sonnet v2 |
anthropic.claude-3-5-sonnet-20241022-v2:0 |
プレビュー |
1,024 |
4 |
5 分 |
「system」、「messages」、「tools」 |
GPT-5.6 ソル |
openai.gpt-5.6-sol |
一般提供 |
1,024 |
4 |
30 分 |
|
GPT-5.6 テラ |
openai.gpt-5.6-terra |
一般提供 |
1,024 |
4 |
30 分 |
|
GPT-5.6 Luna |
openai.gpt-5.6-luna |
一般提供 |
1,024 |
4 |
30 分 |
|
サポートされているモデル (Claude Opus 4.5、、および Claude Sonnet 4.5) で 1 時間 TTL オプションを使用するにはClaude Haiku 4.5、キャッシュチェックポイントで ttlフィールドを指定します。Converse API で、 cachePoint オブジェクト"ttl": "1h"に を追加します。Claude モデル用の InvokeModel API で、 cache_control オブジェクト"ttl": "1h"に を追加します。ttl 値を指定しない場合、デフォルトの 5 分間のキャッシュ動作が適用されます。1 時間の TTL は、長時間実行されるセッションやバッチ処理シナリオで、長期間キャッシュを維持する場合に便利です。
Amazon Nova は、User および System メッセージを含むすべてのテキストプロンプトの自動プロンプトキャッシュを提供します。このメカニズムにより、明示的な設定がない場合でも、プロンプトが反復的な部分で始まる場合にレイテンシーのメリットを得られます。ただし、コスト削減を実現し、より一貫したパフォーマンス上のメリットを確保するには、明示的なプロンプトキャッシュにオプトインすることをお勧めします。
Anthropic からのモデルのキャッシュ管理
Claude モデルの場合、Amazon Bedrock はキャッシュ管理のアプローチを簡素化し、キャッシュチェックポイントを手動で配置する複雑さを軽減します。正確なキャッシュチェックポイントの場所を指定する代わりに、静的コンテンツの最後にある 1 つのブレークポイントで自動キャッシュ管理を使用できます。
キャッシュ管理の簡素化を有効にすると、指定されたブレークポイントから最大約 20 個のコンテンツブロックまで遡って、以前のコンテンツブロック境界でのキャッシュヒットが自動的にチェックされます。これにより、モデルは最適なチェックポイントの場所を予測することなく、最も長く一致するプレフィックスをキャッシュから見つけることができます。これを使用するには、動的または可変コンテンツの前の、静的コンテンツの最後に 1 つのキャッシュチェックポイントを配置します。システムは最適なキャッシュ一致を自動的に見つけます。
よりきめ細かな制御を行うには、複数のキャッシュチェックポイント (Claude モデルの場合は最大 4 つ) を使用して正確なキャッシュ境界を指定することもできます。異なる頻度で変化するセクションをキャッシュする場合や、キャッシュされる内容を正確に制御したい場合は、複数のキャッシュチェックポイントを使用する必要があります。
重要
自動プレフィックスチェックは、キャッシュチェックポイントから約 20 個のコンテンツブロックのみを遡って調べます。静的コンテンツがこの範囲を超える場合は、複数のキャッシュチェックポイントを使用するか、プロンプトを再構築して、最も頻繁に再利用されるコンテンツをこの範囲内に配置することを検討してください。
Anthropic Models でキャッシュ管理を使用するためのベストプラクティス
定期的に使用されるプロンプト (5 分ごとにより頻繁に使用されるシステムプロンプト) がある場合は、引き続き 5 分間のキャッシュを使用します。これは追加料金なしで更新されるためです。
1 時間のキャッシュは、以下のシナリオに最適です。
-
使用する頻度が 5 分未満で、1 時間ごとよりも頻繁になる可能性があるプロンプトがある場合。例えば、エージェント側のエージェントが 5 分以上かかる場合や、ユーザーとの長いチャット会話を保存する場合、通常、そのユーザーは今後 5 分間応答しない可能性があります。
-
レイテンシーが重要で、フォローアッププロンプトが 5 分を超えて送信される場合があります。
-
レート制限の使用を改善する場合、キャッシュヒットはレート制限に対して差し引かれないためです。
同じリクエストで 1 時間と 5 分のキャッシュコントロールの両方を使用できますが、重要な制約があります。TTL が長いキャッシュエントリは、短い TTLs の前に表示する必要があります (つまり、5 分のキャッシュエントリの前に 1 時間のキャッシュエントリを表示する必要があります)。
OpenAI からのモデルのキャッシュ管理
Amazon Bedrock の OpenAI モデルは、bedrock-mantleエンドポイントの Responses API を介したプロンプトキャッシュをサポートしています。キャッシュ動作は、モデル生成によって異なります。
GPT-5.6 モデル
GPT-5.6 Sol (openai.gpt-5.6-sol)、Terra (openai.gpt-5.6-terra)、および Luna (openai.gpt-5.6-luna) では、明示的なプロンプトキャッシュブレークポイントが導入されているため、プロンプトのどの部分をキャッシュするかを正確に制御できます。これは、システム命令、ツール定義、参照ファイルが多くの呼び出しで繰り返され、最新の入力変更のみが行われるエージェントワークフローに特に役立ちます。
主な特徴
明示的なキャッシュブレークポイント — サポートされているコンテンツブロック
"prompt_cache_breakpoint": {"mode": "explicit"}に を追加して、再利用可能なプロンプトプレフィックスの正確な終了をマークします。キャッシュモード — ブレークポイントの動作を制御する
prompt_cache_options.modeように を設定します。implicit(デフォルト) — 最新のメッセージに自動ブレークポイントを配置し、指定した明示的なブレークポイントも使用します。explicit— 自動ブレークポイントを無効にします。キャッシュの読み取りと書き込みには、明示的なブレークポイントのみが使用されます。明示的なブレークポイントが存在しない場合、リクエストはプロンプトキャッシュを使用しないか、キャッシュ書き込み料金が発生します。
最小プレフィックス長 — ブレークポイントあたり 1,024 トークン。
最小 TTL 30 分 — キャッシュされたプレフィックスは、1 つのエージェント実行が生成する呼び出しのバーストをカバーするのに十分な期間、少なくとも 30 分間再利用できます。TTL は を介して設定
prompt_cache_options.ttlされ、デフォルトで に設定されます30m。キャッシュ書き込み請求 — キャッシュに書き込まれたトークンは、キャッシュされていない入力トークンレートの 1.25 倍で請求されます。キャッシュ読み取りは、キャッシュされていない入力トークンと比較して 90% の割引で請求されます。
キャッシュされたトークンはレート制限にはカウントされません — プロンプトキャッシュを通じて読み取られたキャッシュされた入力トークンは、1 input-tokens-per-minuteクォータにはカウントされません。
レスポンスを理解する
レスポンスの使用状況オブジェクトには、2 つのキャッシュ固有のフィールドが含まれます。
cached_tokens— キャッシュから読み取られた入力トークンの数 (キャッシュ読み取り割引率で請求)。cache_write_tokens— キャッシュに書き込まれた入力トークンの数 (キャッシュされていない入力トークンレートの 1.25 倍で請求)。
cached_tokens が 0 より大きく、 cache_write_tokensが 0 の場合、リクエストは既存のキャッシュエントリと完全に一致しました。新しい書き込みは発生せず、最大コスト削減を実現しました。
GPT 5.6 モデルでキャッシュ管理を使用するためのベストプラクティス
安定したコンテンツの後にブレークポイントを配置する — 呼び出し間で変更されないシステム手順、ツール定義、リファレンスドキュメントは、ブレークポイントの前に表示されます。ブレークポイント後のコンテンツは、キャッシュされたプレフィックスを無効にすることなく自由に変更できます。
エージェントループに
explicitモードを使用する — キャッシュされる内容を完全に制御し、書き込みスロットを消費する自動ブレークポイントを回避したい場合。モニタリング
cache_write_tokens— キャッシュ書き込みボリュームと後続のキャッシュ読み取りを比較して純コストへの影響を把握し、それに応じてブレークポイント配置を調整します。
GPT-5.5 以前のモデル
GPT-5.6 より前の OpenAI モデル ( openai.gpt-5.5や などopenai.gpt-5.4) では、プロンプトキャッシュは自動的に行われます。特別なパラメータを追加する必要はありません。システムは 1,024 トークン以上の適格なプロンプトプレフィックスを自動的にキャッシュします。キャッシュ書き込みでは、これらのモデルに追加料金はかかりません。
主な特徴
自動キャッシュ — コードの変更は必要ありません。システムは、正確なプレフィックスマッチングに基づいてプレフィックスを自動的にキャッシュします。
最小プレフィックス長 — 1,024 トークン。
キャッシュ書き込み料金なし — キャッシュ読み取りのみが割引料金で請求されます。
キャッシュされたトークンはレート制限にはカウントされません — プロンプトキャッシュを通じて読み取られたキャッシュされた入力トークンは、1 input-tokens-per-minuteクォータにはカウントされません。
GPT-5.5 以前のモデルでキャッシュ管理を使用するためのベストプラクティス
プロンプトの先頭に静的コンテンツ (システムプロンプト、ツール定義、リファレンスドキュメント) を配置します。
変数コンテンツ (ユーザー固有の入力) を最後に配置します。
キャッシュの削除を最小限に抑えるために、同じプレフィックスを使用してリクエストの安定したストリームを維持します。
開始方法
以下のセクションでは、Amazon Bedrock を介してモデルを操作する各方法でプロンプトキャッシュ機能を使用する方法の概要を示します。
Converse API には、複数ターンの会話でプロンプトキャッシュを実装するための高度で柔軟なオプションが用意されています。各モデルのプロンプト要件の詳細については、前のセクションの「サポートされているモデル、リージョン、制限」を参照してください。
リクエストの例
次の例は、Converse API へのリクエストの messages、system、または tools フィールドに設定されたキャッシュチェックポイントを示しています。特定のリクエストで、これらの場所のいずれかにチェックポイントを配置できます。例えば、Claude 3.5 Sonnet v2 モデルにリクエストを送信する場合、2 つのキャッシュチェックポイントを messages に、1 つのキャッシュチェックポイントを system に、もう 1 つのキャッシュチェックポイントを tools に配置することができます。Converse API リクエストの構造化と送信の詳細な例については、「Converse API を使用した推論」を参照してください。
重要
キャッシュチェックポイントは、 tools → system → の順序で処理されますmessages。最小キャッシュサイズは、各セクションではなく、3 つのセクションすべてを組み合わせた累積トークンに対して評価されます。セクションは連鎖されているため、前のセクションのコンテンツを変更すると、後のセクションのキャッシュが無効になります (たとえば、 を変更すると systemキャッシュと messagesキャッシュtoolsが無効になります)。最適なキャッシュヒット率を得るには、可変コンテンツ (system) の前に安定したコンテンツ (tools、messages) を配置し、安定したコンテンツの後にキャッシュチェックポイントを配置します。
次のように目的の ttl 値を指定します。ttl 値が指定されていない場合、デフォルトの動作である 5 分間のキャッシュが適用されます。
"cachePoint" : { "type": "default", "ttl" : "5m | 1h" }
Converse API からのモデルレスポンスには、プロンプトキャッシュに固有の 3 つの新しいフィールドが含まれています。cacheReadInputTokens と cacheWriteInputTokens の値は、キャッシュから読み取られたトークンの数と、以前のリクエストのためにキャッシュに書き込まれたトークンの数を示します。cacheDetails 値は、キャッシュに書き込まれたトークンの数に使用される ttl を示します。これらは、Amazon Bedrock によって課金される値で、完全なモデル推論のコストよりも低い料金です。
重要
プロンプトキャッシュが有効になっている場合、 inputTokensフィールドはキャッシュされていない入力トークン (キャッシュとの間で読み書きされなかったトークン) のみを表します。リクエストで送信された入力トークンの合計を計算するには、次の式を使用します。
total input tokens = inputTokens + cacheReadInputTokens + cacheWriteInputTokens
InvokeModel API を呼び出すと、プロンプトキャッシュはデフォルトで有効になります。前の Converse API の例と同様に、キャッシュチェックポイントはリクエスト本文の任意の時点で設定できます。
InvokeModel リクエストの送信の詳細については、「InvokeModel で 1 つのプロンプトを送信する」を参照してください。
bedrock-mantle エンドポイントの OpenAI モデルの場合、モデル生成に固有のプロンプトキャッシュパラメータで Responses API を使用します。GPT-5.6 モデルでは、明示的なブレークポイントを使用してキャッシュを制御します。GPT-5.5 以前では、キャッシュは自動的に行われます。
明示的なキャッシュブレークポイントを使用した GPT-5.6 の例
次の例は、明示的なキャッシュブレークポイントopenai.gpt-5.6-solの使用に対する Responses API リクエストを示しています。システム命令はキャッシュされ、後続のリクエスト間で再利用されます。
{ "model": "openai.gpt-5.6-sol", "prompt_cache_key": "my-app:system-prompt-v1", "prompt_cache_options": { "mode": "explicit" }, "input": [ { "type": "message", "role": "developer", "content": [ { "type": "input_text", "text": "You are a technical support agent. Use the company knowledge base to answer questions. Follow these guidelines: 1. Always cite the relevant documentation section. 2. If unsure, escalate to a human agent. 3. Be concise but thorough...", "prompt_cache_breakpoint": { "mode": "explicit" } } ] }, { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "How do I configure SSO for my organization?" } ] } ] }
自動キャッシュを使用した GPT-5.5 の例
GPT-5.5 以前のモデルでは、プロンプトキャッシュは自動的に行われます。ブレークポイントやキャッシュキーは必要ありません。プロンプトプレフィックスが 1,024 トークンを超えていることを確認してください。
{ "model": "openai.gpt-5.5", "input": [ { "type": "message", "role": "developer", "content": [ { "type": "input_text", "text": "You are a technical support agent. Use the company knowledge base to answer questions..." } ] }, { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "How do I configure SSO for my organization?" } ] } ] }
[応答]
レスポンスには、 usage オブジェクトのキャッシュ使用状況メトリクスが含まれます。
{ "id": "resp_abc123", "output": [...], "usage": { "input_tokens": 2048, "output_tokens": 256, "total_tokens": 2304, "input_tokens_details": { "cached_tokens": 1920, "cache_write_tokens": 0 } } }
このレスポンスでは、キャッシュから 1,920 個のトークンが提供され、新しいトークンは書き込まれなかったため、キャッシュ全体がヒットし、コストが最大限削減されたことを示します。
Amazon Bedrock コンソールのチャットプレイグラウンドで、プロンプトキャッシュオプションを有効にすると、Amazon Bedrock が自動的にキャッシュチェックポイントを作成します。
Amazon Bedrock プレイグラウンドでプロンプトを開始するには、「Generate responses in the console using playgrounds」の手順に従います。サポートされているモデルでは、プレイグラウンドでプロンプトキャッシュが自動的に有効になります。ただし、そうでない場合は、次の操作を実行してプロンプトキャッシュを有効にします。
-
[設定] メニューを開きます。
-
[プロンプトキャッシュ] の切り替えをオンにします。
-
プロンプトを実行します。
入力レスポンスとモデルレスポンスの組み合わせがチェックポイントに必要なトークンの最小数 (モデルによって異なります) に達すると、Amazon Bedrock は最初のキャッシュチェックポイントを自動的に作成します。チャットを続けると、トークンの最小数に達するたびに、モデルで許可されるチェックポイントの最大数まで新しいチェックポイントが作成されます。次のスクリーンショットに示すように、[プロンプトキャッシュ] の切り替えの横にある [キャッシュチェックポイントを表示する] を選択すると、キャッシュチェックポイントをいつでも表示できます。
プレイグラウンドレスポンスで [キャッシュメトリクス] ポップアップ (
) を表示して、モデルとのやり取りによってキャッシュとの間で読み書きされているトークンの数を表示できます。
会話の途中でプロンプトキャッシュの切り替えをオフにすると、モデルとのチャットを続行できます。