先に結論
429は要求数が制限を超えた応答です。利用者、IP、API key、パス、時間窓のどれが制限キーかを確認し、Retry-After、指数バックオフ、キュー、キャッシュ、bot制御を組み合わせます。
429を返した層と制限キーを特定する
- URL、method、発生時刻、レスポンスヘッダー、Retry-After、request IDを保存する。
- CDN／WAF、API gateway、アプリ、外部APIのどこが429を返したか確認する。
- IP、ユーザー、API key、token、パス、組織などlimit keyと時間窓を記録する。
- 総要求数だけでなく、急増元、再試行、定期job、bot、失敗率を確認する。
- 成功要求との差分と、制限値変更・デプロイ・キャンペーン開始を時系列で重ねる。
結論：Retry-Afterがあれば従い、クライアントの同時再試行を止めます。増台や制限緩和の前に、正規トラフィック・誤実装・bot・攻撃のどれが枠を消費したかを確定します。
制限主体で対策を変える
| 観測 | 優先候補 | 対策 |
|---|---|---|
| 特定API keyだけ | 契約quota・クライアントburst | 使用量、batch化、cache、上限申請 |
| 同一IPの多数利用者 | NAT・proxy単位制限 | ユーザー／token単位への見直し |
| デプロイ後に急増 | loop・重複送信・polling | request trace、再試行回数、job重複 |
| 一部パス・botだけ | crawl・scraping・WAF | verified bot、robots、rate rule |
| 負荷上昇と同時 | 保護用rate limit | 容量、queue、cache、503との分離 |
| 拒否だが429記録なし | WAF／認可403 | 403の応答主体を確認 |
再試行は指数バックオフ＋jitter＋上限
- Retry-Afterまたは公式API仕様を優先する。
- 待機時間を指数的に増やし、複数クライアントが同時再試行しないようjitterを加える。
- 最大回数と総待機時間を決め、失敗をキューや手動再開へ渡す。
- 書き込みAPIではidempotency keyや重複防止を確認する。
- 429率、制限キー、待機時間、最終失敗を監視する。
botと検索クロールを混同しない
User-Agent文字列だけで正規botと断定しません。検索エンジンの公式確認方法、送信元、アクセス頻度、robots、Search Consoleを照合します。長期間の429はクロールとインデックス更新を抑えるため、重要ページ・静的資産・APIでルールを分けます。
サイト全体が容量不足なら503 Service Unavailableとの使い分けも確認します。
避ける操作
- 全クライアントが即時・無制限に再試行する。
- 原因未確認でrate limitを全解除する。
- 429を200へ置換して失敗内容を正常応答に見せる。
- NAT配下の利用者を一つのIPだけで恒久遮断する。
- API token、Cookie、認証ヘッダーをログや外部ツールへ残す。
- 容量不足、攻撃、クライアントloopを同じ対策で処理する。
公式情報
よくある質問
429が出たら何秒後に再試行しますか？
応答にRetry-Afterがあればそれを優先します。ない場合はサービス仕様を確認し、指数バックオフとjitter、最大回数を設定します。即時の同時再試行は制限と負荷を悪化させます。
サーバーを増やせば429は直りますか？
制限主体がAPI契約、WAF、ユーザー単位、IP単位なら増台では直りません。429を返した層、limit key、時間窓、現在値をログで確定します。
正規のGooglebotにも429を返してよいですか？
一時的な過負荷で429を使う場合はありますが、長期継続はクロールを抑制します。Googleの公開仕様と自サイトのクロール状況を確認し、偽装botを逆引きなど公式手順で区別します。