GPT-6 プロンプトキャッシュで入力代を90%削る

OpenAI が2026年9月22日に「Better prompt caching for GPT-6」を公開し、GPT-6 世代のプロンプトキャッシュと、開発者が触れる制御が一気に増えました。API 代が読めなくて困っている現場ほど効く更新なので、何を見て何を直すかの順に整理します。

結論：キャッシュ済み入力は最大90%引き・窓は30分

OpenAI は GPT-6 世代で「キャッシュされた入力トークンに最大90%の割引」を出しており、再利用できる共通 prefix の有効期間は30分です（公式発表の原文は "discounts of up to 90% on cached input tokens" / "reused within a 30-minute window"）。しかも GPT-6 ファミリーでは既定でヒット率が上がる改良版が動いているので、何も設定しなくても前より安くなる余地があります。

実額では、gpt-6-sol の標準料金は入力 $2.00／キャッシュ済み入力 $0.20（100万トークンあたり）。読み直しは通常入力の0.1倍です。後述の試算では、入力2万トークンを1日500回叩く社内アシスタントで入力代が月 $600 → 約 $61（1ドル150円の仮定で約8万円減）になりました。

ただし条件があります。効くのは「入力の前方（prefix）が毎回同じ処理」だけで、1回だけの生成や毎回違う文章を投げる使い方には効きません。ここを誤解して「キャッシュで安くなるらしい」と期待すると、請求額は1円も変わりません。

効くのは「前方が毎回同じ処理」だけ

プロンプトキャッシュは、モデルが入力を読むときに作る中間状態（KV states）を、先頭から変わっていない部分＝prefix についてだけ保存して再利用する仕組みです。公式ガイドは「Cache reuse requires the entire rendered prefix to match（レンダリング後の prefix が丸ごと一致する必要がある）」と明記しています。

効くのは、同じ社内規程・判定ルール・ツール定義を毎回頭に置いて後ろだけ差し替える処理です。社内問い合わせボット、書類チェック、AIによる採点・分類、エージェントの多ターン対話はここに入ります。逆に、一度きりの原稿生成や毎回別の資料を丸ごと読ませる要約には効きません。

なお prefix には最低の長さがあります。GPT-5.6 以降は可視入力1,024トークンが最小キャッシュ長で、届かない共通部分は対象外です。共通指示が短すぎる場合、安定した参照資料を足して伸ばしたほうが安くなることもあります。

新しく使える4つ：何を見て、何を直すか

増えたのは4つで、順番が大事です。まず現状を見る（①②）、そのうえで直す（③④）。いきなり breakpoint を置くと、効いていなかった本当の原因を見落とします。

① Prompt Caching Dashboard：いまどれだけ効いているか

入力のどれだけがキャッシュから出ているか、ヒット率の推移と構成比を見る画面です。まず自社のヒット率を数字で押さえる。0%に近いなら設計の話、70%あるなら微調整の話で、やることが変わります。コードから測るなら usage.input_tokens_details.cached_tokens と cache_write_tokens を記録し、キャッシュ済み÷総入力で出します。公式ガイドは判定用途の実装例で約70%、多ターンエージェントで90%超を「起こりうる一例」として挙げています。

② diagnostics：ミスの理由が reason で返る

今回いちばん実務を変える機能です。prompt_cache_options.comparison_response_id に比較したい過去のレスポンス ID を渡すと、なぜ再利用できなかったかが理由付きで返ります。ツール名を get_time から get_date に変えただけで外したときの実レスポンスが公式に載っています。

{"prompt_cache_diagnostics":{"type":"cache_miss","reason":"tools_changed","comparison_reusable_tokens":5629,"cache_missed_tokens":5629}}

reason は tools_changed / model_changed / input_changed / text_format_changed / reasoning_effort_changed / verbosity_changed / context_compacted / prompt_cache_key_changed / service_tier_changed が返ります。追加費用なし・レート制限にも別カウントされないので入れっぱなしで構いません。ただし返るのは最初に分類された1件だけなので、直したら比較し直して次の原因を探す反復になります。

③ explicit cache breakpoints：どこまで再利用するか決める

GPT-5.6 以降は prompt_cache_options.mode を explicit にし、再利用したいブロックの末尾に prompt_cache_breakpoint を置けます。安定した部分だけ書き込み、毎回変わる後ろは書き込まない指定ができるので、無駄な書き込み料を払わずに済みます（書き込みは1リクエスト最大4か所）。既定の implicit は直近の対象メッセージ末尾に自動で区切るため、多ターン会話を素直に追記する作りならこれで十分。後ろが毎回捨てられる内容だと explicit が得という使い分けです。

④ prewarming：待ち時間から前処理を外す

prompt_cache_options.prewarm を true にしたリクエストで、出力を生成せずキャッシュだけ温められます。起動時に共通指示・ツール定義・参照資料を温めておけば、最初の質問の待ち時間からその分が消えます。ただしprewarm で書き込まれたトークンも通常の書き込み料金で課金されます。誰も使わない時間帯に温め続けると削ったつもりの費用が書き込み料に化けるので、営業開始前の1回に留めてください。

キャッシュを壊す代表パターン

ヒット率が上がらない理由は、ほぼこの表のどれかです（公式の診断リファレンスの reason と対応）。

この表から Mihata が設計則として推すのは1つだけです。可変の値は必ず後ろに置く。日付・ユーザー名・セッションID を「文脈として先に書いたほうが精度が上がりそう」という感覚で冒頭に置くのは、キャッシュの観点では最悪手です。1文字変わるだけでその後ろ全部が再利用できなくなります。逆に言えば「変わらないもの→変わるもの」の順に並べ直すだけで、コード構造を変えずにヒット率が動きます。既存アプリの改善はここから入るのが安くて速い。パラメータ整理を含む移行の勘所はGPT-6 Astra へのAPI移行で消すパラメータにまとめています。

守り方を実務の手順に落とす

1. 共通指示と参照資料を先頭に固め、可変の値を後ろへ動かす。「安定した developer メッセージ → 可変の developer メッセージ → ユーザーの質問」の3段にする。
2. ツール定義は消さない。使わせたくないだけなら tool_choice: "none"、一部だけ許すなら allowed_tools。定義リストは触らない。
3. 新しい指示は末尾に developer message として追記する。既存の指示文を書き換えず、後ろに足して古い指示を上書きする。過去ターンも編集せず追記。
4. 推論の強さは configuration_update で変える。GPT-6 系なら入力の末尾に {"type":"configuration_update","reasoning":{"effort":"high"}} を追記する形で、会話の途中で reasoning effort を変えてもキャッシュが壊れません（リクエスト直下の reasoning.effort は触らないのが条件）。
5. diagnostics で確かめる。直したら代表リクエストを1本流し、reason が消えたか・cached_tokens が増えたかを見る。

中小企業の現場なら全部やる必要はありません。①と②だけで大半のコスト差がつきます。③④は「同時に何十セッションも動く」「起動直後の待ち時間がクレームになっている」段階で考えれば十分です。

試算：入力2万トークン×1日500回で月いくら違うか

前方が毎回同じ2万トークン（社内規程とツール定義）で、後ろだけ質問が変わる社内アシスタントを想定します。1日500回・月30日＝15,000リクエスト。単価は公式料金表の短コンテキスト帯・標準処理（2026年9月24日時点の実数）で、出力トークンを含めない入力だけの比較。キャッシュ有りは「1日1回書き込み、残り499回は読み」という控えめな前提です。

gpt-6-sol の中身は、キャッシュなしが 15,000回×2万＝3億トークン×$2.00÷100万＝$600。キャッシュありは書き込み30回分 $1.50＋読み14,970回分 $59.88＝$61.38 です。円換算は1ドル150円という仮定で、実際は為替と請求レートで動きます。

注目してほしいのは削減額より、モデルを1段上げても総額が収まる余地が生まれる点です。キャッシュを効かせた astra（約$307）は、効かせない sol（$600）より安い。「安いモデルで我慢する」より「高いモデルでキャッシュを効かせる」ほうが品質と費用の両取りになる場面が実際にあります。素の単価と選び方はGPT-6 Sol の料金と月額試算、Sol と Luna の使い分けはGPT-6 Sol と Luna の違いと使える場所で整理しています。移行検討中ならGPT-6 Astra の移行コスト試算と併せて読むと、移行後の実額がヒット率でどれだけ振れるか見えます。主戦場がキャッシュ読みに移っているのは他社も同じで、Anthropic もClaude Opus 5.5 でキャッシュ読みを $0.20 へ下げました（Opus 5 比60%減）。

自社のプロンプトのどこに可変の値が混ざっているか、どこで区切れば効くかは、実際のログを見ないと決められません。Mihata では社内向けAIの構築時にこの入力設計から詰めていますし、すでに動いている API の見直しも承っています。

落とし穴：ここを誤解すると期待外れになる

30分の窓を過ぎると温まり直しです。最後の書き込みまたは再利用から30分でキャッシュは対象外になり、次は通常入力の料金（GPT-5.6 以降は書き込みで1.25倍）を払います。夜間バッチや、アクセスが1時間に数回の社内ツールでは毎回が書き込みになってむしろ割高になり得ます。

ヒット率はアプリの作り次第で0%にもなります。既定で上がるとはいえ、可変の値を頭に置いていれば0%です。公式が挙げる70%や90%超は「その設計をした実装例」の数字で、保証された上限ではありません。まずダッシュボードの実測を見てから期待値を決めてください。

キャッシュはコスト削減とレイテンシ改善の話で、品質は上がりません。公式ガイドも出力の生成のしかたは変わらないと明言しており、同じリクエストが同じ出力を返す保証もありません。精度の問題はモデル選定とプロンプト設計で解くしかありません。加えてキャッシュ済み入力もレート制限（TPM）には通常どおりカウントされ、手動クリアはできません。検証時は前のキャッシュが残っている前提で測ってください。

自社のAPI代が妥当なのか、どのモデルで組むべきか迷っている段階なら、現状のログを見ながら整理するところからお手伝いできます。