導入
プロンプトキャッシュ すべてのプロンプトを短くすることではありません。これは、モデルプロバイダーが同じコンテキストに何度も請求するのではなく、プロンプトの高価で繰り返される部分を十分に安定させて再利用できるようにすることです。
AI ビルダー、SaaS オペレーター、および技術創設者にとって、難しい部分は、キャッシュ可能なプレフィックスに何が属するか、何が動的に維持される必要があるかを決定することです。キャッシュに適したワークフローにより、命令、スキーマ、およびサンプルがユーザー固有のコンテキストから分離されます。
安定したプレフィックス マップを使用してプロンプト キャッシュを開始する
プロンプトを書き換える前に、ワークフローを安定ブロックと可変ブロックに分割します。安定したブロックは多くの実行にわたって再利用されます。変数ブロックはタスクごとに変化します。
| プロンプトブロック | キャッシュフィット | 理由 |
|---|---|---|
| System instructions | High | Usually reused across tasks |
| Output schema | High | Should not change per user |
| Few-shot examples | Medium to high | 例を再利用する場合に便利です |
| 取得した文書 | Low | Usually task-specific |
| Timestamps and run IDs | Bad | They break prefix stability |
動的コンテキストを後で移動することでプロンプト キャッシュを改善する
一般的なキャッシュミスは、チームが再利用可能な命令の前にユーザー固有のデータを配置したときに発生します。先頭近くのタイムスタンプまたはタスク ID であっても、プレフィックスを変更してキャッシュ ヒットを減らすことができます。
プロンプト キャッシュ プレフィックス ルール
- ロール、ポリシー、スキーマ、および例を最初に配置します。
- ユーザーリクエスト、取得したスニペット、ツール出力を安定したブロックの後に配置します。
- 実行間でフォーマットの一貫性を保ちます。
- 最初のプロンプト ブロックではランダムな ID を使用しないでください。
期待ではなくキャッシュ ヒット率でプロンプト キャッシングを測定する
プロンプト キャッシュはワークフロー レベルで測定する必要があります。キャッシュ ヒット率、キャッシュされた入力トークン、キャッシュされていない入力トークン、待ち時間、最終タスクの成功率を追跡します。
| メトリック | 良い兆候 | Bad サイン |
|---|---|---|
| Cache hit rate | Rises as similar tasks repeat | Drops after prompt edits |
| Cached tokens | Large stable block reused | Only tiny prefix cached |
| Retry rate | Flat or lower | Higher after prompt restructuring |
| Output acceptance | Quality unchanged | Editors rewrite more output |
プロンプト キャッシュ障害モードを回避する
最大のリスクは、エージェントの信頼性を低下させながらトークンを節約することです。代表的なタスクの回帰セットを保持し、キャッシュ変更の前後で出力を比較します。
即時キャッシュ無効化チェックリスト
- システムプロンプトのバージョンを確認します。
- 例が変更された場合は文書化します。
- プロバイダー固有のキャッシュ動作を記録します。
- スキーマまたはツールの説明が変更された場合は再テストします。
モデル ルーティングでプロンプト キャッシュを使用する
プロンプト キャッシュとモデル ルーティングはうまく連携します。安定した計画または命令ブロックをキャッシュし、ルーチンのサブタスクをより安価なモデルにルーティングし、判断が必要なステップ用に強力なモデルを予約します。
キャッシュの安定性によるルーティング ルール
- 安定したスキーマ抽出では、より安価なモデルを使用できます。
- あいまいな推論には、より強力なモデルを使用する必要があります。
- フォーマット修復にはプレミアムモデルを使用しないでください。
- High リスクの最終勧告には、より強力なレビューが必要です。
本番環境での即時キャッシュの適用
運用環境では、即時キャッシュには所有権が必要です。スキーマ、例、またはツールの説明を少し編集すると、何度も実行するとキャッシュの動作がリセットされる可能性があるため、キャッシュされたプレフィックスへの変更を承認する人またはワークフロー所有者を 1 人割り当てます。各プロンプト バージョンの前後のコスト ログ (入力トークン、キャッシュされたトークン、出力トークン、待ち時間、再試行率、および受け入れられた出力率) を保存します。これにより、チームは入力コストが低くなったものの、下流での編集負荷が高くなることを見逃してしまうというよくある失敗を防ぐことができます。
例: 同様のプル リクエストをレビューする Claude Code ワークフローでは、レビュー ルーブリック、出力スキーマ、安全性ルールを安定したプレフィックスに保持できます。変更されたファイルとユーザー要求は、そのプレフィックスの後に残ります。ルーブリックが数十回の実行にわたって再利用される場合、プロンプト キャッシュにより、レビュー基準を弱めることなく、繰り返しのコンテキスト コストが削減されます。
起動後は、キャッシュのパフォーマンスを毎週確認します。プロンプト編集後のキャッシュ ヒットの突然の低下、スキーマ変更後の遅延の増加、サンプルの削除後の再試行率の上昇を確認してください。最良のシグナルは、トークンの節約と編集の手戻りの両方を捉えるため、受け入れられた出力ごとのコストです。各プロンプト リビジョンの前にこれらの番号を表示しておき、すべての実験に変更の原因となったプロンプト バージョンに注釈を付けます。キャッシュ実験によりコストは削減されるものの、人間による編集が増加する場合は、実験をロールバックして、どの安定した命令が弱体化されたかを検査します。
プロンプト キャッシュの起動前チェックリスト
- 安定したプロンプト ブロックと動的なプロンプト ブロックをマップします。
- 動的コンテキストを再利用可能なプレフィックスの後に移動します。
- キャッシュのヒット率とキャッシュされたトークンの量を追跡します。
- 出力品質のために回帰セットを維持します。
- スキーマまたはサンプルが変更されると、バージョンのプロンプトが表示されます。
- リクエストあたりのコストだけでなく、成功したタスクあたりのコストも比較します。
FAQ: プロンプト キャッシュ
プロンプト キャッシュが価値があるのはどのような場合ですか? 大きなプロンプト プレフィックスが多くの同様のリクエストで再利用され、実行間で変更されない場合。
プロンプト キャッシュを最も頻繁に中断するものは何ですか? 動的メタデータ、取得されたコンテンツ、およびユーザー固有のコンテキストは、安定した命令ブロックの前に配置されます。
Should I shorten the cached prefix? 必ずしもそうとは限りません。安定したプレフィックスを大きくすると、繰り返しの請求が回避され、品質が維持されるため、経済的になります。
結論: プロンプト キャッシュはプレフィックス設計の問題です
プロンプトキャッシュ ワークフローが安定した再利用可能なコンテキストを中心に設計されている場合に機能します。プレフィックスを分離し、キャッシュ ヒットを測定し、回帰テストで品質を保護します。
