サイトのアクセス数はそれほど増えていないのに、リソース使用量だけが急増している場合、その原因はボットアクセスかもしれません。ボットがカート操作や商品フィルター、サイト内検索など、キャッシュできないページや機能にアクセスすると、そのたびにPHPの処理やデータベースへの問い合わせが発生します。そのため、ページキャッシュによる負荷軽減の効果が十分に発揮されません。
こうした状況では、すべてのボットをブロックしてしまいたいところですが、GooglebotやBingbot、RSSリーダー、稼働監視ツールも、ボットアクセスと同じ「自動化トラフィック」に分類されます。すべてを遮断してしまうと、サイトの検索表示や正常な運用に必要なアクセスまで失われてしまいます。
Kinstaのボット対策機能なら、コストだけを増やす不要なアクセスを排除しながら、必要なアクセスはそのまま許可することができます。これらの制御はインフラレベルで実行されるため、リクエストがWordPressサイトに到達する前にフィルタリングを行うことが可能です。
以下、ボットを完全にブロックしてしまうのが危険な理由、実用的な対応、そしてKinstaのボット対策機能の詳細を見ていきます。
ボットアクセスを一律にブロックすることが解決策ではない理由
理論上は、すべての自動化されたアクセスを一律に遮断することで、帯域幅の無駄な消費を抑えることができます。しかし、その方法では本来必要なアクセスまでブロックしてしまいます。例えば、GooglebotやBingbotがコンテンツをクロールできなくなり、稼働監視ツールも正常に機能しません。また、WordPressと連携するAPI統合や各種ワークフローにも影響が及ぶ可能性があります。
実際に対策すべきなのは、自動化されたアクセス全体ではなく、その一部です。具体的には、正当性を確認できないボットや、キャッシュできないページや機能に繰り返しアクセスする自動化トラフィックが該当します。こうしたアクセスは、多くの場合SEOやユーザー体験、売上への貢献がありません。
Cloudflareでデータインサイト部門責任者を務めたDavid Belson氏も、現在一般化しているボットアクセスについて以下のように述べています。
私たちが目にしているトラフィックの大半は悪意のあるものではない。問題なのは、非効率なボットが大規模に動作していることであり、そこから本当の課題が生まれている
例えば、URLのバリエーションをたどるボットは、自身が同じ処理を繰り返していることを認識できません。商品フィルターやクエリ文字列、カートパラメータの違いをそれぞれ別ページとして扱い、無限に近いアクセスを発生させることがあります。実際にKinstaのインフラでは、ある30日間で単一のループ検知ルールによって5億5,000万件ものリクエストがフィルタリングされました。意図の有無にかかわらず、サーバーはそれらすべてを通常のリクエストとして処理しなければなりません。
Kinstaでは、プラットフォームレベルのセキュリティにより、悪意のあるアクセスと判断されたトラフィックをサイト到達前に遮断しています。これにはDDoS攻撃対策や、既知の攻撃元IPアドレスからのアクセスブロックが含まれます。
しかし、こうした基本的な保護で防げる脅威と、正常なアクセスとして許可すべきトラフィックの間には、正当性が確認できない不要なボットによるアクセスが存在します。
この中間層の自動化トラフィックを適切に生業することで、冒頭で挙げた「アクセス数は変わらないのにリソース使用量だけが増加する」状況を防ぐことができます。複数のクライアントサイトを運用する制作会社にとって、このような兆候は、ボットによる負荷が既存のセキュリティ対策だけでは対応しきれない水準に達しているサインと言えます。
実際に管理すべきトラフィックを把握する
Kinstaでは、独自のトラフィック分析とCloudflareの機械学習システムを組み合わせて、すべてのリクエストを分類しています。Cloudflareは各アクセスに対して1〜99のボットスコアを付与しており、99に近いほど人間によるアクセスである可能性が高く、1は自動化されたアクセスであることを示します。
ボット対策を検討する上で重要なのは、以下の5つのカテゴリです。
- 認証済みボット：GooglebotやBingbotなど、Cloudflareの認証済みボットリストに登録されている正当なボット。対策レベルに関係なく常に許可される。
- 人間の可能性が高いトラフィック：スコア30〜99に分類されるアクセスで、通常の閲覧行動を示す実際の訪問者。
- ボットの可能性が高いトラフィック：スコア2〜29に分類される未認証の自動化トラフィックで、ボットである可能性が高いと判断されたアクセス。
- 自動化トラフィック：スコア1に分類されるアクセスで、検証済みのボットだけでなく、未検証のプログラム経由のアクセス（カスタム連携ツール、デプロイスクリプト、自前の稼働監視ツールなど）も含まれる。
- 高頻度アクセスAIクローラー：AIクローラーのうち、短時間に大量のリクエストを送信したり、ループによって継続的な負荷を発生させたりするもの。
また補足として、悪意のあるトラフィックは、すべての対策レベルで自動的にブロックされるため、追加の設定は不要です。未分類のトラフィックに関しては、通常ごく少量で、ほとんどの場合は無害です。例えば、サイトがエラーページを返した際に発生する内部サービスリクエストなど、オリジンサーバーに影響を与えないアクセスが含まれます。
MyKinstaでリソース使用状況を確認する方法
まずは、どの種類のトラフィックがリソース使用量の増加につながっているのかを把握することが重要です。Kinstaのコントールパネル『MyKinsta』の分析画面の「ボットアクセス」タブでは、サイトに到達したリクエストがどのカテゴリに分類されているかを確認できるため、自動化トラフィックがサーバー負荷の原因になっていないかを把握できます。
このデータを確認するには、「サイト」＞（サイト名）＞「分析」に移動して、「ボットアクセス」タブを開きます。
例えば、上のスクリーンショットでは、「人間の可能性が高い」「検証済みのボット」「ボットの可能性が高い」「AIクローラー」「自動化トラフィック」に分類されて表示されています。こにように、帯域幅やアクセス数の増減から間接的に推測するのではなく、実際にどれだけの自動化トラフィックがサイトに到達しているのか、そしてKinstaによってどのように分類されているのかを確認できます。
例えば、「高頻度アクセスAIクローラー」や「自動化トラフィック」の急増が見られる場合、ボットがキャッシュ対象外のページや機能に繰り返しアクセスしている兆候である可能性があります。また、「AIクローラー」が増加している場合、実際のユーザーによるアクセス数に大きな変化がなくても、帯域幅の使用量やオリジンサーバーの負荷が増加する原因となることがあります。
「ボット対策の結果」チャートでは、分類後のリクエストがどのように処理されたかも確認できます。許可・検証・ブロックの内訳が表示されるため、対策レベルを変更する前に、現在の設定が受信トラフィックにどのような影響を与えているのかを把握できます。
また、「分析」画面の「受信回数上位リクエスト」レポートでは、リクエスト量が最も多いURLを特定するのにも役立ちます。カートへの追加URL、フィルタリングされた商品ページ、検索クエリ、決済ページなど、キャッシュできないパスへの繰り返しリクエストが集中している場合は通常、ボットがキャッシュでは吸収しきれないサーバーリソースを消費していることを示しています。
このような分析データを総合的に確認することで、どの対策レベルを適用するかを決定する前に、トラフィックパターンとリソース使用量を明確に相関付けることができます。
Kinstaのボット対策機能の仕組み
MyKinsta搭載のボット対策機能は、インフラレベルで動作します。リクエストがPHPやデータベースに到達する前にフィルタリングを行うため、サーバー負荷を根本から軽減できます。そのため、プラグインのインストールやWordPress側での設定変更は不要です。
独自のトラフィック分析とCloudflareのエンタープライズ向けボット検知システムを組み合わせて、受信するトラフィックを分類します。リクエストは、「認証済みのボット」「ボットの可能性が高い」「AIクローラー」「高頻度アクセスAIクローラー」「自動化トラフィック」「人間の可能性が高い」などのカテゴリに分類され、選択した対策レベルに応じて、それぞれに対する処理方法が決定されます。
ボット対策機能の設定は、「サイト」＞（サイト名）＞「ボット対策」で行えます。
この「ボット対策」画面で、以下4つの設定を行うことができます。
- トラフィックを許可、検証、またはブロックするかを決定する対策レベルの選択
- AIクローラーのブロック
- 一般的なWordPress APIやバックグラウンド機能を許可
- 信頼できるトラフィックソースを例外として追加し常に許可
また、Cloudflare統合の一環として、基盤となるボットのスコアリングおよび検証インフラは、デフォルトでエンタープライズグレードとなっています。
対策レベルの選択
「対策レベル」パネルで、以下の4つのレベルから適したものを選択できます。
- 悪意のあるトラフィックをブロック（デフォルト設定）：DDoS対策を行い、既知の攻撃源に関連付けられたIPやエンドポイントからのトラフィックをブロック。
- 自動化されたアクセスをブロック：デフォルトのオプションを拡張し、確認済みの自動化されたトラフィックもブロックする一方で、人間または人間による可能性が高い訪問者には影響を与えない。
- ボットを検証：自動化トラフィックや悪意のあるトラフィックをブロックするほか、ボットの可能性が高いアクセスに対して検証を実施する。検証を通過したアクセスは、同じブラウザおよびIPアドレスからのアクセスに限り、10日間は再度検証されない。なお、CAPTCHAによる検証は、支援技術を利用する訪問者にとって負担となる場合がある。アクセシビリティ要件のあるサイトでは、この点を考慮する必要がある。
- すべてのアクセスを検証：人間の可能性が高いアクセスに対しても検証が行われる。恒久的な設定というよりは、トラフィックの急増時などの短期的な利用に適している。
対策レベルを変更するには、「サイト」＞（サイト名）＞「ボット対策」に移動し、「対策レベル」セクションの「変更」をクリックします。あるいは、「サイト」画面で対象のサイトを複数選択し、「操作」＞「ボット対策の変更」を選択することで、複数のサイトに一括して変更を適用することもできます。
なお、「ボットを検証」以上のレベルを選択すると、API連携や自動化ツールなど、一部の外部サービスに影響が及ぶ可能性があります。Cloudflareの検証済みボットリストに掲載されていないサービスは、これらのレベルではブロック、または検証が行われるようになります。
通常のWordPress自動処理を許可
WordPressには、自動化されたリクエストによって動作する機能が数多くあります。例えば、WordPress REST API、定期実行されるバックグラウンド処理、プラグイン連携、SEOツールやフォーム、分析ツールとの接続、各種同期サービスなどがこれに当たります。
「通常のWordPress自動処理を許可」設定では、不要な自動トラフィックをフィルタリングしながら、こうしたWordPressの一般的なワークフローやサービス連携を維持できます。これにより、より厳格な保護レベルを適用した場合でも、正当な処理やサービスがブロックされるリスクを軽減可能です。
サイトがカスタム統合やサードパーティのサービスに依存している場合でも、対策レベルを上げた後は、主要機能のテストを行うことをおすすめします。
AIクローラーのブロック
「AIクローラーのブロック」設定では、モデルトレーニングや検索拡張生成（RAG）、AI検索サービス向けにコンテンツを収集するAIクローラーをブロックできます。GPTBotなどの認証済みAIクローラーも対象です。この設定は検索エンジンのクローラーには影響せず、GooglebotやBingbotは引き続きサイトのクロールとインデックス登録を行います。
有効にするには、「サイト」＞（サイト名）＞「ボット対策」に移動し、「AIクローラーのブロック」セクションのトグルをオンにします。複数のサイトに適用するには、「サイト」画面で対象のサイトを選択し、「操作」＞「AIクローラーブロックの変更」をクリックしてください。
分析データから、AIクローラーによるアクセスがサイト負荷の要因になっていると考えられる場合は、この設定を有効にすることで、従来の検索エンジンでの可視性を維持したままAIクローラーをブロックできます。ただし、その一方で、AIによる検索結果やコンテンツ要約にサイトが表示される機会は減少する可能性があります。
この設定によってブロックされるクローラーは、AIによる回答やおすすめコンテンツの生成に利用される情報を収集しています。そのため、AI検索やAIによるコンテンツ紹介での露出を重視している場合は、設定を恒久的に有効化する前に、その影響を慎重に確認することをおすすめします。
「常に許可」セクションで例外設定
「常に許可」リストでは、ボット対策の対象外としたいアクセスを例外として登録できます。登録したアクセスは、ブロックや検証の対象になりません。
この機能は、信頼できる連携サービスや監視ツール、デプロイシステム、内部APIなど、継続的なアクセスが必要なサービスに役立ちます。
例外は、以下の条件に基づいて設定できます。
- IPアドレスまたはIP範囲
- パスまたはエンドポイント
- ユーザーエージェント
例えば、監視サービスを許可リストに追加したり、カスタムAPIエンドポイントを認証チェックの対象外にしたりすることができます。また、より厳格な対策レベルを適用している場合でも、デプロイワークフローを中断することなく運用できます。
例えば、監視サービスを許可リストに追加したり、カスタムAPIエンドポイントを認証チェックの対象外にしたりできます。また、より厳しい対策レベルを適用している場合でも、デプロイワークフローが中断されるのを防ぐことができます。
無駄なトラフィックへの帯域幅消費を抑える
適切に管理されていないボットアクセスは、キャッシュが機能する前の段階でサーバーに到達するため、コードの最適化だけでは対処できない負荷を生み出します。こうしたアクセスは、リクエストごとにPHPスレッドやデータベース接続を消費します。
重要なのは、すべての自動化トラフィックをブロックすることではなく、サイトの運用に必要なボットやサービスは許可しつつ、リソースを無駄に消費するトラフィックだけを選択的に制御することです。
自動化トラフィックにお悩みでしたら、Kinstaのボット対策機能をぜひお試しください。MyKinstaから簡単に不要なトラフィックの監視、分類、検証、ブロックを行うことができます。
