レート制限

レート制限とは、ユーザーやクライアントが一定期間内に OpenAI のサービスにアクセスできる回数に対して、API が設ける上限です。

レート制限の目的

API にレート制限を設けるのは一般的です。OpenAI がレート制限を設けている主な理由は次のとおりです。

• API の不正利用や誤用を防ぐためです。 たとえば、悪意のある利用者が大量のリクエストを送り、API に過剰な負荷をかけたり、サービスを妨害したりする可能性があります。OpenAI はレート制限を設けることで、こうした行為を防げます。
• 誰もが公平に API を利用できるようにするためです。 特定のユーザーや組織が過剰な数のリクエストを送ると、ほかの利用者への API の応答も遅くなる可能性があります。OpenAI はユーザーごとのリクエスト数を制限し、できるだけ多くの人が遅延なく API を利用できるようにしています。
• OpenAI のインフラ全体にかかる負荷を管理するためです。 API へのリクエストが急増すると、サーバーに負荷がかかり、パフォーマンスが低下する可能性があります。レート制限を設けることで、すべてのユーザーに安定したサービスを提供しやすくなります。

レート制限の仕組み

レート制限には、RPM（1 分あたりのリクエスト数）、RPD（1 日あたりのリクエスト数）、TPM（1 分あたりのトークン数）、TPD（1 日あたりのトークン数）、IPM（1 分あたりの画像数）などの指標を使用します。一部のストリーミング音声モデルでは、1 分あたりに処理する音声の長さ（分）も指標になります。いずれかの指標が上限に達した時点で、レート制限がかかります。たとえば、RPM の上限が 20、TPM の上限が 15 万の場合、ChatCompletions エンドポイントに合計 100 トークンのリクエストを 1 分間に 20 件送ると、トークン数が 15 万に達していなくてもリクエスト数の上限に達します。

Batch API のキュー上限は、モデルごとにキュー内の入力トークンの合計数で判定します。未完了のバッチジョブのトークンは、この上限に算入されます。バッチジョブが完了すると、そのトークンは該当モデルの集計対象から外れます。

このほか、次の点にも注意してください。

• レート制限はユーザー単位ではなく、組織単位とプロジェクト単位で設定されます。
• レート制限は、使用するモデルによって異なります。
• GPT-5.5 などの長いコンテキストに対応したモデルでは、長いコンテキストを使うリクエストに個別のレート制限があります。上限は開発者コンソールで確認できます。
• OpenAI は組織ごとに月間利用額の上限を定めています。これは、組織やプロジェクトで設定できる支出上限とは別のものです。
• 一部のモデルファミリーでは、複数のモデルがレート制限を共有します。組織の上限設定ページで同じ「共有上限」の一覧に表示されているモデルには、共通の上限が適用されます。たとえば、共有 TPM の上限が 350 万の場合、その一覧にあるどのモデルを呼び出しても、使用したトークンは同じ 350 万トークンの枠に算入されます。
• ベクトルストアへの取り込みにも、ベクトルストア ID ごとのレート制限があります。/vector_stores/{vector_store_id}/files と /vector_stores/{vector_store_id}/file_batches のリクエスト数は、各ベクトルストアで合わせて 1 分あたり 300 件までです。大量のファイルを取り込む場合は、/vector_stores/{vector_store_id}/file_batches の使用を推奨します。

利用ティア

有料の利用ティアは Build、Launch、Grow の 3 つです。組織のクレジット購入総額が各ティアの基準額に達すると、利用ティアは自動的に上がります。通常、上位のティアほど各モデルのレート制限の上限が高くなります。

Standard のレート制限

現在の利用ティアで各モデルに適用される上限を確認するには、Settings > Organization > Limits を開き、Rate limits を確認してください。利用ティアを上げるには、Upgrade tier を選択します。この項目は Usage Tiers セクションにあります。

ここで示す Standard のレート制限は、Ultrafast のレート制限とは異なります。

支出上限

月々の API 利用額を管理するには、組織やプロジェクトに支出上限を設定することを検討してください。以下の設定は、前述の月間利用上限とは別に適用されます。

レスポンスヘッダーのレート制限情報

レート制限はアカウントページで確認できます。HTTP レスポンスのヘッダーでも、残りのリクエスト数やトークン数など、レート制限に関する情報を確認できます。

レスポンスには次のヘッダーフィールドが含まれる場合があります。

プロジェクト単位のトークン上限が適用される場合は、プロジェクトのトークン数に関するヘッダーが含まれることがあります。Retry-After は、一時的なレート制限による 429 レスポンスや、モデルの一時的な過負荷による 503 レスポンスに含まれることがあります。このヘッダーがあっても、利用枠や請求に関するエラーなど、ユーザーによる対応が必要なエラーは再試行では解消できません。

ファインチューニングのレート制限

組織のファインチューニングのレート制限は、ダッシュボードで確認できます。次のように API から取得することもできます。

curl https://api.openai.com/v1/fine_tuning/model_limits \
  -H "Authorization: Bearer $OPENAI_API_KEY"

モデルの利用可否

モデルへのアクセス権とレート制限は別々に設定されます。利用ティアの基準額に達しても、すべてのモデルへのアクセス権が付与されるわけではありません。ドキュメントに記載されているモデルが Playground または GET /v1/models の結果に表示されない場合や、リクエストに対して model_not_found が返る場合は、次の手順で確認してください。

1. モデル ID とエンドポイントを確認します。 モデルのドキュメントに記載されている ID を正確に指定してください。そのモデルが使用するエンドポイントに対応しているかを確認し、モデルの提供終了や利用可否に関するお知らせがないかも確認してください。
2. 組織、プロジェクト、認証情報を照合します。 Playground で目的の組織とプロジェクトを選択してください。List models を呼び出す際は、失敗したリクエストと同じ API キーを使用してください。そのリクエストで OpenAI-Organization ヘッダーや OpenAI-Project ヘッダーを指定していた場合は、それぞれ同じ値を指定してください。現在のダッシュボードのセッションで表示されるモデルでも、別の API キーでは利用できない場合があります。
3. プロジェクトの制限とモデルの利用要件を確認します。 プロジェクトを管理できる人に、プロジェクトのモデル利用権限とデータ保持設定の確認を依頼してください。モデル固有のアクセス要件がある場合はそれに従い、モデルのドキュメントで段階的な提供に関するお知らせも確認してください。モデルが表示されないというだけでは、原因を特定できません。
4. 表示を更新して再度確認します。 アクセス設定を変更したら、モデル一覧または Playground を再読み込みしてください。それでもモデルを利用できない場合は、モデル ID、組織 ID、プロジェクト ID、リクエストを送信した時刻、エラーメッセージを添えてサポートにお問い合わせください。レスポンスに x-request-id ヘッダーが含まれている場合は、その値もお知らせください。API キーは共有しないでください。

エラーへの対処

トラフィックの急増とモデルの過負荷への対処

リクエストの送信レートが急激に上がると、API は slow_down を返すことがあります。リクエスト先のモデルが一時的に過負荷になると、server_is_overloaded を返すことがあります。この 2 つは HTTP ステータスと error.code で区別できます。

レスポンスに Retry-After がない場合は、再試行の間隔を延ばし、ランダムな短い待機時間を加えてください。

トラフィックの増加による slow_down エラーは、1 分あたりのリクエスト数とトークン数がどちらも上限内であっても発生することがあります。このエラーは、上限に達したかどうかではなく、トラフィックがどれだけ急激に増えたかを示します。

目安として、1 分あたりの入力トークン数（TPM）が 100 万に達したら、それ以降の増加幅は 15 分ごとに 50% 以内に抑えてください。トラフィックの増加率に対する制限がどの時点で適用されるかは、モデルやトラフィックの状況によって異なります。

従量課金のトラフィックが日常的に増加率の上限に達するエンタープライズのお客様は、対象モデルの処理容量をより確実に見込めるスケールティアをご検討ください。GPT-5.6 以降のモデルについては、Reserved Tier をご覧ください。どの容量ティアでも、slow_down レスポンスへの対処方法は同じです。Retry-After があればその指定に従い、トラフィックを減らしてから徐々に増やしてください。

既存のエラーハンドラーの更新

アプリケーションが従来のレート制限や過負荷のレスポンスを処理していた場合は、HTTP ステータスと error.code の両方を確認してください。

• 以前はどちらの場合も 503 と slow_down を返していたエンドポイントでは、現在、トラフィックの急増時には 429 と slow_down を返します。モデルの過負荷時には引き続き 503 を返しますが、エラーコードは server_is_overloaded です。
• 動画リクエストがこれらの理由でジョブの作成前に拒否された場合、以前は 429 とともに、エラーの種類として invalid_request_error、コードとして rate_limit_exceeded が返りました。現在は、トラフィックの急増時には 429、rate_limit_error、slow_down が返り、モデルの過負荷時には 503、service_unavailable_error、server_is_overloaded が返ります。動画ジョブのステータスに表示されるエラーは別のケースです。

SDK のエラーハンドラーでは、429 と 503 の両方を処理してください。たとえば、Python、TypeScript、Ruby では RateLimitError が 429 に、InternalServerError が 503 に対応します。Java ではそれぞれ RateLimitException と InternalServerException を使用します。アプリケーションが従来のレスポンスコードを受け取る可能性がある間は、それらのコードにも引き続き対応してください。ほかのエラーでも同じ HTTP ステータスが返ることがあるため、対処方法を決める前にエラーの本文を確認してください。

ストリーミングリクエストでこれらの HTTP エラーレスポンスが返るのは、ストリームの開始前です。開始後のエラーはストリームイベントとして届くことがあります。出力を受け取った後は、リクエストを自動で再送しないでください。

レート制限エラーを減らす方法

OpenAI Cookbook には、レート制限エラーの回避方法を解説した Python ノートブックと、レート制限の範囲内で API リクエストをバッチ処理する Python スクリプトの例があります。

プログラムからのアクセス、一括処理、ソーシャルメディアへの自動投稿といった機能を提供する際も注意が必要です。これらの機能を有効にする対象を、信頼できる顧客に限定することを検討してください。

自動化による不正利用や大量の不正利用を防ぐには、日、週、月などの期間を定め、ユーザーごとに利用上限を設定してください。上限に達した時点で利用を停止するか、上限を超えたユーザーを個別に手動で審査する仕組みを検討してください。

指数バックオフによる再試行

リクエストが一時的なレート制限を超えると、API は 429 エラーを返します。レスポンスには、再試行までに待機する秒数を示す Retry-After ヘッダーが含まれることがあります。この値は待機時間の下限です。指定された時間以上待機し、さらにランダムな短い待機時間を加えて、複数のクライアントが同時に再試行するのを避けてください。

各 OpenAI 公式 SDK は、再試行設定に従い、対象となる 429 および 503 レスポンスを受けたリクエストを自動で再試行します。Retry-After の扱いは SDK のバージョンや設定によって異なり、特に長い待機時間を指定された場合は挙動に違いがあります。サーバーが指定するすべての待機時間に対応していると仮定せず、インストール済みのバージョンの挙動を確認してください。

サーバーが指定した待機時間が有効でも、サポートされている上限や設定した上限を超える場合は、待機時間を短縮して再試行せず、再試行を打ち切ってリクエストを後に回してください。SDK は、上限を超える待機時間を受け入れず、元の HTTP エラーを返すことがあります。キャンセルとタイムアウトのエラーは、この HTTP エラーとは別に処理してください。リクエストのキャンセルや期限切れによって、その HTTP エラーが返らないまま再試行が終了することがあります。各試行のタイムアウトが、処理全体の期限を定めているとは限りません。

独自の HTTP クライアントを使用している場合は、Retry-After ヘッダーがあり、その値が有効であれば、指定に従ってください。ヘッダーがない場合や値が無効な場合は、ジッターを加えた指数バックオフを使用してください。試行回数と再試行に費やす合計時間の両方に上限を設けてください。アプリケーション側で再試行を管理する場合は、SDK の再試行を無効にするか、SDK による再試行も上限に含めてください。これにより、再試行ループが入れ子になってリクエストが何倍にも増えるのを防げます。利用枠や請求に関するエラーなど、ユーザーによる対応が必要なエラーでは再試行しないでください。

指数バックオフでは、リクエストに失敗したら短時間待機し、その後は再試行に失敗するたびに待機時間を延ばします。リクエストが成功するか、設定した再試行の上限に達するまで、この手順を繰り返します。

この方法には次の利点があります。

• 自動で再試行するため、アプリケーションのクラッシュやデータの欠落を起こさずにレート制限エラーから復旧できます。
• 指数バックオフを使うと、最初は短い間隔で再試行でき、失敗が続いたときには長めに待機できます。
• 待機時間にランダムなばらつき（ジッター）を加えることで、再試行が同時に集中するのを防ぎやすくなります。

失敗したリクエストも 1 分あたりの上限に算入されるため、待機せずにリクエストを送り続けても解決しません。

以下の例では、gpt-6-luna を指定した Responses API へのリクエストを再試行します。各ラッパーは試行回数に上限を設け、SDK に組み込まれた再試行機能を無効にします。

以下の Python の例は、サーバーから有効な待機時間の指定を得られない場合のバックオフを示しています。これらの例では Retry-After を確認していません。使用する前に、サーバーの有効な指定を処理するロジックを追加し、ラッパーが指定時間より早く再試行しないようにしてください。SDK の再試行を無効にするか、アプリケーションの再試行上限に含めてください。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28from openai import OpenAI, RateLimitError
from tenacity import (
    retry,
    retry_if_exception_type,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI(max_retries=0)


@retry(
    retry=retry_if_exception_type(RateLimitError),
    wait=wait_random_exponential(min=1, max=60),
    stop=stop_after_attempt(6),
    reraise=True,
)
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19import backoff
import openai
from openai import OpenAI

client = OpenAI(max_retries=0)


@backoff.on_exception(backoff.expo, openai.RateLimitError, max_tries=6)
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI(max_retries=0)

# define a retry decorator


def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""

    def wrapper(*args, **kwargs):
        # Initialize variables
        num_retries = 0
        delay = initial_delay

        # Loop until a successful response or max_retries is hit or an exception is raised
        while True:
            try:
                return func(*args, **kwargs)

            # Retry on specific errors
            except errors:
                # Increment retries
                num_retries += 1

                # Check if max retries has been reached
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    )

                # Increment the delay
                delay *= exponential_base * (1 + jitter * random.random())

                # Sleep for the delay
                time.sleep(delay)

            # Raise exceptions for any errors not specified
            except Exception:
                raise

    return wrapper


@retry_with_exponential_backoff
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

出力長に合わせた max_tokens の引き下げ

レート制限の計算には、max_tokens とリクエストの文字数から推定したトークン数のうち、大きい方の値が使われます。max_tokens は、想定されるレスポンスのトークン数にできるだけ近い値に設定してください。

リクエストのバッチ処理

即時のレスポンスが不要な場合は、Batch API を使用すると、同期リクエストのレート制限に影響を与えずに、大量のリクエストをまとめて送信、実行できます。

同期レスポンスが必要な場合、OpenAI API では、1 分あたりのリクエスト数と1 分あたりのトークン数にそれぞれ別の上限が適用されます。

1 分あたりのリクエスト数が上限に達していても、トークン数に余裕がある場合は、複数のタスクを 1 件のリクエストにまとめることでスループットを高められます。特に小規模なモデルでは、この方法で 1 分あたりに処理できるトークン数を増やせます。

複数のプロンプトをまとめて送信する方法は、通常の API 呼び出しと同じです。唯一の違いは、prompt パラメーターに単一の文字列ではなく、文字列のリストを渡すことです。詳しくは Batch API ガイドをご覧ください。