IPレートリミットとは？

IPレートリミットとは、特定の期間内にIPアドレスがサーバーに送信できるリクエスト数を制限するメカニズムです。制限を超えると、サーバーは一時的にリクエストを拒否し、通常はHTTP 429エラー（「Too Many Requests」）を返します。サーバーを不正利用、サービス拒否攻撃、自動スクレイピングから保護するための最も一般的なツールのひとつです。

おそらく気づかないうちに遭遇したことがあるでしょう。ログインに何度か失敗した後にサイトが「試行回数が多すぎます。5分後にもう一度お試しください」と表示する場合、それはレートリミットです。APIが1分あたりの一定回数の呼び出し後にエラーを返す場合、それもレートリミットです。検索エンジンが検索速度が速すぎるためにクエリを一時的にブロックする場合、それもレートリミットです。

なぜ必要なのか

ウェブサーバーには限られたリソースがあります：CPU、メモリ、帯域幅、データベース接続。各リクエストはこれらのリソースの一部を消費します。制限がなければ、単一のユーザー（または自動化スクリプト）が毎秒数千のリクエストを送信してサーバーを独占し、他のすべてのユーザーにとってサービスを利用不能にする可能性があります。

レートリミットは複数の種類の脅威から保護します：

DDoS攻撃とブルートフォース攻撃。分散型サービス拒否攻撃（DDoS）はサーバーをリクエストで溢れさせて利用不能にします。レートリミットだけでは大規模なDDoS攻撃（数千の異なるIPから来る）をブロックするには不十分ですが、単一のIPが引き起こせる被害を制限します。ブルートフォース攻撃（数千のパスワードを試行）に対して、レートリミットは最初の防御線です：1分あたり5〜10回のログイン試行に制限することで攻撃を非現実的にします。

悪用されるスクレイピングとクローリング。サイトのコンテンツ（価格、記事、データ）を抽出するボットは毎秒数百のリクエストを送信します。レートリミットはこれらのボットを大量抽出が経済的に成り立たない程度まで減速させます（遅すぎる、サーバー時間がかかりすぎる）。

APIの悪用。パブリックAPI（天気、位置情報、AI、決済）はプロバイダーにとってリクエストあたりのコストがあります。レートリミットなしでは、ユーザーが不釣り合いなリソースを消費する可能性があります。コードのループによる事故でも、意図的にでも。ほとんどのAPIはAPIキーとIPアドレスごとに制限を設けています。

ユーザー間の公平性。悪意がなくても、「貪欲な」ユーザー（1分に50回ページを更新する、または書き方の悪いスクリプト）は他のユーザーの体験を劣化させる可能性があります。レートリミットはリソースの公平な共有を保証します。

技術的な仕組み

原理はシンプルです：サーバーは各リクエストをIPアドレスに関連付け、時間ウィンドウ内にそのIPから受信したリクエスト数をカウントし、定義された閾値を超えるリクエストを拒否します。ただし、具体的な実装は使用するアルゴリズムによって異なります。

固定ウィンドウ（Fixed Window）。時間は固定間隔（例：1分間のウィンドウ）に分割されます。サーバーは各ウィンドウ内でIPごとにリクエストをカウントします。現在のウィンドウで100リクエストに達すると、次のウィンドウが始まるまで後続のリクエストは拒否されます。最もシンプルなアルゴリズムですが、欠点があります：あるウィンドウの終わりに100リクエスト、次のウィンドウの始まりに100リクエストを送信すると、数秒で200リクエストを送信したことになり、想定される制限の2倍です。

スライディングウィンドウ（Sliding Window）。固定ウィンドウの代わりに、サーバーは任意の時点で直近のN秒を見ます。各リクエストはスライディング期間にわたってカウントされます。これにより分布が平滑化され、固定ウィンドウの問題が解消されますが、サーバー側でより多くのメモリと計算が必要です。

トークンバケット（Token Bucket）。各IPには固定数のトークンを含む「バケット」があります。各リクエストはトークンを1つ消費します。トークンは一定の速度で再生されます（例：毎秒10個）。バケットが空の場合、リクエストは拒否されます。このモデルは短いバースト（burst）を許容します：バケットが満杯なら一度に多くのリクエストを送信でき、その後再生を待つ必要があります。柔軟で予測可能なため、本番環境で最も広く使用されているアルゴリズムです。

リーキーバケット（Leaky Bucket）。リクエストはキュー（バケット）に入り、一定の速度（漏れの速度）で処理されます。バケットが満杯の場合、新しいリクエストは拒否されます。トークンバケットとは異なり、リーキーバケットはバーストなしで厳密に一定の出力速度を強制します。完全に均一な処理フローが必要な場合に有用です。

レートリミットが適用される場所

レートリミットはネットワークインフラストラクチャのさまざまなレベルで適用でき、実際にはよくそうなっています：複数のレイヤーが重なり合います。

ウェブサーバーレベル。Nginx、Apache、ほとんどのウェブサーバーにはレートリミットモジュールが組み込まれています。Nginxは例えば、limit_reqディレクティブでリーキーバケットアルゴリズムを使用します。IPあたりの秒間リクエスト数を定義すれば、Nginxが残りを処理します。基本的な保護には効果的ですが、サーバーは拒否する前に各リクエストを受信し部分的に処理する必要があります。

リバースプロキシまたはロードバランサーレベル。アプリケーションサーバーの前にレートリミットを配置する（NginxやHAProxyなどのリバースプロキシ、またはロードバランサー上）ことで、リクエストがアプリケーションに到達する前にブロックできます。リソース効率が高くなります。

CDNまたはWAFレベル。Cloudflare、AWS WAF、Akamaiなどのサービスはネットワークエッジでレートリミットを適用し、リクエストがインフラストラクチャに到達する前にブロックします。ボリューム型攻撃に対して最も効果的なレイヤーです。リクエストがソースにできるだけ近い場所でブロックされるからです。

アプリケーションレベル。アプリケーション自体がレートリミットを実装でき、多くの場合より細かい粒度で：ログインユーザーごと、エンドポイントごと、操作タイプごと。例えば、APIは1分あたり1,000のGETリクエストを許可しつつ、アカウント作成エンドポイントでは10のPOSTリクエストのみを許可する場合があります。悪用的なアカウント作成の試みは一般的な攻撃ベクトルだからです。

レートリミットに関連するHTTPヘッダー

サーバーがレートリミットを適用する際、通常はレスポンスのHTTPヘッダーを通じて制限情報を伝達します。ユニバーサルな標準はありませんが、最も一般的な規約は以下の通りです：

X-RateLimit-Limit：現在の時間ウィンドウで許可される最大リクエスト数。X-RateLimit-Remaining：制限に達するまでの残りリクエスト数。X-RateLimit-Reset：ウィンドウがリセットされカウンターがゼロに戻る時点（Unixタイムスタンプまたは残り秒数として）。Retry-After：リトライまでの待ち時間を示す標準HTTPヘッダーで、429レスポンスとともに返されます。

IETFドラフト（429ステータスコード用のRFC 6585およびより新しい提案）がこれらのヘッダーの標準化を試みていますが、実際にはAPIごとに独自の規約を使用しています。APIを消費するアプリケーションを開発する場合は、制限の伝達方法を知るためにAPIドキュメントを必ず読んでください。

IPだけでは常に十分でない理由

IPベースのレートリミットには根本的な問題があります：IPアドレスは常に単一のユーザーに対応するとは限りません。

CGNAT。多くのモバイルキャリアと一部のISPはCGNAT（Carrier-Grade NAT）を使用しており、数百から数千のユーザーが単一のパブリックIPv4アドレスを共有します。IPを1分あたり100リクエストに制限すると、実際にはそのCGNATの背後にいるすべてのユーザーを合計100リクエストに制限していることになります。一人の通常のユーザーが他のすべてのユーザーのクォータを使い果たす可能性があります。

企業ネットワークと大学ネットワーク。数千の社員や学生が単一のパブリックIPアドレス（または少数のアドレス）を通じてインターネットにアクセスする場合があります。IPベースのレートリミットは彼らを集団的にペナルティします。

VPNとプロキシ。VPNユーザーは多くの場合、数百の他のユーザーとIPアドレスを共有しています。厳格なIPベースのレートリミットは、ボットと同じVPNサーバーを使用しているという理由だけで正当なユーザーをブロックする可能性があります。

動的IPアドレス。逆に、攻撃者はIPアドレスを簡単に変更でき（プロキシプール、ボットネット、または単に電話の機内モードを切り替えて）、IPベースのレートリミットを回避できます。制限がIPごとで攻撃者が10,000のアドレスにアクセスできれば、実効的な制限は10,000倍になります。

そのため、現代のレートリミットシステムは通常、IPを他の識別子と組み合わせます：APIキー、認証トークン、ブラウザフィンガープリント、セッションCookie。IPは有用な基準のままですが、単独で十分であることはまれです。

制限されたときに何が起こるか

最も一般的なレスポンスはHTTP 429ステータスコード（Too Many Requests）です。サーバーは、制限が個別の超過ではなく全般的な過負荷による場合、503（Service Unavailable）を返すこともあります。

一部のサービスはアクセスを完全にブロックするのではなく、サービスを劣化させます：レスポンスを遅延させる（スロットリング）、結果の品質を低下させる、またはCAPTCHAを追加して人間であることを確認します。

他のサービスは明示的なエラーを返さずにサイレントにブロックします。200（OK）ステータスコードで応答し続けますが、空のデータまたは劣化した結果を返します。この「サイレントレートリミット」（シャドウバン）はソーシャルネットワークや一部の検索エンジンで一般的であり、ボットが検出しにくいように設計されています。

開発者がレートリミットをどう扱うか

APIを消費するアプリケーションを開発している場合、レートリミットを適切に処理する必要があります。標準的な方法は「指数バックオフ」（exponential backoff）です：429レスポンスを受け取ったら、リトライ前に一定時間待ち、連続する各失敗ごとにその時間を2倍にします。例：最初のリトライは1秒後、2回目は2秒後、3回目は4秒後など。

ベストプラクティスには以下が含まれます：

Retry-AfterとX-RateLimit-Resetヘッダーを読んで、推測ではなくいつリトライすべきかを正確に把握する。同じリクエストの繰り返しを避けるためにキャッシュを実装する。APIが許可する場合にリクエストをバッチ処理する。バーストではなく時間をかけてリクエストを分散する。429エラーが蓄積した場合にしばらくAPI呼び出しを停止するサーキットブレーカーを設け、状況を悪化させないようにする。

レートリミットとプライバシー

IPベースのレートリミットは、サーバーがIPアドレスでリクエストを識別し追跡することを意味します。これは個人データの処理の一形態です（IPアドレスは多くの法域で個人データとみなされ、特に欧州のGDPRや日本の個人情報保護法の下で）。レートリミットを実装する企業は理論的にはプライバシーポリシーでこの処理に言及すべきです。

ユーザーの観点からは、IPベースのレートリミットはあなたの活動がカウントされていることも意味します。プライバシーのためにVPNやプロキシを使用している場合、レートリミットは逆説的にあなたにペナルティを課す可能性があります：他のユーザーとIPを共有しており、共有クォータがより速く枯渇します。

レートリミットの回避

IPアドレスの変更（VPN、ローテーティングプロキシ、またはモバイルの機内モードを通じて）により、IPのみに基づくレートリミットを回避できます。商用スクレイピングサービスは数千の住宅用IPアドレスプールを使用してリクエストを分散し、IPあたりの閾値以下に留まります。

しかし現代の保護システムはIPだけに頼りません。ブラウザフィンガープリント分析、ブラウジング行動（クリックのリズム、マウスの動き、ページ滞在時間）、CAPTCHA、リクエストパターン分析を組み合わせて、IPが各リクエストで変わっても人間とボットを区別します。

レートリミットシステムと回避テクニックの競争は永続的です。今日機能する方法は明日検出される可能性があります。サーバー側にいる場合、最善の戦略はIPだけに頼るのではなく、複数の保護レイヤーを組み合わせることです。

一般的な制限の例

これらの制限はサービス、料金プラン、コンテキストによって大きく異なります。有料APIは通常、無料プランよりもはるかに高い制限を提供します。機密性の高いエンドポイント（ログイン、決済、アカウント作成）はデータ読み取りエンドポイントよりもはるかに低い制限があります。

IPレートリミットは、インターネットに公開されるすべてのサーバーにとって不可欠な保護です。不正利用を防ぎ、リソースを保護し、公平なアクセスを保証します。しかしCGNAT、VPN、プロキシにより、IP単独では信頼性の低い識別子になりつつあります。現代のシステムは正当なトラフィックと悪用トラフィックを区別するためにIPを他のシグナルと組み合わせており、効果的な保護と簡単に回避できる単純なフィルターの違いを生むのはこの組み合わせです。