UXを損なわずに不正アクセスを防ぐ！Cloudflare Bot Management 検証レポート

プラットフォーム

本稿はJCB Advent Calendar 2025の12月20日の記事です。

こんにちは、JDEP アーキテクトチームの長沼です。

Webアプリケーションを運用する上で、Bot対策は避けて通れない課題です。
しかしBot対策を強化しすぎると正規ユーザの利用体験（UX）を損ねてしまう、このトレードオフに悩まれている開発者の方も多いのではないでしょうか。

今回は、この課題を解決する Cloudflare の Bot 対策機能、特に Bot Management について検証する機会がありましたので、その内容についてご紹介します。

TL; DR

  • Cloudflare には標準で Bot 対策の機能が付属
  • 有償オプションの Bot Management では、Cloudflare が評価した Bot 確度の定量指標（ Bot Score ）に基づいて詳細な制御が可能
    • Bot 対策の説明がしやすくなり、離脱率などコンバージョン率（ CVR: Conversion Rate ）を気にするようなアプリへ導入しやすい

Cloudflare の Bot 対策のラインナップ

公式ドキュメントによると、Cloudflare の Bot 対策として以下の機能が提供されています。

  • Bot Fight Mode
  • Super Bot Fight Mode
  • Bot Management

このうち Bot Fight Mode は無償プラン向けのものであり、有償の商用（Pro・Business・Enterpriseプラン）で使う場合、 Super Bot Fight Mode、または Bot Management が選択肢となります。
後者 2 つの概要は以下の通りです。

機能 Super Bot Fight Mode Bot Management
利用可能プラン Pro・Business・Enterpriseに標準付属 Enterpriseに有償アドオン
制御単位 サイト全体 パス単位
制御方法 カテゴリ毎に自動制御 WAF ルールと Bot Score の組合せによる詳細制御
分析・ログ 概要情報のみ Bot Score 分布、詳細ログによる詳細情報

制御と参照それぞれの観点で違いは以下の通りです。

  • Super Bot Fight Mode:
    • 制御の観点では、Web サイト全体に対して事前定義されたカテゴリ（Definitely Automated Traffic、Verified Bots、Likely Automated Traffic）毎に Bot の許可または遮断を設定できます。
    • 参照の観点では、Cloudflare のダッシュボードで、前述の事前定義カテゴリ毎に Traffic 分布などを見ることができます。
  • Bot Management:
    • 制御の観点では、クライアントからのリクエスト毎に Cloudflare により評価された Bot Score が付与されます。
      この Bot Score を用いて WAF ルールを設定・制御することで、/login といったパス単位に Bot の許可や遮断が可能となります。
      なお同制御のため Bot Management では、WAF の利用が実質必須になる点は留意が必要です。
    • 参照の観点では、Super Bot Fight Mode の表示に加えて、Bot Score のヒストグラムや、クライアント種類などの情報が含まれる Bot Detection Tags の分布といった情報もダッシュボードに追加されます。加えて、Bot Score などの Bot 関連情報が付与された HTTP リクエストのログも参照可能となります（詳細後述）。

ちなみに Cloudflare によると、Super Bot Fight Mode と Bot Management の実装は共通とのことで、Bot Management の機能を限定したものが Super Bot Fight Mode になるようです。
実際、今回の検証では Super Bot Fight Mode を適用していたアプリを Bot Management に切り替えたところ、一部で切替前のリクエストについても Bot Management 関連の情報を参照できたため、この説明は正しそうです。

Bot Management の検証

実際に稼働中の Web アプリに対して Bot Management を有効化した結果についてご紹介します。
とはいえ実データを直接お見せできない部分もあり、図・データは一部加工（マスクやダミーデータに置換）しています。ご了承ください。

まず Cloudflare のダッシュボード（Security > Analytics の Bot Analysis タブ）を参照すると、下図のように Bot 関連のグラフが表示されており、Bot によるアプリへのリクエスト状況を把握できます。
特に Bot Management を有効化すると、Super Bot Fight Mode では表示されていなかった Bot Score 分布のヒストグラム（下図青枠）の表示を確認できます。

Cloudflare のダッシュボード（Bot Analytics）

Bot Score は、1 から 99 までの整数値をとり、小さいほど Bot によるリクエストである可能性が高いことを示しています。 Cloudflare によれば、Bot Score が 30 以下は Bot である可能性が高いとのことです。
上の図の下側グラフには、左側が Bot Score 1 、右側が 99 で指定した期間（図の場合は 72 時間）に来たリクエストの Bot Score 毎の分布（ヒストグラム）が表示されています。 例えば今回の検証対象アプリでは、Bot Score 99、すなわち有人リクエストが主となるべき分布の傾向が見てとれますが、一部に Bot である可能性が高いリクエスト（Score 1〜30）も来ていることが確認できます。

そして具体的にどのようなリクエストがアプリに来ているか確認したい場合は、HTTP リクエストログに追加される Bot 関連フィールドを確認することで調査できます。
Bot 関連フィールドが追加された HTTP リクエストログの例（一部加工）を以下に示します。

{"BotDetectionIDs":[12345,...], "BotDetectionTags":["unclassified_bot"], "BotScore":1, "BotScoreSrc":"Verified Bot", "BotTags":["verifiedBot",...], ..., "ClientRequestHost":"my.web.app", "ClientRequestMethod":"GET",..., "ClientRequestURI":"/login", ..., "JA3Hash":"b4da7...", "JA4":"t13d1...", "JA4Signals":{}, "JSDetectionPassed":"Unknown", ..., "ParentRayID":"00", "RayID":"9a45...", ..., "VerifiedBotCategory":"Accessibility", "WAFAttackScore":79, "WAFFlags":"0", "WAFMatchedVar":"", "WAFRCEAttackScore":84, "WAFSQLiAttackScore":96, "WAFXSSAttackScore":96, ..., "ZoneName":"my.web.app"}

このようにアプリの FQDN（ClientRequestHost フィールド）や、リクエストメソッド（ClientRequestMethod フィールド）に加えて、様々な Bot 関連フィールドが追加されていることが確認できます。個々のフィールドの詳細はこちらのドキュメントを参照ください。

今回の検証において、Bot 関連フィールドが含まれた HTTP リクエストログを分析していくことで以下のようなことが分かりました。

  • アプリの外形監視等のリクエストは概ね Bot Score が 1 と判定されている。
  • それ以外の Bot Score が 30 以下のリクエストは、確かに Bot によるリクエストの可能性が高いと判断できる。

実際に適用するうえでは、より詳細な調整が必要とは考えますが、監視系のリクエストを除外しつつ Bot Score で WAF ルールを設定すれば、概ねうまく Bot 対策できそうな印象を受けました。

Bot Management の検証を通しての気付き

今回の検証は、実際にアプリを開発するチームとも協力し実施しました。
検証後、このアプリ開発チームとのディスカッションを通じて、Bot Management は単に Bot Score に基づいた参照・制御以上の価値があると感じました。
その内容を以下に紹介します。

アプリ側での Bot リクエストの把握が容易

Super Bot Fight Mode では、Bot による不正なリクエストがアプリにあったとき、アプリ側では当該リクエストが Bot によるものか否かを判断することが難しいという課題があります。

一方で Bot Management が有効な場合、この課題の解決として、Bot Score など Bot 関連フィールドが付与された HTTP リクエストログを使うことができます。
この HTTP リクエストログとアプリ側のログを突き合わせることで、当該不正リクエストが Bot によるものか否か判断が容易になります。
今回の検証で、Bot Score について前述通り一定の正しさも確認できたため、リクエストを判断するうえで強力な武器になると考えます。

アプリへの導入説明が容易

特に離脱率など CVR を重視するアプリにおいて、CAPTCHA（画像や文字判定による人間判定テスト）などによる Bot 対策は、CVR 低下につながりかねません。
結果、離脱率を避けたいビジネス側と、システムを守るため Bot 対策を入れたいシステム側の対立が発生しえます。
このとき Super Bot Fight Mode では、マネージドであるがゆえにシステム側がビジネス側に影響を説明しにくいという課題があります。

一方で、Bot Management が有効な場合、Bot Score という定量指標に基づいて判定・制御できるため、システム側が導入効果や影響をビジネス側へ説明しやすくなります。
加えて当然 Bot Score による詳細な制御もできるため、実際に CVR を維持しつつ Bot 対策が可能となります。

今回の検証を通し、Bot Management の機能理解に加えて上記の気づきを得られた点は、ドキュメントを読むだけでは伝わらない、実機検証ならではの成果と考えております。

おわりに

一般利用者に公開するWebアプリの Bot 対策は、セキュリティとUXのバランス調整が非常に繊細です。
今回の検証では、Cloudflare Bot Management により詳細な制御ができることを確認できたことに加え、（通常の Bot 対策に比べ）説明容易性があるため CVR を重視するアプリでも導入しやすいという印象を持ちました。

今後はこの結果も基に、セキュリティとUXを両立し、より安全で快適なサービスの提供を目指していきたいと考えています。

最後に、JCB では我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧下さい。 www.saiyo.jcb.co.jp

本文および図表中では、「™」、「®」を明記しておりません。 記載されているロゴ、製品名は各社及び商標権者の登録商標あるいは商標です。

©JCB Co., Ltd. 20︎21