エンジニア諸君、現場は戦場だ。今日もどこかで誰かが「APIが急に重くなった」「データベースのコネクションが枯渇した」と悲鳴を上げていることだろう。
多くのエンジニアが「認証さえ通せば安全」と信じ込んでいるが、それは大きな間違いだ。認証済みのユーザーであっても、あるいは未認証のボットであっても、APIの「流量（レート）」を制御しなければ、それは単なる可用性の欠如ではなく、システム全体の崩壊を招く脆弱性となる。
今日は、教科書的な「レート制限しましょう」という話ではなく、なぜ多くの現場がここを突破され、どう実装すれば攻撃者を無力化できるのか、その核心に切り込む。
1. なぜ「トークンバケット」なのか：攻撃者の視点から考える
単純な「1分間に100リクエスト」という制限は、実は非常に脆い。攻撃者は「バースト」を狙う。数秒間に1,000リクエストを叩き込み、サーバーのメモリやスレッドを瞬時に食いつぶす「スパイキーな攻撃」だ。
ここで「トークンバケットアルゴリズム」の出番だ。バケツ（バケット）に一定の速度でトークンを補充し、リクエストが来るたびにトークンを消費する。この方式の強みは、「ある程度の急激な負荷（バースト）を許容しつつ、長期的には平均流量を厳守できる」点にある。
攻撃者は、このバケットの深さ（バースト耐性）と補充レート（定常流量）を正確に推測してくる。ここを甘く設計すると、認証基盤へのブルートフォース攻撃や、リソース集約型のAPIに対するDoS攻撃の踏み台にされる。
2. 実践：Redisを用いた堅牢なレート制限（Python/FastAPI実装）
メモリ上に制限を置くのはNGだ。複数台のサーバーで構成される現代のインフラでは、各ノードが独立してカウントすると、全体としての流量は制限を大きく超えてしまう。必ず「Redis」のような中央集権的なカウンターを使うこと。
以下は、redis-pyを用いたトークンバケットに近い実装例だ。
import time
import redis
# Redis接続（本番環境では環境変数で管理すること）
r = redis.Redis(host='localhost', port=6379, db=0)
def is_rate_limited(user_id: str, limit: int = 100, window: int = 60) -> bool:
"""
ユーザーごとのリクエスト数をカウントし、制限を超えるか判定する
:param user_id: ユーザーの一意識別子
:param limit: 許可する最大リクエスト数
:param window: 制限期間（秒）
"""
key = f"rate_limit:{user_id}"
# トランザクション処理でアトミックに実行
pipe = r.pipeline()
now = int(time.time())
# 現在のカウントを取得し、一定期間経過していればリセットする論理を内包
pipe.incr(key)
pipe.expire(key, window)
count, _ = pipe.execute()
# 制限を超えていればTrueを返す
return count > limit
# FastAPIのミドルウェアや依存関係で呼び出す想定3. インフラ層での防御：Nginxによる「即死」回避
アプリケーションコードに到達する前に、異常なトラフィックは遮断すべきだ。Webアプリケーションファイアウォール（WAF）やロードバランサー以前の「門番」として、Nginxの limit_req モジュールは最強の武器になる。
nginx.conf に以下の設定を投入してほしい。
# 共有メモリゾーンを定義（10MBで約16万IP分の状態を保持）
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
location /api/ {
# 10リクエスト/秒を許容。バースト値（burst）を設定して急激なアクセスを緩和
# nodelayを指定することで、バースト分を即座に捌きつつ、レート制限を適用する
limit_req zone=api_limit burst=20 nodelay;
# 制限に引っかかった際のレスポンスコード
limit_req_status 429;
proxy_pass http://backend_cluster;
}
}この設定の肝は nodelay だ。これを外すと、バースト時にリクエストがキューイングされ、結果的にバックエンドの応答が遅延し、システム全体が「スローダウン攻撃」を受けた状態になる。429 Too Many Requests を即座に返し、TCPコネクションを切断するのが最も「安上がり」な防御策だ。
4. 現場で生き残るための「心構え」
最後に、エンジニアとして忘れてはならないのは以下の3点だ。
1. IP制限は万能ではない: 公衆Wi-FiやNAT環境下では、多数のユーザーが同一IPになる。必ず User-Agent だけでなく、認証済みの User ID をキーに含めること。
2. 監視なき制限は盲目: 429 エラーが頻発しているなら、それは攻撃かもしれないし、自社のフロントエンドがバグで無限ループしているだけかもしれない。必ずモニタリング（Prometheus + Grafanaなど）でログを可視化せよ。
3. 例外を定義せよ: 重要な外部パートナーや特定の重要APIには、別のバケットを用意する。一律の制限は、ビジネスの機会損失を招く。
セキュリティは「完成」しない。攻撃手法は常に進化する。だが、このようにインフラとアプリケーションの両面で「層状防御」を築いていれば、相手がどれほど狡猾なボットネットを使おうとも、システムを沈めることはできない。
さあ、コードを書いて、ログを監視し、自分のシステムを守り抜け。何かあればまた相談してくれ。
コメント