何が起きたのか？
429 は「少しの間に質問が多すぎたので、いったん落ち着いてほしい」というサインです。 教室で言えば、先生に矢継ぎ早に質問を投げ続けたら「順番に、少し待ってね」と止められた——そんな場面です。サーバーは怒っているのではなく、自分も他の人もちゃんと応えるために、テンポを整えています。
レスポンスには Retry-After ヘッダが付くことが多く、「あと何秒待てばよいか」を教えてくれます。これを無視してまた連打すると、制限が長く延びることもあります。間を置く、それが第一歩です。
黒板からのひとこと
教室では、手が早い子の質問ばかりに先生が応えると、他の生徒の番が回ってこなくなります。だから先生は意識的に「いったん他の人の質問を聞こうね」と整理する。429 もそれと同じで、サーバーがリソースを公平に配るための調整です。
このときに大切なのは、リトライの間隔を少しずつ広げていく「指数バックオフ」と呼ばれる作法です。1 秒、2 秒、4 秒と待ち時間を倍にしていくと、サーバーへの負荷も自分の成功率も両方上がります。
解決への歩み
大丈夫、次はこうしてみよう：
- Retry-After を読む：指定された秒数だけ素直に待つ
- 指数バックオフで再送：1 秒、2 秒、4 秒……とリトライ間隔を広げ、ジッタも入れる
- 同時並列度を下げる：バッチのワーカ数やスレッド数を絞り、ピークを平す
- レート制限の設計を見直す（管理者向け）：ユーザー別/IP 別/APIキー別の上限、429 の理由を返すヘッダ整備、利用者向けドキュメントの整理
実際にはこう見える
$ リクエスト
curl -i https://example.com/some/path↓ レスポンス
HTTP/1.1 429 Too Many Requests
Content-Type: text/html; charset=utf-8
<!DOCTYPE html>
<html><body><h1>429 Too Many Requests</h1></body></html>