OpenAIがAPIの利用ティアを3段階へ。最上位は500ドルで到達、上限は月20万ドル

AI 開発の見積書には、たいてい「API 利用料（従量）」という 1 行がある。トークン単価と想定回数を掛けた金額が入っていて、そこまでは読める。

書かれていないのは、そのアカウントが 1 か月にいくらまで使えるかと、1 分間に何回まで呼べるかである。この 2 つは単価とは別の仕組みで決まっていて、提供事業者側の「利用ティア（usage tier）」に紐づいている。

OpenAI がこのティアの構造を 2026 年 10 月 6 日に変更した。段数が 5 から 3 に減り、最上位への到達条件が下がっている。単価は変わっていないので値下げではないが、見積もりの前提が動く変更である。

公表されている事実

公式の変更履歴（2026 年 10 月 6 日）の記載はこうである。

Simplified API usage tiers from five to three: Build, Launch, and Grow. Organizations automatically upgrade as total credit purchases reach tier minimums. （API の利用ティアを 5 段階から 3 段階へ簡素化した。クレジット購入額の累計が各ティアの下限に達すると自動で上がる）

公式ドキュメントに載っている表は次のとおり。

ティア	到達条件（クレジット購入額の累計）	月あたりの利用上限
Free	対象地域であること	100 ドル / 月
Build	5 ドル	500 ドル / 月
Launch	100 ドル	5,000 ドル / 月
Grow	500 ドル	200,000 ドル / 月

同社の開発者向けアカウントは、最上位ティアの到達条件が 1,000 ドルから 500 ドルへ下がったと説明している。

毎分のリクエスト数（RPM）とトークン数（TPM）もティアで変わる。

ティア	モデル	RPM	TPM
Build	Astra / Sol / Terra	5,000	1,000,000
Build	Luna	5,000	2,000,000
Launch	Astra / Sol / Terra	10,000	4,000,000
Launch	Luna	10,000	10,000,000
Grow	Astra / Sol / Terra	15,000	40,000,000
Grow	Luna	30,000	180,000,000

同じ 10 月 6 日には、判定用途向けの Decisions API がベータ公開されている（この件は文章を書かないAIが同日に2本公開で扱った）。

なお、こうした段階制は 1 社に限った仕組みではない。他の主要な提供事業者も、支払い実績や契約形態に応じた上限を設けている。確認の作業はどの事業者を選んでも必要になる。

発注者・企業への影響

ここから先は見立てである。

1. 月額上限は「予算の目安」ではなく「止まる線」

月あたりの利用上限は、超えたら請求が増えるという話ではない。その月はそれ以上呼べなくなる線である。業務で使っているなら、機能が止まる。

金額の感覚を持つために、公開されている単価で逆算してみる。1 回の処理で入力 7,000 トークン・出力 1,000 トークンを使う社内問い合わせボットを想定する。

使うモデル	1 回あたり	Build（500 ドル / 月）で何回	Launch（5,000 ドル / 月）で何回
上位モデル（入力 2 ドル・出力 10 ドル / 100 万トークン）	約 0.024 ドル	約 2 万回	約 20 万回
軽量モデル（入力 0.1 ドル・出力 0.5 ドル / 100 万トークン）	約 0.0012 ドル	約 41 万回	約 410 万回

上位モデルの Build は月 2 万回、営業日 20 日で割ると 1 日 1,000 回である。社内 200 人が 1 日 5 回ずつ使えば届く。PoC を 5 人で回していた段階では一度も当たらない線が、全社に広げた月に当たる。

見積書の「API 利用料」が月 300 ドル相当と書かれていても、それはティアの上限とは別の数字である。単価の行だけを見て、上限の行が無いことに気づかないのがいちばんありがちな見落ちだと考えられる。計算資源の上限が前提になる話は計算資源の上限は見積もりの前提になるでも書いた。トークン課金の仕組み自体はトークン課金とはにまとめている。

2. ティアは「誰のアカウントか」に付く

ここが実務でもっとも引っかかる点である。到達条件はクレジット購入額の累計なので、ティアはアカウントの支払い履歴に紐づく。つまりアカウントの持ち主ごとに別である。

開発中、多くのプロジェクトでは開発会社のアカウントで API を呼んでいる。その会社は他の案件でも使っているので、累計額はすでに最上位に届いていることが多い。開発中は上限に当たらない。

ところが納品後、自社のアカウントへ切り替えると、累計購入額は 0 からである。最下段から始まる。上限は月 500 ドル、TPM は 100 万。開発環境では出ていた性能が出ない、という形で現れる。

切り替え時期を契約前に決めておけば、先にクレジットを購入して段を上げておける。逆に決めていないと、本番公開の直前に「上限に当たるので来月まで待ってください」という話になる。確認することは 3 つである。

• 開発中・運用中に使う API アカウントはどちらの名義か
• 自社名義へ移すのはいつか（検収前 / 検収後 / 移さない）
• 移すときの設定作業と再試験は誰の費用か

3 つ目は「別途」になりやすい項目である。見積書で外に出やすい費用はAI開発の見積書で「別途」になりやすい費用10個に一覧がある。

3. 毎分の上限は同時利用者数の設計制約になる

TPM は「1 分間に流せるトークンの合計」である。先の 1 回 8,000 トークンの例なら、Build の 100 万 TPM は毎分 125 回に相当する。

社内 50 人の利用なら余裕がある。しかし、朝の始業直後に全員が一斉に開くような使い方、あるいは 1 件あたり数万トークンを読む文書処理では話が変わる。1 回 40,000 トークンなら毎分 25 回である。

ここで必要なのは上限を上げることではなく、設計で逃がすこと。待ち行列に入れて順に処理する、夜間にまとめて走らせる、要約を先に作って読むトークンを減らす、といった作りにしておけば上限は制約として扱える。これは設計の話なので、契約後に判明すると作り直しになる。上限の種類と現れ方はレート制限・スループットとはで整理した。

4. 「秒で返る」と「1 分間に何件返る」は別の指標

提案書に書かれる応答速度は、たいてい 1 件あたりの時間である。利用ティアが決めるのは件数の方で、両者は別に確認する必要がある。

速度そのものが有料の選択肢になっている例はOpenAIが速度を有料ティア化で扱った。速度の上積みを買っても、毎分の件数の上限は別に残る。

見積もりを取るときに揃える 4 点

複数社に見積もりを依頼するなら、次を同じ文面で出す。これを書かないと、A 社は開発会社名義のアカウント前提、B 社は自社名義で段を上げる費用込み、という別物の金額が並ぶ。

1. 想定する月間処理件数とピーク時の毎分件数（概算でよい。桁が合えば足りる）
2. 1 件あたりの入力・出力トークンの想定（提案側に出させる。出せない会社は使う量を見積もっていない）
3. API アカウントの名義と、自社へ移す時期
4. 上限に当たったときの挙動（待たせる / 軽量モデルへ落とす / エラーを返す）のどれにするか

4 つ目は決めておかないと、当たった瞬間に画面がエラーになる作りで納品されることがある。無料で相見積もりの案件票では利用人数・処理件数・運用体制を選択式で揃えているので、各社が同じ前提で出したかを横並びで確認できる。

まとめ

今回の変更そのものは、使う側にとっては到達条件が緩む方向の話である。重要なのは段数が変わったことではなく、API には単価とは別に「月いくらまで」「毎分何件まで」という線があり、それがアカウントの支払い履歴に紐づいているという構造である。

発注側がやることは 2 つ。見積書に上限の行を足させること、そしてアカウントの名義と移管の時期を契約前に決めることである。どちらも契約前なら費用がかからない。

参考・出典

• OpenAI「Changelog」（2026 年 10 月 6 日の項） https://developers.openai.com/api/docs/changelog
• OpenAI「Rate limits」（利用ティアと上限の表） https://developers.openai.com/api/docs/guides/rate-limits
• OpenAI Developers（X・2026 年 10 月 6 日） https://x.com/OpenAIDevs/status/2107539647392096384