OpenAI API、429 と 503 を作り分けるエラー仕様に変更

何が発表されたか

• OpenAI が 2026年9月2日、API のエラーハンドリングを更新。トラフィックの急増とモデル側の一時的な過負荷を、別のステータスコードで区別するようになった。
  • 429 + エラーコード slow_down — トークン／リクエストの上限内であっても、リクエストレートが安全に処理できる速度より速く増えている場合。
  • 503 + エラーコード server_is_overloaded — その時点でモデル側に処理容量がない場合。
• どちらも Retry-After ヘッダを伴うことがある。ドキュメントは「公式SDKはすでに、リトライ対象のリクエストについてこのヘッダを尊重する」と明記している。
• ランプアップの目安も示された。「トラフィックが毎分100万入力トークン（TPM）に達したら、15分ごとに 50% を超えて増やさないこと」。

開発者への影響

• 429 を一律に「レート制限」として同じリトライ処理に流している実装は要見直し。slow_down は「上限は超えていないが増やし方が急すぎる」という別の意味なので、単純な指数バックオフだけでは同じ壁に当たり続ける。レートを一度落として、そこから緩やかに戻す処理が要る。
• 503 側は自分のコードでは解決しない事象なので、Retry-After に従い、ヘッダがなければ待機間隔を伸ばしたうえでステータスページを確認する、という切り分けになる。ここを 429 と同列に扱っていると、障害時に無意味なリトライでコストだけ積み上がる。
• 実務的に効くのはバッチ処理の初回投入。商品説明の一括生成やサイト全体のリライトなど、ゼロから一気に並列数を上げる処理は slow_down を踏みやすい。100万 TPM に達したら 15分で 50% までという公式の目安を、そのまま投入スケジュールの設計に使える。
• 自前でリトライを書いている場合は、公式SDKに寄せるだけで Retry-After への追従が入る。

補足

エラーコードの一覧と対処方針は公式ドキュメントの Error codes ガイドに集約されている。