OpenAI APIの利用ティアが3段階に｜Build・Launch・Growの条件と上限の確認方法

OpenAI APIの利用ティアは、Build・Launch・Growの3段階になりました。2026年10月6日の更新で5段階から整理され、クレジットの累計購入額がしきい値に届くと自動で上がります。ティアは「月にいくらまで使えるか」と「1分あたりどれだけ送れるか」の両方に関わります。この記事では、条件と上限、確認する画面、支出上限との違い、エラーへの備えを公式資料から整理します。

10月6日に何が変わったか

有料の利用ティアが3つにまとまりました。組織のティアは、クレジットの累計購入額が各ティアの最低額に届いた時点で自動的に上がります。ティアが上がるほど、多くのモデルでレート制限も高くなります。Rate limits

レート制限は、ユーザー単位ではなく組織とプロジェクトの単位で決まります。チームで1つの組織を使っている場合、誰か1人の大量処理が全員の上限に影響します。

3つのティアの条件と月の利用上限

有料の3ティアに加えて、比較のために無料のFreeも並べます。Freeは有料ティアとは別枠です。

「月の利用上限」は、OpenAIが組織ごとに承認している1か月の上限です。自分で設定する支出上限とは別物で、この違いは後の章で説明します。条件は「1回の購入額」ではなく累計なので、少額の購入を重ねても条件に届きます。

モデル別のレート制限（Standard）

ティアごとの標準のレート制限は次のとおりです。RPMは1分あたりのリクエスト数、TPMは1分あたりのトークン数です。

どれか1つの指標に先に達した時点で制限がかかります。たとえば短いリクエストを大量に送ると、トークン数に余裕があってもRPMで止まります。また、モデルによっては複数のモデルで1つの上限を共有している場合があり、その内訳は管理画面の「shared limit」に表示されます。

10月8日に追加された高速モードのUltrafastは、この表とは別のレート制限です。料金や上限はGPT-6.1 Sol Ultrafastの解説にまとめています。

自分のティアと上限を確認する手順

1. OpenAIのAPI管理画面でSettings > Organization > Limitsを開く。
2. Rate limitsで、使っているモデルのRPM・TPMを確認する。
3. Usage Tiersの欄で現在のティアを確認する。上げる場合はUpgrade tierを選ぶ。
4. プロジェクトごとに上限を分けている場合は、プロジェクト単位の上限も確認する。

上の表は公式ガイドに載っている標準の値です。組織によって異なる場合があるため、実際の値は必ず管理画面で確認してください。

月の利用上限と「支出上限」の違い

月の利用上限はOpenAIが決める上限です。一方、組織やプロジェクトの管理者は、自分で支出上限（spend limits）を設定できます。

ティアが上がって月の上限が大きくなるほど、想定外の使いすぎも起こり得ます。検証用と本番用でプロジェクトを分け、検証用にはハード上限を置くといった使い分けが考えられます（編集部の運用例です）。

429・503エラーが出たときの扱い

RPMやTPMの上限を一時的に超えたときも429が返ります。この場合は待ってから再試行します。さらに公式ガイドは、次の2つを区別して対応するよう説明しています。HTTPステータスが同じでも別の原因のことがあるため、エラー本文のerror.codeまで確認します。

レスポンスのヘッダーには、残りのリクエスト数・トークン数（x-ratelimit-remaining-requests、x-ratelimit-remaining-tokensなど）や、上限が戻るまでの時間が入ります。ただし、Retry-Afterは一時的な制限のための情報で、利用上限や支払いの問題は再試行では解決しません。

Codexに対応を頼むときの依頼例

既存のアプリにレート制限への対応を入れる場合、Codexには「どのエラーを再試行し、どれを止めるか」を先に伝えます。以下は編集部が作った依頼文の例です。

OpenAI APIを呼んでいる箇所を一覧にしてから、次の方針でエラー処理を追加してください。
- 再試行するのは、一時的なレート制限の429（slow_down を含む）と 503 server_is_overloaded だけにする。HTTPステータスとエラー本文の error.code の両方を見て判断する
- Retry-After があれば、その秒数を最低限の待ち時間として扱い、少しランダムな待ちを足す。なければ待ち時間を指数的に延ばし、ランダムな揺らぎを入れる
- 公式SDKの自動再試行は無効にするか、アプリ側の回数・合計時間の上限に含める（再試行が入れ子にならないようにする）
- 再試行は回数と合計時間の両方に上限を置く。超えたら処理を止めて、入力IDとエラー内容を記録する
- 支出上限・利用上限・支払いなど、利用者の対応が要るエラーは再試行しない
- 変更前に方針と対象ファイルを見せてください。テストを書いてから実装してください

公式SDKは、対象となる429と503を設定に応じて自動で再試行します。アプリ側でも再試行を書くと回数が掛け算で増えるため、どちらで再試行するかを依頼文で決めておきます。「再試行しないエラー」も書いておくと、上限に達したまま同じリクエストを送り続ける事故を防げます。チーム共通の方針にするなら、AGENTS.mdにまとめておくと毎回の説明が要りません。

RPMに余裕があってもTPMで止まる：計算例

以下は、上限の読み方を理解するための架空の計画例です。実際に送信できる件数の保証ではありません。仮に計画上の予算を「1分1,000,000トークン」、一件あたりを20,000トークンと見積もると、単純な割り算では1分50件です。一件が50,000トークンへ増えると20件になります。

実際のレート制限の計算はAPIの方式や指定値にも依存するため、請求で確定したトークン数だけから送信可能数を決めないでください。管理画面とレスポンスの制限情報を確認し、余裕を持つ設計にします。公式：制限の仕組みと回避方法

一分の合計が上限以内でも、短時間に集中させる送信では制限に当たる場合があります。まず同時実行数を抑え、待ち行列に入れた入力を少しずつ処理し、失敗率と待ち時間を見て調整する方法が考えられます。

エラー調査で残す情報と、残さない情報

発生日時：
対象組織・プロジェクト：
モデルとservice tier：
HTTPステータス：
error.code：
Retry-Afterなどの制限情報：
処理対象の内部ID：
再試行回数と経過時間：
同時に動いていた処理：
最終状態：成功 / 保留 / 利用者対応待ち

APIキーや生の顧客データをログへ入れる必要はありません。内部IDで元データへ戻れるようにすれば、同じ入力を二重に処理していないかを照合できます。エラーが出た一回のリクエストと、後続の処理全体を区別して記録してください。

再試行を追加したら、成功時だけでなく、上限に達したままの状態でも止まれるかをテストします。SDKとアプリの両方が再試行する場合は、合計回数と待ち時間を数え、想定以上にリクエストが増えていないかを確認します。

よくある質問

ティアは自分で上げられますか？

クレジットの累計購入額が条件に届くと自動で上がります。管理画面のUsage Tiersの欄にはUpgrade tierの操作もあります。

ChatGPTやCodexの有料プランは、APIのティアに関係しますか？

APIの利用ティアは、APIのクレジット購入額で決まると説明されています。ChatGPTやCodexのプランの料金とは、契約と請求を分けて確認してください。

以前のティアからどう移行されたかは分かりますか？

公式の更新履歴は「5段階から3段階に整理」とだけ説明しています。自分の組織の現在のティアと上限は、管理画面の表示で確認してください。