IPアドレスによるレート制限：共有IP環境を前提にした設計

レート制限は、WebアプリケーションやAPIを不正利用、リソース枯渇、サービス拒否攻撃から守るための基本的な防御策です。最もシンプルで広く使われている方法は、IPアドレスごとのリクエスト数を追跡することです。しかし、このやり方は現代のネットワーク環境、特に共有IPアドレスの存在を前にすると、すぐに限界が見えてきます。

共有IPは、いまや至るところにあります。企業ネットワークのNAT、携帯キャリア網、公衆Wi-Fi、VPN、proxy、TORの出口ノードなどが代表例です。送信元IPだけを見て「1つのIP = 1人のユーザー、または1つの主体」と判断すると、正規ユーザーを誤ってブロックしてしまう false positive や、攻撃者が共有IPを使い回して制限をすり抜ける false negative が避けられません。

本記事では、単純な /32 や /128 単位のIPカウントにとどまらず、共有IP環境でも破綻しにくいレート制限を設計するための考え方を整理します。

The Core Problem: IP Address != User

かつては、1つのIPアドレスが1人のユーザー、あるいは静的NAT配下の小規模な利用者グループと強く結び付いているケースが少なくありませんでした。ところが現在、この前提はほとんど成り立ちません。

• Mobile Carriers: Carrier-Grade NAT（CGNAT）により、数千人、場合によっては数万人規模のユーザーが1つのグローバルIPv4アドレスを共有することがあります。
• Enterprise Networks: 大企業では、限られた数のグローバルIPに外向き通信を集約していることが一般的です。
• Public Wi-Fi/Hotspots: 店舗、空港、ホテル、イベント会場などでは、多数の利用者が同じゲートウェイIP経由で同時にアクセスします。
• Proxies, VPNs, TOR: これらのサービスは、プライバシー保護やアクセス制限の回避を目的に、複数ユーザーを共有IPの背後に集約します。攻撃者にとっても、匿名性を高めたり、多数のIPに負荷を分散したりする手段になります。
• Cloud Providers/Data Centers: クラウド環境やデータセンター上で動くワークロードは、多数のテナントが共有する大規模かつ既知のIPレンジから発信されることがよくあります。

多数の正規ユーザーが同じIPを共有している場合、単純なIP単位のレート制限はすぐに上限へ達し、そのIP配下のユーザーをまとめてブロックしてしまいます。一方で攻撃者は、proxy IPのプールをローテーションすることで、個々のIPでは制限内に見せかけながら、全体としては意図したしきい値を大きく超えるリクエストを送り込むことができます。

Beyond Simple IP: Augmenting Rate Limiting Signals

より堅牢なレート制限を実現するには、直近の送信元IPだけでなく、複数のシグナルを組み合わせて判断する必要があります。

1. User-Centric Identifiers

利用可能で、かつ利用目的として妥当な場合は、IPだけでなくユーザーIDにレート制限を紐づけます。特に認証済みの操作では、このアプローチが最も自然です。

• Session ID/Cookie: セッション単位でリクエストを追跡します。同じ利用者による反復的な操作を捉えやすくなり、共有IP配下の正規ユーザーを一括で制限してしまうリスクを下げられます。