OpenAI APIのusage tiersは、2026年10月6日の更新で有料枠がBuild、Launch、Growの3階層に整理されました。管理者が最初に見るべき点は、総クレジット購入額で自動昇格する条件、月間利用上限、モデル別レート制限、そしてspend limitsとの違いです。
この記事では、OpenAI公式ChangelogとRate limitsドキュメントをもとに、AI基盤担当者・情シス・プロダクト責任者向けに、移行時の確認項目を5つに絞って整理します。
何が変わる？5段階からBuild・Launch・Growへ
公式Changelogでは、API usage tiersが5つから3つに簡素化され、Build、Launch、Growになったと説明されています。組織は総クレジット購入額がしきい値に達すると自動で上位Tierへ移ります。記事公開時点の公式ドキュメントでは、Freeは月100ドル、Buildは月500ドル、Launchは月5,000ドル、Growは月200,000ドルのusage limitsが示されています。
ここで重要なのは、これは単なる名称変更ではないことです。月間上限、モデルごとのRPM/TPM、上位Tierへの昇格条件が同じ画面で確認しやすくなり、PoCから本番運用へ移るときの予算説明がしやすくなります。
仕様表：3階層で見るべき数字
Buildの資格条件は累計5ドルのクレジット購入で、月間usage limitは500ドルです。Launchは累計100ドルで月5,000ドル、Growは累計500ドルで月200,000ドルです。Freeは許可された地域のユーザー向けに月100ドルの枠があります。
Standard rate limitsの例では、BuildのAstra/Sol/Terraは5,000 RPM・1,000,000 TPM、Lunaは5,000 RPM・2,000,000 TPMです。LaunchではAstra/Sol/Terraが10,000 RPM・4,000,000 TPM、Lunaが10,000 RPM・10,000,000 TPM。GrowではAstra/Sol/Terraが15,000 RPM・40,000,000 TPM、Lunaが30,000 RPM・180,000,000 TPMまで広がります。
ただし、実際の上限はモデル、処理モード、プロジェクト設定、共有レート制限によって変わります。運用判断では、ドキュメント上の代表値だけでなく、Platform consoleのSettings > Organization > Limitsで自社組織の値を確認する必要があります。
管理者が先に確認する5項目
1つ目は、現在のTierと次Tierへの昇格条件です。請求担当者は、累計購入額と月間利用実績を見て、PoCがBuildの範囲で足りるのか、Launch前提で設計すべきかを判断します。2つ目は、主要モデルのRPMとTPMです。チャット型アプリではRPM、RAGや大量要約ではTPMが先に詰まりやすくなります。
3つ目は、プロジェクト別の上限です。レート制限は組織レベルとプロジェクトレベルで効くため、本番、検証、個人開発を同じプロジェクトに混ぜると原因調査が難しくなります。4つ目は、spend alertとhard spend limitです。usage limitはOpenAI側の月間利用枠であり、spend limitsは自社が設定する予算ブレーキです。5つ目は、429と503の扱いです。急な増加によるslow_downと一時的なserver_is_overloadedは、監視とリトライ設計で分けて扱うべきです。
30日PoCの進め方：BuildからLaunchを見極める
最初の30日は、Buildで3種類のワークロードを分けて計測するのが現実的です。例えば、社内FAQ、営業メール要約、契約書チェックの3系統を別プロジェクトに分け、各プロジェクトで1日のリクエスト数、平均入力トークン、平均出力トークン、429発生率、月間予測コストを記録します。
7日目にはピーク時間帯のRPMを確認し、14日目には月末予測コストを出します。21日目にはLaunchに上げた場合の余裕を試算し、30日目に本番化の判断をします。判断軸は、上限に近いかどうかだけではありません。業務停止時の影響、部署追加時の伸び、キャッシュやBatchで抑えられる余地も一緒に見ます。
OpenAI APIの利用上限、予算設計、社内AI基盤のPoC設計を相談したい場合は、 HelloCraftAIにご相談ください 。用途別のモデル選定、プロジェクト分離、監視設計までまとめて整理できます。
よくある失敗：上限と予算を同じものとして扱う
よくある失敗は、usage limitを社内の予算上限だと誤解することです。usage limitはOpenAI API側で認められた月間利用枠で、予算を守るための停止条件とは別です。実際に予算事故を防ぐには、spend alertで早めに通知し、hard spend limitで止める設計が必要です。
もう1つの失敗は、Tierだけを上げてアプリ側のバックオフを直さないことです。Rate limitsのヘッダーには残りリクエスト数、残りトークン、リセット時間などが返るため、これをログに残せば、単なる容量不足なのか、急増へのslow_downなのか、モデル混雑による503なのかを切り分けやすくなります。
FAQ：OpenAI API usage tiersのよくある質問
Q. Build、Launch、Growは手動申請が必要ですか？ A. 公式ドキュメントでは、総クレジット購入額が条件に達すると組織のusage tierは自動で上がると説明されています。ただし、実際のレート制限はOrganization Limits画面で確認してください。
Q. Growならコスト管理は不要ですか？ A. 不要ではありません。Growは月間usage limitが大きく、LunaのTPMも大きくなりますが、予算を守る機能はspend alertsやhard spend limitsで別途設定します。
Q. どのタイミングでLaunchを前提にすべきですか？ A. 検証段階で1日のピークがBuildのRPM/TPMに近づく、部署追加で利用量が数倍になる、または本番停止の影響が大きい場合は、Launch前提の設計と監視に切り替えるべきです。
まとめ：3階層化は管理しやすくなったが、見るべき数字は増えた
OpenAI APIのusage tiersは、Build、Launch、Growの3階層に整理されたことで、PoCから本番化までの説明がしやすくなりました。一方で、現場が見るべき数字は月間usage limit、RPM、TPM、プロジェクト別制限、spend limits、429/503のログに分かれます。
まずは30日間、プロジェクトを分けて使用量を測り、Buildで足りる業務とLaunch以上が必要な業務を切り分けましょう。Tier変更そのものより、予算ブレーキと監視を先に整えることが、AI基盤を広げる近道です。
