無料トライアルを開始ログイン

用語集

レート制限とは何か？

レート制限とは、単一のクライアント（IP、アカウント、またはセッションで識別）が特定の時間窓内に実行できるリクエスト数を制限するサーバー側の防御手段であり、インフラストラクチャの保護、悪用の防止、および公平なリソース使用の確保に使用されます。

ウェブサイトとAPIが大量クライアントのリクエストを制限する仕組み、レートリミットの背後にあるアルゴリズム（トークンバケット、スライディングウィンドウ、固定ウィンドウ）、およびローテーションプロキシがIP単位の上限を回避する方法を理解する。

解説

レート制限とは、サーバーが不正使用から自身を守る仕組みです。公開されているすべてのAPIやウェブサイトは、単一クライアントが一定時間内に送信できるリクエスト数を制限しています。例：`100 requests per IP per minute`、`5000 requests per API key per hour`、`30 logins per account per day`。クライアントが上限を超えると、サーバーは429 Too Many Responsesを返します（場合によっては、静かに応答を遅くしたり、リクエストをキューに入れたり、CAPTCHAを表示したりすることもあります）。

スクレイピングやデータ収集の作業において、レート制限はどれだけ速く処理できるかを決める運用上の基本条件です。単純な解決策（リクエスト数を減らす）はスループットを制限します。真の解決策は、リクエストを多くの識別子（IP、アカウント、セッションID）に分散させ、いかなる単一識別子も上限を超えないようにすることです。それがレジデンシャルプロキシが製品カテゴリとして存在する理由です。

サーバー側のレート制限アルゴリズムにはいくつかの種類があります。トークンバケットは、クライアントが上限まで一定速度でトークンを蓄積でき、上限サイズまでのバーストを許容します。スライディングウィンドウは、移動する時間ウィンドウ内のリクエストをカウントし、上限を平滑化します。固定ウィンドウは、時刻の境界（毎分、毎時）でカウントをリセットします。それぞれ、スクレイパーがリクエストのペースをどう調整すべきかに異なる影響を与えます。

仕組み

サーバーは受信リクエストのたびにクライアントを識別し（IP、API key、アカウントID、またはセッショントークンによって）、現在のウィンドウ内でその識別子のカウンターを確認します。カウンターが上限以下であれば、リクエストは通過してカウンターが加算されます。カウンターが上限を超えている場合、サーバーは429を返し、待機時間を示す `Retry-After` ヘッダーを付与します。

ほとんどの大規模APIは複数の識別子を組み合わせて使用しています。同じIPとアカウントでも、異なるカウンターに対して異なる制限が適用されます。たとえばCloudflareのレート制限ルールは、IP、URL パス、セッション、またはそれらの任意の組み合わせで制限をスコープできます。より高度なシステムでは、より滑らかな制御のためにリーキーバケットやスライディングウィンドウカウンターの変形を使用します。

型

トークンバケット

バケットは一定のレートでトークンが補充され、上限まで蓄積されます。各リクエストはトークンを1つ消費します。バケットサイズまでのバーストが許可され、時間をかけて平滑化されます。現代のAPIレート制限で最も一般的なアルゴリズムです。

Leaky Bucket

リクエストはバケットと呼ばれるキューに入り、一定の速度で処理されます。超過したリクエストはオーバーフローして拒否されます。トークンバケットよりも厳密にバーストを平滑化します。

固定ウィンドウ

カウンターは時計の区切り（毎分、毎時）でリセットされます。実装は簡単ですが、ウィンドウ境界でのバースト問題があります（クライアントが2つのウィンドウにまたがることで上限の2倍を送信できます）。

スライディングウィンドウ

カウンターは固定ウィンドウではなく直近のN秒間を参照します。固定ウィンドウより滑らかな制限が可能です。スライディングウィンドウログとスライディングウィンドウカウンターが一般的な実装です。

アダプティブ・行動ベースのレートリミット

リクエストのパターンとリスクスコアに基づいて制限が調整される。アンチボットベンダー（Cloudflare、Datadome）が使用する。同じクライアントでも、トラフィックがどれだけ「本物らしく」見えるかによって、1分あたり1000リクエストまたは10リクエストが許可される場合がある。

主な使用事例

公開APIの不正利用からの保護
クレデンシャルスタッフィング攻撃の防止（ログインレート制限）
大規模なインフラコストの管理
顧客全体への公正な利用ティアの適用
スクレイパーやコンテンツ乱用の遅延
障害発生時のリトライストームをスロットリング
FAQ

よくある質問

よくある質問： レート制限.

多数のIPにリクエストを分散させることによって実現します。ターゲットがIPごとに1分間60リクエストでレート制限している場合、10,000 IPのリジデンシャルプールを通じてリクエストごとにローテーションすると、理論上は1分間に600,000リクエストを達成でき、単一のIPが制限に引っかかることはありません。実際にはビヘイビアシグナルも重要ですが、IPローテーションが基本的な手法です。

HTTP 429「Too Many Requests」は、クライアントがレート制限を超えたことを示します。レスポンスには通常、再試行までの待機時間を示す`Retry-After`ヘッダーが含まれます。適切に実装されたクライアントはRetry-Afterを尊重します。スループットを高める必要があるスクレイパーは、新しいIPにローテーションして即座に再試行します。

わずかにしか効果がありません。リクエストをキャップ未満のペースに抑え、1つのIPをゆっくり再利用することで対処できます。実際の大規模ユースケースでは、ローテーティングプロキシが必要です。レジデンシャルプールなしにIPごとのレート制限を回避するために十分な独立したIPを購入するコストは、小規模なオペレーション以外では現実的ではありません。

レスポンスヘッダーを読んでください。多くのAPIは、上限、残りの予算、ウィンドウのリセット時刻を示す `X-RateLimit-Limit`、`X-RateLimit-Remaining`、`X-RateLimit-Reset` ヘッダーを送信します。これらを送信しないサイトでは、レスポンスコード（401、429、503）を監視し、これらが現れ始めたらアクセスを控えてください。

レート制限はリクエスト量を絞り込みます。CAPTCHAはクライアントに人間であることを証明させます。多くのアンチボットの仕組みは両方を組み合わせています。レート制限以下ではリクエストが通過し、上限を超えるとハードブロックの代わりにCAPTCHAチャレンジが表示されます。どちらも異なる角度から同じ脅威に対処します。

はい。Shifterのレジデンシャルプロキシゲートウェイは、大規模なIPプール全体にリクエストを分散するため、IP単位のレート制限は全体のトラフィック量のごく一部にしか適用されません。セッションごとのリアルなペーシングと最新のブラウザフィンガープリントと組み合わせることで、ほとんどのレート制限の壁は事実上見えなくなります。