429 は単なるエラーではなく、回復シグナルである

なぜ推測せず、ヘッダーを読むのか

三つの反射的反応はいずれも、ひとつの隠れた前提を共有しています——クライアントは 容量がいつ空くかを知る術がなく、探りを入れるか、固定間隔で待つか、立ち去るしか ないという前提です。それを受け入れる前に、二つの事実を並べておく価値があります。 一つ目は、Microsoft Learn が文書化していることです。利用率 100% でサービスは ただちに 429 を返し、retry-after-ms——いつ再試行するかについて サービスが提供する待機値——を付与します。二つ目は、本リポジトリのソース実行に わたって実際に観測された retry-after-ms の値のサニタイズ済みの公開 集計で、それらの助言された待機が実際にどう見えたかを記述的に示すために含めて います。二つを合わせると、「いつ再試行して安全か」は、クライアント側の推測から、 サービスが返してくる値へと変わります。

立ち止まる価値があるのは、その集計の形です。助言された待機は中央値で短く—— 全体の p50 ≈ 43 ms——でした。そのため、ヘルスチェックのループや 当てずっぽうの固定間隔のバックオフは、サービスが実際に求める時間よりはるかに 長く待つことになりがちです。しかしテールは無視できませんでした。待機のごく一部は 17,000 ms（全体の p99 ≈ 16,921 ms）まで伸びていました。 この「中央値は短く、テールは長い」形こそが運用上重要な事実です—— ヘッダーは固定のリセット時計ではなく、アドミッション制御のシグナルとして扱う べきです。即時の 429 と retry-after-ms ヘッダーの規定は Microsoft Learn が 文書化しています。いつ待つのをやめてリダイレクトするかを単一のレイテンシ 予算の上限で決めるべきだ、というのは本リポジトリが擁護する運用上の推論です。 下の元チャートがその分布を明示します。

公式仕様 · サービスが何を伝えるか

ヘッダーがアドミッションシグナルである

Microsoft Learn は、PTU の高負荷ハンドリングを、retry-after-ms と retry-after レスポンスヘッダーを伴う即時の 429 経路として 説明しています。同じ本番ガイドは、この待機をクライアント側のリトライにも、 リクエストを別のサービングターゲットへリダイレクトするためにも使えると述べて います。

サービスの挙動 · なぜ待機は一定ではないか

待機はアドミッション制御であって、固定のクールダウンではない

Microsoft Learn は PTU の利用率を、漏れバケツアルゴリズムの一種として文書化 しています。各リクエストは推定計算コスト——プロンプトのトークン数から キャッシュ済みトークンを引き、呼び出しの max_tokens を足したもの ——を加える一方、デプロイ済み容量は PTU 数に比例して継続的に排出されます。 リクエストが到着した時点で利用率がすでに 100% なら、サービスはただちに HTTP 429 を返し、次のリクエストが受け入れられるまでどれだけ待つかを示す retry-after-ms と retry-after ヘッダーを付与します。

待機はその瞬間にバケツがどう排出されているかを反映するため、固定のクールダウン ではありません。だから同じ文書化された契約は、一つではなく二つのクライアント 経路を支えます。待機が呼び出し側のレイテンシ予算に収まるときはヘッダーを尊重し、 その予算を超える待機はリダイレクトまたは失敗の条件として扱います。単一の予算 上限で二つの経路を分けるべきだ、というのは本リポジトリが擁護する運用上の推論 です。即時の 429 とヘッダーの契約は Microsoft Learn が文書化しているものです。

運用パターン · リトライのオーナーは一つ

リトライループを積み重ねない

安全なパターンは、意図的に退屈です: 429 の回復処理を担うコンポーネントを ちょうど一つだけ選びます。SDK がリトライするよう構成されているなら、待機の制御は SDK に委ねます。アプリケーションのルーターが回復処理を担うなら、SDK の自動 リトライを無効化し、ルーターに retry-after-ms を直接パースさせます。

フォールバック · ネイティブかカスタムか

リダイレクトはポリシーの選択であり、パニックボタンではない

Microsoft Learn のスピルオーバー機能は、超過トラフィックを標準ターゲットへ リダイレクトでき、スピルオーバーの挙動を識別するヘッダーを公開します。 プラットフォームがサポートする形が合致するなら、それが運用の手間が少ない 経路です。カスタムルーターは、PTU ターゲットが 429 を返す前にアプリケーションが 判断しなければならないとき、あるいはルーティングポリシーがテナント、リージョン、 遅延予算、ビジネス優先度に依存するときに、依然として有用です。

出典と根拠の境界

Tier 1 — サービス契約（Microsoft Learn）。 429 のアドミッション 挙動、両方のリトライヘッダー、漏れバケツの利用率モデル、そして SDK の既定 リトライが、ここに文書化されています。

• [1] プロビジョニング済みスループットのデプロイを本番で運用する — 利用率 100% での即時 429、retry-after-ms と retry-after レスポンスヘッダー、漏れバケツの利用率モデル、そして OpenAI SDK の既定の 429 リトライ（max_retries）を定義しています。出典：Microsoft Learn ドキュメント（2026-06-04 アクセス）· アーカイブ。
• [2] プロビジョニング済みデプロイのスピルオーバーでトラフィックを管理する — 非 200（429 を含む）の超過を、spilloverDeploymentName プロパティと、スピルオーバー元のデプロイを示す x-ms レスポンスヘッダー 経由で標準デプロイへリダイレクトするスピルオーバーを定義しています。出典：Microsoft Learn ドキュメント（2026-06-04 アクセス）· アーカイブ。

Tier 2 — 運用上の推論（本リポジトリ）。 経験則——リトライの オーナーを一つにする、ヘッダーを尊重する、フリート全体の同期を崩すためにジッター を加える、尊重した待機を繰り返しても解消しないときだけスピルオーバーへリダイレクト する——は、運用上のものであって Learn の仕様ではありません。

• [3] 本リポジトリ、docs/10-ptu-admission-controller.md — ヘッダー駆動のアドミッションコントローラーのノート。リトライのオーナーを 一つに、retry-after-ms を尊重、既定のジッター、待機が上限を超えたら フォールバック。出典。
• [4] 本リポジトリ、batch_runner/ptu/admission_controller.py — retry-after-ms をパースし、retry-after に フォールバックし、二重のリトライ所有権を拒否するリファレンス実装。出典。

このトピックが証明するものとしないもの。 アクセス日時点で Microsoft Learn が明示する PTU のアドミッション制御の規定——利用率 100% での即時 429、 retry-after-ms と retry-after ヘッダー、そして スピルオーバーのリダイレクト経路——と、本リポジトリが擁護する小さな運用上の 経験則——ヘッダーを尊重し、フリートの同期を崩すためにジッターを加え、尊重した 待機を繰り返しても解消しないときだけスピルオーバーのデプロイへリダイレクトする ——を文書化します。この規定がすべてのリージョン・モデル SKU・将来の API バージョンで 同一に成り立つことは検証しませんし、特定のデプロイの負荷下の測定もしません。