2026年のGPT Image 2レート制限：開発者が知っておくべきこと

やあ、みなさん。Doraです。3人のプロダクトチームで働く友人が、5月初旬にGPT Image 2の機能をローンチしました。ソフトローンチで、約200人のユーザーを招待。90分以内にその機能は壊れました——モデルが失敗したのではなく、彼らはTier 2にいて、最初の午後にそれらのユーザー（平均3〜5枚の画像を生成）からのバーストが20 IPMの上限に達したからです。

GPT Image 2のレート制限というのはそういうものです：制約だと感じないうちは制約に見えない。ドキュメントの表にあるTier番号は抽象的に見えます。それが具体的になるのは、キューの深さがそのTierが1分間に処理できる量を超えた瞬間です。この記事は、GPT Image 2を実際のプロダクトに組み込んでいるチーム向けです——単一プロンプトをベンチマークしている人向けではありません。OpenAI image APIのレート制限は、ロードテストとdev環境とでは異なる形で現れます。

免責事項：私はWaveSpeedAIでエージェントおよびイメージインフラについて書いています。以前の記事ではモデル評価の問題——GPT Image 2があなたのワークフローに合うかどうか——を取り上げました。この記事は、合うと判断した前提で、実際のトラフィックに耐えられるかどうかを見極める段階を想定しています。

2026年のGPT Image 2レート制限の実態

OpenAIのレート制限ドキュメントとGPT Image 2モデルページによると、このモデルはTPM（画像入出力とテキストトークンを含む1分あたりのトークン数）とIPM（1分あたりの画像数、ほとんどのワークフローにとってより厳しい上限）の2つの軸で計測されます。

TierベースのIPMとTPM構造

以下は2026年4月時点で公開されているGPT Image 2の制限です。Freeティアはサポートされていません。

Tier	TPM	IPM	おおよその適格支出
Tier 1	100,000	5	$5支払済み
Tier 2	250,000	20	$50支払済み + 7日
Tier 3	800,000	50	$100支払済み + 7日
Tier 4	3,000,000	150	$250支払済み + 14日
Tier 5	8,000,000	250	$1,000支払済み + 30日

2点注意事項があります。TierはプロジェクトやAPIキー単位ではなく、組織単位です——すべてのプロジェクトが同じGPT Image 2 IPMバジェットを共有します。OpenAIはこれらの数値を予告なく改訂することがあるため、上記の表はあくまで計画の基準です。アーキテクチャの意思決定をする前に、アカウントの制限ダッシュボードで確認してください。

これらの制限が実際に意味すること

Tier 1の5 IPM上限は、持続的には12秒に1枚の画像です。個人開発や小規模なプロトタイプには対応できますが、適度な同時接続がある公開機能には対応できません。Tier 5の250 IPM上限は高く聞こえますが、計算してみると：250枚/分 × 60分 = 1時間15,000枚。ローンチツイートで最初の1時間に5,000人のサインアップがあり、各ユーザーが1枚画像を生成すると、完璧な分散が実現したとしても（実際にはあり得ませんが）すでに容量の33%に達しています。

より深刻な障害モードはバースト状のトラフィックです。OpenAIのドキュメントには、制限は1分未満のウィンドウで適用されると記載されています。20 IPMは最初の1秒で20枚送信して残り59秒休めるという意味ではありません。2秒で5枚送信すると、分単位の平均が上限を大きく下回っていてもスロットルされます。

レート制限が本番環境の計画に与える影響

モデルの評価に2週間かかりました。実際のトラフィック下でそれを動かし続けるインフラには、最低でさらに2週間かかります。ほとんどのチームはこれを過小評価しています。

キュー設計、バッチ処理、リトライの意思決定

ここには3つの層があります。ほとんどのチームは2つしか構築しません。

第1層：クライアントサイドのレート制限。インフライトのリクエスト同時実行数をTierのIPMの約80%に制限し、1分間に分散させます。Tier 3（50 IPM）であれば、約40枚の画像を持続的に、その後ろにキューを配置します。

第2層：指数バックオフを使ったリトライ。OpenAI cookbookが推奨するのは、429に対してジッタリングされた指数バックオフです。標準的なパターン：ランダムジッタリングで1秒、2秒、4秒、8秒待ち、6回試行後に停止。これは必須です。429でのタイトループのリトライはアカウントにフラグが立てられます。

第3層——チームが省略するもの——はリクエスト形状の制御です。すべての画像がquality: highである必要はありません。すべてのワークフローが同期レスポンスを必要とするわけでもありません。OpenAIのBatch APIは別のクォータプールを持ち、24時間SLAで50%の価格設定です。夜間のサムネイル再生成にはバッチが適切なツールです。ユーザー向けの単一生成には適していません。ほとんどのチームは両者が混在していても、同じものとして扱います。「レート制限が問題」と「レート制限が背景に過ぎない」の違いは、非同期ワークを同期IPMプールから切り離してルーティングしているかどうかです。

スループットとスパイクに関するチームの期待値

これはドキュメント化されていない部分です。モデルではなく、プロダクトとオペレーションとの会話です。

Tier 2（20 IPM）では、p50レイテンシは概ねモデル依存——品質と推論モードによって8〜25秒。しかし持続的な負荷下でのp99にはキュー待ちが含まれます。1分間に21番目のリクエストを送信したユーザーは、12秒ではなく60秒待ちます。「画像は15秒で生成される」は、他の誰も生成していない場合にのみ当てはまります。

マーケティングキャンペーンやローンチでは、計画の問いは平均スループットではなく、ピーク分スループットです。キャンペーン開始後の4時間、通常の3倍のトラフィックが予想される場合、Tierがその3倍を破綻なく吸収できる必要があります——そうでなければ事前生成か、フォールバックが必要です。ローンチ前にどれか1つを選んでください。ローンチ中に選ぶのはうまくいきません。

レート制限がプロダクト問題になる時

GPT Image 2のスループットが、インフラの問いからプロダクトの問いになる閾値があります。シグナルは一貫しています：リトライキューがユーザーに見えるほど深くなった時、それはインフラ問題ではなくプロダクト問題です。

それを超えているサインは：

ユーザー向けのレイテンシばらつきが許容帯を超えている（例：リクエストの80%が20秒で完了するが、5%はバーストの後ろにキューされて90秒以上かかる）
Tier内に収まるために機能スコープを縮小している——「UIでバッチ生成なし」はその典型
単一の悪意あるユーザーや人気のシェアリンクが1分を飽和させ、他の全員を劣化させられる
Tier 5の申請が30日以上かかっているのにローンチは14日後

この状況に陥った時の正直な答えは：単一プロバイダーには運用上の上限がある。Tier 5でさえ上限です。大きなボリュームを運用しているチームは、事前生成とキャッシュ、クリティカルでないパスの代替モデルへのルーティング、または複数プロバイダー間で容量をプールするアグリゲーション/フォールバックレイヤーを検討し始めます。それぞれエンジニアリング面が増えます。それぞれ公開のレイテンシインシデントより安上がりです。

このセクションを書いていてしばらく立ち止まりました。WaveSpeedのフレーミングに滑り込みやすいからです。正直なところ：アグリゲーションはいくつかある選択肢の一つです。事前生成とキャッシュは多くの人が思うより多くを解決し、コストも低いことが多い。マルチプロバイダーレイヤーが必要かどうかは、ワークロードが本当にTier 5を超えているか、まだ最適化できていないかによります。アーキテクチャを考える前に診断してください。

スケールアップ前にビルダーが監視すべきこと

3つ、この順番で。

平均ではなくピーク時の実際のIPM。 すべてのレスポンスでx-ratelimit-remaining-imagesとx-ratelimit-remaining-tokensヘッダーをログに記録します。平均ではなく最小値を監視してください。ピーク分の残数がTierの20%を下回ったら、トラフィックスパイクで429になる一歩手前です。

障害モードの分布。 429を総リクエストに対する割合として追跡し、時間帯別に分解します。0.5%の429レートは問題ないように見えますが、マーケティングメールの配信時間帯に8%になっていることを発見するまで。時間バケットのメトリクスはこれを捕捉しますが、集計メトリクスでは分かりません。

Tierアップグレードまでの時間。 Tier 5には$1,000の支出と30日のアカウント年齢が必要です。2ヶ月以内にTier 5が必要な見込みであれば、今すぐ使い始めるか、最初の30日間はキャパシティ制約を受け入れてください。

ここで私のデータは終わります——私はGPT Image 2をTier 2とTier 3で運用したことがあり、Tier 5ではありません。Tier 5チームの報告によると、ダイナミクスが再び変わり、上限がIPMではなくリクエスト形状の効率になります。

FAQ

Tier別のGPT Image 2レート制限は？

2026年4月時点のOpenAIのドキュメントによると：Tier 1は100,000 TPM / 5 IPM、Tier 2は250,000 / 20、Tier 3は800,000 / 50、Tier 4は3,000,000 / 150、Tier 5は8,000,000 / 250。Freeティアはサポートされていません。制限は組織レベルで、すべてのプロジェクト間で共有されます。OpenAIはこれらを改訂することがあるため、アカウントダッシュボードで確認してください。

レート制限はスケール時の画像ワークフローにどう影響するか？

3つの面で：キュー設計（OpenAIの前にクライアントサイドの制限が必要）、レイテンシ分布（p99にはモデル時間だけでなくキュー待ちが含まれる）、ロードマップ（吸収できないスパイクを生むスコープを先送りする可能性がある）。よくあるパターン：チームは平均負荷向けに構築し、ピーク負荷がユーザー体験を決定することを後から発見します。

大量の機能をローンチする前にチームがすべきことは？

4ステップ。日次平均ではなくピーク分の生成ボリュームを見積もる。Tierが約30%のヘッドルームで対応できるか確認する。ジッタリングと指数バックオフおよびサーキットブレーカーを実装する。容量を使い切った場合のフォールバックを決める——事前生成、代替モデル、またはグレースフルデグラデーション。ローンチ当日に対処できない障害モードは、事前に計画していなかったものです。

いつ単一プロバイダーでは運用上不十分になるか？

ピーク分の需要が単一プロバイダーのTier 5容量を継続的に超える場合、SLAが単一プロバイダーの停止ウィンドウに耐えられない場合、または最適化にもかかわらずキュー待ちによるレイテンシばらつきがユーザーに見え続ける場合。ほとんどのチームはここに到達しません。到達するチーム——通常、バイラルパターンのあるコンシューマープロダクトや厳格なSLAのあるエンタープライズパイプライン——は事前生成、マルチプロバイダールーティング、またはその両方を追加します。その判断はピーク負荷のログから来るべきであり、ベンダーのマーケティングページからではありません。

まとめ

GPT Image 2レート制限の要約：Tier 1は5 IPMから始まり、Tier 5は250 IPMで上限に達し、バースト状のトラフィックはこれらの上限に定常状態の計算が示すよりはるかに速く達します。より詳しく言えば：レート制限は運用設計上の制約であり、ドキュメントの脚注ではありません。キュー、SLA、機能スコープ、ローンチ計画を形作ります。

ビルダーにとっての正しい問いは「自分はどのTierにいるか」ではなく、「ピーク分はどんな状況で、Tierはそれをマージンを持って吸収できるか」です。ほとんどのチームはローンチ後に、間違った方法でその答えを発見します。

GPT Image 2をTier 5で運用したらまたお伝えします。上記の数値はOpenAIのものであり、フレーミングは私のものです。容量ポリシーはブログ記事より速く更新されます。

過去の記事：