室谷代表取締役OpenAIがAPIの利用ティア、いわゆるレート制限の段階を組み替えてきたんですよね。有料ティアが5段階から3段階になって、一番上のGrowの条件が累計500ドルになった、と。
テキトー教師DotAI 認定講師そうなんですよ。OpenAIが発表したのは、APIのレート制限ティアの再編です。
有料ティアがBuild・Launch・Growの3段階に整理されて、最上位のGrowに到達する条件が、これまでの累計1,000ドルから500ドルに引き下げられました。
有料ティアがBuild・Launch・Growの3段階に整理されて、最上位のGrowに到達する条件が、これまでの累計1,000ドルから500ドルに引き下げられました。
室谷代表取締役これは地味に見えて、けっこう効く変更ですよね。うちのMYUUUでもAPIの利用量はじわじわ増えていくので、上位ティアまでの距離が半分になるのはありがたい……。
テキトー教師DotAI 認定講師しかも、すでに有料ティアにいる組織は自動的に新しいティアへ移行して、ユーザー側の操作は不要とされています。ここが今回の発表のポイントですね。
室谷代表取締役なるほど。じゃあ何もしなくても枠が変わる可能性がある、と。
まずは何がいつ変わったのか、そこから整理したいです。
まずは何がいつ変わったのか、そこから整理したいです。
OpenAI APIのレート制限ティア再編とは？何がいつ変わったか
OpenAI API レート制限ティア再編前後の比較
再編前
- 有料ティアは5段階
- 最上位ティアの条件は累計1,000ドル
再編後
- Build・Launch・Growの3段階
- 最上位Growの条件は累計500ドル
- 上位ティアに行きやすくなりレート上限が上がる
テキトー教師DotAI 認定講師まず前提として、レート制限というのは、APIが一定時間内に受け付けるリクエスト数やトークン数の上限のことです。OpenAIのドキュメントでは、悪用や誤用の防止、みんなが公平に使えるようにすること、インフラの負荷管理、この3つが目的として挙げられています。
室谷代表取締役つまり、制限そのものは無くなったわけじゃなくて、その段階の刻み方が変わった、という理解でいいんですか。
テキトー教師DotAI 認定講師はい。有料ティアが5段階あったものが、Build・Launch・Growの3段階になりました。
そして、いちばん上のGrowの条件が累計1,000ドルから500ドルに下がった、というのが今回の発表の中心です。
そして、いちばん上のGrowの条件が累計1,000ドルから500ドルに下がった、というのが今回の発表の中心です。
室谷代表取締役発表の主語はあくまでOpenAIですからね。Xで見かけたとしても、発表したのはOpenAIであってXではない、と。
テキトー教師DotAI 認定講師そうですね。ここは正確に押さえておきたいところです。
室谷代表取締役で、実際に何が変わるかというと、上位ティアに行きやすくなることでレート上限が上がる、と。具体的な数字はどうなっているんですか。
Build・Launch・Growの違い——3段階になった新ティアの条件と上限
Build・Launch・Growの条件と利用上限
| ティア | 条件 | 利用上限 |
|---|---|---|
| Free | 許可された地域のユーザー | 月100ドル |
| Build | 累計5ドルのクレジット購入 | 月500ドル |
| Launch | 累計100ドルのクレジット購入 | 月5,000ドル |
| Grow | 累計500ドルのクレジット購入 | 月200,000ドル |
テキトー教師DotAI 認定講師公式ドキュメントの表を整理するとこうです。
| ティア | 条件 | 利用上限 |
|---|---|---|
| Free | 許可された地域のユーザー | 月100ドル |
| Build | 累計5ドルのクレジット購入 | 月500ドル |
| Launch | 累計100ドルのクレジット購入 | 月5,000ドル |
| Grow | 累計500ドルのクレジット購入 | 月200,000ドル |
室谷代表取締役なるほど。累計の購入額でBuildが5ドル、Launchが100ドル、Growが500ドル、と。
以前は最上位に届くのに1,000ドル必要だったのが、500ドルでよくなったわけですね。
以前は最上位に届くのに1,000ドル必要だったのが、500ドルでよくなったわけですね。
テキトー教師DotAI 認定講師そうなんですよ。しかも、ティアが上がるとモデルごとのレート上限も基本的に上がります。
標準のレート制限の表も出ていて、たとえばBuildではAstra・Sol・TerraがRPM 5,000・TPM 1,000,000、LunaがRPM 5,000・TPM 2,000,000。LaunchではAstra・Sol・TerraがRPM 10,000・TPM 4,000,000、LunaがRPM 10,000・TPM 10,000,000。
GrowではAstra・Sol・TerraがRPM 15,000・TPM 40,000,000、LunaがRPM 30,000・TPM 180,000,000です。
標準のレート制限の表も出ていて、たとえばBuildではAstra・Sol・TerraがRPM 5,000・TPM 1,000,000、LunaがRPM 5,000・TPM 2,000,000。LaunchではAstra・Sol・TerraがRPM 10,000・TPM 4,000,000、LunaがRPM 10,000・TPM 10,000,000。
GrowではAstra・Sol・TerraがRPM 15,000・TPM 40,000,000、LunaがRPM 30,000・TPM 180,000,000です。
室谷代表取締役数字が一気に跳ねますね。GrowのLunaのTPMが180,000,000というのは、かなり大きな処理を想定しているんだろうな、と。
テキトー教師DotAI 認定講師ここで注意したいのが、この標準のレート制限はUltrafastのレート制限とは別物だという点です。混同しないようにしてくださいね。
室谷代表取締役あと、これはモデルごとに違うし、一部のモデル群では制限が共有される場合もある、と。うちでも「どのモデルが同じ枠を食っているのか」が見えにくいことがあるので、そこは組織のLimitsページを見るのが大事ですよね。
Grow到達が500ドルに引き下げ——開発者にとって何が変わるのか
まとめ
Grow到達500ドル引き下げのポイント
- 成長段階の開発者にとって上位ティアのハードルが下がった
- 累計500ドルの支払いでGrowに到達し、以前より少ない支払額で高いレート上限を狙える
- プロダクトが伸びてきたタイミングでAPIの枠が足りない、でも上位ティアまではまだ遠い、という状態が一番もどかしい
- 背景には「上位ティアに上がるには返金不可の支払いを積むしかない」という指摘や、Batch APIの上限到達時に引き上げを申請するオプションが見当たらないという声があった
- 500ドル払えば即座に全部の枠が無限になるわけではなく、あくまでティアが上がってそのティアの上限が適用される
- 条件を満たせば自動で昇格するが、上限に達すれば429エラーは返ってくる
- 条件は「累計クレジット購入額」。支払いの種類によって扱いが変わる可能性があるため、自分の組織のUsage Tiersの表示で確認するのが確実
テキトー教師DotAI 認定講師今回いちばん大きいのは、成長段階の開発者にとって上位ティアのハードルが下がったことです。累計500ドルの支払いでGrowに届くので、以前より少ない支払額で高いレート上限を狙えます。
室谷代表取締役これは実践者としては素直にうれしいですよ。プロダクトが伸びてきたタイミングで、APIの枠が足りない、でも上位ティアまではまだ遠い、という状態が一番もどかしいので。
テキトー教師DotAI 認定講師背景には、コミュニティから「上位ティアに上がるには返金不可の支払いを積むしかない」といった指摘や、Batch APIの上限に達したときに引き上げを申請するオプションが見当たらない、という声があったようです。そうした声に応える形の変更だと考えられます。
室谷代表取締役ただ、勘違いしちゃいけないのは、500ドル払えば即座に全部の枠が無限になるわけじゃない、ということですよね。あくまでティアが上がって、そのティアの上限が適用される、と。
テキトー教師DotAI 認定講師そのとおりです。条件を満たせば自動で昇格しますが、適用されるのはあくまでそのティアのレート上限です。
上限に達すれば429エラーは返ってきます。
上限に達すれば429エラーは返ってきます。
室谷代表取締役あと、支払いの考え方も整理しておきたいです。クレジットの購入額が条件になっているので、いわゆる従量課金の支払いがそのまま積み上がるのか、プリペイドの購入が対象なのか、というのは気になるところですよね。
テキトー教師DotAI 認定講師公式の表記は「累計クレジット購入額」です。ここは支払いの種類によって扱いが変わる可能性があるので、自分の組織のUsage Tiersの表示で確認するのが確実です。
自分の組織はどうなる？自動移行の仕組みと確認方法
室谷代表取締役で、ここが実務で一番気になるところなんですけど、自分の組織がどのティアになるのか、どうやって確認するんですか。
テキトー教師DotAI 認定講師公式ドキュメントでは、Settings > Organization > Limits を開いてRate limitsを確認する、と案内されています。ティアを上げたい場合はUsage TiersセクションのUpgrade tierを選ぶ、という流れです。
室谷代表取締役なるほど。すでに有料ティアにいる組織は自動で新ティアに移行して、操作は不要、と。
これは助かりますね。手動で何か申請しないといけないのかと身構えていました。
これは助かりますね。手動で何か申請しないといけないのかと身構えていました。
テキトー教師DotAI 認定講師そこは発表で明言されています。有料ティアであれば自動的に新しいティアへ移動します。
室谷代表取締役ただ、自動移行だからといって、自分のところがBuildなのかLaunchなのかGrowなのかは把握しておいたほうがいいですよね。レート上限の設計に関わりますから。
テキトー教師DotAI 認定講師そうですね。講座でも、まず自分の組織の現在のティアと、モデルごとのRPM・TPMを確認するところから始めてもらっています。
数字を見ずに「なんとなく遅い」と悩んでも解決しないので。
数字を見ずに「なんとなく遅い」と悩んでも解決しないので。
室谷代表取締役あと、組織単位とプロジェクト単位で制限が定義される、というのも見落としがちです。個人のユーザー単位ではないんですよね。
テキトー教師DotAI 認定講師はい。レート制限は組織レベルとプロジェクトレベルで定義され、ユーザーレベルではありません。
チームで同じAPIキーを共有していると、誰かのバッチが枠を食う、ということも起こります。
チームで同じAPIキーを共有していると、誰かのバッチが枠を食う、ということも起こります。
レート制限はどう決まる？RPM・TPMなど指標と429エラー時の対処
室谷代表取締役ここからは実務寄りの話を。レート制限って、結局何で測られているんですか。
テキトー教師DotAI 認定講師公式ドキュメントでは、RPM（1分あたりリクエスト数）、RPD（1日あたりリクエスト数）、TPM（1分あたりトークン数）、TPD（1日あたりトークン数）、IPM（1分あたり画像数）、一部のストリーミング音声モデルでは音声の分あたり、といった指標が挙げられています。どれか最初に到達したもので制限に引っかかります。
室谷代表取締役たとえばRPMが20のときに、100トークンのリクエストを20回送っただけで上限に達する、という例が書いてありましたよね。トークンは全然余っていても、リクエスト数で引っかかる、と。
テキトー教師DotAI 認定講師そうなんですよ。だから「TPMはまだ余っているのに」と思っても、RPMで詰まることがある。
単にトークンの話じゃないんですよ。
単にトークンの話じゃないんですよ。
室谷代表取締役429エラーが出たときの対処も知りたいです。
テキトー教師DotAI 認定講師429が返ったときは、レスポンスにRetry-Afterヘッダが含まれることがあります。これは再試行するまでに待つべき最小秒数なので、少なくともその秒数は待って、さらに少しランダムな遅延を足すのが推奨されています。
複数のクライアントが同時に再試行しないようにするためですね。
複数のクライアントが同時に再試行しないようにするためですね。
室谷代表取締役指数バックオフとジッター、と。ここは実装でよく詰まるところです。
テキトー教師DotAI 認定講師公式SDKは対象となる429と503のレスポンスを自動で再試行しますが、Retry-Afterの扱いはSDKのバージョンや設定によって異なります。インストールしているバージョンの挙動を確認したほうがいい、と書かれています。
室谷代表取締役あと、レート制限に関わるヘッダも見ておくと原因が分かりますよね。x-ratelimit-limit-requestsやx-ratelimit-remaining-requests、x-ratelimit-reset-requestsなど。
テキトー教師DotAI 認定講師そうですね。残りのリクエスト数やトークン数、リセットまでの時間がヘッダで見られます。
プロジェクト単位のトークン制限が適用される場合は、x-ratelimit-limit-project-tokensのようなプロジェクト用のヘッダも出ることがあります。
プロジェクト単位のトークン制限が適用される場合は、x-ratelimit-limit-project-tokensのようなプロジェクト用のヘッダも出ることがあります。
室谷代表取締役エラーの種類も整理しておきたいです。429のrate_limit_errorでslow_down、503のservice_unavailable_errorでserver_is_overloaded、みたいに分かれていますよね。
テキトー教師DotAI 認定講師はい。slow_downはリクエストの増加が速すぎる場合で、RPMやTPMの上限に達していなくても起きることがあります。
server_is_overloadedはモデルが一時的に過負荷の状態です。どちらもRetry-Afterがあれば従い、無ければ遅延を増やして再試行、とされています。
server_is_overloadedはモデルが一時的に過負荷の状態です。どちらもRetry-Afterがあれば従い、無ければ遅延を増やして再試行、とされています。
室谷代表取締役急激にトラフィックを増やすと怒られる、と。目安として、入力トークンが1分あたり100万TPMに達したら、15分ごとに50%以内で増やす、というルールオブサムが示されていますね。
テキトー教師DotAI 認定講師そうなんですよ。ここは講座でもよく質問が出るところで、受講生さんが「急に本番トラフィックを流したら429が出た」と言ってくるのは大体これです。
室谷代表取締役既存のエラーハンドラを見直す必要がある、というのも書いてありました。以前は503でslow_downを返していたエンドポイントが、いまは429でslow_downを返す、といった変更です。
テキトー教師DotAI 認定講師429と503の両方をSDKのエラーハンドラで扱うようにして、以前のレスポンスコードへの対応も残しておく、と。ストリーミングの場合は、ストリームが始まる前のHTTPエラーとして返るので、出力を消費した後に自動でリプレイしないように、という注意もあります。
室谷代表取締役あと、max_tokensを実際のレスポンスサイズに近づける、というのも地味に効きますよね。レート制限はmax_tokensと推定トークン数の大きいほうで計算されるので。
テキトー教師DotAI 認定講師はい。max_tokensを必要以上に大きく取っていると、その分だけ枠を食います。
ここは見直す価値があります。
ここは見直す価値があります。
室谷代表取締役Batch APIとレート制限の関係——大量処理をしたい場合の考え方
室谷代表取締役大量処理の話も外せないですよね。Batch APIは同期リクエストのレート制限に影響を与えずに実行できる、と。
テキトー教師DotAI 認定講師そうなんですよ。即時応答が不要な大量のリクエストは、Batch APIにまとめて投げることで、同期のレート制限を消費せずに処理できます。
室谷代表取締役ただし、Batch APIにもキューの上限がある、と。これはそのモデルにキューされている入力トークンの合計で計算されて、保留中のバッチジョブのトークンがキューの上限にカウントされる。
ジョブが完了すると、そのトークンはカウントされなくなる、という仕組みです。
ジョブが完了すると、そのトークンはカウントされなくなる、という仕組みです。
テキトー教師DotAI 認定講師はい。コミュニティでも、Batch APIの上限に達して引き上げを申請するオプションが見当たらない、という声が上がっていました。
ただ、そのスレッドでは、上限は「一度にキューできるトークンの最大数」であって1日あたりの総量ではない、という指摘もされています。処理は24時間以内、場合によってはずっと早く終わることもあるので、小さなジョブの完了を見ながら流すことで、1日により多くを通せる可能性がある、という話でした。
ただ、そのスレッドでは、上限は「一度にキューできるトークンの最大数」であって1日あたりの総量ではない、という指摘もされています。処理は24時間以内、場合によってはずっと早く終わることもあるので、小さなジョブの完了を見ながら流すことで、1日により多くを通せる可能性がある、という話でした。
室谷代表取締役なるほど。だから「1日の上限に達したからもう無理」と決めつけずに、キューの状況を見ながら回すのが大事なんですね。
テキトー教師DotAI 認定講師そうですね。あと、ベクトルストアの取り込みにもレート制限があって、/vector_stores/{vector_store_id}/filesと/file_batchesが、ベクトルストアごとに毎分300リクエストの制限を共有しています。
大きな取り込みをするときはfile_batchesを使うほうがよい、と案内されています。
大きな取り込みをするときはfile_batchesを使うほうがよい、と案内されています。
室谷代表取締役大量処理の設計は、同期とBatchのどちらに寄せるかでレート制限の当たり方が変わる、と。ここはプロダクトの性質次第ですよね。
テキトー教師DotAI 認定講師そうなんですよ。即時性が要らないならBatch、要るなら同期で、RPMとTPMの両方を見ながら並列数を調整する。
単に「枠を増やす」だけじゃないんですよ。
単に「枠を増やす」だけじゃないんですよ。
室谷代表取締役あと、支出の管理も別物として押さえておきたいです。spend limitsは月間の利用上限とは別の管理項目で、spend alertは通知だけでトラフィックは続く、hard spend limitは設定額に達すると対象のAPIリクエストが429を返す、と。
テキトー教師DotAI 認定講師はい。ここを混同すると「なぜか429が出る」の原因を見誤ります。
レート制限なのか、支出上限なのか、切り分けて考える必要があります。
レート制限なのか、支出上限なのか、切り分けて考える必要があります。
室谷代表取締役よくある質問
室谷代表取締役ここからは、開発者がよく気にする点をFAQの形で整理していきましょう。
テキトー教師DotAI 認定講師いいですね。まず、レート制限は誰の単位で適用されるのか。
これは組織レベルとプロジェクトレベルで定義され、ユーザーレベルではありません。
これは組織レベルとプロジェクトレベルで定義され、ユーザーレベルではありません。
室谷代表取締役モデルごとに違うのか、という点も。レート制限は使用するモデルによって異なり、一部のモデル群では制限が共有される場合もあります。
GPT-5.5のような長いコンテキストのモデルでは、長いコンテキストのリクエスト用に別のレート制限があり、開発者コンソールで確認できる、と。
GPT-5.5のような長いコンテキストのモデルでは、長いコンテキストのリクエスト用に別のレート制限があり、開発者コンソールで確認できる、と。
テキトー教師DotAI 認定講師429が出たときはどうすればいいか。Retry-Afterがあればその秒数を守り、無ければ指数バックオフとジッターで再試行します。
ただし、クォータや請求など、ユーザー側の対応が必要なエラーは再試行しても解決しません。
ただし、クォータや請求など、ユーザー側の対応が必要なエラーは再試行しても解決しません。
室谷代表取締役自分のティアを上げたいときは。Usage TiersセクションのUpgrade tierから、というのが公式の案内ですね。
有料ティアにいる組織は自動で新ティアに移行するので、操作は不要です。
有料ティアにいる組織は自動で新ティアに移行するので、操作は不要です。
テキトー教師DotAI 認定講師モデルごとの具体的なレート制限値はどこで見るのか。Settings > Organization > LimitsのRate limitsで確認できます。
室谷代表取締役あと、これは現時点では明らかにされていない部分もあって、たとえば支払いの種類によって累計額のカウントがどう扱われるか、といった細かい仕様は公式の表示で確認するのが確実です。憶測で動かず、自分の組織の画面を見る。
これが一番大事ですね。
これが一番大事ですね。
テキトー教師DotAI 認定講師そうですね。今回の再編は、上位ティアへの距離を縮める変更ではありますが、レート制限そのものが無くなるわけではありません。
自分のティアとモデルごとの上限を確認して、429が出たときのハンドリングを整えておく。そこまでやって初めて、この変更を活かせるんだと思います。
自分のティアとモデルごとの上限を確認して、429が出たときのハンドリングを整えておく。そこまでやって初めて、この変更を活かせるんだと思います。
室谷代表取締役うちでも、まずはLimitsページを開いて現状を確認するところから始めます。枠が変わったかもしれないのに気づかずに、無駄にリトライを繰り返していた、なんてことにならないようにしたいですね。
