OpenAI請求の裏にあるキャッシュミスを見つける
更新日 September 26, 2026 · 初回公開 September 26, 2026
プロンプトキャッシュのダッシュボードは、再利用率が下がったことを教えてくれます。しかし、それだけでは、どのリクエストの変更が低下を招いたのか、またそれにいくらかかったのかは分かりません。OpenAIの2026年9月8日のリリースにより、Prompt Cache DiagnosticsがGPT-5.6以降の対応モデル向けにResponses APIで一般提供となりました。FinOpsとして有効なのは、キャッシュ済みトークンの低下を、短く繰り返し実行できる調査に落とし込むことです。
ミスしたリクエストを比較する
プレフィックスが再利用されると見込んでいた、直近の完了済みレスポンスのIDを保存します。同じ組織からの次の比較可能なResponses APIリクエストで、prompt_cache_options.comparison_response_idにそのIDを設定します。その後、新しいレスポンスのprompt_cache_diagnosticsを、usage.input_tokens_details.cached_tokensと合わせて確認します。比較オプションは診断を要求するだけで、以前の会話を読み込むことも、キャッシュの挙動を変えることもありません。OpenAIの診断ガイドには、動作するリクエスト例が掲載されています。
const next = await client.responses.create({
model: model,
instructions: stableInstructions,
input: nextInput,
tools: stableTools,
prompt_cache_options: { comparison_response_id: baseline.id }
});
console.log(next.prompt_cache_diagnostics);
console.log(next.usage.input_tokens_details.cached_tokens);このスニペットは、baselineが直近の完了済みレスポンスであり、その他の変数が自社のリクエストデータであることを前提としています。キャッシュできるだけの長さの安定したプレフィックスを維持してください。OpenAIは、GPT-5.6以降の最小値を1,024トークンと定めています。小さいプロンプトや大きく異なるプロンプトは、意味のあるキャッシュミスのテストにはなりません。
指標ではなく原因を直す
cache_missの結果は、モデル、サービスティア、ツール定義またはその順序、キャッシュキー、レスポンス形式、推論の工数、冗長度、圧縮されたコンテキストのいずれかの変更を示している可能性があります。たとえば、一見無害なツールスキーマの名前変更でも、再利用可能なプレフィックスが無効になることがあります。リクエスト設定とプロンプトの先頭バイトを比較し、変更が意図しないものだった箇所は安定性を戻して、同じベースラインとの比較をやり直してください。OpenAIは最初に見つかった原因を報告するため、最初の修正後に別の原因が現れることがあります。
変更が意図的なものであれば、ヒットを無理に作る必要はありません。別のモデルは、キャッシュの再利用を失ってもタスク全体のコストを下げることがあります。圧縮は今後のコンテキストを減らせます。キャッシュヒット率だけを単独で見るのではなく、リクエストとタスク全体で判断してください。期限切れのベースラインやunavailableの結果は結論が出せないという意味であり、キャッシュが失敗した証拠ではありません。
発見を金額に換算する
cache_missed_tokensは、比較レスポンスと比べて失われた再利用可能トークンの推定値です。課金トークン数ではありません。同様に、cache_hitの結果もドル単位の削減を裏付けるものではありません。実際の入力コストを求めるには、各レスポンスのinput_tokens、cached_tokens、cache_write_tokensの合計を集め、そのモデルと処理ティアの現行レートを適用します。GPT-5.6以降について、OpenAIのプロンプトキャッシュのガイドは、キャッシュ読み取りがキャッシュなしの入力レートの0.1倍、キャッシュ書き込みがそのレートの1.25倍のコストだと示しています。
ordinary = input_tokens - cached_tokens - cache_write_tokens
weighted_input = ordinary + 0.1 * cached_tokens + 1.25 * cache_write_tokens
input_cost = weighted_input * input_price_per_million / 1_000_000これらは互いに排他的なトークン区分です。すでに書き込みレートで数えたトークンに、キャッシュ書き込みの割増を重ねて加算しないでください。この式は入力のみが対象です。成功したタスクあたりのコストを計算する際は、出力、ツール、リトライ、その他の料金も含めてください。この記事の固定価格ではなく、プロバイダーの最新の料金表を使用してください。
有効な週次チェック
- 比較可能なトラフィックをワークロード、モデル、サービスティアごとにグループ化し、キャッシュ済みトークンの割合と、完了タスクあたりの入力コストをグラフ化します。
- 急な悪化をサンプリングして直近のベースラインと比較し、診断の理由と原因となったコード変更を記録します。
- 意図しないプレフィックスや設定のドリフトを修正します。品質やルーティングの意図的な変更は、タスク全体の経済性が改善するなら維持します。
- 代表的な本番トラフィックで結果を検証し、観測された削減額を請求と突き合わせます。
診断機能そのものに追加の機能料金はありませんが、追加のテストリクエストは通常どおり課金されます。見返りは、見栄えのよいヒット率のグラフではありません。特定のワークロードの入力コストがなぜ変わったのか、そして提案した修正が実際に請求額を下げたのかについて、説明責任を果たせる根拠を得られることです。
チームからよくある質問
キャッシュヒットの診断は、リクエストが安かった証拠になりますか?
いいえ。選択したベースラインと比べてミスが検出されなかったことを示すだけです。節約を主張する前に、実際のcached_tokensとリクエストの課金対象トークン区分を確認してください。
診断は任意の2つのOpenAIリクエストを比較できますか?
いいえ。同じ組織の直近の完了済みベースラインを使用してください。このワークフローは、GPT-5.6以降の対応するResponses APIモデルでのみ利用できます。比較レコードは期限切れになることがあります。
すべてのキャッシュミスをなくすべきですか?
いいえ。モデルの切り替え、別のサービスティア、圧縮されたコンテキストは意図的な場合があります。変更を元に戻す前に、品質、レイテンシ、成功したタスクあたりのコストを比較してください。
関連記事
この方法を自社の環境にも適用しますか? プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 →