APIのレート制限とは？ログイン・Webhook・外部APIで必要になる理由

先に要点

レート制限は、一定時間に受け付けるリクエスト数を制御する仕組みです。
ログインでは総当たり攻撃を遅くし、Webhookでは再送の集中を受け止め、外部APIでは相手の制限に合わせて壊れにくくします。
制限に達したときは、HTTP 429 Too Many Requests や Retry-After を使って待つべき時間を伝えることがあります。
単に厳しくすればよいわけではなく、利用者、IP、アカウント、エンドポイント、処理の重さごとに分けて設計します。

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だけで厳しく制限すると、会社や学校のような共有ネットワークで正規ユーザーまで止まることがあります。逆にアカウント単位だけで制限すると、攻撃者が特定アカウントをわざとロックする嫌がらせができます。

そのため、ログインではレート制限だけでなく、MFA、アカウントロック、通知、CAPTCHA、リスクベース認証、監査ログを組み合わせて考えます。

Webhookで必要になる理由

Webhook は、外部サービスがイベント発生時にこちらのURLへHTTPリクエストを送ってくる仕組みです。
便利ですが、相手サービスの再送、障害復旧後の集中送信、設定ミス、悪意あるリクエストで、短時間に大量のアクセスが来ることがあります。

Webhook受信では、レート制限を雑に入れすぎると必要なイベントまで落としてしまいます。
一方で無制限に受けると、アプリサーバー、DB、キュー、メール送信、外部API呼び出しが一気に詰まることがあります。

現実的には、Webhookでは次のように分けて考えます。

署名検証に失敗するリクエストは早く拒否する
受信だけは軽く済ませ、重い処理はキューへ回す
同じイベントIDを二重処理しない
送信元サービスごとに制限を分ける
429を返したときに相手がどう再送するか確認する

Webhookは再送されることが多いため、冪等性も重要です。
同じイベントが2回来ても二重決済や二重メール送信にならないよう、イベントIDや処理済みフラグを使います。

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."
}

このように、何が起きたか、いつ再試行すべきか、利用者側がどう扱えばよいかを伝えると、無駄な再試行を減らせます。

設計でよくある失敗

レート制限でよくある失敗は、全員に同じ制限を雑にかけることです。
無料プランと有料プラン、通常ユーザーと管理者、軽い参照APIと重いCSV出力を同じ枠で制限すると、必要な利用まで止めたり、重い処理を守れなかったりします。

もうひとつは、制限した結果を監視していないことです。
429が大量に出ているのに誰も気づかないと、ユーザーは なんとなく使えない と感じます。攻撃なのか、人気機能なのか、フロントエンドのバグで連打しているのかも分かりません。

また、ログインでは厳しすぎるロックアウトがDoSの入口になることがあります。
攻撃者が他人のメールアドレスでわざと失敗を繰り返し、正規ユーザーを締め出せる設計は危険です。

レート制限は、止める仕組みであると同時に、状況を観測する仕組みでもあります。
どのキーで、どのエンドポイントが、どのくらい制限に達しているのかをログやメトリクスで見られるようにしておくと、改善しやすくなります。

まず決めるチェックリスト

レート制限を入れるときは、次を決めると設計しやすくなります。

何を守りたいのか: 認証、DB、外部API、メール送信、重い検索
誰を単位に数えるのか: IP、ユーザー、APIキー、アカウント、送信元サービス
どの時間窓で見るのか: 秒、分、時間、日
制限に達したら何を返すのか: 429、エラーメッセージ、Retry-After
正規ユーザーの巻き込みをどう減らすのか
制限に達したログやメトリクスをどう見るのか
リトライやWebhook再送で連鎖的に増えないか
管理者やサポートが解除・調査できるか

最初から完璧な数値を決めるのは難しいです。
まずは危険な入口から入れ、ログを見ながら調整する方が現実的です。

まとめ

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