エージェント型のアプリケーションや複数ターンにわたるアプリケーションでは、新しいアクションや指示を常にモデルのコンテキストの末尾に追加し、API リクエストをまたいで推論を保持することで、モデルの性能を最大限に引き出せます。プレフィックスをそのまま保つことは、プロンプトキャッシュを活用する方法として以前から推奨されています。キャッシュはリクエストを先頭から照合するため、プレフィックスを編集すると、その箇所以降のキャッシュが再利用できなくなることがあります。変更内容を末尾に追加すれば、会話のより広い範囲でキャッシュを再利用でき、入力コストの大幅な削減とレスポンスの高速化が期待できます。
新しい世代のフロンティアモデルでは、プレフィックスを編集すると、API は編集箇所より後にある推論アイテムを破棄します。推論アイテムが破棄されると、モデルは推論の一部をやり直す必要が生じ、トークン使用量やコストが増え、レイテンシが高くなることがあります。失われた推論をモデルが復元できない場合は、出力品質も低下することがあります。
モデルの性能を最大限に引き出すには、プレフィックスを変更せず、できる限り新しい内容を末尾に追加するだけの実装を推奨します。
プレフィックスの変更とは
推論アイテムのプレフィックスとは、そのアイテムより前の会話履歴のことです。たとえば、ツールの実行結果を短くする、開発者メッセージを書き換える、過去のターンを要約に置き換えるなど、この履歴に手を加えると、プレフィックスが変わります。
| Original conversation | Next request and API handling |
|---|---|
| User messageCheck the ledger total. | Same message |
| Reasoning before the tool call | Reusable |
Tool calllookup_ledger() | Same call |
Tool result[{"amount": 40}, {"amount": 50}] | Same rows |
| Reasoning after the tool result | Reusable |
プレフィックスを変更しない実装への移行
Responses API の tools、instructions、text.format などのパラメーターを更新したり、以前の input アイテムを編集したりすると、意図せずプレフィックスが変わることがあります。アプリの実装にこうした変更がないか確認してください。
次の表に、アプリがプレフィックスを変更する代表的なケースと、可能な限りコンテキストの末尾への追加で同じ目的を達成する方法を示します。
| プレフィックスが変わる主なケース | プレフィックスの変更を避ける方法 |
|---|---|
| 推論強度の変更 | Responses API の reasoning.effort パラメーターは変更せず、新しい推論強度を指定した configuration_update アイテムを入力アイテムのリストの末尾に追加します。リクエストレベルの設定は元の値のままにしてください。 |
| 構造化出力のスキーマの変更 | Responses API の text.format パラメーターは変更せず、新しいスキーマを指定した configuration_update アイテムを入力アイテムのリストの末尾に追加します。リクエストレベルの設定は元の値のままにしてください。 |
| エージェントが利用できるツールの変更 | Responses API の tools パラメーターは変更せず、ツールを追加するには additional_tools アイテムを使います。あるターンでモデルが呼び出せるツールを制限するには、tool_choice で allowed_tools を指定します。既存のツール定義は元の順序で保持してください。additional_tools を末尾に追加する際は、ロールに developer を指定し、tools 配列を含めます。このアイテムを再送する際は、履歴内の元の位置に置いてください。 |
| 開発者の指示の更新 | 元の開発者メッセージは編集せず、新しい developer メッセージを末尾に追加し、以前の指示を無視して新しい指示に従うようモデルに伝えます。特定のターンだけに適用する指示の場合は、最新の開発者メッセージの直前に明示的なキャッシュブレークポイントを置きます。これにより、そのメッセージの直前までが再利用可能なプレフィックスになります。 |
| コンパクション | コンパクションを行うとプレフィックスが変わるため、キャッシュミスを避けるのは困難です。 OpenAI のコンパクション：OpenAI のコンパクションを /responses/compact または context_management 経由で使用すると、プレフィックスが変更されても、OpenAI のシステムは変更箇所より後の推論アイテムを保持します。OpenAI のコンパクションアイテムはコンテキスト内のどの位置にも配置できます。/responses/compact を呼び出す際は instructions を省略し、返されたコンテキストウィンドウを元の順序のまま次のリクエストに渡してください。履歴に configuration_update アイテムが含まれる場合は、設定更新時のコンパクションの要件に従ってください。カスタムコンパクション：独自の方式など、別の方法でコンパクションを行う場合は、処理後のアイテムを直近のターンの前ではなく、モデルのコンテキストの末尾に置いてください。直近のターンの前に置くこともできますが、その場合は、その位置より後にある元の履歴の推論アイテムが破棄されます。 |
| 過去のツール出力の短縮や、送信済みファイル・画像のサイズ削減 | アプリによっては、コンパクションを使わず、過去のツール出力、ファイル、画像などの一部を切り詰めます。こうした変更を加えると、プレフィックスが変わります。コンパクションを使用するか、モデルに初めて送信する前に長いツール出力を短くし、画像やファイルのサイズを小さくすることを強く推奨します。 |
プレフィックスの変更箇所の確認
プロンプトキャッシュ診断では、キャッシュミスが発生するタイミングを確認し、プレフィックスの変更箇所を調べられます。リクエストを以前のレスポンスと比較するには、prompt_cache_options.comparison_response_id にそのレスポンスの ID を設定し、診断結果に示された理由とキャッシュされたトークン数を確認してください。この情報をもとに、アプリがプレフィックスを編集する箇所を減らせます。診断では、検出できた範囲で最初の差異が報告されます。モデルが推論を再利用したかどうかは確認できません。