KinstaとCloudflare、WordPressのボット対策はどちらを選ぶべき？

WordPressサイト運営者にとって、ボットトラフィックはもはや見過ごせる問題ではありません。Kinstaの「AI・ボット時代におけるトラフィックの実態」では、Kinstaが管理するインフラ全体で発生した100億件以上のリクエストを分析した結果、自動化されたトラフィックは単なるセキュリティやアクセス解析上の課題ではなく、インフラそのものに影響を及ぼす問題になっていることが明らかになりました。

現在では、クローラーが動的なURLにアクセスしたり、クエリ文字列のループにはまり込んだり、キャッシュを回避したりするケースが増えています。その結果、通常のインデックス作成というよりも、大規模な自動化の不具合を思わせるようなトラフィックパターンが発生しています。

こうした変化を受けて、ボット対策はWordPressサイト運営に欠かせない要素となりました。そのためKinstaは、不要な自動トラフィックをMyKinstaから簡単に検出・管理できる組み込みのボット対策機能をリリースしました。

一方で、すでにCloudflareを利用している方は、「Kinstaのボット対策機能はCloudflareとどう使い分ければいいのだろう？」と疑問に思うかもしれません。

Cloudflareのボットファイトモードと同じ機能なのか。両方を併用すべきなのか。どちらか一方で十分なのか。また、サイトの前段に独自のCloudflareアカウントを導入している場合、Kinstaのボット対策機能を有効にするとどのような動作になるのか。

こうした質問は、先日開催したAIボットに関するウェビナー（日本語字幕付き録画版はこちら）でも数多く寄せられました。そこでこの記事では、それらの疑問にお答えしていきます。

要点

Kinstaのボット対策機能とCloudflareは同じものではありません

Kinstaでは、CDN、WAF（ウェブアプリケーションファイアウォール）、DDoS攻撃対策にCloudflareを採用しています。

ボット対策機能もCloudflareの基盤上で動作しており、ボット検知にはCloudflareの検知エンジンを利用しています。

ただし、Cloudflareの検知エンジンを利用しているからといって、Cloudflareの製品そのものというわけではありません。

Cloudflareと同じインフラや検知機能を活用していますが、それに加えて、WordPressサイト向けに最適化した独自の設定やルールを適用しています。長年にわたりWordPressサイトを運用してきた知見を生かし、多くのWordPressサイトで効果的に機能するデフォルト設定を提供している点が特徴です。

具体的には、Cloudflareのボットリストに独自の分類ルールを重ねて適用しており、この違いは実際のボット判定にも反映されます。Cloudflareでは、機械学習を用いてすべてのリクエストに1～99のボットスコアを割り当てます。スコアが1に近いほどボットである可能性が高く、99に近いほど人間によるアクセスである可能性が高いことを示します。

Kinstaのボット対策機能は、このボットスコアを判定材料の一つとして利用しながら、さらに独自のロジックを組み合わせています。そのため、Cloudflareでは「検証済みボット」と判断されるAIクローラーであっても、短時間に過剰なリクエストを送信している場合は、「過剰なアクセスを行うAIクローラー」として再分類し、検証の対象にすることができます。

Cloudflareのボット対策機能は、さまざまなサイトやアプリケーション、トラフィックパターンに対応できるよう設計されています。一方、Kinstaのボット対策機能は、WordPressサイト向けに最適化されているため、WordPress特有のトラフィックやURL、自動化処理、各種インテグレーションを考慮したデフォルト設定になっています。

Cloudflareのボット対策機能の種類

Kinstaのボット対策機能とCloudflareを比較する前に、「Cloudflareのボット対策機能」が具体的に何を指すのかをご説明します。Cloudflareでは単一のボット対策機能を提供しているわけではなく、3つのプランが用意されており、それぞれ制御の自由度や運用の複雑さが異なります。

Cloudflareのボットファイトモード

Cloudflareのボットファイトモードは、Cloudflareのボット対策機能の中で一番シンプルなオプションです。設定はオン・オフを切り替えるだけで利用でき、無料プランを含むすべてのCloudflareプランで利用できます。

最大の特長は、その手軽さにあります。複雑なルールを作成することなく、有効にするだけで基本的なボット対策を導入できます。

その反面、細かな制御ができないという制約があります。Cloudflareの公式ドキュメントによると、この機能はドメイン全体を対象に動作し、WAFのカスタムルールやページルールを使って特定のアクセスだけを除外することはできません。これは、CloudflareのRuleset Engine上で動作していないためです。

そのため、本来は許可したいアクセスまで検証されてしまっている場合は、機能全体を無効にするか、より高度な設定が可能な上位プランへアップグレードしなければなりません。

この制約は、正当な自動アクセスを利用しているWordPressサイトでは特に問題となることがあります。例えば、APIクライアント、監視ツール、プラグイン連携、決済処理など、安定してアクセスできることが求められるサービスでは、意図せず通信が妨げられる可能性があります。

Cloudflareのスーパーボットファイトモード

スーパーボットファイトモードは、有料のPro、Business、Enterpriseプランで利用できるボット対策機能です。無料プランで利用できるボットファイトモードよりも細かな設定が可能で、「ボットである可能性が極めて高い」「ボットである可能性が高い」「検証済みボット」といったトラフィックのカテゴリごとに、許可、検証、ブロックなどのアクションを個別に設定できます。

スーパーボットファイトモードは、ボットファイトモードとは異なり、CloudflareのRuleset Engine上で動作します。そのため、WAFのカスタムルールでSkipアクションを使用し、特定のトラフィックをボット対策の対象から除外することができます。

このように柔軟な制御が可能になる一方で、スーパーボットファイトモードもドメイン全体を対象としたボット対策機能である点は変わりません。特定のURLごとに対策を適用したり、リクエスト単位で詳細なボットスコアに基づいて制御したりすることはできません。

こうしたより高度な制御が必要な場合は、ボット管理機能の利用を推奨しています。

Cloudflareのボット管理機能とカスタムルール

ボット管理は、エンタープライズ向けアドオンとして利用可能な、Cloudflareで最も柔軟性の高い機能です。すべてのリクエストに対して1～99のボットスコアを生成し、ボットスコア、URIパス、国、ASN、IP範囲、ヘッダー、ユーザーエージェントなどのシグナルを参照して、WAFカスタムルールやWorkersを使用してアクションを実行できるようにします。

これがCloudflareの強みで、たとえばログインページではボットスコアの低いリクエストだけを検証し、一般公開されているブログページには影響を与えない、といった柔軟な設定が可能です。

一方で、その柔軟性を活かすには適切な運用が欠かせません。自社のトラフィックを把握した上でルールを設計し、誤検知が発生していないかを検証しながら、ボットの傾向の変化に合わせて継続的に調整していく必要があります。

Kinstaのボット対策機能の位置づけ

Kinstaのボット対策機能は、Cloudflareのボットファイトモードと、ボット管理＋カスタムルールの中間に位置するソリューションです。単純なオン・オフだけのボット対策よりもWordPressに特化した制御が可能でありながら、高度なボット管理ルールを一から設計・運用する必要はありません。

ボットスコアやルール式、エンドポイントごとの設定を起点に考えるのではなく、WordPressサイトの運用を前提に設計されています。通常の訪問者、検索エンジンのクローラー、AIクローラー、稼働監視サービス、WordPressの自動処理、プラグイン連携、ECサイトの処理、管理画面での操作、そして不審な自動アクセスまで、WordPress環境で発生するさまざまなトラフィックを考慮して保護を行います。

シンプルにまとめると、以下のような位置づけです。

CloudflareをベースにしたKinstaのボット対策

Kinstaのボット対策機能は、Cloudflareのボット検知と検証機能を基盤としながら、WordPress向けに最適化されたマネージドレイヤーを提供します。具体的には、次のような機能が追加されています。

4段階の対策レベル

Kinstaのボット対策では、環境ごとに適用できる4つの対策レベルがあります。

• 悪意のあるトラフィックをブロック：すべてのサイトで有効になるデフォルトの対策レベル。DDoS攻撃対策に加え、悪意のあるアクセスでのみ使用されるIPアドレスやエンドポイントに対するグローバルルールが適用される。これを有効にするだけでも、サイトに到達する前に、明らかに悪意のあるトラフィックの約15〜20%を遮断することができる。
• 自動化されたアクセスをブロック：自動化トラフィックと悪意のあるトラフィックをブロック。
• ボットを検証：自動化トラフィックと悪意のあるトラフィックをブロックした上で、ボットである可能性が高いアクセスや未分類のトラフィックを検証。
• すべてのアクセスを検証：最も厳しい対策レベル。自動化トラフィックと悪意のあるトラフィックをブロックし、ボットだけでなく、人間である可能性が高いアクセスや未分類のトラフィックも検証。サイトが攻撃を受けている場合や、異常なトラフィックの急増に迅速に対応したい場合に推奨される。

これらのレベルは環境ごとに設定できるため、本番環境ではより厳格な設定を適用しつつ、ステージング環境では寛容な設定を維持したり、その逆を行ったりすることが可能です。

検証とは、必ずしもCAPTCHAによる認証を意味するわけではありません。ブラウザベースのチェック、バックグラウンドでの検証、または対話型のテストである場合もあります。 正当な人間の訪問者は通常、目に見える中断がほとんどないか、まったくない状態で通過します。また、訪問者が一度認証を通過すれば、同じブラウザとIPアドレスを使い続けている限り、少なくとも10日間は再度認証を求められることはありません。

トラフィックの分類

MyKinstaの分析画面では、各リクエストがどのように分類されたかが表示されます。分類には、「人間の可能性が高い」「検証済みのボット」「ボットの可能性が高い」「未分類のトラフィック」「自動化トラフィック」「悪意のあるトラフィック」「過剰アクセスAIクローラー」などがあります。

また、各リクエストが最終的に許可、検証、またはブロックされたかといった処理結果も確認できます。

ここで重要なのは、自動化されたトラフィックが必ずしも悪意のあるものとは限らないという点です。 カスタムAPI連携や稼働監視ツール、デプロイスクリプトなど、サイト運営に必要な自動化ツールも含まれます。

このようなアクセスが存在するため、「許可する」か「ブロックする」かの二択だけでは、WordPressサイトに適した柔軟なボット対策は実現できません。

WordPress向けに管理された許可リスト

WordPressサイトでは、REST APIリクエスト、定期実行タスク（Cron）、プラグイン連携、フォーム送信、SEOツール、同期ツール、ECサイトのワークフローなど、多くの正当な自動化トラフィックが日常的に発生します。

こうしたアクセスが厳しいボット対策の影響を受ける場合は、「通常のWordPress自動処理を許可」をオンにすることで、Kinstaが管理する許可リストを利用できます。これにより、信頼できるWordPressのURLやサービスへのアクセスを許可しながら、ボット対策を継続できます。

あるいは、「常に許可」リストでIPアドレス、パス、またはユーザーエージェントを指定して特定の例外を追加することも可能です。

どの連携機能を厳しいボット対策の対象外にすべきかを、判断・設定する必要はありません。Kinstaが許可リストを継続的に管理・更新するため、新しいサービスや連携にも順次対応していきます。

AIクローラー専用の設定

AIクローラーは、必ずしも悪意のあるボットとは限らないため、AIクローラーの管理は独立した設定を用意しています。

AIクローラーの中には、自身を適切に識別し、クロール制限を遵守するものもありますが、一方で過剰なクロールやキャッシュされていない負荷の高いページへのアクセスによって、サイトに負荷をかけるものも存在します。

Kinstaのボット対策では、「AIクローラーをブロック」をオンにすることで、検証済みのAIクローラーを含むAIクローラーをブロックできます。GooglebotやBingbotなどの検索エンジンクローラーには影響しません。AIクローラーへの対応と一般的なボット対策では、求められる運用方針が異なることが多いため、それぞれを個別に設定できるようになっています。

複数の環境をまとめて管理

制作会社などで複数のWordPressサイトを運用している場合、ボットの問題は1つのサイトだけで発生するとは限りません。Kinstaでは、WordPressサイト一覧から一括操作を実行できるため、各サイトを個別に開くことなく、複数の環境に対して保護レベルの変更やAIクローラーの許可・ブロック、WordPress自動化の許可リストの設定をまとめて行えます。

WordPressに精通したスタッフが常時サポート

ボットの問題は、WordPressサイトの他の要素と切り離して考えられるものではありません。突然トラフィックが増加した場合でも、その原因は悪意のあるボットだけでなく、AIクローラー、不適切な連携設定、プラグインの競合、WooCommerceの同期処理、あるいは正当なマーケティングキャンペーンである可能性もあります。

Kinstaのボット対策なら、サポートはお客様のサーバー環境を把握しているKinstaのカスタマーサポートが一貫して対応します。異なるサービスのダッシュボードを見比べながら原因を切り分ける必要はありません。

すでにCloudflareアカウントを利用している場合はどうすべきか

これは先日のウェビナーで多く寄せられた質問です。一言で言えば、「併用しないこと」になりますが、もう少し詳しくご説明します。

Kinstaのボット対策とCloudflareのボット対策（ボットファイトモード、スーパーボットファイトモード、ボット管理）は、併用できないことはありませんが、両方を同時に使用することは推奨していません。併用すると不要な負荷が生じ、初回アクセス時に、本来1回で済むはずのマネージド型の検証が複数回表示されるなど、ユーザー体験に影響を及ぼす可能性があります。

併用する必要性はほとんどなく、どちらか一方のみを使用するので十分です。問題は、システムが正常に動作しなくなることではなく、正当な訪問者に不要な検証が発生し、ユーザー体験が損なわれる可能性がある点です。

また、Kinstaのボット対策と併せて、別のCDN、リバースプロキシ、またはWAFをサイトの前段に配置することも推奨されません。これには、WAFやボット対策を有効にした独自のCloudflareアカウントのほか、AWS、Microsoft Azure、Sucuri、Fortinetなどのリバースプロキシサービスも含まれます。これらのサービスが先にトラフィックを処理すると、Kinstaは各リクエストの本来の送信元を正確に把握できなくなり、ボット対策が自動化されたトラフィックと正当なユーザーのアクセスを適切に判別できなくなる可能性があります。

現在、Kinstaサイトの前段でCloudflareアカウントを使用し、独自のボットルールやWAFルールを設定している場合は、設定を変更する前にKinstaのカスタマーサポートまでご相談ください。お客様の構成を確認し、適切な構成をご案内します。

CloudflareとKinstaの監視機能の違い

日々のトラフィックを確認するのには、CloudflareとKinstaのどちらを利用するべきかについては、確認したい内容によって異なります。

Cloudflareは、詳細な調査に優れており、カスタムフィルターを使って個々のリクエストを詳しく確認したり、さまざまなリクエスト属性を条件に検索したりできるため、特定のインシデントの原因調査に適しています。Cloudflareのボット分析に関しては、すべてのリクエストではなくサンプルデータに基づいています。そのため、トラフィックの傾向を把握したり問題を調査したりするには適していますが、正確なトラフィック数を確認する用途には向いていません。

Kinstaでは、サイトに到達したすべてのリクエストを対象に、MyKinstaで時間単位および日単位の集計データを確認できます。そのため、Cloudflareのような柔軟な絞り込み検索はできないものの、サイト全体のトラフィック量や推移を正確に把握するのにおすすめです。

まとめると、インシデントの詳細な原因調査にはCloudflare、サイト全体のトラフィックを正確に把握・監視するにはKinstaが適しています。

Kinstaのボット対策はどのレイヤーで動作するのか

Kinstaのボット対策機能は、HTTPリクエストを処理するレイヤー7（アプリケーション層）のエッジで動作します。

Cloudflareアカウントのボット対策とKinstaのボット対策が同じリクエストに適用される場合、先にCloudflareがリクエストを処理し、その後でKinstaのボット対策が適用されます。Kinstaがリクエストを処理する時点で、Cloudflare側ですでに判定が行われているため、両方を併用しても得られるメリットはほとんどありません。

CloudflareとKinsta、どちらのアプローチを採用すべきか

どちらが適しているかは、必要とする制御の細かさと、ボット対策の運用をどこまで自社で担いたいかによって異なります。

WordPress向けのマネージド型対策を求めるならKinsta

WordPressサイトをKinstaで運用していて、ボット対策を継続的な管理業務にしたくない場合は、Kinstaのボット対策が基本的な選択肢になります。

これは、多くのWordPressサイトに当てはまります。たとえば、多数の顧客サイトのトラフィックを管理する制作会社や代行業者、専任のセキュリティ担当者がいないチーム、ボットルールの保守よりも本来の事業運営に時間を使いたい方に適しています。

細かな制御が必要ならCloudflareの高度なボット対策

スーパーボットファイトモードをWAFやカスタムルールと組み合わせるなど、Cloudflareの高度なボット対策を利用していて、その構成を適切に管理するための時間と専門知識がある場合は、Cloudflareの方が適しているかもしれません。

これは、基本的にオンとオフを切り替える仕組みに近いボットファイトモードとは異なり、Cloudflareの高度な機能は、自社サイトのトラフィックを詳しく把握しており、URLごとに異なる処理を設定したい場合や、特定のリクエストパターンに対する動作を細かく定義したい場合に適しています。

こうした精密な制御には大きな利点がありますが、一度設定すれば終わりではなく、継続的な確認と調整が必要です。自社で細かな調整を行うための専門知識と時間がある場合は、Cloudflareが有力な選択肢になります。一方、トラフィック制御の細部ではなく事業に集中したい場合は、WordPress向けに調整され、Kinsta側で継続的に管理・保守されるボット対策機能の方が適しています。

特別な理由がない限り、両方を併用する必要はない

ほとんどの場合は、ボット対策の役割をどちらか一方に任せることをおすすめします。

• KinstaでホストしているサイトでCloudflareのボットファイトモード、またはスーパーボットファイトモードを利用している場合は、WordPress向けに最適化され、サーバー環境内で一元管理できるKinstaのボット対策を利用する方が適しています。
• Cloudflareのボット管理で独自のカスタムルールを運用している場合は、一概には判断できません。ルールの内容や、Kinstaのボット対策機能との組み合わせによる影響、さらにKinstaのマネージド型ボット対策を有効にしたあともそれらのルールが必要かどうかを確認する必要があります。このような構成では、Kinstaのカスタマーサポートへご相談ください。
• Kinstaサイトの前段でCloudflareアカウントをリバースプロキシとして運用している場合は、前述のとおりです。この構成では、単に不要な重複になるだけでなく、Kinstaのボット対策機能が本来どおり動作しなくなる可能性があります。

ボット対策は今後WordPress運用の一部へ

ボット対策は、もはや一度設定すれば終わるセキュリティ対策ではありません。Daniel Patakiがウェビナーで説明したように、ボットは諸刃の剣です。パフォーマンスの低下やコストの増加、アクセス解析の精度低下を招くことがある一方で、クローラーなどの正当なボットはWebを支える重要な役割も担っています。

AIクローラーやスクレイパーをはじめとする自動化されたアクセスが増え続ける中、WordPressサイトでは、人間以外のトラフィックを適切に管理できる仕組みがますます重要になっています。ただし、そのためにサイトごとに複雑なルールを構築・保守する必要があるわけではありません。

Kinstaのボット対策機能は、こうした課題に対応するために設計されています。複数の保護レベル、AIクローラー専用の設定、WordPress向けに最適化された標準設定、そしてMyKinstaから確認できる可視化機能により、運用負荷を抑えながら効果的なボット対策を実現できます。

さらに詳しく知りたい方は、AIボットについて掘り下げたウェビナーや「AI・ボット時代におけるトラフィックの実態」レポートをご覧ください。また、MyKinstaからボット対策機能を有効にすれば、サイトにどのような自動化トラフィックが到達しているのかを実際に確認できます。