GPT-5.6 プロンプトガイド：課金が 1.5 倍・10 倍に膨らむ 2 つのデフォルト

GPT-5.6 をうまく使うコツは、ほぼ 2 つのリクエストパラメータに尽きる。そしてどちらもデフォルトが高くつく設定になっている。reasoning_effort を省くと、50 回のコールマトリクスでは "none" を明示した場合の 1.5 倍が課金された（回答は同一）。安定した prefix を未指定のまま送ると、毎回キャッシュ読み取りレートの 10 倍で課金される。本記事は、GPT-5.6 コストガイドの実測から導き出したリクエスト設計の手引きだ。適切な形のリクエストとは何か、タスクごとに effort をどう設定するか、キャッシュを効かせるためにプロンプトをどう並べるか、そして GPT-5.5 からプロンプトを移植すると何が壊れるかを扱う。

TL;DR

• GPT-5.6 のすべてのリクエストで reasoning_effort を明示する。省略すると、4 タスクのマトリクスで回答は同一のまま "none" の 1.5 倍が課金された。
• 指定できる effort は none から xhigh まで。"max" は Sol でも Terra でも 400 を返す。
• 安定した prefix には明示的なキャッシュ breakpoint を付ける。キャッシュ読み取りは入力レートの 10%、書き込みは 1.25 倍で課金される。だから「安定して見えるもの」ではなく「実際に繰り返されるもの」に印を付ける。
• prompt_cache_options と breakpoint は GPT-5.5 以前では 400 を返す。ロールアウトはバージョンでゲートすること。

GPT-5.6 のリクエストはどんな形にすべきか

まずはこの形から始めて、不要なものを削っていく。高くつくデフォルトをそのまま引き継ぐのではなく、2 つのレバーを明示的に指定している。

{
  "model": "gpt-5.6-terra",
  "reasoning_effort": "low",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    { "role": "system", "content": "…stable instructions…",
      "prompt_cache_breakpoint": { "mode": "explicit" } },
    { "role": "user", "content": "…the part that changes per request…" }
  ]
}

背後にある並べ方のルールはこうだ。安定したものはすべて breakpoint の前に置き、リクエストごとに変わるものはすべて後ろに置く。動的なもの（タイムスタンプ、ユーザー名、コールごとに異なる取得ドキュメントなど）は、印を付けたブロックの中には絶対に入れない。1 バイトでも変われば、そのブロックは 1.25 倍の書き込みプレミアムで再課金されるからだ。prompt_cache_key は繰り返しを同じキャッシュにルーティングする。テナントやセッションごとに 1 つの安定したキーを使うこと。ドキュメントに記載のソフトリミットは、キーあたり毎分およそ 15 リクエストである点にも注意。

reasoning_effort はどう設定すべきか？

常に明示的に指定すること。避けるべきなのは「何も設定しない」ことだ。計測では、reasoning_effort を付けないリクエストは "none" を指定した場合の 1.5 倍の課金になり、回答はどの組み合わせでも同一だった。受け付ける値は none、low、medium、high、xhigh で、"max" は 400 で拒否され、有効な範囲が返る。1 行の算数チェックで Luna を使い、このダイヤルが何をもたらしたかは以下の通り。

GPT-5.6 は、私たちの トークン使用量の解剖 研究の中で、このチェックにおいて thinking を完全にオフにしても正解を維持した唯一のファミリーだった。そのため、抽出、分類、フォーマット、検索型のコールでは none を妥当なデフォルトにできる。推論する場合、そのトークンは見えないうえに出力の全レートで課金される。デフォルト設定の算数の例では、出力課金の 88% が読めない chain of thought だった。ダイヤルを上げるのは、評価がそのタスクに必要だと示したときにすること。デフォルトがすでに消費してしまっているから、ではない。

キャッシュが効くプロンプトのレイアウトは？

プロンプトは安定度の順に層を分け、それぞれの層に印を付ける。まず system instructions、次に tool 定義、その次に参照ドキュメントの順で、各層を breakpoint で終わらせ、変動する user ターンは最後の印の後に置く。リクエストごとに 4 回のキャッシュ書き込みが使える。デフォルトの暗黙モードでは最新メッセージに自動 breakpoint が付いてそのうち 1 回を消費するので、明示モードなら 4 回すべてを使えるうえ、より重要なのは、印を付けたものだけがキャッシュされる点だ。

見返りは部分再利用で、これは計測できる。安定ブロック A と入れ替えた末尾 B の構成では、メーターは末尾分だけ再課金した。2,431 トークンのプロンプトのうち、1,212 トークンがキャッシュレートで読み戻され、1,210 トークンがプレミアムレートで新規書き込みされ、レート表と桁まで一致した。ここから予算設計のルールが 3 つ導かれる。

• 読み込みは input レートの 10% で課金されるので、温まった層構造の prefix は請求の input 側を平坦にする。
• 書き込みは 1.25 倍で課金されるので、二度と読まれない印付きブロックはキャッシュしない場合より 25% 高くつく。安定して見えるものすべてではなく、繰り返されるものに印を付けること。
• 完全一致の繰り返しでも、マッチ長が印より下に切り詰められることがある（あるプローブでは 2,422 トークン書き込みのうち 1,897 トークンがキャッシュされた）ので、完全一致数ではなく割引レートで予算を組むこと。ファミリーごとの下限値は キャッシュ最小値の研究 にある。

ttl: "30m" の下限は保証された最小値であって上限ではなく、Claude のデフォルト 5 分の 6 倍にあたる。24 時間ティアはもう存在しないので、長期保持に頼っていた日次バッチのワークロードは損益分岐点を再計算すべきだ。

GPT-5.5 からプロンプトを移植すると何が壊れるか？

派手に壊れるものが 2 つ、静かに壊れるものが 1 つある。派手なもの：prompt_cache_options と prompt_cache_breakpoint は GPT-5.5 以前ではきれいに 400 を返す（prompt_cache_options is not supported on this model）ので、共通のプロンプトビルダーにはバージョンによるゲートが必要になる。同じく派手なもの：一部の 5.5 の設定が引き継いでいた "max" の effort は拒否される。

静かに、そしてより高くつくもの：GPT-5.6 はデフォルトで推論するが、5.5 のワークロードでは推論がオフだった可能性がある。reasoning_effort を一度も設定しないまま移植したプロンプトは、同じレート表で 1.5 倍の未指定税を負う。キャッシュの移行は逆方向に働く。5.5 の自動 prefix 検出はマークアップ不要だったが、手動でトリガーもデバッグもできなかった。5.6 では同じプロンプトも印を付けるまで何もせず、印を付ければ書き込みはすべて usage.prompt_tokens_details.cache_write_tokens に報告される。ミスは沈黙ではなく、自分で作ったフィールドにゼロとして現れる。

どのティアでプロンプトを実行すべきか

リクエストの形はどのティアでも同じなので、ティアの選択はプロンプト設計ではなく価格の判断になる。Sol は 100 万トークンあたり $5/$30、Terra はその半分、Luna は 5 分の 1 だ。プレフィックスが安定してキー付けされ、ウォームな状態になれば、キャッシュ読み取りの割引がどのティアでも入力側をならすため、差がつくのは出力価格になる。出力品質の eval が許す範囲で、できるだけ下のティアに落とせばいい。ティアごとの書き込みプレミアムの損益分岐点を含めた計算の全体は コストガイド にある。

FAQ

GPT-5.6 は reasoning_effort: “max” をサポートしますか？

いいえ。"max" を指定したリクエストは 400 を返し、有効な値として none から xhigh までを列挙する。これは Sol でも Terra でも同じだ。上限を使いたいワークロードは xhigh を明示的に送ること。

キャッシュのブレークポイントは GPT-5.5 でも動きますか？

いいえ。GPT-5.5 以前は prompt_cache_options とブレークポイントマーカーを 400 で拒否する。これらのモデルでは自動プレフィックス検出に戻ることになり、トリガーもキー付けもデバッグもできない。キャッシュの挙動はベストエフォートとして扱い、新しいフィールドを出力するプロンプトビルダーはバージョンでゲートすること。

プロンプトは実際にいくつブレークポイントを使うべきですか？

本当に繰り返されるレイヤーの数だけ、予算の上限まで使えばいい。上限はリクエストあたり 4 回の書き込みで、明示モードに切り替えない限りそのうち 1 つは暗黙の自動ブレークポイントが消費する。典型的なレイヤー化プロンプトなら 2 〜 3 個（instructions、tools、リファレンスブロック）で足りる。5 つ目のマーカーもエラーにはならないが、後ろのマークが手前の全体をカバーするため、単に書き込みスロットを共有するだけだ。

このガイドの数値はすべて、リリース初日の GPT-5.6 モデルに対して Synthorai ゲートウェイ経由で計測し、稼働中の usage.cost メーターと突き合わせている。手法と生の測定データは コストガイド と キャッシュ最小値の調査 にある。自分の利用記録と照合して確認してほしい。レートや受け付ける値は変わる可能性がある。

← ブログに戻る