OpenAI APIの利用ティアを解説:Build、Launch、Growと支出上限
更新日 October 7, 2026 · 初回公開 October 7, 2026
OpenAIは2026年10月6日、有料のAPIティアをBuild、Launch、Growの3つに簡素化しました。累計のクレジット購入額が各しきい値を超えると、組織は自動的に上位のティアへ移り、一般にレート制限が引き上げられます。ティアは、キャパシティと月間利用枠を示すシグナルです。プロジェクトや組織の支出上限とは別のものであり、支出上限は予算管理として別途設定する必要があります。
OpenAI APIの利用ティアでは何が変わりましたか?
OpenAIの10月6日の変更履歴によると、APIプラットフォームは5つの有料ティアから、Build、Launch、Growの3つに移行しました。現在のレート制限ガイドには、次の認定レベルが記載されています。Buildはクレジット購入の合計$5、Launchは$100、Growは$500です。また、対象となる無料ティアのユーザーには月間$100の利用上限があることも記載されています。OpenAIは、上位のティアでは一般にモデルのレート制限が高くなると説明しています。
購入額は、ティアの適格性を判断するための累計のしきい値です。月額のサブスクリプション料金ではなく、毎月その金額をちょうど使うという約束でもありません。公開されているガイドでは、これらをクレジット購入の合計額として説明しています。実際のティア、承認された月間利用上限、モデルごとの上限は、組織のダッシュボードで確認してください。運用計画で重要なのは、組織のステータスです。
上位のティアはチームに何をもたらしますか?
レート制限は、1分あたりのリクエスト数(RPM)、1分あたりのトークン数(TPM)、1日のボリューム、画像のスループット、キューに入ったBatch処理を制約することがあります。ジョブが月間利用上限の範囲内でも、1分あたりの上限に達することがあります。現行のガイドにはモデルごとの違いが示されています。GPT-6 Astra、Sol、Terraでは、標準のRPM/TPMの例がBuildの5,000 RPMと1M TPM(100万)から、Launchの10,000 RPMと4M TPM(400万)、Growの15,000 RPMと40M TPM(4,000万)へと増えます。GPT-6 Lunaの標準上限はさらに異なります。これらは公開されている参考値であり、ご自身の組織、モデル、プロジェクトに表示される上限の代わりにはなりません。
この違いは、ローンチ時に重要です。月間の利用枠は十分に見込んでいても、新しいワークロードがトラフィックを急に送ったり、リクエストやトークンのスループットを超えたりすると、スロットリングを受けることがあります。レート制限は組織レベルとプロジェクトレベルの両方で適用されることがあり、複数のモデルが1つの上限を共有する場合もあります。ティア名をキャパシティの保証と見なす前に、レスポンスヘッダーとダッシュボードを確認してください。
利用ティアは月間支出を制限する手段ですか?
いいえ。OpenAIは、承認された月間利用上限を、組織やプロジェクトに設定できる支出上限とは別に記載しています。支出アラートは通知を送りますが、APIトラフィックは継続します。ハード支出上限は、設定した金額に達すると、対象のAPIリクエストを429レスポンスでブロックします。強制力が必要な場合はハード上限を選んでください。アラートは可視化であり、サーキットブレーカーではありません。
したがって、ティアのしきい値を超えるためにクレジットを購入することは、それだけでは安全なコスト管理の方針とは言えません。ティアはスループットを高められますが、プロジェクトごとのオーナーシップ、アラートの通知経路、利用予測、意図的に設定したハード上限の代わりにはなりません。ローンチのキャパシティを増やしたいエンジニアリングチームは、適格になるために必要な購入しきい値と、財務部門が強制したい別個の月間支出上限の両方をモデル化するべきです。
財務とエンジニアリングはティアのアップグレードをどう管理すべきですか?
- 組織とプロジェクトを棚卸しします。 各本番プロジェクトについて、ティア、月間利用枠、モデルごとのRPM/TPM、共有される上限、オーナーを記録します。
- 明示的な支出管理を設定します。 固定予算でトラフィックを止めるべき箇所にはプロジェクトレベルのハード上限を、早期警告が必要な箇所にはアラートを設定します。ティアの利用枠がこの管理を提供すると思い込まないでください。
- ワークロードの増加を見積もります。 月間のトークン支出に加えて、1分あたりのリクエスト数とトークン数を予測します。サービスは、月間のドル上限よりはるか前にスループットの上限へ達することがあります。
- ティアに関わる購入を統制します。 累計のしきい値を進める追加のクレジット購入は、アクセスとキャパシティに関する意思決定として扱います。申請の前に、ワークロード予測、オーナー、既存の管理策のレビューを求めます。
- 実際のレスポンスを観察します。 レート制限ヘッダーとログを使って、リクエスト、トークン、その他の上限の枯渇を区別します。一時的なレート制限のレスポンスにはバックオフを適用し、リトライの嵐を招かないようにします。
たとえば仮に、プロダクトチームがローンチキャンペーンで1分あたりのリクエスト数が3倍になる一方、月間のトークン使用量は財務の上限内に収まると見込んでいるとします。運用上の問いは、プロジェクトのモデル別RPMとTPMがその増加に耐えられるかどうかです。財務上の問いは、ハード支出上限が承認済みのキャンペーン予算に設定されているかどうかです。これらは関連するレビューですが、別々の管理策です。
BuildからLaunchへ移行すべきか、チームはどう判断すべきですか?
ティアの名称ではなく、ワークロードの証拠から始めてください。本番ログで現在のティアの上限が繰り返し枯渇している場合は、必要なRPMとTPMの余裕を見積もり、適用されるモデルとプロジェクトの上限を特定し、ダッシュボードでティアの効果を確認します。そのうえで、適格になるために必要なクレジット購入額を、ビジネス上の価値や予算方針と比較します。現在の上限で足りているなら、次のティアがあるというだけでアップグレードしても、運用上のメリットはありません。
OpenAIは、上位のティアでは一般に上限が引き上げられ、公開されているしきい値は変更される可能性があると述べています。予算サイクルの前や、トラフィックが大きく変わる前には、レート制限ガイドとダッシュボードを再確認してください。支出アラートとハード上限のレビューは、モデルの構成、リトライ、成功タスク1件あたりのコストと同じ月次のFinOps業務に組み込みましょう。
実務上の要点は何ですか?
Build、Launch、Growはキャパシティに関する問いに答えます。組織の累計購入額が増えるにつれて、どの上限と利用枠が適用されるのか、という問いです。支出管理は予算に関する問いに答えます。いつチームに警告し、いつリクエストを止めるのか、という問いです。両方を追跡してください。ティアのアップグレードはスループットを解放できますが、月間のコスト上限を強制できるのは、別途設定したハード上限だけです。
チームが読むべき関連リサーチは何ですか?
関連記事
この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 →