レート制限

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

レート制限を設ける理由

レート制限は API で広く採用されており、次のような理由で設けられています。

• API の悪用や誤用を防ぐためです。 たとえば、悪意のある第三者が API に大量のリクエストを送りつけ、過負荷やサービスの中断を引き起こそうとする場合があります。OpenAI はレート制限を設けることで、このような行為を防ぐことができます。
• 誰もが公平に API を利用できるようにするためです。 特定の個人や組織が過剰な数のリクエストを送ると、ほかのすべてのユーザーにとって API の動作が遅くなる可能性があります。OpenAI は、1 人のユーザーが送信できるリクエスト数を制限することで、できるだけ多くのユーザーが速度低下を感じることなく API を利用できるようにしています。
• OpenAI のインフラ全体にかかる負荷の管理に役立ちます。 API へのリクエストが急増すると、サーバーに負担がかかり、パフォーマンスの問題が生じる可能性があります。レート制限を設けることは、すべてのユーザーにとってスムーズで安定した利用環境を維持するうえで役立ちます。

レート制限の仕組み

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

Batch API のキューの上限は、モデルごとにキューに入っている入力トークンの総数に基づいて計算されます。未完了のバッチジョブのトークンは、キューの上限に対してカウントされます。バッチジョブが完了すると、そのトークンはそのモデルの上限に対してカウントされなくなります。

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

• レート制限は、ユーザー単位ではなく、組織単位およびプロジェクト単位で定義されます。
• レート制限は、使用するモデルによって異なります。
• GPT-5.5 のような長いコンテキストに対応したモデルでは、長いコンテキストを含むリクエストに別のレート制限が設けられています。これらのレート制限は、開発者コンソールで確認できます。
• OpenAI は、組織ごとに承認された月間利用上限を設定しています。これは、組織やプロジェクトに対してお客様が設定できる利用額の上限とは別のものです。
• 一部のモデルファミリーでは、レート制限を共有しています。組織の制限ページで「共有上限」の下に表示されているモデルは、同じレート制限を共有します。たとえば、表示されている共有 TPM が 3.5M の場合、その「共有上限」のリストにあるモデルへの呼び出しはすべて、この 3.5M に対してカウントされます。
• ベクトルストアへの取り込みにも、ベクトルストア ID ごとにレート制限が適用されます。/vector_stores/{vector_store_id}/files と /vector_stores/{vector_store_id}/file_batches は、ベクトルストアごとに 1 分あたり 300 リクエストという上限を共有します。大量のデータを取り込む場合は、/vector_stores/{vector_store_id}/file_batches の使用を推奨します。

利用ティア

組織のレート制限と利用上限は、アカウント設定の制限セクションで確認できます。API の利用額が増えると、利用ティアは自動的に次の段階に引き上げられます。通常、これに伴って、ほとんどのモデルでレート制限の上限が引き上げられます。

モデルごとのレート制限の概要は、モデルのページをご覧ください。

ヘッダー内のレート制限情報

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

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

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

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

組織のファインチューニングのレート制限も、ダッシュボードで確認できます。また、API 経由でも取得できます。

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

エラーの軽減

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

API は、リクエストレートが急激に増加した場合に slow_down を、リクエストしたモデルが一時的に過負荷になっている場合に server_is_overloaded を返すことがあります。これらの状況を区別するには、HTTP ステータスと error.code を確認します。

Retry-After がない場合は、再試行の間隔を長くし、短いランダムな待機時間を追加します。

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

目安として、入力トークン数が毎分 100 万トークン（TPM）に達したら、その後の増加率は 15 分ごとに 50% 以下に抑えてください。増加率の制限が適用される具体的な条件は、モデルやトラフィックの状況によって異なる場合があります。

従量課金のトラフィックが増加率の制限に頻繁に達するエンタープライズのお客様は、対象モデルでより予測しやすい処理容量を確保するために、スケールティアを検討できます。GPT-5.6 以降のモデルについては、Reserved Tier をご覧ください。容量ティアを利用しても、slow_down レスポンスへの対処方法は変わりません。Retry-After がある場合はその値に従い、トラフィックを減らしてから徐々に増やします。

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

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

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

SDK のエラーハンドラーでは、429 と 503 の両方を処理してください。たとえば、Python、TypeScript、Ruby では、429 に RateLimitError、503 に InternalServerError を使用します。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 クライアントを使用する場合、Retry-After ヘッダーが存在し、有効な値を含んでいれば、その値に従います。ヘッダーがない場合や値が無効な場合は、ジッター付きの指数バックオフに切り替えます。試行回数と再試行に費やす合計時間の両方に上限を設けてください。アプリケーション側で再試行を管理する場合は、入れ子になった再試行ループによってリクエスト数が増幅しないよう、SDK の再試行を無効にするか、それらも含めて上限を管理してください。クォータや請求に関するエラーなど、自分で対応する必要があるエラーでは再試行しないでください。

指数バックオフは、リクエストが失敗した後に短時間待機し、その後も再試行が失敗するたびに待機時間を長くする方法です。リクエストが成功するか、設定した再試行の上限に達するまで続けます。

この方法には、次のような利点があります。

• 自動再試行により、クラッシュやデータの欠落を起こさずにレート制限エラーから復旧できます
• 指数バックオフにより、最初は短い間隔で再試行でき、最初の数回が失敗した場合には、待機時間を長くする効果も得られます
• 待機時間にランダムなジッターを加えることで、再試行が同時に集中するのを防ぎやすくなります。

失敗したリクエストも 1 分あたりの上限にカウントされるため、リクエストを繰り返し送信し続けても解決しません。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19from openai import OpenAI
from tenacity import (
    retry,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI()


@retry(wait=wait_random_exponential(min=1, max=60), stop=stop_after_attempt(6))
def completion_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completion_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

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

client = OpenAI()


@backoff.on_exception(backoff.expo, openai.RateLimitError)
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completions_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

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# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI()

# 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 completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)

生成結果のサイズに合わせた max_tokens の引き下げ

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

リクエストのバッチ処理

即時のレスポンスが不要なユースケースでは、Batch API を使うことで、同期リクエストのレート制限に影響を与えずに、大量のリクエストをより簡単に送信して実行できます。

同期レスポンスが 必要な ユースケースでは、OpenAI API は 毎分のリクエスト数 と 毎分のトークン数にそれぞれ個別の制限を設けています。

毎分のリクエスト数の上限に達していても、毎分のトークン数に余裕がある場合は、複数のタスクを各リクエストにまとめることでスループットを向上できます。これにより、特に OpenAI の小型モデルでは、毎分処理できるトークン数を増やせます。

プロンプトをバッチで送信する場合も、通常の API 呼び出しと動作はまったく同じです。唯一の違いは、prompt パラメーターに単一の文字列ではなく、文字列のリストを渡すことです。詳しくは Batch API ガイドをご覧ください。