OpenAI API利用枠が3段階へ｜Build/Launch/Grow上限表

OpenAI は2026年10月6日、API の利用枠（usage tiers）を5段階から3段階へ簡素化しました。新しい枠の名前は Build / Launch / Grow。無料の Free を含めた月間の利用上限は Free が $100、Build が $500、Launch が $5,000、Grow が $200,000（いずれも1か月あたり）で、昇格はクレジット購入の累計額が各枠のしきい値（$5 / $100 / $500）に達した時点で自動で行われます。申請も審査もありません。

実務で効くのはここからです。この「月間利用上限（ドル）」とは別に、モデルごとの「標準レート上限（RPM / TPM）」があり、さらに Ultrafast モードは標準とは完全に別枠のレート上限を持ちます。「枠を上げたのに Ultrafast だけ 429 で詰まる」という事故が起きるのは、この3つを1つの数字だと思い込んだときです。この記事では OpenAI 公式のレート制限ドキュメントの表をそのまま置いたうえで、中小企業がどの枠で足りるのかという読み方まで整理します。

なお旧5段階（Tier 1〜5）の金額や上限、新しい3段階との対応関係は公式に記載がありません。「旧 Tier 3 は新 Launch 相当」といった換算は本記事では行いません（推測で書くと、そのまま見積もりの根拠に使われてしまうためです）。

【2026年10月6日】Build / Launch / Grow と月間利用上限

公式ドキュメントは「有料の利用枠は Build・Launch・Grow の3つ」と明記し、しきい値と月間上限を次の表で示しています。Free は有料枠には数えられておらず、条件は「対象地域にいること」だけです。

ここで読み落としやすいのが「クレジット購入総額」が累計であって、月次の支払額ではないという点です。過去に合計 $500 分のクレジットを買っていれば、その月の利用がわずかでも Grow のままです。逆に言えば、$500 を一度入れるだけで月間上限は $200,000 まで開くので、上限に困って問い合わせる前にまずクレジット残高の履歴を見るのが正解になります。

枠が上がると「一般に、モデル横断でレート上限も高くなる」と公式は書いています。つまり枠はドルの上限とレートの上限を同時に動かすつまみです。レートだけを上げる方法は、OpenAI の担当チームがつく組織を除けば用意されていません。

混同しやすい4つの「上限」を分けて考える

詰まりの原因を切り分けるには、名前の似た上限を最初に分けておくのが早いです。公式ドキュメントの記述を整理すると次の4つになります。

公式は「OpenAI は組織ごとに承認済みの月間利用上限を設定する。これは組織やプロジェクトに自分で設定できる支出上限とは別物である」とはっきり書いています。前者は上げてもらう対象、後者は自分でかける歯止めという違いです。請求が怖くて Free のまま使い続けるより、Build に上げたうえで支出上限を $50 に設定するほうが、実務では安全かつ速くなります。

モデル別の標準レート上限（RPM・TPM）

標準モードのレート上限は、枠とモデルファミリーの組み合わせで決まります。GPT-6 系の Astra / Sol / Terra と、軽量な Luna で数字が違うのがポイントです。

表から読める実務的な結論を2つ挙げます。

ひとつめ。Luna は同じ枠でも TPM が大きい（Build で2倍、Launch で2.5倍、Grow で4.5倍）。大量の分類・抽出・要約をさばくバッチ処理は、上位モデルで無理に流すより Luna に寄せたほうがレートの頭を打ちません。Grow の Luna は 180,000,000 TPM で、Astra / Sol / Terra の 40,000,000 TPM と桁が違います。

ふたつめ。中小企業の規模では、レート上限より月間のドル上限が先に当たります。Build の 1,000,000 TPM は単純計算で1日あたり14億4,000万トークンで、これを使い切るほどのトークン量を $500 の枠内で買うことはできません。「速度の上限に当たった」と感じたときは、多くの場合バーストの作り方（短時間に集中させている）か、次に述べる Ultrafast の別枠が原因です。

あわせて公式が注意しているのが、一部のモデルファミリーはレート上限を共有している（組織の Limits 画面で「shared limit」に並ぶモデルは同じ枠を食い合う）点と、長文コンテキスト向けのリクエストには別のレート上限がある点です。また Batch API のキュー上限は投入済み入力トークンの総量で計算され、ジョブが完了すればその分は解放されます。即時性の要らない処理を Batch に逃がせば、同期リクエストのレート上限を消費しません。トークン自体を減らす手としては、GPT-6 のプロンプトキャッシュで入力コストを下げる方法が併用できます。

Ultrafast は標準と別枠（ここが実務の落とし穴）

Ultrafast モードは OpenAI API で最速のサービスティアで、GPT-6 Astra と GPT-6.1 Sol で広く利用できます（GPT-5.6 Sol はプレビュー）。そして公式は「Ultrafast は標準モード・Fast モードとは別のレート上限を持つ」と明記しています。既定の TPM は次のとおりです。

右端の標準 TPM と並べると、落とし穴の正体が見えます。GPT-6 Astra の Ultrafast は、どの枠でも標準の半分から8分の1しかありません（Build で 500,000 対 1,000,000、Grow では 5,000,000 対 40,000,000）。同じモデル・同じ枠・同じコードでも、service_tier に ultrafast を指定した瞬間に別の、しかも狭い勘定に切り替わるということです。

したがって実務の手順はこうなります。枠を上げたら「上がったこと」を確認するのではなく、Ultrafast を使っている経路だけ別に実測する。公式も「Ultrafast は標準・Fast と別のレート上限なので、トラフィックを増やす前に組織の上限を確認すること」と注意しています。それでも足りない場合、上限の引き上げを頼めるのは OpenAI の担当チームがついている組織に限られます。

もうひとつ、Ultrafast には接続の作法があります。公式はWebSocket の利用を強く推奨しており、特にツール呼び出しが連続するエージェント用途では、永続接続がないとネットワークのオーバーヘッドでせっかくの低遅延が相殺されると書いています。データの置き場所も差があり、GPT-6.1 Sol の Ultrafast は US と EU のデータレジデンシーとグローバル処理に対応、GPT-6 Astra の Ultrafast は US とグローバル処理のみです。EU 要件のある案件では、モデル選択がそのままコンプライアンス要件に直結します。

速度を上げる選択肢そのものの比較は、ChatGPT Pro の Ultrafast と API 側の違いを整理した記事と、GPT-6 Sol の料金体系をまとめた記事が参考になります。

ここまでの切り分けは、慣れていれば30分で終わります。ただ「どのモデルをどの経路で呼ぶか」を業務フローごとに設計し直す段になると、社内に前例がないぶん迷いやすい部分です。Mihata では、こうした API の枠とコストの設計を含めた独自AIの構築支援も行っています。記事の途中で恐縮ですが、自社で抱えるには重いと感じたときの選択肢として、よろしければ覗いてみてください。

支出上限は2種類（アラートとハード上限）

自分でかける歯止めは2段あります。公式ドキュメントの区別は明快です。

実務での勘所は、ハード支出上限による 429 は、レート制限による 429 と見分けがつきにくいことです。リトライやバックオフを実装していると、支出上限で止まっているのにクライアントが延々と再試行して「原因不明の停止」に見えます。アラートを先に鳴らしておく（アラートは通信を止めない）設計のほうが、障害対応が速くなります。

いま何で詰まっているかを見分ける（ヘッダーとエラーコード）

詰まりの切り分けは、ダッシュボードを開く前にレスポンスヘッダーで済みます。公式が返すと明記しているフィールドのうち、実務で見るのは次の5つです。

• x-ratelimit-limit-requests / x-ratelimit-limit-tokens ── いまの上限そのもの。枠が上がったかはここで確認する
• x-ratelimit-remaining-requests / x-ratelimit-remaining-tokens ── 残量。どちらが先に減るかで RPM 律速か TPM 律速かが分かる
• x-ratelimit-reset-requests / x-ratelimit-reset-tokens ── 初期状態に戻るまでの時間（6m0s のような表記）
• x-ratelimit-limit-project-tokens 系 ── プロジェクト単位のトークン上限が効いているときに現れる。組織の上限に余裕があるのに詰まる場合はここを見る
• Retry-After ── 再試行まで待つべき最小秒数

Retry-After の読み方には公式の注意書きがあります。このヘッダーは「一時的なレート制限による 429」と「モデルの一時的な過負荷による 503」に付くことがありますが、クォータ・課金など利用者側の対応が必要なエラーがリトライで解決することを意味しません。ここを読み違えると、支払い情報の不備で止まっているものを永久にリトライし続ける実装になります。値は最小待ち時間として扱い、そこに小さなランダム遅延を足すのが公式の推奨です。

エラーコードの対応も整理されています。リクエスト数の増え方が急すぎる場合は 429 の slow_down、モデルが一時的に過負荷の場合は 503 の server_is_overloaded。前者は RPM / TPM の範囲内でも出るのが曲者で、「上限を使い切ったか」ではなく「どれだけ急に増やしたか」を反映します。公式の目安は入力 1,000,000 TPM に達したら、15分あたり50%以上は増やさないこと。新サービスのローンチ当日にトラフィックを一気に流す計画なら、ここを織り込んでおく必要があります。

中小企業の現実的な読み方（どの枠で足りるのか）

先に断っておくと、「月 $500 で足りるか」はモデルの単価と使うトークン量で決まるため、枠の数字だけでは答えが出ません。以下は枠の構造から言える範囲の目安と、Mihata が実務で置いている仮定です。仮定の部分はそう明記します。

Build（$500 / 月）で収まりやすい使い方

社内の人数に比例してトークンが増えるタイプの使い方は、Build の範囲に収まりやすい側です。たとえば社内ナレッジ検索、議事録の要約、メール下書き、問い合わせの一次分類といった用途は、1日に流れる件数が人数と営業日で上限を持ちます。（仮定）利用者が数十人規模で、1件あたりの入出力が数千トークンに収まるなら、月 $500 の枠は現実的な天井として機能します。実際の消費はモデルの単価次第なので、最初の1か月は支出アラートを低めに置いて実測するのが確実です。

Launch（$5,000 / 月）以上が必要になりやすい使い方

枠が足りなくなるのは、トークン量が社員数ではなく顧客数・アクセス数に比例し始めたときです。自社サービスにチャットを組み込む、エンドユーザー向けの生成機能を提供する、長文ドキュメントを丸ごと毎回投げる、といった構造では、売上の伸びとそのまま同じ曲線で消費が伸びます。（仮定）Launch の $5,000 を超える組織は、社内利用ではなく自社プロダクトに API を組み込んでいるケースが大半だと考えていますが、これは公式が公表している分布ではないので目安として扱ってください。

枠を上げる前に試す順番

上限に当たったとき、クレジットを積む前に効く手が3つあります。順番にも意味があります。

1. プロンプトキャッシュと入力の整理。同じ前提文を毎回送っているなら、まずここでトークンが減ります
2. モデルの振り分け。分類・抽出のような定型処理を Luna に寄せる。前述のとおり Luna は同じ枠でも TPM が大きく、単価も上位モデルより低く設定されています
3. Batch API への退避。即時性が不要な処理を同期リクエストから外せば、レート上限の取り合いから抜けられます

この3つをやっても足りないなら、それは本当に事業が伸びている合図です。$5 でも $500 でも、クレジットを買えば自動で枠は上がるので、作業としては一瞬で終わります。

同じ週に入った、API 側のその他の変更

利用枠の簡素化と前後して、changelog には3つの変更が並んでいます。いずれも枠の話と一緒に見ておくと判断が速くなるものです。

10月6日 ── Decisions API のベータ公開。gpt-6-luna を使う v1/decisions エンドポイントが追加されました。公式の説明は「テキストと画像を型付きの回答に変える。Responses API より10倍速い」。分類や抽出のような「決まった形の答えが欲しい」処理をここに寄せられるなら、レート上限の取り合いの観点でも効きます。

10月8日 ── GPT-6.1 Sol に Ultrafast モードを追加。Responses API で gpt-6.1-sol に service_tier: "ultrafast" を指定すると、出力トークン間の時間が縮みます。全 API ユーザーが利用可能（レート上限あり）で、グローバル処理と US・EU のデータレジデンシーに対応します。本記事の Ultrafast の表は、この追加を反映した時点のものです。

10月5日 ── HIPAA 対応の申請フローを組織設定に追加。API の組織設定から BAA（事業提携契約）を受諾する流れが用意されました。米国の医療情報を扱う案件での前提条件がセルフサービス化された、という位置づけです。日本国内の案件では直接は効きませんが、海外の医療系と組む可能性があるなら押さえておく変更です。

エージェント用途での枠の効き方は、OpenAI Agents API の構成と導入前の制約にまとめた内容と合わせて読むと設計の勘所がつかめます。セッションを長く開けたまま並列でサブエージェントを走らせる設計では、枠の違いが「何本まで同時に通るか」に直接出ます。

まとめ：3段階になって何を変えるべきか

やることは多くありません。第一に、自組織の枠と、標準／Ultrafast それぞれのレート上限を Limits 画面とレスポンスヘッダーの両方で確認する。第二に、支出アラートを低めに設定して実測する（ハード上限だけ置くと 429 の原因が分かりにくくなります）。第三に、上限に当たったらクレジットを積む前にキャッシュ・モデル振り分け・Batch の3手を試す。枠の昇格は自動なので、焦って設定を探し回る必要はありません。

AI の導入そのもので迷われている場合も、枠やコストの設計から一緒に整理できます。お気軽にご相談ください。