AI APIのレート制限：仕組みと対処法

AI APIからの429レスポンスは、4つの異なる事態を意味する可能性があります。1分あたりのリクエスト数が多すぎる、1分あたりのトークン数が多すぎる、同時接続数が多すぎる、あるいはアカウント残高が不足している、のいずれかです。これら4つはすべて同じステータスコードを返すため、解決策は「とにかく再試行する」ことではなく、どの制限に抵触したかを診断することにあります。本ガイドでは、障害モードの分類、現在の制限に関して利用可能な証拠とそうでないもの、そして本番環境で耐えうる再試行およびフォールバックのパターンを解説します。

重要なポイント

• 429は、リクエスト上限、トークン予算、同時実行数制限、またはアカウント残高不足を意味します。それぞれ異なる対処が必要であり、一律の再試行では4つのうち1つしか解決できません。
• エラー発生後だけでなく、成功したレスポンスのレート制限ヘッダーも読み取り、上限に達する前にスロットリング（制限）を行ってください。
• クライアント側のトークンカウントはあくまで推定であり、保証ではありません。使用しているライブラリとプロバイダーの実際のカウント方法との間にトークナイザーの不一致があると、想定よりも安全マージンが狭くなる可能性があります。
• モデルおよびティアごとの正確なRPM/TPM上限は、本記事で利用可能な証拠には含まれていません。他で見かける数値は固定値ではなく、自身のアカウントダッシュボードで確認すべきものとして扱ってください。
• 回復力のある再試行には、指数バックオフ、ジッター（揺らぎ）、最大再試行回数の設定、そしてretry-afterヘッダーの尊重が必要です。冪等（べきとう）でない操作を盲目的に再試行してはいけません。

AI APIのレート制限を理解する：4つの障害モード

リクエスト制限

ほとんどのプロバイダーは1分あたりのリクエスト数（RPM）をカウントしています。これを超えると即座に429が返され、多くの場合レスポンスボディは空です。ユーザーが結果を急速にページングしたり、cronジョブがスロットリングなしで実行されたりすることが一般的なトリガーとなります。

トークン制限

チームが最も過小評価しがちな罠です。プロバイダーはRPMとは別に1分あたりのトークン数（TPM）を課すことが多いため、リクエスト上限に達していなくても429に抵触する可能性があります。大規模コンテキストモデルではこれがさらに深刻になります。TokenLabのライブ価格データ（2026年7月7日観測）によると、Claude Opus 4.8とGPT-5.5はどちらも1,000,000トークン以上のコンテキストをサポートしています。大きなドキュメントやコードベース全体、あるいは長いチャット履歴をそのウィンドウに読み込む呼び出しは、たとえ「1回」のリクエストであっても、1分あたりのトークン予算の大部分を消費する可能性があります。これは呼び出しごとのトークン数ではなく、コンテキストウィンドウサイズに基づくキャパシティプランニングのリスクであるため、固定値を想定するのではなく、自身のログで実際の使用量を確認してください。

同時実行制限

プロバイダーは、一度に50個のストリームを開くまでは、1分あたりの平均ボリュームを許容するかもしれません。同時実行制限は、処理中（in-flight）のリクエストや接続の同時数を制限します。ストリーミングレスポンスは接続を長く保持するため、短い単発の呼び出しよりも速く同時実行枠を使い果たします。Claude Sonnet 5やKimi K2.7 Codeで構築されたコーディングエージェント、Gemini 3.5 Flashでストリーミングを行う音声インターフェースなどは、一度に多くの長寿命接続を維持するため、一般的なトリガーとなります。

クォータまたは残高の枯渇

これはダッシュボード上ではレート制限と同一に見え、呼び出しが機能しなくなります。しかし、解決策は異なります。アカウントのプリペイドクレジットが切れたり、厳しい1日の支出上限に達したりすると、APIはレート制限に似たエラーを返します。ここではバックオフは無意味です。残高を補充するか、支出のしきい値を引き上げる必要があります。

ソーススナップショット

データポイント	ソース	観測日
モデルのコンテキストウィンドウとトークン単価	TokenLab ライブモデル/価格データ	2026-07-07
モデルSSOT命名（Claude Sonnet 5, GPT-5.5, Gemini 3.5 Flash等）	TokenLab モデルSSOT	2026-07-07（2026-07-14失効）
公式プロバイダーのRPM/TPMティア制限	本データセットには含まれていません	未検証、プロバイダーのアカウントダッシュボードを確認のこと
TokenLabゲートウェイのヘッダー正規化動作	本データセットには含まれていません	単一のヘッダー仕様に依存する前にTokenLab APIドキュメントを確認のこと

現在のモデルコンテキストウィンドウと価格（TokenLab ライブデータ）

これらの数値はTokenLabのライブ価格スナップショットから直接取得したものです。これらはRPMやTPMの制限ではなく、大規模コンテキストモデルでの単一の呼び出しが、なぜトークン予算を不釣り合いに消費するのかを示しています。

モデル	プロバイダー	コンテキストウィンドウ	入力 $/MTok	出力 $/MTok	ソース	観測日
Claude Sonnet 5	Anthropic	1,000,000	$2.00	$10.00	TokenLab ライブ価格データ	2026-07-07
Claude Opus 4.8	Anthropic	1,000,000	$5.00	$25.00	TokenLab ライブ価格データ	2026-07-07
Claude Fable 5	Anthropic	1,000,000	$10.00	$50.00	TokenLab ライブ価格データ	2026-07-07
GPT-5.5	OpenAI	1,050,000	$5.00	$30.00	TokenLab ライブ価格データ	2026-07-07
GPT-5.5 Batch/Flex	OpenAI	1,050,000	$2.50	$15.00	TokenLab ライブ価格データ	2026-07-07
Gemini 3.5 Flash	Google	1,048,576	$1.50	$9.00	TokenLab ライブ価格データ	2026-07-07
GLM-5.2	Z.ai	1,048,576	$0.93	$3.00	TokenLab ライブ価格データ	2026-07-07
Kimi K2.7 Code	Moonshot AI	262,144	$0.74	$3.50	TokenLab ライブ価格データ	2026-07-07
DeepSeek V4 Pro	DeepSeek	1,048,576	$0.44	$0.87	TokenLab ライブ価格データ	2026-07-07
DeepSeek V4 Flash	DeepSeek	1,048,576	$0.09	$0.18	TokenLab ライブ価格データ	2026-07-07
Qwen3.7 Plus	Alibaba	1,000,000	$0.32	$1.28	TokenLab ライブ価格データ	2026-07-07
MiniMax M3	MiniMax	1,048,576	$0.30	$1.20	TokenLab ライブ価格データ	2026-07-07

モデルSSOTに関する注記：これらの名称は2026年7月7日に観測され、2026年7月14日に失効するTokenLabモデルSSOTを反映しています。命名や可用性は頻繁に変更されます。本番コードにモデル文字列をハードコードする前に、TokenLabモデルディレクトリまたはモデルリーダーボードで解決できることを確認してください。

再試行ロジックをゼロから構築せずにレート制限エラーを修正する

上記はすべて診断です。どのモデルにフォールバックするかを決定し、ユーザーごとの同時実行数を追跡し、どのモデルファミリーが健全かをリアルタイムで把握するという修正作業こそ、TokenLabのルーティングレイヤーが吸収するために構築されたものです。5つのプロバイダーにまたがるフォールバックマトリックスを自前で作成する代わりに、リクエストをTokenLabに向けることで、可用性とフォールバックルールに基づいて現在のモデルカタログからゲートウェイが選択するようにできます。

正直な注意点として、TokenLabは複数のアップストリームプロバイダーの前に位置しており、各アップストリームは独自のヘッダーセット、エラー形式、再試行セマンティクスを返します。ゲートウェイがすべてのレート制限ヘッダーを1つの整合性のあるスキーマに完全に正規化するのか、あるいは一部のアップストリームヘッダーをそのまま通過させるのかは、本記事で利用可能な証拠では確認されていません。すべてのモデルで単一の統一スキーマを前提とした解析ロジックを書く前に、TokenLabのAPIドキュメントで現在のヘッダーの動作を確認してください。ヘッダーパーサーは、各フィールドが存在すると仮定するのではなく、存在を確認するように防御的に構築してください。

レート制限ヘッダーの読み取り

プロバイダーはレスポンスヘッダーでレート制限情報を返しますが、正確な名称はプロバイダーによって異なります。一般的なパターンは以下の通りです：

x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499
x-ratelimit-reset-requests: 12s
retry-after: 0

これらは429エラーの後だけでなく、成功したレスポンスでも読み取ってください。残りの予算をローリングカウントし、安全しきい値（通常は10〜20%の余裕）を下回ったときに速度を落としてください。ただし、適切な数値はトラフィックのバースト性に依存するため、本データセットで指定することはできません。

明示的なエラーハンドリングを伴う再試行ロジック

再試行ヘルパーは429ケース以外も処理する必要があります。一時的なエラー（429、503、タイムアウト）と、再試行しても成功しないクライアントエラー（429以外の4xx）を区別し、存在する場合はretry-afterを尊重する必要があります。

async function callWithRetry(fn, maxRetries = 4) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const status = err.status;

      // 429以外のクライアントエラーは再試行しても成功しない
      if (status && status >= 400 && status < 500 && status !== 429) {
        throw err;
      }

      // エラーの種類に関わらず最大再試行回数で終了
      if (attempt === maxRetries) throw err;

      // 429: retry-afterがあれば尊重し、なければジッター付きでバックオフ
      if (status === 429) {
        const retryAfter = parseRetryAfterHeader(err);
        const delay = retryAfter
          ? retryAfter * 1000
          : Math.pow(2, attempt) * 1000 + Math.random() * 1000;
        await sleep(delay);
        continue;
      }

      // 503またはネットワークタイムアウト: バックオフして再試行、監視用にログ記録
      if (status === 503 || err.code === 'ETIMEDOUT' || err.code === 'ECONNRESET') {
        await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
        continue;
      }

      // 不明な5xx: バックオフして再試行、試行回数を厳格に制限
      if (status && status >= 500) {
        await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
        continue;
      }

      throw err;
    }
  }
}

決済処理や副作用を伴う書き込みなど、冪等でない操作を単純な再試行ループでラップしてはいけません。冪等性を確認するか、冪等性キーを使用してからそれらの呼び出しを再試行してください。

トークン推定の精度：なぜローカルカウントがプロバイダーのカウントとずれるのか

クライアント側のトークンカウントライブラリは、特定のモデルが実際に使用するトークナイザーを近似しています。tiktokenはOpenAIのファミリーに近いものですが、Anthropic、Google、またはオープンウェイトのトークナイザーと完全に一致する保証はありません。違いは特殊トークン、マルチバイト文字、システムプロンプトのフォーマット周辺で現れ、長い会話では累積されます。

ドリフトを減らすための実践的なステップ：

• レスポンスボディで返される実際のトークン使用量を読み取り（ほとんどのプロバイダーはプロンプトと完了トークン数を含んでいます）、それを使用して時間の経過とともにローカル推定器を調整してください。
• ハードな境界線ではなく、安全マージンを維持してください。プロバイダーのTPM上限が推定使用量に近い場合は、ギリギリで送信するのではなく、リクエストを遅らせるか分割してください。
• プロンプトが大きく、呼び出し間で繰り返される場合は、TokenLabのトークン化動作とプロンプト分割戦略に関する情報を参照し、上限に達する前にリクエストあたりのトークンを削減する具体的な方法を確認してください。呼び出しごとのトークンを削減することは、上位ティアを交渉するよりも安価な解決策になることがよくあります。

トラフィックシェーピングとモデルフォールバック

ジッター付きの指数バックオフ。再試行のたびに待機時間を倍にし、ランダムなジッターを追加することで、同時実行クライアントが同期して再試行しないようにします。

ユーザーまたはタスクごとのトラフィックシェーピング。ユーザーごとの同時呼び出しを制限（例：3同時、1秒あたり5リクエストのバースト）し、1人のヘビーユーザーがアカウント全体の制限を使い果たして他のユーザーのパフォーマンスを低下させないようにします。

送信前のトークン予算推定。クライアント側でトークンをカウントし、リクエストが追跡中のTPM予算を超過する場合は、送信して期待するのではなく、遅延させるか分割します。

安全策としてのモデルフォールバック。プライマリモデルが429を返したときに、別の制限と能力を持つ代替モデルにルーティングします。コーディングタスクであればClaude Sonnet 5からDeepSeek V4 ProやKimi K2.7 Codeにフェイルオーバーできます。高ボリューム・低コストのワークロードであれば、DeepSeek V4 Flash、Gemini 3.5 Flash、Qwen3.7 Plusの間でフェイルオーバー可能です。これらはすべて現在のモデルカタログの低コストルーティングティアに含まれています。

レート制限ハンドリングチェックリスト

カテゴリ	確認事項	即時アクション	長期的な修正
リクエスト制限	RPMヘッダー値、バースト頻度	クライアントリクエストのスロットリング、ローカルレートリミッターの追加	ユーザーごとのティア設定、サーバーサイドのキューイング
トークン制限	モデルごとのTPM予算、呼び出しごとの平均トークン、レスポンス報告使用量	トークンの事前カウント、大きなプロンプトの分割、上限付近での呼び出し遅延	トークン予算管理を伴うバッチ処理、高ボリューム作業の低コストモデルへのルーティング
同時実行制限	最大同時ストリームまたは接続数	クライアントごとの同時リクエスト上限設定、アイドルストリームのクローズ	コネクションプーリング、ストリーム開始のスタッガード（時間差）起動
クォータ / 残高	アカウント残高、1日の支出上限	クレジットの補充、支出閾値の調整	低残高アラート、プリペイドの自動補充

一般的な制限範囲：確認できることとできないこと

このトピックの二次検索では、「一般的な」RPM/TPM数値の表が求められることがよくあります。私たちはそれを作成しません。公開されているティアごとの制限は頻繁に変更され、アカウント履歴や使用ティアによって異なり、本記事で利用可能な証拠の一部ではありません。

質問	ステータス	検証ステップ
フロンティアモデルの「一般的な」RPM制限は？	本データセットでは未確認	プロバイダーのアカウントダッシュボードまたはレート制限レスポンスヘッダーを直接確認
1Mコンテキストモデルの「一般的な」TPM制限は？	本データセットでは未確認	1週間のトラフィックからレスポンスヘッダーの実際の使用量を記録し、独自のベースラインを構築
使用ティアによってこれらの数値は変わるか？	一般的なプロバイダーの動作に基づくと妥当だが、ここではベンチマークしていない	プロバイダーコンソールで現在のティア制限を確認
TokenLabの集約制限はアップストリームプロバイダーの制限と完全に一致するか？	本データセットでは未確認	キャパシティプランニングの前にTokenLabのAPIドキュメントで検証

制限事項

• GPT-5.5、Claude Opus 4.8、Gemini 3.5 Flash、その他ここで参照されているモデルについて、公式のRPM/TPM数値は利用できませんでした。上記の価格表にある数値はすべてコンテキストウィンドウサイズとトークン単価であり、レート制限ではありません。
• TokenLabのゲートウェイがすべてのアップストリームプロバイダー間でレート制限ヘッダーを完全に統一するのか、あるいは一部をそのまま通過させるのかは、本データセットでは確認されていません。ドキュメントで現在のゲートウェイの動作を検証するまでは、ヘッダー解析はプロバイダー固有のものとして扱ってください。
• 本記事のモデル名は2026年7月7日に観測され、2026年7月14日に失効するTokenLabモデルSSOTを反映しています。モデル文字列をハードコードしたコードを出荷する前に、モデルディレクトリで現在の可用性を確認してください。
• トークン推定の精度とプロバイダー側のカウントとの比較は、本データセットではベンチマークされていません。固定オフセットを信頼するのではなく、レスポンスで報告された使用量に対して独自の推定器を調整してください。

FAQ

リクエスト数が制限内なのにアプリが429エラーになるのはなぜですか？ まずトークン・パー・ミニット（TPM）予算を確認してください。リクエスト数が少なくても、1つの大きなプロンプトがトークン許容量を使い果たす可能性があります。また、同時実行数も確認してください。開いているストリーミング接続は、RPMとTPMの両方が正常に見えても新しいリクエストをブロックする可能性があります。

429を受け取ったときにすぐに再試行すべきですか？ いいえ。retry-afterで指定された期間を待つか、そのヘッダーがない場合はジッター付きの指数バックオフを使用してください。即時の再試行は「サンダリング・ハード（群れによる攻撃）」効果のリスクがあり、ロックアウト期間を延長する可能性があります。

ローカルのトークンカウントがプロバイダーの請求額と一致するかどうかはどうすればわかりますか？ 正確にはわかりません。クライアント側のトークナイザーは近似値です。各レスポンスボディで返されるトークン使用量を読み取って時間の経過とともに推定器を調整し、推定上限ギリギリでリクエストを送信するのではなく、安全マージンを維持してください。

TokenLabはすべてのモデルで統一されたレート制限ヘッダーセットを公開していますか？ ここで利用可能な証拠では確認されていません。アップストリームプロバイダーによって異なるヘッダー形式が返されるため、TokenLabがどの程度の正規化を適用しているかは、想定するのではなく現在のAPIドキュメントで検証してください。

プランをアップグレードせずにレート制限を回避するにはどうすればよいですか？ トークン予算管理、ローカル同時実行上限、モデルフォールバックを組み合わせてください。送信前にトークンを推定し、長いプロンプトを分割し、プライマリ制限に達した場合はClaude Sonnet 5からDeepSeek V4 Proへ切り替えるなど、別のモデルへルーティングしてください。

はじめに

レート制限はAI APIを構築する上での事実ですが、障害を引き起こす必要はありません。TokenLabのゲートウェイは、現在のモデルカタログとライブ価格およびスループットデータへのアクセスを提供するため、制限を推測するのではなく、制限を回避するルーティングが可能です。アグリゲーターのトレードオフを評価している場合は、OpenRouter比較でフォールバックの動作と運用オーバーヘッドについて詳しく解説しています。tokenlab.shでAPIキーを取得し、プロバイダーごとではなく、一度の構築で再試行およびフォールバックロジックを実装してください。