GPT-6 Astra プロンプトキャッシングガイド：繰り返しのコンテキストコストを削減する方法
GPT-6 Astraのプロンプトキャッシングの仕組み、再利用可能なプレフィックスの構造化方法、キャッシュブレークポイントの配置、ヒットの測定、高コストなキャッシュミスの回避方法について学びます。
大規模なエージェントプロンプトは、同じシステムポリシー、ツール定義、製品ドキュメント、例、会話履歴を繰り返し含むことがよくあります。そのような素材を再送信することが避けられない場合もありますが、同一のプレフィックスに対して完全な入力コストとレイテンシを支払う必要はありません。GPT-6 AstraはResponses APIでプロンプトキャッシングをサポートしており、繰り返されるプレフィックスを再利用できます。
キャッシュは最適化であり、メモリではありません。モデルがリクエスト間で顧客を記憶するわけでも、モデルが見る内容を変えるわけでもありません。リクエストには依然として関連する入力が必要です。違いは、対象となる同一のプレフィックスがキャッシュからより低いキャッシュ入力レートで提供される可能性があることです。
GPT-6 Astraがキャッシュするもの
キャッシュはプレフィックスベースです。OpenAIは、次のリクエストが一致するコンテンツで始まる場合、プロンプトの先頭からトークンを再利用できます。便利なメンタルモデルは、安定した章が最初にあり、リクエスト固有の付録が最後にあるドキュメントです。
これらを前面の近くに置いてください：
- 安定した開発者向けの指示;
- 安定した順序でのツールスキーマ；
- 複数のリクエストで使用される長い参照文書；
- 正規の例と出力ルール。
これらを最後の方に置いてください：
- 現在のユーザーメッセージ；
- タイムスタンプ、リクエストID、一時的な状態;
- 呼び出しごとに変わる取得されたパッセージ；
- ユーザーごとの共有されない設定。
上部付近に挿入された1つのタイムスタンプが、それ以降のすべてを無効にする可能性があります。同様に、順序付けされていないマップからツール配列を生成すると、意味的には同一だがバイト列が異なるプレフィックスが生成される可能性があります。プロンプトは決定論的に構築してください。
暗黙的および明示的キャッシュ
GPT-5.6以降のモデルでは、prompt_cache_optionsが公開されています。暗黙モードでは、サービスが再利用可能なブレークポイントを自動的に識別します。これは最も簡単な開始点であり、プロンプトに1つの大きな安定したプレフィックスがある場合に適しています。
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({ model: "gpt-6-astra", prompt_cache_key: "support-agent:v4", prompt_cache_options: { mode: "implicit", ttl: "30m" }, 入力: [ { role: "developer", content: "安定したポリシーと運用指示..." }, { role: "user", content: "なぜ請求書が重複したのですか？" } ] });
現在文書化されているTTL値は`30m`で、30分がデフォルトです。文書化されていない時間を前提に設計しないでください。OpenAIは、古い`prompt_cache_retention`フィールドを非推奨としてマークしています。
明示モードでは、アプリケーションがより細かく制御できるようになります。保存する価値のある境界に `prompt_cache_breakpoint` コンテンツアイテムを追加します。これは、プロンプトが複数の安定したブロックとその後に続く変動する素材から構成される場合に便利です。リクエストは最大4つのブレークポイントを書き込むことができ、サービスは最新の80個までのブレークポイントを考慮します。ブレークポイントの数が多いほど自動的に良いわけではありません。各書き込みにはコストがかかり、断片化されたプレフィックスは理解しにくくなる可能性があります。
## 実用的なプレフィックスアーキテクチャ
プロダクションエージェントの場合は、4つのレイヤーを使用します。
### 1. アイデンティティと安全性
耐久ロール、安全制約、応答契約を最初に配置する。このブロックは意図的にバージョン管理する。ポリシー編集は、2つのバージョンの測定値を暗黙的に混在させるのではなく、新しいキャッシュキーを作成する必要がある。
### 2. ツール定義
ツールスキーマはしばしば大きく、繰り返し使用されます。名前、説明、プロパティ、順序は安定させてください。可能な限り未使用のツールは削除してください。これにより、キャッシュされていないコンテキストとキャッシュされたコンテキストの両方が減少し、ツール選択のあいまいさが軽減されます。
### 3. 共有知識
耐久性のあるマニュアル、分類体系、スタイルガイド、製品ドキュメントを追加してください。知識が頻繁に変更される場合は、すべてのプロンプトに埋め込むよりもファイル検索の方が適している場合があります。安定した運用知識をキャッシュし、変化する事実を取得します。
### 4. 動的リクエスト状態
ユーザー入力、現在のレコード、ライブ検索結果、一時的な状態を追加します。この配置により、再利用可能なプレフィックスが日常的な変更から保護されます。
クリエイティブなワークフローにおいて、安定層にはアニメーション制作ルールやハウススタイルが含まれ、動的テールには現在のシーンが含まれます。[Elser AI](https://www.elser.ai/)のようなプラットフォームは、キャッシュ自体が一貫性を生み出すことを示唆することなく、繰り返し使用されるストーリーバイブルやキャラクターの一貫性コンテキストに同じ原則を適用できます。
## 節約額を想定するのではなく、実際に測定する
`usage.input_tokens_details.cached_tokens` と `cache_write_tokens` を確認してください。キャッシュされたトークン数が多い場合は、プレフィックスの一部が再利用されたことを示しています。キャッシュ書き込みトークンは、エントリの作成や更新にかかるコストを示します。
GPT-6 Astraにおいて、検証日時点で公開されているモデル価格では、キャッシュ入力は通常入力より低く、キャッシュ書き込みは通常入力より高く設定されています。これにより損益分岐点の問題が生じます。繰り返し再利用されるプレフィックスはコストを節約できますが、一度書き込まれて再利用されないプレフィックスはコストが増加する可能性があります。価格は変動するため、計画のスプレッドシートに数値を固定するのではなく、最新のモデルページで計算してください。
最低でもトラック：
- プロンプトバージョン別のキャッシュヒット率;
- キャッシュ済み、書き込まれた、および合計入力トークン。
- 最初のトークンまでのp50およびp95時間;
- 完了したタスクごとのコストであり、単なるリクエストごとのコストではありません。
- リリースによるキャッシュミス。
モデルだけでグループ化されたダッシュボードでは、ミスの原因が隠れてしまいます。独自のテレメトリにキャッシュキーやプロンプトバージョンのディメンションを含めてください。ただし、キャッシュキーに個人データや秘密情報を入れないでください。
## キャッシュミスのよくある7つの原因
### 動的コンテンツが早すぎるタイミングで表示される
再利用可能なコンテンツの後に、日付、ユーザーID、取得した資料を移動します。
### ツールスキーマの変更順序
アプリケーションのビルドステップで、ツールとスキーマプロパティを決定論的にソートします。
### プロンプトは「同等」ですが、同一ではありません
空白、例、またはシリアライゼーションが異なる場合があります。アドホックな文字列ではなく、バージョン管理された成果物から共有ブロックを生成してください。
### プレフィックスが短すぎます
キャッシュ可能な最小長さはモデルによって異なります。非常に短いプロンプトでは効果が得られない場合があります。使用データで確認してください。
### コンパクションがプレフィックスを変更しました
コンパクションは長い会話を収めるのに役立ちますが、異なるコンテキスト表現を生成します。コンパクション後に再利用パターンが変化することを想定し、マイルストーンの境界付近で測定してください。
### 低価値のブレークポイントが多すぎる
ブレークポイントは、意味のある再利用可能なレイヤーに対応する必要があります。許可される4つの書き込みは上限であり、目標ではありません。
### キャッシュキーが広すぎるか狭すぎる
無関係なワークフローごとに1つのキーを使用すると、グループ化が弱くなります。リクエストごとに一意のキーを使用すると再利用が妨げられます。`legal-review:v3:us` のような意味のあるキーを使用することを推奨します。
## 安全なロールアウト計画
1つの高ボリュームワークフローで暗黙モードから始めます。プロンプト構築を安定させ、トークン詳細を記録し、2週間のコストとレイテンシを比較します。その後、プロンプトに複数の再利用可能なレイヤーや頻繁な動的テールがある場合は、明示的なブレークポイントを検討します。品質を節約とともに評価します。コンテキストの積極的な削除はキャッシングではなく、回答品質を低下させる可能性があります。
APIに送信することが既に許可されているコンテンツのみをキャッシュしてください。キャッシュは、データ分類、テナント分離、アクセス制御、または保持ポリシーの決定を代替するものではありません。ツールがリアルタイムで取得できる場合は、プロンプトに機密情報を含めないでください。
## FAQ
### プロンプトキャッシュは出力トークンのコストを削減しますか？
いいえ。対象となるのは、該当する繰り返し入力です。出力は通常通り生成され、出力レートで課金されます。
### `previous_response_id` によって以前のターンが無料になりますか？
いいえ。OpenAIは、応答チェーン内の初期の入力トークンは依然として入力として課金されると述べています。プロンプトキャッシングにより、対象となる繰り返しプレフィックスのコストが削減される可能性がありますが、会話チェーンとキャッシングは別のメカニズムです。
### 取得した検索結果をキャッシュすべきですか？
安定し、実際に再利用される場合に限ります。ライブ結果は通常、動的テールに属します。管理されたコーパスの場合、ファイル検索により、すべてのプロンプトにコレクション全体を埋め込むことを回避できます。
### キャッシュヒットは信頼できますか？
キャッシュは機会主義的な最適化として扱ってください。ミスが発生してもアプリケーションが正しく動作し続ける必要があります。
## 結論
最高価値のGPT-6 Astraキャッシング戦略はアーキテクチャ上のものです。安定した指示とツールを最初に、揮発性の状態を最後に、決定的なシリアライゼーション、意図的なバージョン管理、そしてトークン詳細による測定です。暗黙的なキャッシングから始め、データがそれを支持する場合にのみ明示的なブレークポイントを追加し、成功したタスクあたりのコストを最適化し、単なる追及はしないでください。
