短.beレート制限 (Rate Limiting) とは、API やサービスに対するリクエスト数を、一定の時間枠内で上限値に制限する仕組みです。「1 分間に 60 リクエストまで」「1 日に 1,000 リクエストまで」のように設定され、上限を超えたリクエストには HTTP 429 (Too Many Requests) が返されます。この 429 は RFC 6585 で定義されたステータスコードで、一定時間内のリクエストが多すぎることをクライアントに伝えます。
レート制限の目的は 3 つあります。第一にサーバー保護 (大量リクエストによるサービスダウンの防止)、第二に公平性の確保 (特定ユーザーによるリソースの独占防止)、第三にコスト管理 (クラウドサービスの従量課金を制御) です。
短縮 URL サービスでは、レート制限が複数の場面で適用されます。URL 短縮 API のリクエスト数制限 (スパム的な大量生成の防止)、短縮 URL へのアクセス数制限 (DDoS 攻撃の緩和)、管理画面へのログイン試行回数制限 (ブルートフォース攻撃の防止) などです。
レート制限のアルゴリズムには主に 4 種類あります。固定ウィンドウ (1 分ごとにカウンターをリセット)、スライディングウィンドウ (直近 1 分間のリクエスト数を常時計算)、トークンバケット (一定速度でトークンが補充され、リクエストごとにトークンを消費)、リーキーバケット (一定速度でリクエストを処理し、超過分をキューに蓄積) です。
API を利用する開発者がレート制限に対処するには、レスポンスヘッダーを確認して残量に応じてリクエスト頻度を調整する実装が必要です。残量を伝えるヘッダーの名前はサービスごとに異なり、X-RateLimit-Limit や X-RateLimit-Remaining といった名前が慣習的に使われてきました。標準のヘッダーは策定作業が進んでいる段階で、2026 年 8 月時点では Internet-Draft です。429 レスポンスを受けた場合は、Retry-After ヘッダーがあればその値に従って待機します。ヘッダーが無い場合や、待機して再送しても 429 が続く場合は、待機時間を段階的に伸ばす指数バックオフを併用します。この 2 つは別の手段で、Retry-After に従う待機がそのまま指数バックオフになるわけではありません。