Responses API の Prompt Cache Diagnostics が GA、キャッシュミスの理由が公式に見えるようになった

要約

OpenAI は 2026-09-08、**Prompt Cache Diagnostics を Responses API で一般提供（GA）**にしました。対象は GPT-5.6 以降のサポート対象モデルです。

この機能がやることは明快です。あるレスポンスのキャッシュ再利用状況を、直前のレスポンスと比較する。そのうえで、キャッシュミスが起きた理由を提示し、再利用率を上げるためのトラブルシューティング手順を案内します。

なぜこれが必要だったかは、プロンプトキャッシュの仕組みを思い出すと分かります。キャッシュは、リクエストの先頭部分（プレフィックス）が前回と一致していれば、その処理結果を再利用して入力コストを大幅に下げる仕組みです。しかし一致の条件は厳密で、モデルが同じであること、プレフィックスが完全に一致していること、有効期限内であること、といった条件のどれか1つでも崩れるとミスになります。

問題は、ミスしたときにアプリケーション側から理由が見えなかったことです。キャッシュヒット率が落ちたとき、開発者にできるのは「システムプロンプトにタイムスタンプが混ざっているのでは」「ツール定義の順序が変わったのでは」と当たりをつけて、1つずつ潰していく作業でした。今回の GA は、その推測作業を公式の診断機能に置き換えるものです。

なお、これはプレビューではなく GA である点も実務上は重要です。本番環境の運用手順に組み込んで構わない、という位置づけになりました。

何が変わったか

• Prompt Cache Diagnostics が Responses API で GA（プレビューではない）
• 対象は GPT-5.6 以降のサポート対象モデル
• 直前のレスポンスとキャッシュ再利用状況を比較できる
• キャッシュミスの理由が提示される
• 再利用率を上げるためのトラブルシューティング手順が案内される

業務インパクト（一般企業向け）

これは機能追加というより、コスト管理の作業手順が変わる話です。

LLM を組み込んだアプリケーションの運用コストのうち、入力トークンが占める割合は、エージェント型・長文脈型になるほど大きくなります。会話が伸びるにつれてプレフィックスが積み上がり、毎ターンそれを再送するためです。キャッシュが効いているかどうかで、同じ機能の月額が数倍変わることも珍しくありません。

にもかかわらず、これまでキャッシュ効率の改善は属人的な作業でした。ヒット率が悪いと分かっても、原因の切り分けにはプロンプト構築のコードを読み解く必要があり、担当者の勘と経験に依存していました。診断が公式機能になったことで、この作業は手順書に落とせます。「ヒット率が閾値を下回ったら診断を取り、示された理由に対処する」という運用フローが組めます。

**監視項目としての位置づけも変わります。**キャッシュヒット率を SLO や運用ダッシュボードの項目に入れている組織は少ないはずですが、診断でミス理由まで取れるなら、コスト異常の一次切り分けに使える指標になります。月次のコストが跳ねたとき、トラフィック増なのかキャッシュ効率の劣化なのかを、請求書を眺める前に判別できます。

**対象が GPT-5.6 以降である点は確認が要ります。**それ以前のモデルを本番で使い続けている構成では、この診断は使えません。旧モデルに留まっている理由が「動いているから」であれば、コスト最適化の手段が増えたことは移行を検討する材料になります。逆に、検証コストを理由に移行を見送るなら、キャッシュ効率の改善は従来どおり手作業で行うことになる、という前提を明示しておくべきです。

**リリース作業への影響も見ておいてください。**プロンプトやツール定義を変更するデプロイは、キャッシュのプレフィックスを壊します。デプロイ直後にコストが一時的に上がるのは正常な挙動ですが、それが恒久的な劣化になっていないかを、次のリリースまでに診断で確認する運用にすると、変更が意図せずキャッシュを壊し続ける事故を防げます。

副業・個人活用視点

個人開発では、この診断は「請求書が怖くなくなる機能」として効きます。

副業や個人開発で API を叩く場合、月額の上限は自分の財布です。エージェント的なものを組んで動かしてみたら想定より請求が伸びていた、という経験は多くの人が通ります。その原因の相当部分はキャッシュが効いていないことで、しかもそれは動作としては正常なので、エラーもログも出ません。気づく手段がなかったのが従来です。

診断が使えるなら、**個人開発でも「作ったら一度診断を取る」を習慣にする価値があります。**特に、システムプロンプトに現在時刻を入れている、リクエストごとにセッション ID を差し込んでいる、といった構成は、それ自体は自然な実装ですが、キャッシュの観点では毎回プレフィックスを壊します。指摘されなければ気づきにくい類のミスで、まさに診断が向いている領域です。

受託や小規模開発の提案材料としても使えます。「コスト最適化をやります」という提案は、根拠を示しにくいものです。診断でミス理由を出し、対処前後のヒット率を並べれば、削減額の説明が数字で成立します。工数の見積もりも、勘での調査ではなく診断ベースの手順として組めるため、外しにくくなります。

一点、**この機能はコストを下げてくれるわけではありません。**下げるべき場所を教えてくれるだけです。診断を取っただけで満足せず、示された理由に沿ってプロンプトの組み立て順を直すところまでが作業です。「静的な部分を先に、変動する部分を後ろに」という原則を守るだけで、多くのケースは改善します。