Cloudflare 06：レート制限 ― 回数を数えて、多すぎたら止める

レート制限：同じ相手の回数を数え、多すぎたら止める

そこで使うのがレート制限（Rate Limiting）です。「レート」は、一定の時間あたりの回数のことです。

レート制限は、同じ相手から来たリクエストの回数を数え、決めた上限を超えたら止める仕組みです。中身は見ません。回数だけを見ます。

Cloudflare のレート制限ルールは、次の4つの決めごとでできています。

このあとのページで、1つずつ見ていきます。

エッジの中での置き場所は、05号で見たとおり、WAF のカスタムルールの後ろ、マネージドルールの前です。管理画面でも、WAF と同じ場所に並んでいます。

レート制限はアプリの中でも作れます。ただ、エッジで止めれば、上限を超えたリクエストはオリジンまで届きません。サーバーの負担を減らすという意味でも、前に置く価値があります。

① どのリクエストを数えるか

最初に決めるのは、どのリクエストを数えるかです。図の下にあるのは、「パスが /login で、メソッドが POST」のリクエストだけを数える条件です。

書き方は、05号の WAF のカスタムルールと同じルールの言葉です。項目・比べ方・値を and や or でつなぎます。

ここで大事なのは、サイト全体を1つのルールで数えないことです。1つのページを開くと、ブラウザは HTML のほかに、画像・CSS・JavaScript・フォントなどを何十本も取りに行きます。全部を数えると、普通の人がページを数枚めくっただけで上限に届いてしまいます。

守りたい入口ごとに、狙いを絞ってルールを作ります。

上位のプランでは、リクエストだけでなく応答を見て数えることもできます。たとえば「オリジンが 401（認証失敗）を返したものだけを数える」とすれば、正しくログインできた人の回数は数えずに、失敗の多い相手だけを止められます。

② 誰ごとに数えるか（特徴）

次に決めるのは、誰ごとに数えるかです。Cloudflare はこれを特徴（characteristics）と呼びます。

いちばん基本の特徴は、送り元の IP アドレスです。図のように、IP ごとに別々の数え箱を持ち、それぞれの箱の回数が上限を超えたら、その IP だけを止めます。他の IP の利用者には影響しません。

ただし、IP には弱点があります。

1つ目は、止めすぎの原因になります。上限を厳しくしすぎると、同じ会社の人がまとめて締め出されます。2つ目は、止まらない原因になります。攻撃者が1つの IP あたりの回数を減らし、IP を増やせば、上限に届きません。

そこで上位のプランでは、IP 以外の特徴でも数えられます。たとえば、API キーのヘッダー、ログインしている利用者の Cookie、国などです。API なら、IP ではなく API キーごとに数えるほうが、利用者1人あたりの使いすぎを正しく抑えられます。

③ 何秒のあいだに何回まで（期間と上限）

3つ目は、期間と上限です。「10秒で5回まで」「60秒で100回まで」のように決めます。

図は、時間の軸の上に、同じ IP から来たログインのリクエストを縦の刻みで並べたものです。1秒に1回のペースで送られてきています。青い枠が「10秒の窓」です。この窓の中に、10本の刻みが入っています。上限が5回なら、6回目からルールの動作がかかります。赤くなった刻みがそれです。

期間と上限の決め方の目安は、「普通の人が絶対に届かない回数」です。ログインなら、人間が1分に何回も打ち間違えることはあまりありません。一方、API なら、アプリが1画面を表示するのに何本も呼ぶことがあるので、もっと大きな上限が必要です。

最初から厳しい上限にすると、思わぬ場面で正しい利用者を止めてしまいます。はじめはゆるく設定し、分析の画面で実際の回数を見ながら締めていくのが安全です。

なお、期間として選べる値は決まっていて、プランによって選べる範囲が違います。Free プランでは10秒に固定です。

④ 超えたら、しばらく止める（止める時間）

最後は、上限を超えた相手を、どれだけの時間止め続けるかです。Cloudflare はこれを mitigation timeout（緩和の継続時間）と呼びます。

図の赤い帯が、その時間です。6回目で上限を超えた瞬間から、この例では60秒間、その IP からの /login への POST は、何を送っても止められます。帯の間の刻みは、すべて赤です。

この時間の長さは、両方向に悩ましいものです。

ログインの総当たりなら、数分〜10分程度が1つの目安になります。1回の総当たりで試せる回数を、大きく減らせるからです。

一方で、レート制限だけで総当たりを完全に防ぐことはできません。攻撃者は IP を変えられるからです。アプリの側でも、失敗が続いたアカウントのロック、二要素認証、07号のボット対策や 08号の Turnstile を組み合わせます。

動作：止める・確かめる・429 を返す

上限を超えたときの動作は、05号の WAF とほぼ同じです。

Block のときに返す応答は、状態コードや本文を変えられます。API なら、JSON で「しばらく待ってください」と返すと、アプリ側で扱いやすくなります。429 は「回数が多すぎる」を表す状態コードで、行儀のよいクライアントは、これを受け取ると待ってから再試行します。

Challenge は、ブラウザでしか通れません。スマホアプリや、サーバー同士の通信に Challenge を掛けると、正しい相手まで止まります。API には Block を使いましょう。

どの動作を選べるか、応答を見て数えられるか（上位プラン）などは、プランによって違います。Free プランで選べるのは Block です。

例：ログインの総当たりを止める

ここまでの4つの決めごとを、ログインの例でまとめます。

これで、1つの IP から1分に6回以上ログインを試すと、その IP は10分間ログインを送れなくなります。人間の利用者なら、1分に6回も失敗することはまずありません。一方、攻撃者の試行は、1つの IP あたり1時間に数十回程度にまで落ちます。

Free プランでは、期間と止める時間が10秒に固定されるので、この例と同じ設定はできません。それでも「10秒で5回まで」だけでも、1秒に何十回という機械的な総当たりは大きく遅くなります。

レート制限はあくまで遅くする道具です。IP をたくさん持つ攻撃者は、1つの IP あたりの回数を上限以下に抑えてきます。アプリ側のアカウントロック、二要素認証、そして強いパスワードの強制と組み合わせることで、はじめて総当たりに強いログインになります。

導入：管理画面でルールを1本作る

レート制限ルールは、管理画面でドメインを選び、セキュリティ > WAF の中のレート制限ルールから作ります。新しいセキュリティの管理画面では、WAF のカスタムルールなどと一緒に「セキュリティルール」として並んでいます。表示の場所は変わることがあるので、見つからないときは公式のドキュメントで確かめてください。

作ったあとは、セキュリティの分析画面で、どの IP がどれくらいの回数でルールに当たっているかを見ます。正しい利用者が当たっているようなら上限をゆるめ、攻撃が抜けているようなら締めます。

前提として、ルールが効くのは Cloudflare のプロキシを通るリクエストだけです。オリジンの IP が漏れていると、攻撃者は Cloudflare を通らずにログイン画面を叩けます。04号の「Cloudflare からしか受けない」設定は、ここでも前提です。

コードで書く：Terraform と Workers

ルールは管理画面のほか、API や Terraform でも書けます（34号）。図の左は、Terraform の設定の一部です。全体は次のような形になります。

resource "cloudflare_ruleset" "login_rl" {
  zone_id = var.zone_id
  name    = "login rate limit"
  kind    = "zone"
  phase   = "http_ratelimit"
  rules = [{
    expression = "(http.request.uri.path eq \"/login\" and http.request.method eq \"POST\")"
    action     = "block"
    ratelimit = {
      characteristics     = ["cf.colo.id", "ip.src"]
      period              = 60
      requests_per_period = 5
      mitigation_timeout  = 600
    }
  }]
}

characteristics に cf.colo.id（拠点の ID）が入っているのは、回数を拠点ごとに数えるためです。これは落とし穴のページでもう一度出てきます。Terraform のプロバイダーは版によって書き方が変わるので、使う版のドキュメントに合わせてください。

アプリの中で、ログインしている利用者ごとに数えたいときは、Workers（18号）の Rate Limiting バインディングが使えます。

[[ratelimits]]
name = "LIMITER"
namespace_id = "1001"
simple = { limit = 5, period = 60 }

const { success } = await env.LIMITER.limit({ key: userId });
if (!success) return new Response("多すぎます", { status: 429 });

期間は10秒か60秒から選びます。厳密な回数を数える仕組みではなく、「おおよそ」で止めるものなので、課金の回数の管理のように正確さが要る用途には、Durable Objects（21号）を使います。

料金と制限

レート制限ルールは、Free プランでも1本使えます。次の表は 2026年9月時点の目安です。

レート制限は、以前は「リクエスト数に応じて課金する」製品でしたが、今はプランに含まれる形になり、止めたリクエストの数で料金が増えることはありません。

Pro・Business の本数や選べる値は、見直されることがあります。具体的な数は、公式の料金ページとドキュメントの「プランごとの提供範囲」で確かめてください。

よくある落とし穴

とくに2つ目は知らない人が多い点です。レート制限の回数は、Cloudflare の拠点ごとに数えられ、世界全体の合計ではありません。ふつうは1人の相手は1つの拠点にしかつながらないので問題になりませんが、「全世界で合計何回まで」という厳密な制限には向きません。

他の号とのつながり

レート制限は「回数」を見る守りです。ほかの守りと、見ているものが違います。

ログインを守るなら、このうち複数を重ねるのが基本です。たとえば、ログインのフォームに Turnstile（08号）を置き、レート制限で回数を抑え、ボット対策（07号）で自動化の道具を見分けます。

アプリの中で数えたいときは、Workers（18号）の Rate Limiting バインディングや、正確に数えられる Durable Objects（21号）が使えます。AI の API の使いすぎを抑えたいなら、AI Gateway（30号）にもレート制限の機能があります。ルールの状況を分析する方法は 32号、ルールをコードで管理する方法は 34号で扱います。