翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
モデル推論を高速化するためのプロンプトキャッシュ
プロンプトキャッシュは、Amazon Bedrock でサポートされているモデルで使用できるオプション機能であり、推論レスポンスのレイテンシーと入力トークンのコストを削減できます。Amazon Bedrock は、暗黙的なプロンプトキャッシュと明示的なプロンプトキャッシュの 2 種類のプロンプトキャッシュをサポートしています。各タイプのサポートは、モデルと API によって異なります。
プロンプトキャッシュは、長さと繰り返しがあり複数のクエリで頻繁に再利用されるコンテキストのワークロードがある場合に役立ちます。例えば、ユーザーがドキュメントをアップロードして質問できるチャットボットがある場合、ユーザーが入力するたびにモデルがドキュメントを処理すると時間がかかる可能性があります。プロンプトキャッシュを使用すると、ドキュメントをキャッシュでき、そのドキュメントを含む将来のクエリを再処理する必要がなくなります。
プロンプトキャッシュのタイプ
2 つのタイプは、再利用可能なプロンプトコンテンツの選択方法によって異なります。
| タイプ | 仕組み | リクエスト設定 |
|---|---|---|
| 暗黙的なプロンプトキャッシュ | Amazon Bedrock とモデルは、対象となるプロンプトプレフィックスを自動的に再利用しようとします。 | リクエストにキャッシュコントロールやブレークポイントは必要ありません。 |
| 明示的なプロンプトキャッシュ | モデル固有のキャッシュコントロールまたはブレークポイントを追加して、再利用可能なプロンプトプレフィックスを識別します。 | リクエストには、モデルと API でサポートされているキャッシュコントロールが含まれている必要があります。 |
暗黙的なプロンプトキャッシュ
暗黙的なプロンプトキャッシュは、リクエストにキャッシュコントロールを必要とせずに、対象となるプロンプトプレフィックスを自動的に再利用しようとします。プロンプトの先頭に静的コンテンツを保持し、最後に動的コンテンツを保持して、プレフィックスが完全に一致する可能性を高めます。
暗黙的なプロンプトキャッシュはベストエフォートです。同じプロンプトを繰り返してもキャッシュヒットが保証されず、キャッシュヒット率は異なる場合があります。
明示的なプロンプトキャッシュ
明示的なプロンプトキャッシュを使用すると、モデル固有のキャッシュコントロールまたはキャッシュチェックポイントを使用して、再利用可能なプロンプトプレフィックスを特定できます。キャッシュチェックポイントは、キャッシュするプロンプトの連続するサブセクションを定義するマーカーです。プロンプトプレフィックスは、リクエスト間で静的なままにする必要があります。後続のリクエストでプロンプトプレフィックスを変更すると、キャッシュミスが発生します。
キャッシュチェックポイントには、モデルに応じてトークンの最小数と最大数があります。キャッシュチェックポイントは、合計プロンプトプレフィックスがトークンの最小数を満たしている場合にのみ作成できます。たとえば、 Claude Opus 5では、キャッシュチェックポイントごとに少なくとも 512 トークンClaude Sonnet 5が必要で、キャッシュチェックポイントごとに少なくとも 1,024 トークンが必要で、キャッシュチェックポイントごとに少なくとも 4,096 トークンClaude Haiku 4.5が必要です。最小値は、必要に応じて、、、toolssystemおよび messagesフィールドのコンテンツを含め、各チェックポイントの前にプロンプトプレフィックス全体に累積的に適用されます。キャッシュチェックポイント間で必要なトークンの最小数はありません。1,024 トークン以上のモデルの場合、各チェックポイントの前のプロンプトプレフィックスの合計に少なくとも 1,024 トークンが含まれている限り、1,024 トークン未満の追加のチェックポイントを定義できます。プロンプトプレフィックスの合計数がトークンの最小数に達する前にキャッシュチェックポイントを追加すると、推論は成功しますが、プレフィックスはキャッシュされません。
キャッシュには有効期限 (TTL) があり、キャッシュヒットが成功するたびにリセットされます。この期間中、キャッシュ内のコンテキストは保持されます。TTL ウィンドウ内でキャッシュヒットが発生しない場合、キャッシュは期限切れになります。多くのモデルは 5 分の TTL をサポートしています。モデルのモデルカードをチェックして、正確な TTL 条件を確認します。
明示的なプロンプトキャッシュは、キャッシュの対象となるプロンプトコンテンツを制御します。対象となるリクエストがキャッシュヒットになることは保証されません。
キャッシュされたトークンの請求
暗黙的なプロンプトキャッシュと明示的なプロンプトキャッシュの両方で、キャッシュから正常に読み取られたトークンはキャッシュされたトークンとして報告され、モデルのキャッシュ読み取りレートで請求されます。キャッシュから読み取られないトークンは、標準の入力トークンレートで請求されます。モデルに応じて、キャッシュに書き込まれたトークンは、標準の入力トークンレートよりも高いレートで請求できます。詳細については、「Amazon Bedrock の料金ページ
重要
プロンプトキャッシュのサポートは、リクエストのキャッシュヒットを保証しません。モデルレスポンスのキャッシュ使用状況フィールドをチェックして、トークンがキャッシュから読み取られたか、キャッシュに書き込まれたかを判断します。
サポートされているモデルで Amazon Bedrock で推論を実行するときに、プロンプトキャッシュを使用できます。各プロンプトキャッシュタイプの可用性は、モデルと API によって異なります。プロンプトキャッシュは、次の Amazon Bedrock 機能を通じて使用できます。
- Converse API と ConverseStream API
-
サポートされているモデルとの会話を続けることができます。明示的なプロンプトキャッシュでは、プロンプトでキャッシュチェックポイントを指定します。
- InvokeModel API と InvokeModelWithResponseStream API
-
サポートされているモデルにシングルプロンプトリクエストを送信できます。明示的なプロンプトキャッシュでは、プロンプトキャッシュを有効にし、キャッシュチェックポイントを指定します。
- クロスリージョン推論を使用したプロンプトキャッシュ
-
プロンプトキャッシュは、クロスリージョン推論と組み合わせて使用できます。クロスリージョン推論は、推論リクエストを処理するために地域内の最適な AWS リージョンを自動的に選択し、利用可能なリソースとモデルの可用性を最大化します。需要が高い場合、この最適化によりキャッシュ書き込みが増加する可能性があります。
- Amazon Bedrock Prompt Management
-
プロンプトを作成または変更するときに、プロンプトキャッシュを有効にするように選択できます。モデルに応じて、システムプロンプト、システム手順、メッセージ (ユーザーとアシスタント) をキャッシュできます。プロンプトキャッシュは無効にすることもできます。
注記
プロンプトキャッシュは、オンデマンド推論エンドポイントでのみサポートされています。バッチ推論 API ではサポートされていません。
明示的なプロンプトキャッシュをサポートするモデルの場合、APIs はプロンプトキャッシュをきめ細かく制御します。プロンプト内で個々のキャッシュチェックポイントを設定し、モデルに許可される最大数までチェックポイントを追加できます。詳細については、「サポートされているモデル、リージョン、および明示的なキャッシュ制限」を参照してください。
サポートされているモデル、リージョン、および明示的なキャッシュ制限
プロンプトキャッシュのサポートは、モデルと API によって異なります。モデルカードは、モデルが暗黙的なプロンプトキャッシュ、明示的なプロンプトキャッシュ、またはその両方をサポートしているかどうかを識別します。プロンプトキャッシュは、サポートされているモデルが利用可能なすべての AWS リージョンで使用できます。リージョン別にモデルの可用性を確認するには、「」を参照してくださいモデル別のリージョンの可用性。
次の表に、明示的なプロンプトキャッシュをサポートするモデルと、トークンの最小値、キャッシュチェックポイントの最大数、キャッシュチェックポイントを許可するフィールドを示します。
モデルがサポートするプロンプトキャッシュタイプを確認するには、「Models at a glance」を参照し、関心のあるモデルを選択します。
| モデル名 | モデル ID | リリースタイプ | キャッシュチェックポイントあたりのトークンの最小数 | リクエストあたりのキャッシュチェックポイントの最大数 | サポートされている TTL | プロンプトキャッシュチェックポイントを受け入れるフィールド |
|---|---|---|---|---|---|---|
Claude Fable 5.1 |
anthropic.claude-fable-5-1 |
一般提供 |
512 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Mythos 5.1 |
anthropic.claude-mythos-5-1 |
制限あり |
512 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Fable 5 |
anthropic.claude-fable-5 |
一般提供 |
512 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Mythos 5 |
anthropic.claude-mythos-5 |
制限あり |
512 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Mythos Preview |
anthropic.claude-mythos-preview |
制限あり |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 5 |
anthropic.claude-opus-5 |
一般提供 |
512 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 4.8 |
anthropic.claude-opus-4-8 |
一般提供 |
1,024 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 4.7 |
anthropic.claude-opus-4-7 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 4.6 |
anthropic.claude-opus-4-6-v1 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Opus 4.5 |
anthropic.claude-opus-4-5-20251101-v1:0 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Sonnet 5 |
anthropic.claude-sonnet-5 |
一般提供 |
1,024 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Sonnet 4.6 |
anthropic.claude-sonnet-4-6 |
一般提供 |
1,024 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
Claude Sonnet 4.5 |
anthropic.claude-sonnet-4-5-20250929-v1:0 |
一般提供 |
1,024 |
4 |
5 分、1 時間 |
「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」 |
Claude Haiku 4.5 |
anthropic.claude-haiku-4-5-20251001-v1:0 |
一般提供 |
4,096 |
4 |
5 分、1 時間 |
「system」、「messages」、「tools」 |
GPT-5.6 Sol |
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 Fable 5、、、Claude Opus 4.8、、、、Claude Opus 5、Claude Opus 4.7Claude Opus 4.6Claude Opus 4.5、Claude Haiku 4.5) で 1 時間の TTL オプションを使用するにはClaude Sonnet 4.5、キャッシュチェックポイントで Claude Sonnet 5 Claude Sonnet 4.6ttlフィールドを指定します。Converse API で、 cachePoint オブジェクト"ttl": "1h"に を追加します。Claude モデル用の InvokeModel API で、 cache_control オブジェクト"ttl": "1h"に を追加します。ttl 値を指定しない場合、デフォルトの 5 分間のキャッシュ動作が適用されます。1 時間の TTL は、長時間実行されるセッションやバッチ処理シナリオで、長期間キャッシュを維持する場合に便利です。
Amazon Nova は、 Userおよび System メッセージを含むすべてのテキストプロンプトに対して暗黙的なプロンプトキャッシュを提供します。このメカニズムは、プロンプトが明示的な設定なしで反復的な部分で始まる場合、レイテンシーの利点を提供します。Amazon Novaモデルカードで明示的なプロンプトキャッシュをサポートしているとして示されているモデルでは、キャッシュ適格性をより詳細に制御するためにキャッシュチェックポイントを指定することもできます。
Anthropic からのモデルのプロンプトキャッシュ
Amazon Bedrock でプロンプトキャッシュをサポートするアントロピックモデルは、暗黙的なプロンプトキャッシュと明示的なプロンプトキャッシュの両方をサポートしています。暗黙的なプロンプトキャッシュは、リクエストにキャッシュコントロールを必要とせずに、対象となるプロンプトプレフィックスを自動的に再利用しようとします。
明示的なプロンプトキャッシュの場合、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 モデルは、 Responses API による暗黙的なプロンプトキャッシュをサポートしています。GPT-5.6 モデルは、明示的なプロンプトキャッシュもサポートしています。Responses API は、 エンドポイントbedrock-runtimeと bedrock-mantleエンドポイントの両方で使用できます。
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 トークン。
30 分の最小 TTL — キャッシュされたプレフィックスは、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 つのプロンプトを送信する」を参照してください。
OpenAI モデルの場合、 エンドポイントbedrock-runtimeと bedrock-mantleエンドポイントの両方で利用可能な 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 は最初のキャッシュチェックポイントを自動的に作成します。チャットを続けると、Amazon Bedrock はモデルに許可されるチェックポイントの最大数まで追加のチェックポイントを作成できます。最小数は、前のチェックポイント以降に追加されたトークンの数ではなく、各チェックポイントの前のトークンの累積数に対して評価されます。次のスクリーンショットに示すように、[プロンプトキャッシュ] の切り替えの横にある [キャッシュチェックポイントを表示する] を選択すると、キャッシュチェックポイントをいつでも表示できます。
プレイグラウンドレスポンスで [キャッシュメトリクス] ポップアップ (
) を表示して、モデルとのやり取りによってキャッシュとの間で読み書きされているトークンの数を表示できます。
会話の途中でプロンプトキャッシュの切り替えをオフにすると、モデルとのチャットを続行できます。