Azure OpenAI の 429 を調べるときは、呼び出し先デプロイに割り当てた TPM と、失敗したリクエストのレスポンスヘッダーを先に確認してください。 サブスクリプションに余っているクォータや、Azure Monitor の少ないトークン使用量だけでは、リクエストを受け付けられる状態かどうかは分かりません。
TPM は 1 分あたりのトークン数の上限ですが、制限の判定に使われるのは受信時点の推定最大処理トークン数です。処理後に確定する課金トークン数とは異なります。また、1 分あたりのリクエスト数を表す RPM は、短い時間幅でも評価されます。このため、少ない課金使用量と 429 は両立します。Microsoft Learn のレート制限の説明
以下は主に Standard 系デプロイの診断手順です。2026 年 9 月 5 日時点の仕様に基づき、PTU と API Management を使う場合の分岐も示します。
最初の 429 で残す情報
再試行後の最終結果だけを記録すると、途中の 429 が見えなくなります。まず、同じ処理の初回と再試行を区別できるようにし、次の情報を失敗した試行ごとに残します。
- タイムゾーンを含む送信時刻、HTTP ステータス、エラー本文、返されたリクエスト ID。
- サブスクリプション、リソース、デプロイ名、モデルとバージョン、デプロイの種類、リージョン。
- 出力上限の設定、入力の長さ、再試行回数。入力本文を保存する必要はありません。
- 応答に含まれるレート制限ヘッダーと、その試行を送ったアプリケーションまたはワーカー。
公式のレスポンスヘッダー一覧を使うと、設定値と実際の制限を比較できます。
| 記録するヘッダー | 診断で見る点 |
|---|---|
x-ratelimit-limit-tokens | 応答が示す TPM 上限。デプロイの設定値と一致しているか |
x-ratelimit-remaining-tokens | トークンの残り枠が少なくなっているか |
x-ratelimit-limit-requests | 応答が示す RPM 上限。TPM から独自に換算しない |
x-ratelimit-remaining-requests | 短いリクエストでも回数の残り枠を使い切っていないか |
retry-after-ms | 429 後の推奨待機時間。単位はミリ秒 |
x-ratelimit-reset-tokens / x-ratelimit-reset-requests | リセットに関する情報。生の値を残し、形式を確かめてから利用する |
ヘッダーがなければ「残り枠は十分」とは判断できません。API Management などの中継サービスが削除・変更している可能性もあります。許可されたログやトレースで、中継前後の応答を確認します。
この情報と同じ時間帯の送信件数を並べ、対処を選びます。
| 見えている状態 | 最初に確かめること | 試す変更 |
|---|---|---|
| サブスクリプションには余裕があるが、特定デプロイだけ 429 | そのデプロイへの TPM 割り当て | 未使用分の再配分、または割り当ての増加 |
| 課金トークンは少ないが、出力上限を大きく設定している | リクエスト受信時の見積もりに影響する設定 | 必要な回答量に合わせて出力上限を下げる |
| バッチ開始直後や複数ワーカーの起動直後に集中する | 1 秒・10 秒単位の到着件数 | キューからの送信間隔を均す |
| 応答のトークン上限が設定した TPM より低い | 同じデプロイの応答か、設定反映待ちか、一時調整か | 負荷を下げて待機し、時刻付きの応答を比較する |
| ゲートウェイ側で拒否され、Azure 側への送信がない | 適用中のポリシーとカウンター | ゲートウェイの制限に合わせて送信を調整する |
1 本のヘッダーだけで原因を断定せず、設定、エラー本文、前後の試行を合わせて見てください。Microsoft は容量不足や一時的な実効上限の引き下げも 429 の原因として挙げています。429 の原因と対処
クォータの総量と、呼び出し先の割り当てを照合する
クォータはデプロイに配分できる利用枠です。利用枠が承認されていても、アクセスが集中するデプロイに十分な TPM を割り当てていなければ、そのデプロイのレート制限に達します。TPM と RPM の比率もモデルによって異なるため、「1,000 TPM につき必ず 6 RPM」とは計算できません。クォータの割り当てとモデル別の比率
2026 年の共有範囲は Scope 列で確認する
リージョンを増やす前に、Foundry の Quota 画面で対象モデルの Scope 列を確認してください。サブスクリプション単位の新しい管理方式は 2026 年 5 月 7 日以降に導入が始まっていますが、全モデルへの移行完了を前提にしてはいけません。適用されるクォータ管理方式の確認方法
| Scope の表示 | 配分を確認する範囲 |
|---|---|
Global | 新方式の対象では、同一サブスクリプションの同一モデル・バージョンの Global Standard がリージョンをまたいで共有 |
Data Zone | 新方式の対象では、同一サブスクリプションの同一モデル・バージョンの Data Zone Standard が同じデータゾーン内で共有 |
East US などのリージョン名 | そのサブスクリプション・モデルはリージョン単位で管理 |
新方式の対象なら、同じモデルを別リージョンに配置しても、それだけで利用枠が倍になるわけではありません。別デプロイへの振り分けを検討する際は、共有枠、各デプロイの割り当て、配置可能な容量をそれぞれ確認します。データの処理場所に関する要件も維持してください。
必要なデプロイへ再配分する
新しい Foundry 画面では、New Foundry を有効にし、Manage → Quota → Token per minute を開きます。対象デプロイの詳細にある Affiliated deployments using shared quota で、同じ利用枠を共有するデプロイを確認し、鉛筆アイコンから割り当てを調整できます。総枠が足りない場合は Request quota から申請します。現在の画面操作
たとえば、同じ利用枠の上限が 120,000 TPM、検証用に 90,000 TPM、本番用に 30,000 TPM を割り当てているとします。検証側で必要な処理量を確認して 30,000 TPM に減らせれば、本番側を 90,000 TPM に増やす余地ができます。これは配分の計算例であり、特定モデルの既定上限や推奨値ではありません。再配分後は検証側の必要な処理も継続できるか確認します。
割り当て変更は反映に最大 15 分を見込み、画面を更新して確かめます。この時間はクォータ増加申請の承認期限ではありません。閲覧に推奨される Cognitive Services Usages Reader はサブスクリプション単位の読み取り権限なので、編集には別途適切な権限が必要です。権限の前提
「使用可能なクォータなし」と表示された場合も、請求対象のトークンを使い切ったとは限りません。正しいサブスクリプションと Scope を選んでいるか、同じ枠をほかのデプロイへ配分済みか、そもそも当該モデルの枠が付与されているかを確認します。
自動監視に使う管理 API にも注意が必要です。Usages API の currentValue はデプロイが消費しているクォータの割り当て量で、その 1 分間に推論で使ったトークン数ではありません。name.value、name.localizedValue、unit、limit と一緒に保存し、千トークン単位などの表示を失わないようにします。新規配置や拡張が可能かを調べる用途は Model Capacities API です。2 つの管理 API の使い分け
トークン使用量が低い場合は、送信時の条件を変える
Azure Monitor のトークン使用量は、成功した処理の課金トークンを示します。一方、制限はリクエストを受信した時点で適用され、一部の HTTP 400 など、課金されない失敗も枠を消費する場合があります。グラフの合計値から「残り TPM」を引き算する方法では、拒否された負荷を捉えられません。使用量がクォータ未満でも 429 が出る理由
短い回答に大きすぎる出力上限を付けていないか
公式説明では、受信時の見積もりに入力、max_tokens、対応 API での best_of が影響します。たとえば短い分類結果を返す処理で、使っている API が max_tokens を受け付けるなら、4,000 を指定する必要があるかを見直します。実際の応答が 200 トークン程度でも、大きな上限の設定は制限の判定に影響します。出力上限の調整
ただし、すべてのモデルに max_tokens をコピーしてはいけません。使っているモデルと API が受け付ける出力上限パラメーターを確認してください。best_of も、その機能を備えた API に限られる設定です。
変更は、代表的な短い入力と長い入力を使い、回答が途中で切れない範囲で行います。出力上限だけを変え、同じ送信ペースで 429 と回答の完了状態を比較してください。ローカルのトークナイザーで正確に数えられても、それを Azure の制限用推定値と同一視はできません。文字数も使う概算のため、「入力トークン＋実際の出力トークン」で受け付け可能件数を保証することはできません。
また、TPM を増やしても、モデルが 1 回に扱える入力長やコンテキスト長は増えません。入力長のエラーは、履歴や検索で追加した文書の長さを見直す問題として扱います。TPM とモデルの入力上限
同時実行数だけでなく、送信間隔を制御する
RPM の評価期間は通常 1 秒または 10 秒程度です。1 分間の平均では余裕があっても、開始直後の集中で拒否されることがあります。短い評価期間での RPM 制限
仮に 120 RPM のデプロイへ 20 件を送る場合、20 件を同時に送るのと、0.5 秒ごとに 1 件ずつ送るのでは到着の仕方が異なります。0.5 秒は 60 秒 ÷ 120 件 の単純計算で、受け付けを保証する推奨間隔ではありません。実際には短時間の評価やトークン量にも余裕を持たせます。
同時実行数を 5 にしても、短い応答が連続して返れば、すぐ次の 5 件を送れてしまいます。そのため、キューの取り出し側で送信間隔を制御し、長い入力のジョブが固まらないようにすることが有効です。複数プロセスや複数サーバーが同じデプロイを使うなら、各ワーカーの設定値だけでなく合計の到着量を制御します。再試行も同じキューに戻し、通常の送信とは別の抜け道を作らないようにします。
リトライで負荷を増幅させない
429 に対しては、応答に有効な retry-after-ms があればその時間を待ちます。2000 なら 2 秒です。利用中の API や中継サービスが返す Retry-After を扱う場合は、その形式と単位に対応した実装を使います。待機指定がなければ、ジッターを加えた指数バックオフを使い、試行回数と処理全体の期限を決めます。Microsoft の再試行ガイド
実装時には、待機時間の上限と処理期限を混同しないでください。サーバーが指定した待機時間より短く丸めて送信を再開するのではなく、待つと処理期限を超える場合は、その処理を打ち切るか後続のジョブへ延期します。待機を終えたリクエストも送信ペースの制御を通します。
再試行を実行する場所は一つにまとめます。SDK が 2 回再試行し、その外側の処理が初回を含めて 3 回試すと、1 件の処理から最大 3 × 3 = 9 回の HTTP 試行が発生し得ます。独自の再試行処理を置く場合は SDK 側の自動再試行を無効にするなど、重複をなくしてください。
ログ上では、利用者が依頼した「1 件」と、Azure に送った「各試行」を別に数えます。たとえば、業務処理 ID に対して試行番号、待機した理由、待機時間、最終的な成功・失敗を持たせれば、429 が再試行で隠れていないか分かります。認証エラーや無効な入力まで同じ再試行ループに入れず、原因を修正します。
待ち続けられない処理では、別のデプロイやモデルへ切り替える条件も設計対象になります。応答の互換性や重複実行の扱いを含めた判断は、再試行とフォールバックの使い分けを参照してください。
割り当て不足では説明できない場合
実効上限が設定値より低い
同じデプロイの x-ratelimit-limit-tokens が、反映済みの設定 TPM より継続して低い場合は、Standard の共有容量に応じた一時的な調整の可能性があります。エラーがサービスの高負荷を示す場合も、クォータを増やすだけで解決するとは限りません。一時的な制限調整と容量不足
設定を何度も上げ直す前に、送信量を抑え、推奨待機時間に従い、応答ヘッダーと発生時間を残します。低負荷でも続く場合や、割り当て変更が実効上限へ反映されない場合は、リソース・デプロイ・モデルの情報、UTC の発生期間、リクエスト ID、設定値とヘッダー値を添えてサポートへ連絡します。特定時間内の回復を前提にせず、業務側の待機期限や延期先も決めておきます。
API Management が先に拒否している
API Management の llm-token-limit は、Azure OpenAI のデプロイとは別のカウンターで制限します。このポリシーではトークンレート超過が 429、指定期間のトークンクォータ超過が 403 です。すべての 403 がこの原因とは限らないため、適用されたポリシーとトレースで確認します。llm-token-limit ポリシー仕様
ゲートウェイ管理者に、対象リクエストの counter-key、tokens-per-minute、期間クォータ、上流へ送信されたかを照合してもらいます。Azure 側の割り当てだけを増やしても、ゲートウェイ側の上限は変わりません。承認済みの制御経路を維持したまま、送信量かポリシーを調整します。
PTU を使っている、または移行を検討している
Provisioned デプロイは、PTU でモデルの処理容量を確保します。Standard の TPM 枠と同じ方法で診断せず、割り当てた容量と実際の負荷を確認してください。PTU が飽和すれば 429 は発生し得ます。PTU のクォータ承認だけでは配置可能な容量を保証せず、PTU と TPM の換算もモデルや処理条件によって変わります。Provisioned throughput の容量とサイジング
安定した処理量が必要なら、通常時と繁忙時のリクエスト数、入力長、出力長を使って容量を見積もります。単に 429 を消すために切り替えるのではなく、必要な処理量を維持できるかを検証してから判断します。
設定変更後は、成功件数と待ち時間まで確認する
復旧確認では一度に一つの条件を変えます。割り当て、出力上限、送信間隔、再試行回数を同時に変更すると、どれが効いたのか分からなくなります。次の手順なら、429 を減らした代わりに処理が遅くなりすぎた場合も見つけられます。
- 比較条件を残す。 同じデプロイ、モデル、代表的な入力の構成、処理件数を使います。変更前の設定と、初回試行・全試行の件数を保存します。
- 変更の反映を確認する。 割り当て変更ならポータルを再読み込みし、許可された少量の処理で応答の実効上限も確認します。画面の数字が変わっただけでは復旧としません。
- 負荷を段階的に戻す。 最初から全ワーカーを起動せず、低い送信ペースから通常の処理量へ上げます。1 秒・10 秒単位の到着件数、トークンの残り枠、429 の出方を見ます。
- 完了まで測る。 成功した業務処理件数、最終失敗数、1 件あたりの HTTP 試行数、キュー待ちを含む所要時間の p95（95% の処理が完了するまでの時間）、未処理件数の推移を比べます。出力上限を下げたなら、回答の途中終了や必要項目の欠落も確認します。
- 再発する条件を確かめる。 通常運転だけでなく、定期バッチの開始や長い入力が混ざる時間帯でも、必要な処理量と待ち時間を満たすか観測します。キューが増え続ける場合は、送信を抑えて 429 が減っていても処理能力が足りません。
429 の割合には分母を付けてください。「初回に失敗した業務処理の割合」と「再試行を含む全 HTTP 試行に占める 429 の割合」は別の指標です。最終成功率だけが上がり、試行数や待ち時間が増えているなら、復旧の大部分を再試行が支えている可能性があります。
必要な処理量を保ち、待ち時間と未処理件数が許容範囲に収まり、回答の品質も維持できたところで変更を採用します。Azure ではなく OpenAI の直接 API を呼んでいる場合はクォータの管理単位が異なるため、OpenAI API のレート制限で対象の上限を確認してください。
