OpenAIの12時間プロンプトキャッシュ：2.5×の書き込み料金が見合う条件
長い間隔を空けて再利用する固定プレフィックスには12時間キャッシュを使い、変化する会話内容は30分キャッシュか書き込み対象外に分けます。損益分岐点、Responses APIでのTTL混在設定、usageから入力料金を再計算する方法を確認し、Codex・Workの製品利用やAnthropicのキャッシュとの違いも整理します。
目次
OpenAIの12時間プロンプトキャッシュは、エージェントが長い間隔を空けて再利用する固定プレフィックス（毎回変わらない先頭部分）に使い、変化するセッション内容は 30m またはキャッシュ書き込み対象外に分けます。30m では毎回新たな書き込みが必要になる場合、プレフィックスが一致し続けるなら、12h で一度書き込むほうが通算3回目のリクエスト、つまり2回目の再利用から安くなります。30m ですでに毎回キャッシュがヒットするなら、期間を延ばしても読み取り料金は下がらず、費用だけが増えます。
30mと12hの料金はいくらか
12h は、デフォルトの2倍の書き込み料金で、キャッシュ入力料金を適用できる最低期間を長くする設定です。この最低有効期間を指定する値がTTLです。OpenAIの2026年10月20日のAPI変更履歴でResponses向けに導入され、プロンプトキャッシュのガイドにはGPT-5.6以降について次のルールが記載されています。確認日は2026-10-24です。
| 入力の課金区分 | 通常入力料金に対する倍率 | GPT-6.1 Sol、1M tokensあたりのUSD |
|---|---|---|
| 通常入力 | 1× | $2.00 |
30m の書き込み（デフォルト） | 1.25× | $2.50 |
12h の書き込み | 2.5× | $5.00 |
| キャッシュ読み取り（どちらの期間でも同じ） | 大半のモデルは0.1×、GPT-6.1 Solは0.05× | $0.10 |
これらは書き込みの総額を表す倍率です。12h の書き込みとして課金されるトークンは通常入力の2.5×であり、通常入力料金にさらに2.5×が上乗せされるわけではありません。
ドル建ての列は、gpt-6.1-sol のOpenAI Standard料金を使っています。入力が272Kトークン以下で、地域指定の処理に伴う追加料金がない場合の値です。出力料金は1M tokensあたり$10.00です。長いプロンプト、別のサービス階層、地域指定の処理では料金が変わることがあるため、以下の計算を使う前に、適用されるモデルの料金条件を確認してください。
再利用するプレフィックスには、可視の入力トークンだけで少なくとも1,024トークンを含める必要があります。リクエスト全体が大きくても、変わらない先頭部分が短ければ、その部分が自動的にキャッシュ対象になるわけではありません。
高い書き込み料金はいつ回収できるか
長い有効期間によって、何回の書き込みを避けられるかを数えます。B を変更しないプレフィックスの通常入力コスト、n をリクエストの総数、r を読み取り料金の倍率、k を初回を含む 30m の書き込み回数とします。
毎回の書き込みまたはキャッシュヒットがプレフィックス全体を対象とし、12h では一度書き込んだ後にすべての読み取りが成功すると仮定すると、その固定プレフィックスに対する入力費用は次のとおりです。毎回変わる末尾部分の費用は、この比較と分けて扱います。
12h cost = B × [2.5 + (n - 1) × r]30m cost = B × [1.25 × k + (n - k) × r]No-cache cost = B × n
r = 0.1 と r = 0.05 のどちらでも、n = 3 から長時間キャッシュがキャッシュなしの入力より安くなります。デフォルトのキャッシュとの比較では、12h の書き込みが一度で済む間に k >= 3 になることが条件です。つまり、初回以降の短時間キャッシュへの書き込みを2回避ける必要があり、単にヒット回数が多ければよいわけではありません。
両方の方式が一度だけ書き込み、その後すべてのリクエストでヒットするなら、12h は常に 1.25 × B だけ高いままです。頻繁にやり取りする対話では、書き直しが必要になるほどの中断を挟んで再開するのでなければ、長い有効期間に追加料金を払う理由はあまりありません。
30分を超える間隔は節約の可能性を生みますが、キャッシュミスを証明するものではありません。OpenAIは最低有効期間を超えてエントリを保持する場合があり、30m の読み取りが成功すると、キャッシュ読み取り料金が適用される期間が、読み取り時点から少なくともさらに30分に更新されます。既存のワークロードの費用を予測するときは、実際に観測した書き込み回数を使ってください。
具体的な試算として、GPT-6.1 SolのStandard料金で10,000トークンのプレフィックスを考えます。B = $0.02、r = 0.05 です。プレフィックスを変えず、開始から0時間後、1時間後と、11時間後まで1時間おきに合計12回リクエストします。
| 仮定するキャッシュの動作 | 12回のリクエストにおけるプレフィックスの入力コスト |
|---|---|
| キャッシュなし：通常入力を12回 | $0.240 |
30m：12回すべてで書き込みが必要 | $0.300 |
12h：書き込み1回と読み取り11回 | $0.061 |
30m：書き込み1回と読み取り11回 | $0.036 |
30m の2つの行は、リクエスト間隔だけでは節約額を決められないことを示しています。毎回書き込む行は仮定であり、1時間おきの利用で必ずそうなるという意味ではありません。これらの試算には、変化する末尾部分、出力トークン、ツール料金は含まれておらず、実際の請求書を測定した結果でもありません。
リクエスト全体を12hにすると高くなる理由
リクエスト単位の prompt_cache_options.ttl: "12h" は、暗黙のブレークポイントにも適用されます。ブレークポイントは、どこまでのプレフィックスをキャッシュ対象にするかを決める境界です。デフォルトの mode: "implicit" では、以前のプレフィックスを安く読み取れていても、各ターンで追加されたキャッシュ対象の会話内容に2.5×の書き込み料金が発生することがあります。
ツールの結果やユーザーメッセージを蓄積するエージェントでは、増え続ける末尾部分の費用が、固定の先頭部分で得られる節約を上回る場合があります。キャッシュヒット率が高いというだけでは、その設定で入力料金の合計を減らせているかどうかは判断できません。
用途に合わせて、次のいずれかを選びます。
- 固定の共有資料と、再利用するセッションの文脈がある場合： リクエストのデフォルトを
30mにし、共有資料の末尾だけ12hで上書きします。 - 固定の資料と、一度しか使わない質問がある場合：
mode: "explicit"を使い、変化する質問は最後の明示的なブレークポイントより後ろに置きます。 - 会話の最新の文脈をすぐ再利用する場合： リクエストのデフォルトを
30m、モードをmode: "implicit"に保ち、共有プレフィックスには12hのブレークポイントを置きます。
ブレークポイントは、それ以前のプレフィックス全体を対象にします。まだキャッシュがないリクエストで、2,000トークンの位置に 12h、5,000トークンの位置に 30m のブレークポイントがあれば、2,000トークンが長い有効期間の書き込み、3,000トークンが短い有効期間の書き込みとして課金されます。12h のブレークポイントを後ろの5,000トークンの位置に置くと、5,000トークンすべてに長い有効期間の書き込み料金が適用されます。各トークンの書き込みは、それを対象に含む設定のうち最も長い有効期間で一度だけ課金されます。
有効期間を変えるときには、さらに2つのルールがあります。まだ有効な 30m のキャッシュを 12h に延長すると、新たな長時間キャッシュへの書き込みとして課金され、前の書き込み料金は差し引かれません。30m を指定したリクエストが有効な 12h のプレフィックスを読み取る場合、そのトークンには読み取り料金が適用され、12時間のカウントが最初からやり直されたり、新たな書き込み料金が加算されたりすることはありません。この重複と有効期間のルールを踏まえ、大きなプレフィックスを初めてキャッシュに入れる前に設定を決めておきましょう。
Responsesの1リクエストで12hと30mを設定する
リクエストのデフォルトを 30m にし、明示的なブレークポイントで共有の参考資料、セッションの文脈、今回の質問を分けます。次の例はOpenAIのResponses APIに直接リクエストし、生成されたテキストと、料金確認に必要な使用量の両方を表示します。
Bash、curl、jqと、gpt-6.1-sol にアクセスできるOpenAI APIキーが必要です。現在のディレクトリに、次のファイルを用意してください。
shared-context.md：一日を通して再利用する、役に立つ開発指示や参考資料。少なくとも1,024の可視入力トークンを含めます。session-context.md：現在のデプロイやプルリクエストの文脈。このセッション中に再利用する内容を入れます。
例の2回の呼び出しの間は、どちらのファイルも変更しないでください。read が入力待ちになったらAPIキーを貼り付け、Enterを押します。入力したキーはターミナルに表示されません。認証方法はOpenAI APIクイックスタートに従っています。
set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY
cache_request() {
jq -n \
--rawfile shared ./shared-context.md \
--rawfile session ./session-context.md \
--arg question "$1" \
'{
model: "gpt-6.1-sol",
service_tier: "default",
reasoning: {effort: "low"},
prompt_cache_options: {mode: "explicit", ttl: "30m"},
input: [
{
role: "developer",
content: [{
type: "input_text",
text: $shared,
prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
}]
},
{
role: "user",
content: [
{
type: "input_text",
text: $session,
prompt_cache_breakpoint: {mode: "explicit"}
},
{type: "input_text", text: $question}
]
}
]
}' |
curl --silent --show-error --fail-with-body \
https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @- |
jq '{id, status, service_tier,
text: ([.output[]? | .content[]? |
select(.type == "output_text") | .text] | join("\n")),
usage, error}'
}
cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."最初のコンテンツブロックは "ttl": "12h" でリクエストのデフォルトを上書きします。セッションのブロックは独自のTTLを省略しているため、"30m" を引き継ぎます。リクエストが明示的なブレークポイントだけを使うモードなので、最後の質問にはキャッシュ書き込み料金がかかりません。ただし、通常入力の料金は発生します。
キャッシュ対象の条件を満たし、まだ保存されていないプレフィックスなら、最初に完了したレスポンスの usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens に長時間キャッシュへの書き込みが記録されるはずです。プレフィックスとキャッシュの有効性が保たれていれば、2回目には cached_tokens > 0 が表示され、新たな12時間キャッシュへの書き込みは発生しないはずです。返された text に、実際に使える回答が入ります。直後に同じプレフィックスで再実行すると、プレフィックスの一致とトークンの課金区分を確認できます。一方、長い中断を挟む場合の節約は、本番と同じ間隔でリクエストして評価します。
400 invalid_request_error が返ったら、TTLの文字列が正確か、選んだモデルが正しいか、Responsesのエンドポイントを使っているかを確認してください。両方の呼び出しでキャッシュ済みトークンがゼロなら、まずプレフィックスの長さを確認し、次にファイル、モデル、設定、ブレークポイントの位置を比較します。ツールを追加する際にツール定義を変更する場合も含め、共有ブレークポイントより前の内容が変わると、同じプレフィックスとして再利用できなくなる場合があります。
キャッシュなしの比較基準を試すには、mode: "explicit" を維持したまま、すべての prompt_cache_breakpoint を削除します。公式のリクエストスキーマには、マーカーのない明示モードではプロンプトキャッシュを使わないと記載されています。
usageから入力料金を再計算する
通常入力、キャッシュ読み取り、2種類の書き込みを、互いに重複しない課金区分として扱います。書き込みトークン数の合計である cache_write_tokens には ttl_30m_tokens と ttl_12h_tokens がすでに含まれているため、3つすべてを課金すると書き込みを二重計上してしまいます。12h への延長として課金されるトークンは書き込みに含まれ、cached_tokens からは除外されます。
OpenAIの使用量の計算例は、次の形式です。
{
"usage": {
"input_tokens": 12000,
"input_tokens_details": {
"cached_tokens": 4000,
"cache_write_tokens": 7000,
"cache_write_tokens_details": {
"ttl_30m_tokens": 3000,
"ttl_12h_tokens": 4000
}
}
}
}I を input_tokens、R を cached_tokens、W30 と W12 をそれぞれのTTLで書き込んだトークン数とします。通常入力は U = I - R - W30 - W12 で求められ、この例では1,000トークンです。
通常入力の価格 P を1M tokensあたりのUSD、キャッシュ読み取りの倍率を r とすると、入力料金は次のように計算できます。
Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000
ドキュメントの仮定例では P = $1、r = 0.1 を使い、次の結果になります。
(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515
同じ使用量にGPT-6.1 SolのStandard料金を適用するなら、P = $2、r = 0.05 に置き換え、入力料金は $0.02990 です。出力や、そのほかの該当する料金は別途加算します。この式で分かるのは入力料金だけであり、コーディングのタスクを完了するまでの総費用を見積もるものではありません。
レスポンスID、時刻、モデル、実際の service_tier と、これらのトークン数を記録してください。クライアントがTTL別の内訳を省略している場合は、異なる有効期間の費用を計算する前に生のJSONを確認します。カウンターが見当たらないことは、書き込みがゼロである証拠にはなりません。単一のヒット率で設定を選ぶのではなく、普段の使い方を反映する一日を通してドル建ての料金を集計しましょう。
12h が定めるのは、キャッシュ読み取り料金が適用される最低有効期間です。削除期限を指定するものではなく、データの最大保持期間に関する方針を変えたり、毎回のリクエストで低いレイテンシーを保証したりするものでもありません。
Codex、Work、Anthropicとの違いは何か
APIの課金と、ログインして使う製品に含まれる利用枠は分けて考えてください。Tibo Sottiauxは2026年10月21日の投稿で、ログインしたCodexとWorkのユーザーにはキャッシュを無期限に保持し、古い会話に戻ってもキャッシュがヒットすると述べています。この発言はそれらの製品のセッションについてであり、APIのTTLを定義したり、サブスクリプションを無制限にしたりするものではありません。
Codexの公式料金ドキュメントには、Codexのクレジット課金ではキャッシュ書き込みに別料金はかからず、APIキーによる利用にはAPI料金が適用されると記載されています。APIキーでCodexを使う場合は、ログインした製品での説明をそのまま当てはめず、APIのルールで費用を見積もってください。
Claudeについて2026-10-24時点で記載されている選択肢は、書き込みが1.25×のデフォルト5分キャッシュと、書き込みが2×のオプションの1時間キャッシュです。読み取りの割引はモデルによって異なり、Claude Opus 5.5とSonnet 5.5は0.05×です。そのほかの料金はAnthropicの料金表を確認してください。読み取りに成功すると追加の書き込み料金なしで有効期間が更新され、TTLを混在させる場合は、長い有効期間のブロックを短いものより前に置く必要があります。
すでに対応するOpenAIモデルを使っているアプリで、数時間の間隔を繰り返し挟むなら、固定プレフィックスの 12h 設定を最初に試してください。常に動いているセッションなら、短いキャッシュから始めます。プロバイダーを比較するには、実際の基本料金、出力量、観測したキャッシュの動作が必要です。有効期間と書き込み倍率だけでは、タスクを最後まで実行したときにどちらが安いかは判断できません。
