プロンプトキャッシュとは、モデルリクエスト内で繰り返し現れるプロンプトプレフィックスをキャッシュし、今後同じまたは非常に一貫したプレフィックスに遭遇した際に、毎回一から数えるのではなく、処理結果を直接再利用しようとする方法を指します。 過去2年間で人気が高まっている理由は、名前の高度なことではなく、多くの製品が固定されたシステムプロンプト、ツール定義、長いルール、長いドキュメントの背景が多くのAIコストや遅延の本当の主体であることにようやく気づいたからです。
多くの人はプロンプトキャッシュとコンテキストキャッシングを混同しますが、確かに近くはあるものの、まったく同じ焦点ではありません。 プロンプトキャッシュは「プロンプトプレフィックス」を強調しており、特に各リクエストの前半がほぼ同じで後半のみ変わる場合に適用されます。 例えば、カスタマーサービス担当者、コードアシスタント、エンタープライズナレッジアシスタントは、まず固定されたシステムルール、ツールの記述、フォーマットの制約を詰め込む必要があり、唯一の本当の変更はユーザー問題だけです。
なぜマルチホイールエージェントに特に適しているのでしょうか? なぜなら、エージェントがツールコールや多段階推論に入ると、多くの繰り返しのコンテキストが伴うからです。 モデルにツールのリストや長いシステムヒント、固定されたワークフロー指示を一歩一つ教えてくれれば、作業は遅くなり、請求額も高額になります。 キャッシュメカニズムの価値は、これらの繰り返されるコストをできるだけ希釈することにあります。
しかし、プロンプトキャッシュは「オンにすれば自動的に大量の節約ができる」万能の薬ではありません。 プレフィックスの安定性に大きく依存しています。 システムプロンプトの位置を1〜2つ毎回変え、例の順序をシャッフルし、ツールの定義を行き来させれば、命中率は大幅に下がります。 多くのチームがキャッシュ効果が悪いのは、モデルが対応していないからではなく、プロンプトプロジェクト自体があまりにも緩く書かれていて、再利用可能な安定したプレフィックスが全くないからです。
プロンプトキャッシュに適したコンテンツには一般的に3つのカテゴリーがあります。 最初のカテゴリーは、役割、トーン、境界、セキュリティ制約など、長期的に変わらないシステムルールです。 第二のカテゴリーは、ナレッジベースのインデックス記述、フォーマットスキーマ、ツールリストなど、高度に多重化されたブロック記述です。 3つ目のカテゴリーは、セッション間で繰り返されるテンプレート化されたタスクです。 逆に、ユーザーパーソナライズされたフィールドやリアルタイムデータ、毎回変わる検索結果は、前方のキャッシュスペースには適していません。
また、誤解されている点もあります。キャッシュは前処理やプレフィックスの計算コストを節約しますが、結果が全く同じになるわけでも、モデルが「すべての履歴を記憶している」という意味でもありません。 回答の質は、その後の入力、サンプリングパラメータ、ツールの返却結果、そして文脈の正確性に依存します。 キャッシュは反復作業を解決するもので、正しいかどうかを考えるのではありません。
そのため、OpenAIやAnthropicのようなAPIドキュメントはプロンプトキャッシュを強調し始めており、開発者に一つのメッセージを伝えています。プロンプトはもはや一度きりのテキストではなく、最適化可能なシステム資産であるということです。 静的な部分を安定させ、動的な部分を後ろに移動させ、ヒット率を上げられる人が、長いプロンプトやエージェントシーンをより速く、より経済的に実行できる可能性が高いです。
