Bedrock上のOpenAIモデル、プロンプトキャッシュ併用の実装パターン

何が公開されたのか

AWSは機械学習ブログで、Amazon Bedrock上でOpenAIのモデルを動かす際のプロンプトキャッシュの使い方を公開した。エージェントの1ターン目から、新しいツールを追加する場面、補助エージェント（サブエージェント）を起動する場面までを順に追う構成になっている。冒頭では映画「Groundhog Day」を引き合いに、毎回同じコンテキストを読み直すエージェントの姿をたとえている。

記事はまず、エージェントがLLMに送る内容を4つに分解する。ツール一覧、指示（開発者プロンプト）、これまでの履歴、そして最新のツール結果やユーザーメッセージだ。履歴はターンごとに伸びるため、20ターン目には1〜19ターン分を毎回読み直すことになり、そのトークン代は利用者が負担する。記事はこの構造がコスト増の根本だと説明している。

仕組みはprefillの再利用

モデルがプロンプトを読むとき、最初にprefillと呼ばれる処理で全入力トークンを処理し、key/value（KV）ベクトルという作業状態を組み立てる。プロンプトキャッシュはこの状態を保存しておき、後続リクエストの先頭が同じトークン列であれば、計算し直さずに読み込んで差分だけを処理する。これにより、毎ターン同じ前置きを読み直す費用が抑えられる。

方式は2つある。暗黙（implicit）キャッシュでは、Amazon Bedrock側が再利用できるプレフィックスの終端を選ぶ。明示（explicit）キャッシュでは、コード内のprompt_cache_breakpointで終端を指定する。両者は併用でき、記事は併用を推奨している。暗黙だけでは会話の伸びに追従できる一方、セッションをまたいでツールと指示を共有したい場合は明示のマーカーが要る、という整理だ。

3つの実装パターン

1つ目は静的な部分のキャッシュだ。ツールと指示を明示モードで保存し、prompt_cache_keyでキャッシュを共有するリクエスト群を識別する。例ではTTLを30分に設定している。再利用可能なプレフィックスは1,024トークン以上に達する必要がある、と記事は条件を示している。

2つ目は会話履歴とツール結果のキャッシュだ。暗黙モードで履歴全体を渡し、Bedrockに直近の適格なメッセージまでを保存させる。ツール呼び出しの結果を履歴に追記してループを回す形で、過去のメッセージとツール定義は変更しないことが前提になる。

3つ目は明示のローリングブレークポイントで、各バッチの最後のツール結果にマーカーを付け、それ以前のマーカーは履歴に残す。記事はさらに、指示ブロックに明示マーカーを置いたうえで暗黙モードを併用する形を、共有の起点と伸びる履歴の両方を扱える構成として示している。

数値と注意点

記事には具体的な計測値が示されている。約4,000トークンのツールと指示のプレフィックスは、最初のリクエストで4,120トークンを書き込み、以降のリクエストでは同じ4,120トークンを読み込んだ。6ターンのワークロードで、GPT-6 Astraは暗黙キャッシュが約62%、明示のローリングブレークポイントが約61%の入力コスト削減になったという。一方、ツールと指示だけを固定して履歴を毎回処理する明示のみの構成は相対コスト0.61にとどまったとしている。

注意点として、キャッシュはまったく同じテキストを渡したときだけ効くと記事は強調する。指示やツール一覧のシリアライズ方法を毎回そろえ、MCPサーバーなどは索引化して一貫させる必要がある。日付、ユーザー名、リクエストIDといった変動する情報は、キャッシュ境界より後ろに置く。ブレークポイントを1つ動かすだけでも再利用が壊れ、書き込みが繰り返される可能性があるという。

なおstore=Falseは会話履歴をアプリケーション側に残す設定であり、キャッシュを無効化するものではない。キャッシュの読み書きはusage.input_tokens_detailsのcached_tokensとcache_write_tokensで確認できる。記事は、示された数値は著者のワークロードでの結果であり、自分のエージェントで計測すべきだと付け加えている。