悪意のあるボットトラフィックへの適切な防御は、サイトのトラフィックパターンとプランによって異なります。このガイドでは、Cloudflare Bots、Cloudflare Application Security(Web Application Firewall、WAF とも呼ばれます)、Turnstile を使い、基本的な保護から対象を絞ったカスタムルールまで、層を重ねたアプローチを説明します。中核のワークフローは Free、Pro、Business プランの機能を使います。Enterprise 向けの選択肢は補足で示します。
ボット設定を変える前に、トラフィックデータを確認し、ボットがサイト上で何をしているかを把握します。
Bot Analytics では、トラフィックのうち自動化されている割合、ボットが狙うページ、Cloudflare が各リクエストに付けるスコアを確認できます。
-
Cloudflare ダッシュボードで Analytics ページを開きます。
Analytics を開く ↗ -
Bot analysis タブを選びます。
次を確認します。
- Bot score distribution chart: 1 に近いスコアは自動トラフィックを示します。99 に近いスコアは人間のトラフィックを示します。
- Top requested paths: ボットトラフィックが最も多いエンドポイントです。ログインページ、API エンドポイント、チェックアウトフローはよく狙われます。
- Traffic patterns: 低スコアのトラフィックの急増、特定のユーザーエージェントの大量出現、リクエストの地理的な集中は、調査すべきボット活動を示すことがあります。
Cloudflare は、ボットスコアと検証状態に基づいて、ボットトラフィックを次のカテゴリに分類します。
- Verified bots: Googlebot、Bingbot、稼働監視サービスなど、Cloudflare が正当だと確認したクローラーとサービスです。Cloudflare は、要件の厳しい 検証済みボットのリスト を維持しています。
- Automated(スコア 1): リクエストが自動化されていると、Cloudflare がかなり確信しています。
- Likely automated(スコア 2-29): ボットである可能性が高いです。このカテゴリと Automated は、スクレイパー、クレデンシャルスタッフィングツール、スパム送信ツールを含む、セキュリティルールの主な対象です。
- Likely human(スコア 30-99): 実際のユーザーからのリクエストに見えます。このトラフィックはチャレンジもブロックもしないでください。
Bot Fight Mode は、既知のボットパターンに一致するリクエストを識別し、計算コストの高いチャレンジを発行します。ルールを書かずに、サイト全体の自動トラフィックを減らせます。
Bot Fight Mode は Free プランに含まれます。有効にすると、次を行います。
- 既知のボットのパターンに一致するトラフィックを識別します
- これらのボットに対して、計算コストの高いチャレンジを発行します
- エンドポイント制限なしでドメイン全体を保護します
- カスタムルールではカスタマイズ、調整、再設定できません
- カスタムルール の Skip アクションではバイパスできません。許可したいリクエストに Bot Fight Mode がチャレンジする場合は、Bot Fight Mode をオフにするか、より細かい制御ができる Super Bot Fight Mode へアップグレードします。
詳細は Bot Fight Mode の考慮事項 を参照してください。
-
Cloudflare ダッシュボードで Security Settings ページを開きます。
Settings を開く ↗ -
Bot traffic で絞り込みます。
-
Bot fight mode を開きます。
-
Bot fight mode をオンにします。
Super Bot Fight Mode には、検証済みボットの許可リスト、カテゴリごとのアクション、静的リソースの保護、JavaScript 検出が加わります。
-
Cloudflare ダッシュボードで Security Settings ページを開きます。
Settings を開く ↗ -
Bot traffic で絞り込みます。
-
Super Bot Fight Mode を開きます。
-
Super Bot Fight Mode をオンにします。
-
各種類のトラフィックへの応答方法を、対応する編集アイコンを選んで設定します。
- 検証済みボットの詳細は、Verified Bots を参照してください。
- 対応ファイルタイプの詳細は、静的リソース保護 を参照してください。
- 不可視のコード注入の詳細は、JavaScript detections を参照してください。
- WordPress 最適化の詳細は、Super Bot Fight Mode for WordPress を参照してください。
Turnstile と Application Security の レート制限ルール は、それぞれ異なる方法でフォームエンドポイントを保護し、併用すると最も効果的です。
Turnstile は、訪問者に CAPTCHA を見せずに、疑わしいボットがフォーム(ログイン、サインアップ、お問い合わせ、チェックアウト)を送信する前にチャレンジします。トラフィックを Cloudflare 経由にしなくても、任意の Web サイトに埋め込めます。自動のフォーム送信にチャレンジしたいときに Turnstile を使います。
レート制限では、式に一致するリクエストのレート上限と、上限に達したときのアクションを定義できます。ログインページへの総当たり攻撃や、1 つのクライアントからの過剰な API 呼び出しなど、エンドポイントの不正利用を防ぐために使います。
両方を組み合わせると、カバー範囲が最も広くなります。Turnstile はフォーム単位で自動送信にチャレンジします。レート制限は、クライアント側ウィジェットをスキップするエンドポイントへの直接 POST など、フォームを迂回する、またはフォームに到達しない大量攻撃を捕捉します。
Turnstile の追加は 3 ステップです。ウィジェットを作成し、クライアント側スニペットを追加し、サーバーでトークンを検証します。
Turnstile はアカウントレベルで設定します。
-
Cloudflare ダッシュボードで Turnstile ページを開きます。
Turnstile を開く ↗ -
Add widget を選択します。
-
必要な情報を入力します。
- Widget name: ウィジェットのわかりやすい名前です。
- Hostname management: ウィジェットを使うドメインです。
- Widget mode: Managed、Non-Interactive、Invisible から選びます。
-
(任意)シングルページアプリケーション向けに Pre-clearance support を設定します。
-
Create を選択してウィジェットを保存します。
-
sitekey とシークレットキーをコピーし、シークレットキーは安全に保管します。
以降の手順では、sitekey と secret key の両方が必要です。
フォームの HTML に Turnstile のスクリプトとウィジェット用コンテナを追加します。
<script
src="https://challenges.cloudflare.com/turnstile/v0/api.js"
async
defer
></script>
<form action="/submit" method="POST">
<!-- Your existing form fields -->
<div class="cf-turnstile" data-sitekey="<YOUR_SITE_KEY>"></div>
<button type="submit">Submit</button>
</form><YOUR_SITE_KEY> を、前の手順の sitekey に置き換えます。ウィジェットは div 内に描画され、訪問者がチャレンジに合格するとトークンを生成します。
フォーム送信を処理する前に、トークンを Turnstile の siteverify エンドポイントへ送り、訪問者がチャレンジに合格したことを確認します。
curl https://challenges.cloudflare.com/turnstile/v0/siteverify \
--header "Content-Type: application/json" \
--data '{
"secret": "<YOUR_SECRET_KEY>",
"response": "<TURNSTILE_RESPONSE_TOKEN>"
}'<YOUR_SECRET_KEY> を secret key に、<TURNSTILE_RESPONSE_TOKEN> をフォーム送信の cf-turnstile-response の値に置き換えます。エンドポイントは success フィールドを含む JSON オブジェクトを返します。success が true のときだけ、フォーム送信を処理します。
統合の詳細は Turnstile のはじめ方 を参照してください。
ログインエンドポイントでは、段階的なレート制限を Turnstile と併用すると効果的です。次の例は レート制限のベストプラクティス からのもので、失敗回数に応じて対応を強める 2 つのルールです。しきい値はサイトのトラフィックパターンに合わせて調整します。
短時間ウィンドウのルール: 短時間に失敗したログインリクエストを送りすぎた IP にチャレンジします。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Rate limiting rules を選びます。
-
Rule name にわかりやすい名前を入力します。
-
If incoming requests match で Edit expression を選び、次を入力します:
http.request.uri.path eq "/login" and http.request.method eq "POST" -
With the same characteristics で IP を選びます。
-
Use custom counting expression を有効にし、次を入力します:
http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403} -
When rate exceeds で、
1 minuteあたり4リクエストと入力します。 -
Then take action で Managed Challenge を選びます。
-
Deploy を選びます。
長時間ウィンドウのルール: より長い期間に失敗したログイン試行が蓄積した IP をブロックします。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Rate limiting rules を選びます。
-
Rule name にわかりやすい名前を入力します。
-
If incoming requests match で Edit expression を選び、次を入力します:
http.request.uri.path eq "/login" and http.request.method eq "POST" -
With the same characteristics で IP を選びます。
-
Use custom counting expression を有効にし、次を入力します:
http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403} -
When rate exceeds で、
1 hourあたり20リクエストと入力します。 -
Then take action で Block を選び、期間を
1 dayにします。 -
Deploy を選びます。
このパターンは、認証失敗コードを返す POST リクエストだけを数えるカウント式を使います。初回でログインに成功する正当なユーザーは、ルールに引っかかりません。Security Events で結果を確認し、しきい値が正当なユーザーを拾っていないことを確かめます。
3 つのルールを使う段階的なクレデンシャルスタッフィングの完全な例は、レート制限のベストプラクティス を参照してください。
Application Security の カスタムルール と レート制限ルール では、組み込みのボット保護では拾えない特定のトラフィックパターンを狙えます。Cloudflare は検出(トラフィックのスコア付け)と緩和(そのスコアに基づく対処)を分けています。検出シグナルを参照するルールを書き、取るアクションを決めます。
正当なブラウザーは通常、User-Agent、Accept、Accept-Language などのヘッダーを送ります。多くのボットはこれらのヘッダーを省略するか、ブラウザーらしくない値を送ります。空または不審なヘッダーのリクエストを対象にするカスタムルールは、スコアベースの検出をすり抜けるボットを捕捉します。
カスタムルールを作成する前に、Security > Settings(Bot traffic で絞り込み)の組み込みボット設定を確認します。これらの設定は、AI クローラーのブロック、自動トラフィックへのチャレンジ、検証済みボットの許可など、よくあるシナリオを、式を書かずに扱います。組み込み設定の一覧は 悪意のあるボットにチャレンジする を参照してください。
組み込み設定では足りない場合は、カスタムルールを作成します。ブロックルールをデプロイする前に、検証済みボット向けの例外を先に作成します。
カスタムルールへ移動し、次の 2 つのルールを作成します。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Custom rules を選びます。
まず、検証済みボットの例外を作成します:
- Rule name にわかりやすい名前を入力します。
- When incoming requests match で Edit expression を選び、次を入力します:
(cf.client.bot) - Then take action で Choose action ドロップダウンから Skip を選びます。続けて All remaining custom rules を選びます。
- Place at で Select order ドロップダウンから First を選び、ブロックルールより先にこのルールが実行されるようにします。
- Deploy を選びます。
これにより、検証済みボット(検索エンジンのクローラー、監視サービス)はカスタムルールを迂回します。内部 API、パートナー連携、監視ツールが自動トラフィックを送る場合は、ブロックルールをデプロイする前に、その IP アドレスまたはユーザーエージェント向けの Skip ルールを追加で作成します。Security Events で想定する自動トラフィックを確認し、許可リストに入れる対象を特定します。
次に、ブロックルールを作成します:
- Create rule を選びます。
- Rule name にわかりやすい名前を入力します。
- When incoming requests match で Edit expression を選び、次を入力します:
(http.request.uri.path eq "/login" and http.request.method eq "POST") - Then take action で Choose action ドロップダウンから Managed Challenge を選びます。
- Place at では、Select order ドロップダウンを Last のままにします。検証済みボットの例外の後にこのルールが置かれます。
- Deploy を選びます。
- Security Events で結果を確認します。ルールがボットトラフィックだけに一致する場合は、ルールを編集し、アクションを Managed Challenge から Block に変更します。
ビジュアルフィールドビルダーを含む追加のカスタムルールオプションは、ダッシュボードでカスタムルールを作成する を参照してください。
ボットトラフィックが、実際のユーザーがいない国に集中している場合は、上記のルールに地理フィルターを組み合わせられます。式に ip.src.country を追加し、特定の地域にルールを限定します。例は 地理位置情報でトラフィックをブロックする を参照してください。
フォームエンドポイント以外にも、ボットはチェックアウトフロー、API エンドポイント、その他の高価値パスを狙います。レート制限ルールは、これらのパスに対して、1 つのクライアントが時間枠内に出せるリクエスト数に上限を設けます。
次の例は、チェックアウトエンドポイント向けのレート制限ルールを作成します。パス、レート、アクションはサイトに合わせて調整します。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Rate limiting rules を選びます。
-
Rule name にわかりやすい名前を入力します。
-
If incoming requests match で Edit expression を選び、次を入力します:
http.request.uri.path eq "/api/checkout" and http.request.method eq "POST" -
With the same characteristics で IP を選びます。
-
When rate exceeds で、
1 minuteあたり10リクエストと入力します。 -
Then take action で Managed Challenge を選びます。
-
Deploy を選びます。
-
Security Events で結果を確認します。ルールがボットトラフィックだけに一致する場合は、必要に応じてルールを編集し、アクションを Block に変更します。
追加のパターンとしきい値は、レート制限のベストプラクティス を参照してください。
ボット保護ルールをデプロイしたあと、Security Events で意図どおりに動作しているかを確認し、結果に基づいてしきい値を調整します。
Security Events には、Cloudflare のセキュリティ製品が対処またはフラグ付けしたリクエスト(ブロック、チャレンジ、フラグ)が表示されます。
-
Cloudflare ダッシュボードで Analytics ページを開きます。
Analytics を開く ↗ -
Events タブを選びます。
Sampled logs で個々のリクエストを確認します。各ログエントリには、実行したアクション、トリガーしたルール、送信元 IP、ユーザーエージェント、URI パス、国が表示されます。ダッシュボードのセクションはプランによって異なります。プランの機能は Security Events の提供状況 を参照してください。
誤検知(ルールが誤ってチャレンジまたはブロックした正当なトラフィック)がないかを確認します。よくある兆候は次のとおりです。
- 既知の監視サービスや決済処理事業者からのリクエストが、ブロックされたイベントに現れる
- 正当なブラウザーに一致するユーザーエージェントがチャレンジを受ける
- 実際のユーザーがいる国からのチャレンジ済みリクエストが多い
Managed Challenge アクションを使うルールでは、チャレンジ解決率(CSR) を確認します。CSR が低い場合、ルールが正当なユーザーではなく自動トラフィックを効果的に選別している可能性が高いです。
Bot Fight Mode と Super Bot Fight Mode は、設計上積極的です。誤検知は想定内で、とくに有効化後の最初の数日に起きやすいです。両者の主な違いは、例外の扱いです。
- Bot Fight Mode(Free)は、カスタムルールの Skip アクションではバイパスできません。Bot Fight Mode をオフにするか、より細かい制御ができる Super Bot Fight Mode へアップグレードします。
- Super Bot Fight Mode(Pro 以上)は、Skip アクションのカスタムルールでバイパスでき、例外を柔軟に作成できます。
誤検知の扱いの詳細は 誤検知 を参照してください。
Security Events を確認したあと、結果に基づいてルールを調整します。
シナリオ 1: 監視ツールやサービスがブロックされている。
内部の監視ツール、ヘルスチェックサービス、パートナー API がブロックされたイベントに現れます。対処は、ブロックしている機能によって異なります。
-
Super Bot Fight Mode(Pro 以上)がトラフィックをブロックしている場合は、ツールの IP アドレスまたはユーザーエージェントに一致する Skip アクションのカスタムルールを作成します。
-
Security rules ページを開きます。
Security rules を開く ↗ -
Create rule > Custom rules を選びます。
-
わかりやすい名前を入力します。
-
When incoming requests match で Edit expression を選び、次を入力します:
(ip.src eq 192.0.2.1)(ツールの IP アドレスに置き換えます)。 -
Then take action で Skip を選びます。続けて All Super Bot Fight Mode rules を選びます。
-
Deploy を選びます。
-
-
Bot Fight Mode(Free)がトラフィックをブロックしている場合は、Bot Fight Mode をオフにするか、細かい例外ルールが使える Super Bot Fight Mode へアップグレードします。
Skip アクションの設定の詳細は Skip アクションでルールを設定する を参照してください。
シナリオ 2: 悪意のあるトラフィックがまだ通過している。
現在のルールでは拾えないボット活動が Security Events に現れます。レート制限を下回る、または単一シグナルのルールをすり抜けるボットには、複数のシグナルを組み合わせます。たとえば、検証済みボット以外からの /login への POST リクエストにチャレンジするには:
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Custom rules を選びます。
-
わかりやすい名前を入力します。
-
When incoming requests match で Edit expression を選び、次を入力します:
(http.request.uri.path eq "/login" and http.request.method eq "POST" and not cf.client.bot) -
Then take action で Managed Challenge を選びます。
-
Deploy を選びます。
-
Security Events で結果を確認します。ルールがボットトラフィックだけに一致する場合は、アクションを Block に変更します。
追加の式フィールドと例は、カスタムルールのユースケース を参照してください。
ボットがレート制限のしきい値を下回っている場合は、レート制限ルールを編集し、リクエスト数を減らすか、時間枠を短くします。
Bots
- Bot Fight Mode — すべてのプランで使える基本的なボット保護
- Super Bot Fight Mode — Pro、Business、Enterprise プラン向けの細かいボット制御
- Enterprise Bot Management — 機械学習ベースのボットスコアと行動分析
- Bot Analytics — ドメイン全体のボットトラフィックパターンを監視する
Application Security
- カスタムルール — トラフィックシグナルとボットスコアを使う対象を絞ったルールを書く
- レート制限ルール — リクエスト量を制御し、エンドポイントの不正利用を防ぐ
- Security Events — 緩和したリクエストを確認・調査する
Turnstile
- Turnstile — フォームとユーザー操作向けの、無料でプライバシーを守るチャレンジ