OpenAI Scale Tierと従量課金の違い｜大口利用の判断基準

従量課金との考え方の違い

従量課金は使った分だけ支払うため、需要変動に対応しやすい方式です。Scale Tierは特定のモデルスナップショットについて、入力・出力のtoken unitを前払いで購入します。公式案内では1 unitあたり最低30日で、購入分はレート上限へ加算されます。

Scale TierとReserved Tierを混同しない

OpenAIの公式ページでは、Scale TierはGPT-5.6より前に公開されたモデル向けで、GPT-5.6以降はReserved Tierを参照するよう案内されています。『OpenAIの予約容量』を一括りにせず、利用モデルと契約方式が一致するか営業窓口へ確認してください。

判断に必要な4つの実測値

平均利用量だけで判断すると危険です。日次・時間帯別に分け、ピークと谷を確認します。

• 入力と出力の毎分トークン量
• ピーク時間帯の継続時間
• 429・待ち時間が事業KPIへ与える損失
• モデル別利用量の今後6〜12カ月予測

損益分岐は稼働率で変わる

確保した容量を使い切れない時間が長いほど、実質的な完了タスク単価は上がります。比較では、30日分のunit費用を想定処理トークンで割り、未使用容量を含む実効単価を出します。そのうえで、429や遅延による売上損失、運用工数、SLAの価値を足します。

• 実効単価＝契約費用÷実際に消費できる対象トークン
• 稼働率＝実利用TPM÷購入TPM（時間帯別で確認）
• 超過分の処理方式と追加料金
• モデル更新時の移行条件

先にやるべきこと

予約容量を検討する前に、不要な出力、再試行、重複リクエスト、キャッシュ可能な処理を洗い出します。需要そのものを整えてから容量を見積もると、過剰契約を避けやすくなります。

公式仕様から分かる課金と超過処理

OpenAIの公式ページでは、Scale TierのTPMは15分単位の平均で課金判定されます。購入した処理枠を15分間の合計が超えると、超過分はFast modeの従量料金で処理されます。2026年7月以降はScale TierからFast modeへのスピルオーバーが自動化されたと案内されています。

この仕組みでは1分だけの瞬間的な山と、15分続く高負荷で費用影響が異なります。日次平均ではなく、15分窓で入力・出力トークンを集計し、購入枠内、超過、未使用の割合を試算する必要があります。

30日費用の見方

公式ページに掲載されるunit価格は1日あたりです。たとえば入力unitと出力unitを別々に買うモデルでは、必要なunit数をそれぞれ算出し、日額を合計して最低30日分へ換算します。GPT-5.4やGPT-5.5のように入力・出力を統合したbundleでは、出力トークンが入力より大きな比率で枠を消費する場合があります。

『月に何トークン使えるか』だけでは比較できません。処理枠は毎分または15分窓の容量であり、夜間に使わなかった枠を翌日のピークへ繰り越す考え方ではありません。需要が一日に偏るサービスほど、月間総量に対して多くのunitが必要になる可能性があります。

SLAとレイテンシの読み方

Scale Tierは公式に99.9% uptime SLAとモデル別のレイテンシSLAを掲げています。ただしSLAは障害をゼロにする保証ではなく、測定条件やクレジットの扱いが定められた契約条件です。自社の顧客向けSLOと同じ意味ではありません。

導入時は、最初のトークンが返るまでの時間、出力速度、リクエスト全体の完了時間を分けて計測します。平均だけでなくp95・p99を記録し、Standard processingやFast modeと同一プロンプトで比較します。

契約前チェックリスト

Scale Tierは性能だけでなく、特定モデルスナップショットと最低期間へ容量を固定する意思決定です。モデル更新が速い環境では、契約期間中に利用モデルを変更したくなる可能性も含めます。

• 対象モデルがScale TierかReserved Tierか
• 必要な入力・出力unitと最低30日の総額
• 15分窓での超過率とFast modeの追加費用
• 未使用容量を含む実効単価
• モデル更新・終了時の移行条件
• SLA違反時の測定方法とサービスクレジット