レート制限、429、ティア引き上げ
Updated September 1, 2026 · first published September 1, 2026
429 が返り始めると、可用性のインシデントとして扱いたくなります — 上限を上げ、ティアを上げ、リトライを足してスループットを戻す。正しいこともあります。同時にそれは、暴走したループが五桁の請求書に変わる経路でもあります。止めていた唯一のものを、いま外したからです。
429 が実際に伝えていること
「システムが許容より速く支出しようとしている」ということです。理由は大きく 2 つあり、対応は正反対になります。本物の需要増（利用者増、ローンチ、季節ピーク）なら上限が低すぎるので、引き上げは売上を買います。暴走（リトライ嵐、ループするエージェント、絞っていないバックフィル、本番キーを向いたテスト）なら、上限はまさに仕事をしています。
エラー率だけでは両者を区別できません。作業 1 件あたりのコストを見れば簡単に区別できます。本物の成長では量が増えても比率はほぼ一定、暴走では比率が壊れます。この比率をティア引き上げの判断基準にしてください。
リトライが静かに悪化させる
指数バックオフとジッターのない 429 リトライは、1 回の超過を同期した嵐に変えます。成功した分は課金され、失敗分も入力処理を消費していることがあります。しかもリトライはクライアントライブラリ側にあることが多く、機能の設計書にはどこにも現れません。
意図して上限を使う
プロバイダの上限より低い自前の上限を、環境ごと・機能ごとに設定してください。最初に壊れるのが自分の上限なら、次に何が起きるかを自分で決められます。非本番は厳しく固定を。アラートはエラー数ではなく作業あたりコストに。そしてティア引き上げは、名前のある担当者が行う支出判断として扱ってください。
Related
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →