# Azure OpenAI の TPM 制限を切り分ける：使用量が少なくても出る 429 の対処法

> Azure OpenAI でトークン使用量が低いのに 429 が出る場合は、呼び出し先の割り当てとレスポンスヘッダーを照合します。TPM と RPM、共有クォータの範囲、再試行の増幅を切り分け、変更後に処理量と待ち時間を確かめる手順です。

- URL: https://blog.laozhang.ai/ja/posts/azure-openai-tpm-rate-limit
- Published: 2026-09-05
- Updated: 2026-09-05
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about)
- Topic: API ガイド
- Tags: Azure OpenAI, TPM, レート制限, HTTP 429, クォータ

---
Azure OpenAI の 429 を調べるときは、**呼び出し先デプロイに割り当てた TPM と、失敗したリクエストのレスポンスヘッダーを先に確認してください。** サブスクリプションに余っているクォータや、Azure Monitor の少ないトークン使用量だけでは、リクエストを受け付けられる状態かどうかは分かりません。

TPM は 1 分あたりのトークン数の上限ですが、制限の判定に使われるのは受信時点の推定最大処理トークン数です。処理後に確定する課金トークン数とは異なります。また、1 分あたりのリクエスト数を表す RPM は、短い時間幅でも評価されます。このため、課金対象の使用量が少なくても 429 は発生します。[Microsoft Learn のレート制限の説明](https://learn.microsoft.com/ja-jp/azure/foundry/openai/how-to/quota#understanding-rate-limits)

以下は主に Standard 系デプロイの診断手順です。2026 年 9 月 5 日時点の仕様に基づき、PTU と API Management を使う場合の分岐も示します。

## 最初の 429 で残す情報

再試行後の最終結果だけを記録すると、途中の 429 が見えなくなります。まず、同じ処理の初回と再試行を区別できるようにし、次の情報を失敗した試行ごとに残します。

- タイムゾーンを含む送信時刻、HTTP ステータス、エラー本文、返されたリクエスト ID。
- サブスクリプション、リソース、デプロイ名、モデルとバージョン、デプロイの種類、リージョン。
- 出力上限の設定、入力の長さ、再試行回数。入力本文を保存する必要はありません。
- 応答に含まれるレート制限ヘッダーと、その試行を送ったアプリケーションまたはワーカー。

[公式のレスポンスヘッダー一覧](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#rate-limit-response-headers)を使うと、設定値と実際の制限を比較できます。

| 記録するヘッダー | 診断で見る点 |
| --- | --- |
| `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 側への送信がない | 適用中のポリシーとカウンター | ゲートウェイの制限に合わせて送信を調整する |

一つのヘッダーだけで原因を断定せず、設定、エラー本文、前後の試行を合わせて見てください。Microsoft は容量不足や一時的な実効上限の引き下げも 429 の原因として挙げています。[429 の原因と対処](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#understanding-429-throttling-errors-and-what-to-do)

## クォータの総量と、呼び出し先の割り当てを照合する

クォータはデプロイに配分できる利用枠です。利用枠が承認されていても、アクセスが集中するデプロイに十分な TPM を割り当てていなければ、そのデプロイのレート制限に達します。TPM と RPM の比率もモデルによって異なるため、「1,000 TPM につき必ず 6 RPM」とは計算できません。[クォータの割り当てとモデル別の比率](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#introduction-to-quota)

### 2026 年の共有範囲は Scope 列で確認する

リージョンを増やす前に、Foundry の **Quota** 画面で対象モデルの **Scope** 列を確認してください。サブスクリプション単位の新しい管理方式は 2026 年 5 月 7 日以降に導入が始まっていますが、全モデルへの移行完了を前提にしてはいけません。[適用されるクォータ管理方式の確認方法](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits#check-quota-management-scope)

| 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** から申請します。[現在の画面操作](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#view-and-request-quotas-in-foundry-portal)

たとえば、同じ利用枠の上限が 120,000 TPM、検証用に 90,000 TPM、本番用に 30,000 TPM を割り当てているとします。検証側で必要な処理量を確認して 30,000 TPM に減らせれば、本番側を 90,000 TPM に増やす余地ができます。これは配分の計算例であり、特定モデルの既定上限や推奨値ではありません。再配分後は検証側の必要な処理も継続できるか確認します。

![同じ 120,000 TPM の利用枠で、検証用と本番用の割り当てを 90,000 対 30,000 から 30,000 対 90,000 に変更する計算例](https://blog.laozhang.ai/posts/ja/azure-openai-tpm-rate-limit/img/quota-reallocation.webp)

割り当て変更は反映に最大 15 分を見込み、画面を更新して確かめます。この時間はクォータ増加申請の承認期限ではありません。閲覧に推奨される **Cognitive Services Usages Reader** はサブスクリプション単位の読み取り権限なので、編集には別途適切な権限が必要です。[権限の前提](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#prerequisites)

「使用可能なクォータなし」と表示された場合も、請求対象のトークンを使い切ったとは限りません。正しいサブスクリプションと Scope を選んでいるか、同じ枠をほかのデプロイへ配分済みか、そもそも当該モデルの枠が付与されているかを確認します。

自動監視に使う管理 API にも注意が必要です。**Usages API** の `currentValue` はデプロイが消費しているクォータの割り当て量で、その 1 分間に推論で使ったトークン数ではありません。`name.value`、`name.localizedValue`、`unit`、`limit` と一緒に保存し、千トークン単位などの表示を失わないようにします。新規配置や拡張が可能かを調べる用途は **Model Capacities API** です。[2 つの管理 API の使い分け](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#programmatically-check-quota-and-capacity)

## トークン使用量が低い場合は、送信時の条件を変える

Azure Monitor のトークン使用量は、成功した処理の課金トークンを示します。一方、制限はリクエストを受信した時点で適用され、一部の HTTP 400 など、課金されない失敗も枠を消費する場合があります。グラフの合計値から「残り TPM」を引き算する方法では、拒否された負荷を捉えられません。[使用量がクォータ未満でも 429 が出る理由](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#why-you-might-see-429s-even-when-token-usage-metrics-are-below-quota)

### 短い回答に大きすぎる出力上限を付けていないか

公式説明では、受信時の見積もりに入力、`max_tokens`、対応 API での `best_of` が影響します。たとえば短い分類結果を返す処理で、使っている API が `max_tokens` を受け付けるなら、4,000 を指定する必要があるかを見直します。実際の応答が 200 トークン程度でも、大きな上限の設定は制限の判定に影響します。[出力上限の調整](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#optimize-your-requests)

ただし、すべてのモデルに `max_tokens` をコピーしてはいけません。使っているモデルと API が受け付ける出力上限パラメーターを確認してください。`best_of` も、その機能を備えた API に限られる設定です。

変更は、代表的な短い入力と長い入力を使い、**回答が途中で切れない範囲**で行います。出力上限だけを変え、同じ送信ペースで 429 と回答の完了状態を比較してください。ローカルのトークナイザーで正確に数えられても、それを Azure の制限用推定値と同一視はできません。文字数も使う概算のため、「入力トークン＋実際の出力トークン」で受け付け可能件数を保証することはできません。

また、TPM を増やしても、モデルが 1 回に扱える入力長やコンテキスト長は増えません。入力長のエラーは、履歴や検索で追加した文書の長さを見直す問題として扱います。[TPM とモデルの入力上限](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#model-specific-settings)

### 同時実行数だけでなく、送信間隔を制御する

RPM の評価期間は通常 1 秒または 10 秒程度です。1 分間の平均では余裕があっても、開始直後の集中で拒否されることがあります。[短い評価期間での RPM 制限](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#understanding-rate-limits)

仮に 120 RPM のデプロイへ 20 件を送る場合、20 件を同時に送るのと、0.5 秒ごとに 1 件ずつ送るのでは到着の仕方が異なります。0.5 秒は `60 秒 ÷ 120 件` の単純計算で、受け付けを保証する推奨間隔ではありません。実際には短時間の評価やトークン量にも余裕を持たせます。

同時実行数を 5 にしても、短い応答が連続して返れば、すぐ次の 5 件を送れてしまいます。そのため、キューの取り出し側で送信間隔を制御し、長い入力のジョブが固まらないようにすることが有効です。複数プロセスや複数サーバーが同じデプロイを使うなら、各ワーカーの設定値だけでなく合計の到着量を制御します。再試行も同じキューに戻し、通常の送信とは別の抜け道を作らないようにします。

## リトライで負荷を増幅させない

429 に対しては、応答に有効な `retry-after-ms` があればその時間を待ちます。`2000` なら 2 秒です。利用中の API や中継サービスが返す `Retry-After` を扱う場合は、その形式と単位に対応した実装を使います。待機指定がなければ、ジッターを加えた指数バックオフを使い、試行回数と処理全体の期限を決めます。[Microsoft の再試行ガイド](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#implement-retry-logic-with-exponential-backoff)

実装時には、待機時間の上限と処理期限を混同しないでください。サーバーが指定した待機時間より短く丸めて送信を再開するのではなく、待つと処理期限を超える場合は、その処理を打ち切るか後続のジョブへ延期します。待機を終えたリクエストも送信ペースの制御を通します。

![429 の待機後に同じ送信制御付きキューへ戻し、処理期限を超える場合は延期または終了する再試行の流れ](https://blog.laozhang.ai/posts/ja/azure-openai-tpm-rate-limit/img/paced-retry-queue.webp)

再試行を実行する場所は一つにまとめます。SDK が 2 回再試行し、その外側の処理が初回を含めて 3 回試すと、1 件の処理から最大 `3 × 3 = 9` 回の HTTP 試行が発生し得ます。独自の再試行処理を置く場合は SDK 側の自動再試行を無効にするなど、重複をなくしてください。

ログ上では、利用者が依頼した「1 件」と、Azure に送った「各試行」を別に数えます。たとえば、業務処理 ID に対して試行番号、待機した理由、待機時間、最終的な成功・失敗を持たせれば、429 が再試行で隠れていないか分かります。認証エラーや無効な入力まで同じ再試行ループに入れず、原因を修正します。

待ち続けられない処理では、別のデプロイやモデルへ切り替える条件も設計対象になります。応答の互換性や重複実行の扱いを含めた判断は、[再試行とフォールバックの使い分け](https://blog.laozhang.ai/ja/posts/llm-api-retry-vs-fallback-model)を参照してください。

## 割り当て不足では説明できない場合

### 実効上限が設定値より低い

同じデプロイの `x-ratelimit-limit-tokens` が、反映済みの設定 TPM より継続して低い場合は、Standard の共有容量に応じた一時的な調整の可能性があります。エラーがサービスの高負荷を示す場合も、クォータを増やすだけで解決するとは限りません。[一時的な制限調整と容量不足](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#understanding-429-throttling-errors-and-what-to-do)

設定を何度も上げ直す前に、送信量を抑え、推奨待機時間に従い、応答ヘッダーと発生時間を残します。低負荷でも続く場合や、割り当て変更が実効上限へ反映されない場合は、リソース・デプロイ・モデルの情報、UTC の発生期間、リクエスト ID、設定値とヘッダー値を添えてサポートへ連絡します。特定時間内の回復を前提にせず、業務側の待機期限や延期先も決めておきます。

### API Management が先に拒否している

API Management の `llm-token-limit` は、Azure OpenAI のデプロイとは別のカウンターで制限します。このポリシーではトークンレート超過が 429、指定期間のトークンクォータ超過が 403 です。すべての 403 がこの原因とは限らないため、適用されたポリシーとトレースで確認します。[llm-token-limit ポリシー仕様](https://learn.microsoft.com/en-us/azure/api-management/llm-token-limit-policy)

ゲートウェイ管理者に、対象リクエストの `counter-key`、`tokens-per-minute`、期間クォータ、上流へ送信されたかを照合してもらいます。Azure 側の割り当てだけを増やしても、ゲートウェイ側の上限は変わりません。承認済みの制御経路を維持したまま、送信量かポリシーを調整します。

### PTU を使っている、または移行を検討している

Provisioned デプロイは、PTU でモデルの処理容量を確保します。Standard の TPM 枠と同じ方法で診断せず、割り当てた容量と実際の負荷を確認してください。PTU が飽和すれば 429 は発生し得ます。PTU のクォータ承認だけでは配置可能な容量を保証せず、PTU と TPM の換算もモデルや処理条件によって変わります。[Provisioned throughput の容量とサイジング](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput)

安定した処理量が必要なら、通常時と繁忙時のリクエスト数、入力長、出力長を使って容量を見積もります。単に 429 を消すために切り替えるのではなく、必要な処理量を維持できるかを検証してから判断します。

## 設定変更後は、成功件数と待ち時間まで確認する

復旧確認では一度に一つの条件を変えます。割り当て、出力上限、送信間隔、再試行回数を同時に変更すると、どれが効いたのか分からなくなります。次の手順なら、429 を減らした代わりに処理が遅くなりすぎた場合も見つけられます。

1. **比較条件を残す。** 同じデプロイ、モデル、代表的な入力の構成、処理件数を使います。変更前の設定と、初回試行・全試行の件数を保存します。
2. **変更の反映を確認する。** 割り当て変更ならポータルを再読み込みし、許可された少量の処理で応答の実効上限も確認します。画面の数字が変わっただけでは復旧としません。
3. **負荷を段階的に戻す。** 最初から全ワーカーを起動せず、低い送信ペースから通常の処理量へ上げます。1 秒・10 秒単位の到着件数、トークンの残り枠、429 の出方を見ます。
4. **完了まで測る。** 成功した業務処理件数、最終失敗数、1 件あたりの HTTP 試行数、キュー待ちを含む所要時間の p95（95% の処理が完了するまでの時間）、未処理件数の推移を比べます。出力上限を下げたなら、回答の途中終了や必要項目の欠落も確認します。
5. **再発する条件を確かめる。** 通常運転だけでなく、定期バッチの開始や長い入力が混ざる時間帯でも、必要な処理量と待ち時間を満たすか観測します。キューが増え続ける場合は、送信を抑えて 429 が減っていても処理能力が足りません。

429 の割合には分母を付けてください。「初回に失敗した業務処理の割合」と「再試行を含む全 HTTP 試行に占める 429 の割合」は別の指標です。最終成功率だけが上がり、試行数や待ち時間が増えているなら、復旧の大部分を再試行が支えている可能性があります。

必要な処理量を保ち、待ち時間と未処理件数が許容範囲に収まり、回答の品質も維持できたところで変更を採用します。Azure ではなく OpenAI の直接 API を呼んでいる場合はクォータの管理単位が異なるため、[OpenAI API のレート制限](https://blog.laozhang.ai/ja/posts/openai-api-rate-limit)で対象の上限を確認してください。

## 参考資料

本文で参照している外部ページを、登場順に並べています。最終更新日：2026-09-05。

- [Microsoft Learn のレート制限の説明](https://learn.microsoft.com/ja-jp/azure/foundry/openai/how-to/quota) (learn.microsoft.com)
- [公式のレスポンスヘッダー一覧](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota) (learn.microsoft.com)
- [適用されるクォータ管理方式の確認方法](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits) (learn.microsoft.com)
- [llm-token-limit ポリシー仕様](https://learn.microsoft.com/en-us/azure/api-management/llm-token-limit-policy) (learn.microsoft.com)
- [Provisioned throughput の容量とサイジング](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput) (learn.microsoft.com)