AWSは固定の指示と増える会話履歴を分けたキャッシュ設計を公開しました。明示的な保存境界と自動の保存を併用する実装を紹介しています。 繰り返す入力の費用を減らすには、同じ内容と順序を保つ必要があります。利用者固有の情報、ツール変更、保存期限の管理が焦点です。 同じ指示を読み直す処理を再利用 AWSは10月26日、Amazon BedrockでOpenAIモデルを使うエージェント向けに、プロンプトキャッシュの実装例を公開しました。ツールの定義、指示、過去の操作結果を毎回送る構成では、共通部分も繰り返し処理されます。キャッシュは入力の処理で作った状態を保存し、後の要求で一致する先頭部分を再利用します。今回の記事はモデル自身が会話を恒久的に記憶する機能ではなく、サービス側で計算済みの入力を使う仕組みを扱っています。固定の初期設定と、やり取りごとに増える履歴の両方を、どこまで保存するかに応じて設計します。 固定部分と会話の成長を異なる境界で扱う 明示的な方式ではコードで保存の終点を指定し、自動の方式ではBedrockが会話に応じて境界を選びます。記事は両者を組み合わせ、複数の会話で共通の指示を再利用しつつ、各会話の履歴も扱う方法を示しています。例では再利用する先頭部分が1,024トークン以上であることを条件としています。同じ文字列と順序を保つ必要があり、日時、利用者名、要求ごとの識別子は固定部分の後へ置きます。ツールの一覧をMCPなどから得る場合も、順序が変われば一致に影響する可能性があります。長いセッションや補助エージェントを使う開発者にとって、プロンプトの内容だけでなく、組み立て方を共通化することが運用上の論点になります。入力の版管理も確認点です。 保存期限と変更時の無効化も費用に含める 実務では、命中率だけでなく保存への書き込みと新しい入力の費用も測る必要があると見られます。指示やツールを変更した場合は、以前の構成と同じキャッシュの扱いにしない設計が論点です。共有するキーの範囲を決める際も、部署や用途が異なる情報をどう区別するかを整理する必要があります。記事の例では応答保存を無効にしてもキャッシュが機能すると説明しており、会話の保存設定とは区別して読む必要があります。導入前には、自社で使うモデルとAPIの対応、保存期限、変更時の挙動を確認することが重要です。短い入力や共通部分が少ない業務では効果が異なるため、一定の削減率を前提にしない比較が適切と考えられます。遅延と費用を実際の会話で測り、更新後も同じ条件で追うことが判断材料になります。 入力が変わる場所を記録して検証する キャッシュの効果を調べるには、入力が一致しなかった原因も追う必要があります。アプリが付ける日時やツール定義の並びなど、業務担当者から見えない変更が影響する可能性があります。固定部分を作る処理を共有し、変更時に記録を残すことが論点です。試験では同じ会話の続きと新しい会話を区別して計測すると、どの部分が再利用されたかを確認しやすくなります。利用者の待ち時間を減らす効果も、応答全体の時間と入力処理の時間を分けて読む必要があります。