先に要点
- GPT-5.5で Prompt Caching を効かせたいなら、基本は static parts first, dynamic parts last です。
- キャッシュが見るのは全文一致ではなく、先頭 prefix の一致です。後ろが毎回変わっても、前半が同じなら効く余地があります。
- 前に置きたいのは、system instructions、共通ルール、例、tool 定義、Structured Outputs の schema です。
- 後ろに寄せたいのは、ユーザー入力、検索結果、会話ごとの個別文脈、現在値、ユーザー固有データです。
プロンプトキャッシュとは？ の記事では、キャッシュがコストと速度に効く仕組みを広く整理しました。
今回はそこから一歩進めて、GPT-5.5で本当に効く並べ方はどう作るのか を実務寄りに見ます。
- Prompt Caching を前提にした設計
- Responses API の利用
- プロンプトから schema を外して Structured Outputs へ寄せる
をかなり強く勧めています。
つまり、長いプロンプトを送ってもキャッシュがあるから大丈夫 ではなく、長いなら長いなりに、どこを固定 prefix にするか が大事です。
まず前提: キャッシュは「先頭が同じか」で決まる
OpenAI公式の Prompt Caching ガイドで一番大事なのはここです。
キャッシュヒットは、exact prefix matches、つまり先頭部分の一致が前提です。
言い換えると、
- 前半が毎回同じ
- 後半だけ変わる
構造ならキャッシュが効きやすくなります。
逆に、
- 冒頭に現在時刻を入れる
- 冒頭に毎回違うユーザーIDを入れる
- 冒頭に検索結果を差し込む
ような設計だと、長い共通 instructions が後ろにあってもヒットしにくくなります。
GPT-5.5で特に意識したい理由
OpenAIの最新モデルガイドでは、GPT-5.5移行時の見直し項目として Prompt Caching が明示されています。
しかも GPT-5.5 では、キャッシュ設計が単なる節約術ではなく、通常の設計論の一部になっています。
理由は3つあります。
1. GPT-5.5は長い実務プロンプトで使われやすい
GPT-5.5 は
- coding
- tool-heavy agents
- long-context retrieval
- customer-facing workflows
のような、そもそも共通 prefix が長くなりやすい場面で使われます。
このタイプのワークロードでは、
- system prompt
- 共通方針
- role 指示
- tool descriptions
- output schema
が毎回長くなりがちです。
だからこそ、キャッシュが効く設計かどうかで差が出ます。
2. GPT-5.5は extended prompt cache retention の対象
OpenAI公式によると、gpt-5.5 と gpt-5.5-pro は extended prompt cache retention に対応しています。
しかもデフォルトは 24h で、in_memory はサポートされません。
つまり GPT-5.5 では、短時間だけの一時キャッシュというより、共通 prefix をちゃんと安定させれば、より長くヒットを狙える 前提で設計しやすいです。
3. Responses API との相性がよい
Responses APIの記事でも触れた通り、GPT-5.5 の本命は Responses API 側です。
Responses API では prompt_cache_key、prompt_cache_retention、usage.prompt_tokens_details.cached_tokens など、観測と調整の軸を持ちやすくなっています。
何を前に置くべきか
OpenAI公式は、static or repeated content at the beginning を勧めています。
GPT-5.5 で前に寄せたいのは、だいたい次の要素です。
| 前に置くもの | 理由 |
|---|---|
| system instructions | 毎回ほぼ同じなら、いちばん大きい共通 prefix になりやすい |
| 共通の出力方針 | 語調、禁止事項、成果物条件などはリクエストごとに変わりにくい |
| tool definitions | 同じ tools を繰り返し使うなら prefix にしやすい |
| Structured Outputs の schema | schema 自体が prefix としてキャッシュ対象になる |
| 共通 examples | 毎回同じ few-shot が必要なら前に寄せた方がよい |
要するに、誰に対しても同じ説明 はできるだけ前です。
何を後ろに置くべきか
一方で、変わるものは後ろへ寄せます。
このあたりは、毎回違うほど prefix を壊しやすいです。
特に GPT-5.5 移行では、OpenAI公式が Drop the current date とまで書いています。
モデルは UTC の current date を把握しているので、業務上どうしても必要でない限り、毎回 system prompt 冒頭に日付を入れる必要はありません。
これはキャッシュの観点でもかなり重要です。
ありがちな悪い並べ方
キャッシュが効きにくい例は、次のようなものです。
1. system prompt の先頭に可変情報を入れる
例えば、
- 今日の日付
- 顧客ID
- 案件名
- セッションID
を system prompt の先頭に差し込んでしまうケースです。
これをやると、後ろにどれだけ立派な共通 instructions を積んでも、prefix が毎回変わります。
2. tools を毎回違う順番で並べる
OpenAI公式は、tools もキャッシュ対象に入ると説明しています。
ということは、同じ tools でも
- 順番が違う
- description が少しずつ違う
- 未使用 tool をその場で足したり引いたりする
と、prefix 一致を壊しやすいです。
3. schema を会話ごとに細かく変える
Structured Outputsの記事 でも触れた通り、schema は API 側で持つ方が筋がいいです。
ただし、毎リクエストごとに schema を少しずつ変えると、その schema 自体が prefix の差分になります。
だいたい同じ出力なのに key 名だけ少し違う といった設計は、キャッシュ効率の面では不利です。
GPT-5.5でのおすすめ分離パターン
GPT-5.5 で一番素直なのは、次の3層に分ける考え方です。
1. 固定 prefix 層
- system instructions
- 共通ポリシー
- tool definitions
- schema
- 固定 examples
ここは、なるべく変更頻度を下げます。
2. セッション共通層
- その会話でだけ使う背景情報
- その案件でだけ使う資料
- そのユーザー群でだけ使う条件
ここは固定 prefix ほどではないけれど、同じセッション内ではなるべく安定させる部分です。
3. リクエスト固有層
- 今回の質問
- 今回の検索結果
- 今回の取得ログ
- 今回のファイル抜粋
これは最後に置きます。
この3層構造にしておくと、何がキャッシュを壊しているか を切り分けやすくなります。
prompt_cache_key はいつ使うべきか
OpenAI公式によると、prompt_cache_key は prefix hash と組み合わせて routing を改善するためのパラメータです。
特に、長い共通 prefix を持つリクエストが多いときに有効です。
ただし、ここも雑に一つの key に寄せればいいわけではありません。
公式は、各 prefix + prompt_cache_key の組み合わせが 15 req/min 程度を超えると overflow で効率が落ちることがある と書いています。
なので実務では、
くらいの粒度から始めるのが分かりやすいです。
細かすぎると共通性が消え、粗すぎると overflow しやすくなります。
効いているかはどう見るのか
設計しただけでは意味がありません。
見るべきなのは usage.prompt_tokens_details.cached_tokens です。
ここを見れば、
- どのくらい prefix がヒットしているか
- 変更後に cached_tokens が増えたか
- latency が下がったか
を確認できます。
OpenAI公式も、cache hit rate、latency、cached token counts を監視することを勧めています。
実務での設計ルール
最後に、GPT-5.5 で Prompt Caching を効かせたいときの実務ルールを短くまとめます。
- 先頭に固定情報、末尾に可変情報を置く
- 現在日時やユーザーIDを system prompt 冒頭へ入れない
- tool 定義は順番・文言を安定させる
- schema はむやみに揺らさず、共通化できるなら共通化する
- 共通 prefix が長いフローでは
prompt_cache_keyを検討する cached_tokensをログに出し、効いているか観測する
要するに、GPT-5.5での Prompt Caching 設計は、長い instructions を送ること ではなく、長い固定 prefix を安定して保つこと です。
そこができると、コストだけでなく応答体感もかなり変わってきます。
この記事と一緒に読みたい
- プロンプトキャッシュとは？AI APIのコストと応答速度に効く理由
- GPT-5.5移行でプロンプトはそのままでいい？OpenAI公式ガイドで見る見直しポイント
- OpenAIのResponses APIとは？Chat Completionsからいつ移るべきか
- Structured Outputsとは？JSON modeと何が違うのか
参考リンク
- OpenAI Developers: Prompt caching
- OpenAI Developers: Using GPT-5.5
- OpenAI Developers: Migrate to the Responses API