OpenAI APIのレート制限：GPT-6 AstraのTier別上限と429/503対策

GPT-6 Astra（APIモデルID: gpt-6-astra）を使うとき、公開されているレート制限だけを見て処理量を決めるのは危険です。公開表が示すのは Standard 処理の Usage Tier 別上限であり、実際に使えるモデルと上限はAPI組織・プロジェクトによって異なります。まず自分の Limits ページを確認し、実際のレスポンスに含まれる x-ratelimit-* ヘッダーで残り枠とリセット時刻を読んでください。

2026年9月4日時点では、APIとしてリリースされたことと、すべてのアカウントで使えることは同じ意味ではありません。OpenAI API changelogはAstraのAPIリリースを2026年9月3日と記録していますが、公式モデルページは提供を段階的に進めていると案内しています。モデルへアクセスできない状態を、RPMやTPMの超過と決めつけないことが重要です。

GPT-6 Astra Standardの公開レート制限

OpenAIのGPT-6 Astraモデルページで確認できる Standard の値は次のとおりです。数値と提供状況は変わり得るため、表には確認日を付けています。

Free ではこのモデルを利用できません。ただし、有料アカウントであることや該当Tierにいることだけで、Astraへのアクセスが保証されるわけではありません。段階的な提供状況、API組織、プロジェクト、契約上の資格を別々に確認する必要があります。

RPM は1分あたりのリクエスト数、TPM は1分あたりのトークン量です。どちらか先に達した方がボトルネックになります。たとえば、ピーク時に毎分80件、1件あたり平均18,000トークンを処理するなら、概算は毎分144万トークンです。リクエスト数は Tier 2 の5,000 RPMを大きく下回りますが、TPMは公開上限の100万を超えます。この場合、RPMだけを見て「十分余裕がある」と判断できません。

Batch queue はリクエスト件数でも1日のトークン枠でもありません。公式レート制限ガイドによると、同じモデルで処理待ちになっているBatchジョブの入力トークン合計です。ジョブが完了すれば、その入力トークンはBatch queueの上限を占有しなくなります。たとえば入力5,000トークンのジョブを300件待機させると150万トークンになり、Tier 1 の公開上限に達します。

この表を Fast、別バージョンのモデル、Work、Codex に転用してはいけません。Fast modeの公式ガイドでは、同一モデルの Standard と Fast はレート制限を共有すると説明されています。Fast は待ち時間を短くする選択肢であって、別のRPM・TPM枠を追加する手段ではありません。

公開表より先に自分の実効上限を確認する

運用時の基準は、一般公開のtier表ではなく、自分のAPI組織・プロジェクトに現在適用されている値です。確認は次の順で行うと、アクセス問題とレート超過を混同しにくくなります。

1. OpenAI Platform の Limits で現在の Usage Tier とモデル別上限を確認する。
2. API キーが属する組織とプロジェクトを確認する。
3. Astra がそのプロジェクトで選択可能かを確認する。
4. 実際の API レスポンスから上限、残り枠、リセット時刻を記録する。

OpenAI APIのレート制限は利用者単位ではなく、organizationとprojectの両方で適用されます。モデルごとに上限が異なる場合があり、モデルファミリーで枠を共有する場合もあります。Astraが他モデルと必ず独立した枠を持つとは、公開tier表だけからは判断できません。APIキーと組織の対応が曖昧なら、OpenAI API KeyとOrganization IDの確認方法も先に整理してください。

レスポンスヘッダーで残り枠を読む

OpenAIのレート制限ヘッダーでは、少なくとも次の組を確認できます。

ヘッダーは1回の成功レスポンスだけ保存するのではなく、モデル、エンドポイント、プロジェクト、HTTPステータス、error.type、error.code と一緒に時系列で記録します。リクエスト残数だけが先に減るのか、トークン残数が先に尽きるのか、リセット後も同じ失敗が続くのかを比較できるからです。

次のように読むと、最初の修正を絞れます。

ヘッダー値が取得できない失敗でも、推測で上限を埋めないでください。レスポンス本文、Limits、API 組織・プロジェクト、公式モデルページを突き合わせます。

429と503は同じ再試行で処理しない

Astra の処理が止まったら、HTTP ステータスだけでなく error.type と error.code を読みます。OpenAIのトラフィック急増と過負荷のガイドは、少なくとも次の二つを区別しています。

slow_down は、表示上のRPM・TPMをまだ使い切っていなくても発生し得ます。総量だけでなく、トラフィックを立ち上げる速さが問題だからです。夜間バッチを毎時ちょうどに一斉起動する、デプロイ直後に全ワーカーを同時起動する、失敗した全ジョブを同時に戻す、といった形では起きやすくなります。ワーカーを段階的に増やし、キューから取り出す間隔にばらつきを入れてください。

server_is_overloaded はアカウントの残高不足を示すコードではありません。最初から API キーを交換したり、支払いを追加したりするのではなく、Retry-After を優先し、続く場合は OpenAI Status と障害の時間帯を確認します。代替モデルへ切り替えるなら、出力品質や機能差を事前に検証した経路だけを使います。

どちらも Retry-After が返る場合はその値を優先します。返らない場合は、上限時間を設けた指数バックオフにジッターを加えます。再試行回数、合計待機時間、キューへ戻す条件、失敗として確定する条件を決めずに無限再送してはいけません。

ts
const maxAttempts = 6;
const maxDelayMs = 15_000;

let response = await sendRequest();

for (let attempt = 0; attempt < maxAttempts && isRetryable(response); attempt += 1) {
  const retryAfter = readRetryAfter(response.headers); // 秒またはHTTP日時を解釈
  const exponential = Math.min(maxDelayMs, 500 * 2 ** attempt);
  const delay = retryAfter ?? exponential + Math.random() * exponential * 0.25;

  await sleep(delay);
  response = await sendRequest();
  // 再送後のstatus、error.code、残り枠を改めて記録する。
}

このコードは骨格にすぎません。Retry-After の解釈、冪等性、タイムアウト、キャンセル、SDKやゲートウェイ側の自動再試行を含め、アプリケーション全体で一つの再試行予算にする必要があります。再試行と代替モデルの判断を分ける手順は、LLM APIの再試行とフォールバックを分ける5項目で詳しく説明しています。

公開されていない上限は推定しない

2026年9月4日に確認したAstraの公式ページで公開されているレート制限は、RPM、TPM、Batch queueです。次のAstra固有値は、確認した公開資料には掲載されていません。

• RPD（1日あたりのリクエスト数）
• TPD（1日あたりのトークン量）
• 同時実行数または同時に処理中のリクエスト数
• 長いコンテキスト専用のRPM・TPM

「公開されていない」は「システム内に存在しない」という意味ではありません。別のモデルの値、料金、RPMとTPMの比率から推定せず、Limits と実際のレスポンスで確認してください。長いコンテキストに別の上限が適用される可能性についても、公式レート制限ガイドは開発者コンソールでの確認を案内しています。

コンテキスト長とTPMも別物です。Astraの公式モデル仕様には、コンテキストウィンドウ1,050,000トークン、最大入力922,000トークン、最大出力128,000トークンとあります。入力が272Kを超える場合の価格条件もありますが、272Kはレート制限の境界ではなく、長い入力に対する料金の境界です。これらの数値から、Astra固有の長文RPMや同時実行数を逆算することはできません。

WorkやCodexの利用枠とは分けて考える

OpenAI APIのRPM・TPMと、ChatGPTの Work や Codex で表示される利用枠は別の仕組みです。ChatGPTのワークスペースでAstraを有効にしても、その操作だけでAPIキーにAstraへのアクセスは付与されません。Enterprise向けの公式提供案内でも、ワークスペース側の有効化とAPIアクセスは分けて説明されています。

Work/Codexの公式料金案内にあるメッセージ数の目安、5時間単位や週単位の利用枠、creditsによる消費は、APIのRPM・TPMではありません。反対に、APIのUsage Tierを上げても、ChatGPTで使えるメッセージ数を直接増やすことにはなりません。

切り分けるときは認証方法を確認します。

• APIキーでOpenAI APIを呼んでいるなら、API組織・プロジェクトの Limits とレスポンスヘッダーを見る。
• ChatGPTアカウントで Work や Codex にサインインしているなら、そのプランの利用枠とワークスペース設定を見る。
• Codex にAPIキーを設定しているなら、Codexの画面上の契約ではなく、そのキーが属するAPIプロジェクトの上限を見る。

Codex側の制限を調べたい場合は、OpenAI Codexの利用制限とCodexのAPIキー利用とサブスクリプションの違いを参照してください。APIの429対策としてChatGPTプランだけを変更する、あるいはWorkのcreditsをAPIの処理量へ換算するのは誤りです。

導入前に必要量を見積もる

処理量の設計では、1日平均ではなく最も集中する時間帯を使います。次の三つを別々に見積もってください。

1. ピーク1分間に発生するリクエスト数
2. その1分間の入力と出力を含むトークン量
3. Batch APIを使う場合、同じモデルで待機中になる入力トークン合計

公開表のRPM・TPMを両方満たし、かつ現在の Limits で同じ値を確認できて初めて、名目上の処理量を置けます。実運用では、急増、再試行、入力長のばらつき、モデルファミリーで共有する可能性を吸収できる余裕も必要です。余裕率は公式の固定値ではないため、自社のトラフィック分布と許容遅延から決めます。

リアルタイム性が不要な処理はBatch APIへ移せますが、Batch queueの上限は待機中の入力トークンで消費されます。投入前にジョブ数だけでなく入力トークンを集計し、完了したジョブが枠から外れる速度も監視します。Fastへ切り替えてもレート制限はStandardと共有されるため、容量不足の解決策にはなりません。

障害時の判断手順

実際に止まったときは、次の順番なら不要な変更を抑えられます。

1. モデル、エンドポイント、API組織、プロジェクトを記録する。
2. HTTPステータス、error.type、error.code、Retry-After を保存する。
3. リクエスト数とトークン量の limit、remaining、reset を保存する。
4. Limits と照合し、公開tier表ではなく実効値を採用する。
5. アクセス不可、RPM、TPM、急な流量増加、503、請求・契約のどれかに分ける。
6. 並列数、入力・出力、送信ペース、再試行のうち原因に合う一つを小さく直す。
7. 同じ観測項目で回復を確認してから、必要なら上限変更を検討する。

RPMが原因なら送信の平準化と並列数の調整、TPMが原因なら会話履歴や不要な文脈、過大な最大出力の見直しが先です。slow_down ならワーカーを段階的に戻し、server_is_overloaded なら指定された時間を待ちます。請求やアクセス資格の問題は、バックオフを精巧にしても解決しません。

上限の引き上げを検討するのは、正しいプロジェクトを使い、処理量の偏りと不要なトークンを減らし、再試行を制御しても、継続的な需要が実効上限を超える場合です。その際は、対象モデル、エンドポイント、ピークRPM・TPM、リセットの観測、並列数、実施済みの削減策をまとめると、必要量を説明しやすくなります。

まとめ

GPT-6 Astraの公開レート制限は、2026年9月4日時点で Standard の Tier 1 から Tier 5 までRPM、TPM、Batch queueが示されています。ただし、その表はモデルへのアクセスや各プロジェクトの実効上限を保証しません。Limits と x-ratelimit-* ヘッダーを現在の基準にしてください。

障害時は、Astraへのアクセス待ち、通常のRPM・TPM超過、429 の slow_down、503 の server_is_overloaded を分けます。Retry-After を守り、原因に合う送信ペース、並列数、トークン量だけを修正します。そしてOpenAI APIの上限を、Work や Codex のメッセージ枠・creditsと混ぜない。この切り分けが、無駄な再試行や誤ったプラン変更を避ける最短経路です。