先に要点
APIを作るとき、最初は 正しいリクエストに正しいレスポンスを返す ことに意識が向きます。
でも実運用では、正しい形のリクエストが大量に来ることもあれば、ログインを機械的に試されることもあります。外部APIを呼ぶ側なら、相手サービスの上限に引っかかって処理が止まることもあります。
そこで必要になるのが レート制限 です。
レート制限は、一定時間内に許可するリクエスト数や処理量を制御し、攻撃、誤実装、過負荷、外部APIの使いすぎを抑えるための仕組みです。
この記事では、2026年4月22日時点で RFC 6585 の HTTP 429、OWASP API Security Top 10 2023 の認証防御、主要API運用で一般的に使われる Retry-After の考え方を確認しながら、ログイン、Webhook、外部APIでなぜレート制限が必要になるのかを整理します。
API仕様書として利用制限まで共有したい場合は、OpenAPI / Swaggerとは？API仕様書をチームで共有する基本を整理 もあわせて読むとつながりやすいです。
レート制限とは何か
レート制限は、一定時間に受け付けるリクエスト数を制限する仕組みです。
たとえば、1分あたり60回まで、1時間あたり1000回まで、ログイン失敗は同じアカウントに対して5回まで のように決めます。
制限に達したとき、HTTP APIでは 429 Too Many Requests を返すことがあります。
RFC 6585では、429は一定時間に多すぎるリクエストが送られたことを示すステータスコードとして定義されています。また、レスポンスに Retry-After を含め、いつ再試行すればよいかを伝えることもできます。
サービスを落とさない、他の利用者へ影響を広げない、攻撃者に試行回数を与えすぎない、外部APIの上限に合わせて処理する、といった実務上の安全装置です。
何を基準に制限するのか
レート制限では、何に対して数えるか がかなり重要です。
| 基準 | 向いている場面 | 注意点 |
|---|---|---|
| IPアドレス | 未ログイン画面、公開API、簡易的な防御 | 共有回線やプロキシで巻き込みが起きる |
| ユーザーID | ログイン後API、管理画面、会員機能 | 未ログイン攻撃には使いにくい |
| APIキー | 外部開発者向けAPI、システム間連携 | キー漏えい時の検知と停止が必要 |
| エンドポイント | 重い検索、メール送信、CSV出力、Webhook | 軽いAPIと重いAPIを同じ枠にしない |
| アカウント対象 | ログイン、パスワードリセット、認証コード | 攻撃者が被害者アカウントをロックできる設計に注意 |
全APIを1分60回まで のような単純な制限だけだと、実務では粗すぎることがあります。ログイン、検索、Webhook受信、管理者操作、外部API呼び出しでは守りたいものが違うため、別々に考える方が安全です。
ログインで必要になる理由
ログイン画面は、攻撃者から見て分かりやすい入口です。
メールアドレスとパスワードを大量に試す ブルートフォース攻撃 や、漏えい済みパスワードを試すクレデンシャルスタッフィングでは、試行回数をどれだけ許すかが重要になります。
OWASP API Security Top 10 2023でも、認証エンドポイントやパスワードリセットは保護対象であり、ブルートフォースやクレデンシャルスタッフィングへの対策として、通常APIより厳しい制御が必要だと整理されています。
ログインでは、次のような制限を組み合わせることがあります。
接続元で数える
IP・端末・セッション
同じIPからの試行回数、同じ端末やセッションからの試行回数を見ます。
狙われる側で数える
アカウント
同じアカウントへの失敗回数を見ます。
周辺の機能
リセットと認証コード
パスワードリセットメールの送信回数、ワンタイムコードの検証回数も制限します。
ここで大事なのは、攻撃者だけを止めて、正規ユーザーをなるべく巻き込まないことです。
同じIPだけで厳しく制限すると、会社や学校のような共有ネットワークで正規ユーザーまで止まることがあります。逆にアカウント単位だけで制限すると、攻撃者が特定アカウントをわざとロックする嫌がらせができます。
そのため、ログインではレート制限だけでなく、MFA、アカウントロック、通知、CAPTCHA、リスクベース認証、監査ログを組み合わせて考えます。
Webhookで必要になる理由
Webhook は、外部サービスがイベント発生時にこちらのURLへHTTPリクエストを送ってくる仕組みです。
便利ですが、相手サービスの再送、障害復旧後の集中送信、設定ミス、悪意あるリクエストで、短時間に大量のアクセスが来ることがあります。
Webhook受信では、レート制限を雑に入れすぎると必要なイベントまで落としてしまいます。
一方で無制限に受けると、アプリサーバー、DB、キュー、メール送信、外部API呼び出しが一気に詰まることがあります。
現実的には、Webhookでは次のように分けて考えます。
- 1
署名を検証する
署名検証に失敗するリクエストは早く拒否する。
- 2
受信は軽く済ませる
受信だけは軽く済ませ、重い処理はキューへ回す。送信元サービスごとに制限を分ける。
- 3
二重処理を防ぐ
同じイベントIDを二重処理しない。
- 4
再送の挙動を確かめる
429を返したときに相手がどう再送するか確認する。
Webhookの基本は、Webhookとは？APIとの違い・よくある使い方・実務の注意点を解説 で整理しています。
外部APIで必要になる理由
外部APIを呼ぶ側でも、レート制限は重要です。
決済、メール送信、地図、AI、翻訳、CRM、在庫連携などの外部サービスには、プランやエンドポイントごとの利用上限があります。
相手APIの上限を無視して呼び続けると、429が返る、一定時間ブロックされる、処理が遅延する、場合によっては利用制限や追加課金につながります。
外部APIを使う側では、次のような設計が必要です。
待ち方
連打しない
429を受けたらすぐ再試行し続けない。Retry-After があれば尊重する。指数バックオフで間隔を広げる。
送り方
量を減らす・ならす
キューで送信量を平準化する。キャッシュできる結果はキャッシュする。同じ処理をまとめて送れるならバッチ化する。
見せ方
失敗時の表示
失敗時にユーザーへどう見せるか決めておきます。
外部APIの障害時は、リトライ とフォールバックの設計も関係します。
やみくもにリトライすると、相手の復旧を邪魔し、自分のキューも詰まります。リトライの考え方は、フォールバックとは？障害時に機能を止めないための代替処理をわかりやすく解説 も参考になります。
429とRetry-Afterの見方
APIのレート制限に引っかかったとき、代表的なのが 429 Too Many Requests です。
429は リクエストが多すぎる という意味なので、クライアント側は同じリクエストを即座に連打しない方が安全です。
レスポンスに Retry-After がある場合は、その時間まで待ってから再試行します。
また、APIによっては X-RateLimit-Remaining や RateLimit-Remaining のようなヘッダーで、残り回数やリセット時刻を返すことがあります。
残り回数やリセット時刻のヘッダーは、名前も意味もサービスごとに違うため、相手APIの公式ドキュメントを確認する必要があります。
自分がAPIを提供する側なら、制限時のレスポンスを利用者が扱いやすい形にしておくと親切です。
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
{
"error": "rate_limited",
"message": "Too many requests. Please retry after 60 seconds."
}
このように、何が起きたか、いつ再試行すべきか、利用者側がどう扱えばよいかを伝えると、無駄な再試行を減らせます。
設計でよくある失敗
レート制限で起きやすい失敗を3つ並べます。
失敗 1
全員に同じ制限を雑にかける
無料プランと有料プラン、通常ユーザーと管理者、軽い参照APIと重いCSV出力を同じ枠で制限すると、必要な利用まで止めたり、重い処理を守れなかったりします。
失敗 2
制限した結果を監視していない
429が大量に出ているのに誰も気づかないと、ユーザーは なんとなく使えない と感じます。攻撃なのか、人気機能なのか、フロントエンドのバグで連打しているのかも分かりません。
失敗 3
厳しすぎるロックアウト
ログインでは、厳しすぎるロックアウトがDoSの入口になることがあります。攻撃者が他人のメールアドレスでわざと失敗を繰り返し、正規ユーザーを締め出せる設計は危険です。
どのキーで、どのエンドポイントが、どのくらい制限に達しているのかをログやメトリクスで見られるようにしておくと、改善しやすくなります。
まず決めるチェックリスト
レート制限を入れるときは、次を決めると設計しやすくなります。
レート制限を入れるときに決めること
- 1何を守りたいのか
認証、DB、外部API、メール送信、重い検索。
- 2誰を単位に数えるのか
IP、ユーザー、APIキー、アカウント、送信元サービス。
- 3どの時間窓で見るのか
秒、分、時間、日。
- 4制限に達したら何を返すのか
429、エラーメッセージ、Retry-After。
- 5巻き込みと連鎖を防ぐ
正規ユーザーの巻き込みをどう減らすのか。リトライやWebhook再送で連鎖的に増えないか。
- 6見て、直せるようにする
制限に達したログやメトリクスをどう見るのか。管理者やサポートが解除・調査できるか。
最初から完璧な数値を決めるのは難しいです。まずは危険な入口から入れ、ログを見ながら調整する方が現実的です。
APIレート制限のよくある質問
Q. 一般的なレート制限の数値は？
A. 全サービスに共通する正解の数値はありません。通常の利用でどのくらいのリクエストが来るかをログで確認し、それを十分に上回る値から始めて、ログイン・パスワードリセット・メール送信のように悪用されやすい入口だけ厳しめにします。制限に達した件数を見ながら調整します。
Q. レート制限はどの層で実装しますか？
A. CDN(Cloudflare、CloudFront)、ロードバランサー(ALB)、WAF、API Gateway、アプリ内部、複数層で重ねるのが定番。攻撃を受ける前段で大量に弾く、正常使いを内側で精密に制御、の役割分担です。
Q. 429 レスポンスと 403 はどう使い分けますか？
A. 429 は 一時的にリクエスト過多(Retry-After で再試行可能を示唆)、403 は 権限不足で永続的に拒否。レート制限超過は 429 が正しい挙動です。
Q. レート制限のアルゴリズムは何がありますか？
A. Fixed Window(固定窓)、Sliding Window(スライド窓)、Token Bucket(トークンバケット)、Leaky Bucket(漏れバケット)、の4つが主流。トークンバケットは短時間の集中(バースト)をある程度許しながら平均の量を抑えられるため、よく使われます。
Q. Redis をレート制限に使うのは定番ですか？
A. 定番です。INCR + EXPIRE で簡単に実装でき、複数サーバーで共有可能。専用ライブラリ(express-rate-limit と rate-limit-redis の組み合わせなど)も多数あります。
Q. 正規ユーザーが巻き込まれるリスクは？
A. あります。共有 IP(オフィスからの集団アクセス、CGN を経由する利用者)、大量データ操作する正規ユーザー、などは制限に引っかかります。IP ベース だけでなく、ログインユーザー ID ベース の制限も組み合わせます。
Q. 外部 API のレート制限を超えそうな時は？
A. 指数バックオフでリトライ、キューに溜めて時間調整、より上位プランへ移行、提供元に上限の引き上げを相談、で対処します。エラーになるたびにリトライすると逆効果なので、429 を受けたら待つ が原則。
まとめ
APIのレート制限は、一定時間内のリクエスト数や処理量を制御し、サービスを守るための基本的な仕組みです。
ログインでは攻撃者の試行回数を減らし、Webhookでは再送や集中アクセスを受け止め、外部APIでは相手サービスの上限に合わせて壊れにくくします。
制限に達したときは、429やRetry-Afterを使って、クライアントが待つべき状況を伝えることがあります。
ただし、どのヘッダーを返すか、どの単位で数えるか、どこまで待つかはサービスごとに違います。
大事なのは、レート制限を とりあえず厳しくする設定 と見ないことです。
守りたい入口、正規ユーザーへの影響、再試行の挙動、監視まで含めて設計すると、ログイン・Webhook・外部API連携の事故をかなり減らせます。
参考リンク
- RFC Editor: RFC 6585 - 429 Too Many Requests
- OWASP API Security Top 10: API2:2023 Broken Authentication
- OWASP Cheat Sheet Series: Denial of Service Cheat Sheet