Amazon Bedrockは、プロンプトの一部をキャッシュできる機能を提供開始しました。これにより、静的なプロンプトの接頭辞（prefix）を再利用するアプリケーションにおいて、トークン使用料を最大90%削減し、レスポンスのレイテンシを最大85%短縮することが可能になります。

この変更が重要な理由

大規模言語モデル（LLM）をオンデマンドで実行する場合、モデルにトークンが送信されるたびにコストが発生します。チャットボット、コードアシスタント、ドキュメント検索ツールなどは、同じシステム指示や参照資料を繰り返し送信することが多く、それがコストの増大やレスポンスの遅延を招いています。

プロンプトキャッシュの仕組み

Bedrockは、プロンプトの任意のセグメントに開発者が付与できる「cacheable」フラグを追加しました。対象となるのは、通常、セッション中に変更されることのないシステムレベルの指示、長い背景ドキュメント、またはツールの定義などです。リクエストが届くと、Bedrockはフラグが立てられたセグメントが保存済みのエントリと一致するかどうかを確認します。一致する場合、サービスはその部分の再エンコードとモデルによる再実行をスキップし、代わりにキャッシュから事前計算済みの表現を取得します。

数値による効果

  • 入力トークンコスト: キャッシュされた接頭辞は呼び出しごとにトークンを消費しなくなるため、最大90%削減されます。
  • レイテンシ: 静的な部分に対してモデルの負荷の高い処理を回避できるため、最大85%高速化されます。

最適なユースケース

この機能は、プロンプトが「変化しない大きなブロック」と、それに続く「短く可変的なユーザーのクエリ」で構成されている場合に真価を発揮します。一般的なパターンは以下の通りです。

  • すべてのクエリの先頭に取得したドキュメントを付加する、検索拡張生成（RAG）パイプライン。
  • 常に同じポリシー声明やトーン設定テキストから始まるカスタマーサポートボット。
  • 開発者のコードスニペットの前に、固定の言語ツール定義を読み込むコーディングアシスタント。

開発者が変更すべき点

開発者は、静的なコンテンツがプロンプトの最前頭に配置され、呼び出し間でバイト単位で完全に一致するようにプロンプトの順序を再構成する必要があります。可変的なユーザー入力は、キャッシュされた接頭辞の後に続きます。モデルの切り替えは不要で、同じBedrockエンドポイントがリクエストを処理します。

メリットを受ける層と注意が必要なケース

メリットが得られるのは、接頭辞が真に静的な状態を維持するワークロードに限られます。ユーザーごとにシステム指示をパーソナライズしたり、コンテキストを頻繁に変更したりするアプリケーションでは、ほとんどメリットが得られないため、プロンプト作成の複雑さが増すことと、得られるわずかな利得を天秤にかける必要があります。

結論: プロンプトキャッシュは、アプリケーションが再利用可能なプロンプトの接頭辞を分離できるのであれば、BedrockユーザーにとってAI運用コストを削減し、レスポンス時間を改善するための直接的な手段となります。