OpenAIは、Zero Data Retentionではない組織について、prompt_cache_retentionを指定しない場合の既定値をin_memoryから24hへ変更した。対象モデルや組織設定によって利用可能な保持方式は異なる。

この変更は、コードを変更していないアプリケーションにも影響し得る。キャッシュヒットが増えてコストとレイテンシが改善する可能性がある一方、「省略時は短時間だけ」という運用前提は維持できない。

何が変わったか

Prompt Cachingは、長いプロンプトの共通Prefixを再利用し、再計算を減らす仕組みである。保持方式には短いインメモリ保持と、最大24時間の保持がある。

非ZDR組織では、保持指定を省略したリクエストが24時間保持を使う方向へ変わった。ZDR組織では、既定値や利用可能な方式が異なるため、組織設定と公式ドキュメントを確認する必要がある。

変更前後の差

項目以前の省略時変更後の非ZDR省略時
prompt_cache_retentionin_memory24h
キャッシュ再利用機会比較的短い日をまたぐ処理でも増える
コスト削減余地ワークロード次第定期処理で拡大しやすい
データ保持前提短期メモリを想定最大24時間を前提に評価
運用省略でも従来挙動明示設定が重要

キャッシュはモデル出力を保存する単純なレスポンスキャッシュではない。入力Prefixの再利用に関係するため、どのデータがキャッシュ対象になり得るかを理解する必要がある。

誰に影響するか

  • 数千トークンのSystem Promptを毎回送る
  • 多数のFunction/Tool schemaを共通で送る
  • 法令、マニュアル、ポリシー本文をPrefixとして付ける
  • 日次・時間単位のバッチ処理を行う
  • 顧客別の長いコンテキストを使う
  • ZDR、保持期間、データ所在地を契約要件として管理する
  • キャッシュヒットをFinOps指標へ入れている

短い対話や毎回Prefixが変わる処理では、24時間保持の効果は限定的である。

必要な対応

省略に依存しない。各ワークロードで保持方式を明示し、理由を設定管理へ残す。

public_or_low_sensitivity:
  prompt_cache_retention: 24h

internal_confidential:
  prompt_cache_retention: in_memory

regulated_or_customer_restricted:
  prompt_cache_retention: in_memory
  require_zdr_project: true

実際に選べる値と対象モデルは公式仕様へ合わせる。アプリ側のポリシー名とAPI値を分けると、将来の仕様変更へ対応しやすい。

実装・移行手順

1. 省略箇所を検索する

Responses API、Chat Completions API、SDKラッパー、Gateway、社内共通ライブラリでprompt_cache_retentionが省略されている箇所を特定する。

2. 入力データを分類する

System Prompt、Tool schema、文書、会話履歴、顧客情報、個人情報、秘密情報を分ける。キャッシュ効果だけでなく、保持条件と契約上の制限を確認する。

3. 明示値を設定する

低機密で繰り返しが多いワークロードは24時間を検討し、保持を最小化したいものはインメモリを明示する。ZDRが必要なら、組織・Project設定も合わせて確認する。

4. Prefixを安定化する

キャッシュ効果を得るには、共通部分を前方へ置き、時刻、Request ID、ユーザー固有情報など変化する値を後方へ移す。意味を変えない範囲で構造を安定させる。

5. 可観測性を追加する

レスポンスUsageからキャッシュ済み入力トークンを取得し、モデル・Project・ワークロード別に記録する。生のPromptをFinOpsログへ保存しない。

6. 段階評価する

同一トラフィックの一部で保持方式を比較し、キャッシュヒット率、入力コスト、レイテンシ、品質、データ統制を確認する。

失敗しやすい点

  • 24時間を「必ず24時間残る」と解釈する
  • 顧客間でPrefixを不用意に共有する
  • キャッシュキーだけでデータ分離できると仮定する
  • 効果測定なしで24時間を強制する
  • SDKや社内ラッパーの暗黙値を信頼する

キャッシュミスを前提に性能と費用を設計し、最終HTTPリクエストを確認する。

評価方法

  • キャッシュ済み入力トークン比率
  • リクエスト当たり入力費用
  • P50・P95レイテンシ
  • Prefixハッシュ別のヒット率
  • 24時間設定対象のデータ分類違反件数
  • ZDR Project以外からの規制データ送信件数
  • キャッシュミス時の性能・費用
  • 設定省略リクエスト比率
  • 顧客・環境をまたぐ共通Prefix利用の検査結果
  • 保持方針変更の承認履歴

成功条件は、コスト削減だけでなく、全ワークロードの保持意図が明示されていることである。

ロールバック

24時間保持で問題が見つかった場合、対象ワークロードをin_memoryへ明示変更し、新規リクエストから適用する。高機密データが誤って送信された場合は、通常の設定ロールバックだけで完了としない。

  1. 対象Projectと期間を特定する
  2. 送信データの分類と件数を確認する
  3. 24時間設定または省略を停止する
  4. 法務・セキュリティのインシデント手順を実行する
  5. 必要に応じてOpenAIサポートへ確認する
  6. 再発防止として明示値とCI検査を追加する

編集部分析

今回の変更は、性能最適化機能の既定値変更であると同時に、データ保持に関する運用前提の変更である。コスト改善と統制強化を同時に達成するには、保持値をアプリ開発者の自由な最適化パラメータとして扱わず、データ分類ポリシーへ組み込む必要がある。

既定値は将来も変わり得る。重要なデータ取扱いを「省略時の現在値」へ依存させる設計は弱い。保持方式、ZDR要否、対象Projectをコードまたはポリシーで明示し、CIで検証する方がよい。

また、キャッシュ効果はPrompt設計の安定性を可視化する指標にもなる。ヒット率が低い場合、単なるコスト問題ではなく、System PromptやTool schemaが無秩序に変化している可能性がある。

実務チェックリスト

  • [ ] prompt_cache_retention省略箇所を特定した
  • [ ] 対象モデルと組織のZDR状態を確認した
  • [ ] 入力データを機密度別に分類した
  • [ ] 保持方式をワークロードごとに明示した
  • [ ] 顧客固有情報を共通Prefixから分離した
  • [ ] Usageからキャッシュヒットを記録した
  • [ ] キャッシュミス時の費用と性能を試験した
  • [ ] 設定省略をCIまたはGatewayで検出した
  • [ ] インシデント時の対象Project特定手順を作った
  • [ ] 方針を法務・セキュリティ・FinOpsで合意した

一次情報