サイトへの訪問数が増えていないにもかかわらずリソース使用量が増えている場合、プランのアップグレードを検討するのが一般的です。確かに、実際のトラフィック増加によってサーバー負荷が高まり、より多くのリソースが必要になっている状態であれば、理に適った判断です。
しかし、サーバーリソースを増やしても、サーバーに到達するリクエスト数そのものが減るわけではありません。ボットアクセスがリクエスト数やサーバー負荷の増加要因となっている場合、リソースを追加しても、ボットが消費できる余地が広がるだけです。
その結果、運用コストは増加する一方で、根本的なパフォーマンスの問題は解決されません。Kinstaのボット対策機能は、このようなケースを想定して設計されています。サーバーリソースを増やすのではなく、サーバーに到達するトラフィックを制御することで、ボットによる不要な負荷を抑えることができます。
ボットと実際の訪問者ではアクセスパターンが異なる
ページの表示速度が遅い場合、人間の訪問者であれば、しばらく待ったり、再読み込みしたり、あるいはそのまま離脱したりします。一方でボットは、サーバーの応答状況に関係なく、同じペースでリクエストを送り続けます。そのため、サーバーリソースを増強してもボットトラフィックが自然に抑制されることはなく、プランをアップグレードすれば、その分だけボットが消費できるリソースも増えてしまいます。
さらに、現代のWordPressサイトにおけるリクエスト処理を考慮すると、状況はより複雑になります。多くのボットトラフィックは、キャッシュで処理できる静的ページではなく、キャッシュを回避してサーバーに直接負荷をかけるエンドポイントにアクセスします。WooCommerceやサイト内検索、絞り込み機能を利用しているサイトでは、ボットは主に以下のような箇所にアクセスします。
- カート操作や
?add-to-cart=パラメータ付きURL - さまざまなクエリ文字列を含む絞り込み済みの商品ページ
- 検索クエリ
- チェックアウトの各ステップやウィッシュリスト機能
- AJAXを利用した動的な操作
これらは静的ページのようにキャッシュできません。そのため、こうしたエンドポイントへのリクエストが発生するたびに、サーバー側では以下の処理が実行されます。
- PHPの実行：リクエスト処理中はPHPスレッドが占有されます。ボットによる負荷が継続すると利用可能なスレッドが枯渇し、実際の訪問者は応答を待たされることになります。
- データベースクエリ：動的ページは表示のたびにデータベースへ問い合わせを行います。キャッシュによる負荷軽減ができないため、その分サーバーへの負担も増加します。
- セッション処理：カートページやチェックアウトページでは、リクエストごとにセッションの作成や検証が行われます。購入につながらないボットアクセスであっても、この処理負荷は発生します。
Kinstaのインフラデータによると、ある単一のボットは24時間で「add-to-cart」URLに対して375万件ものリクエストを発生させました。これは24時間休みなく、約23ミリ秒ごとに1回のリクエストを送信していた計算になります。また、単一のループ検知ルールだけで、30日間に5億5,000万件のリクエストがプラットフォーム全体でフィルタリングされました。
ただし、これらは従来の意味での攻撃トラフィックではありません。多くの場合、ボットが発見したあらゆるURLをたどるよう設計されており、クエリ文字列の違いやパラメータ付きURLまで機械的に巡回した結果です。
「インフラの観点では、『単なるボットアクセス』というものは存在せず、すべてのリクエストが実際の処理負荷になる。非効率なクロールは、規模が大きくなるにつれて、単なるトラフィックの問題から、リソースの問題に変化する」─Daniel Pataki（Kinsta CTO）
ボットアクセスがサイトに与えるコスト
多くの制作会社や代理店では、同じような状況が繰り返されがちです。リソース使用量が増加するとプランをアップグレードし、その後またリソース使用量が増加する──というサイクルです。しかし、根本的なリクエスト数が変わっていないため、パフォーマンスは改善されません。
Kinstaでは、ボットアクセスをプランの訪問数に計上しないため、ボットが問題の原因かどうかを簡単に判断できます。MyKinstaの「分析」画面にある「訪問数」チャートでは、検証済みのボットのユーザーエージェントが訪問数データからあらかじめ除外されています。そのため、訪問数は正常に見えるにもかかわらずサーバーに大きな負荷がかかっている場合は、自動化トラフィックが原因である可能性があります。
また、「分析」画面の「ボットアクセス」タブでは、サイトに到達しているトラフィックの内訳をより詳しく確認できます。検証済みボット、ボットの可能性が高い、AIクローラー、過剰アクセスAIクローラー、自動化トラフィック、人間の可能性が高いなどを分類して把握できます。
これにより、自動化トラフィックがリソース使用量の増加に関係しているかどうかを把握しやすくなります。過剰アクセスAIクローラーや自動化トラフィックの急増が確認された場合は、ボットがキャッシュされないURLへ繰り返しアクセスしている可能性があります。
また、「ボット対策の結果」チャートでは、トラフィックの分類後に各リクエストがどのように処理されたかを確認できます。許可・検証・ブロックされたトラフィックの内訳が表示されるため、現在の対策設定が受信トラフィックにどのような影響を与えているのかをより正確に把握できます。
「受信回数上位リクエスト」一覧には、サーバーに負荷をかけている要因も反映されており、課金対象の訪問だけでなく、すべてのトラフィックが含まれています。これら2つの数値の差こそが、明確な理由なくコストが積み上がっている部分です。
その差を読み解く方法は次のとおりです：
- まず、「サイト」＞（サイト名）＞「分析」に移動し、「プランご利用状況」タブの「訪問数」を確認。訪問数が通常通りであれば、人間によるトラフィックの急増が原因ではない。
- 「受信回数上位リクエスト」を開き、ボットを含むすべてのトラフィックを表示。キャッシュできないパス（カートへの追加URL、クエリ文字列のバリエーション、チェックアウト手順など）に対する高トラフィックのリクエストが集中している場合、ボットがキャッシュでは対応できないリソースを消費していることがわかる。
- 「パフォーマンス」タブに目を通してみる。PHPの応答時間が長くなったり、スレッド上限に達したりしている場合は、ボットによる負荷がサーバーへの負担として現れていることを示している。
クライアントサイトを複数管理している場合、ボットによる負荷が発生しているサイトは、実態を把握しにくいコスト要因になりがちです。特に、プランをアップグレードしてもパフォーマンスが改善しない場合はなおさらです。実際、AIボットによるトラフィックは過去1年間で300%増加しており、現在ではサイトへのアクセス31回に1回がAIボットによるものとされています。この問題が自然に解消されることは期待できません。
Kinstaでは、プラットフォームレベルのセキュリティ機能により、悪意のあるトラフィックがサイトに到達する前にブロックされます。これにはDDoS攻撃対策や、既知の攻撃元IPアドレスからのリクエストの遮断が含まれます。しかしその一方で、悪意があると確認されていないものの、大量かつリソース消費の大きい自動化トラフィックはサーバーに到達してしまいます。Kinstaのボット対策は、このようなトラフィックを制御し、不要な負荷を軽減するための機能です。
Kinstaのボット対策の仕組み
MyKinstaのボット対策機能はインフラ層で動作し、フィルタリングはWordPressが関与する前の段階で実行されます。そのため、プラグインのインストールやWordPressの設定変更は不要です。
Kinstaは、独自のトラフィック分析とCloudflareの機械学習システムを組み合わせてすべてのリクエストを分類し、各訪問者に1から99までの「ボットスコア」を割り当てます。スコアが高いほどリクエストが人間によるものである可能性が高く、スコアが低いほど自動化されたアクティビティである可能性が高いことを意味します。
トラフィックは、「検証済みボット」「ボットの可能性が高い」「AIクローラー」「過剰アクセスAIクローラー」「自動化トラフィック」「人間である可能性が高い」などのカテゴリに分類されます。選択した対策レベルによって、各カテゴリの処理方法が決定されます。
ボット対策は、MyKinsta内の「サイト」＞（サイト名）＞「ボット対策」から管理可能です。
対策レベルの選択
「ボット対策」画面の「対策レベル」パネルでは、以下の4つのレベルから選択できます。
- 悪意のあるトラフィックをブロック（デフォルト設定）：DDoS対策を行い、既知の攻撃源に関連付けられたIPやエンドポイントからのトラフィックをブロック。
- 自動化されたアクセスをブロック：デフォルト設定を基に、検証済みの自動化トラフィックもブロックしつつ、認証済みのボットや実際の訪問者は通過させる。
- ボットを検証：自動化トラフィックや悪意のあるトラフィックをブロックし、ボットと見なされる可能性のある訪問者に対して検証を行う。通過した訪問者は、同じブラウザおよびIPアドレスから10日間は再度確認を求められない。
- すべてのアクセスを検証：人間である可能性が高いユーザーに対しても検証を行う。トラフィックが急増する期間の短期的な使用に適している。
レベルを変更するには、「サイト」＞（サイト名）＞「ボット対策」に移動し、「対策レベル」セクションの「変更する」をクリックします。あるいは、「サイト」から対象のサイトを選択し、「操作」＞「ボット対策設定の変更」をクリックすることでも対策レベルを変更できます。
ただし、「ボットを検証」以上のレベルに引き上げると、プログラム経由でサイトに接続し、Cloudflareの検証済みボットディレクトリに掲載されていないツールはすべてブロックされるか、検証の対象となります。これには、独自に構築した連携機能、デプロイスクリプト、自社運用の稼働監視ツールなども含まれます。そのため、こうした仕組みを利用している場合は、対策レベルを引き上げる前に、Cloudflareの認証済みボットとして登録されているか確認しておくことをおすすめします。
AIクローラーのブロック
「AIクローラーのブロック」設定は、AIクローラーを対象としたもので、AIモデルの学習やRAG（検索拡張生成）、AI検索機能のためにコンテンツを収集するボットが該当します。この設定は検索エンジンのクローラーには影響しませんが、GPTBotのようなAI専用クローラーは対象となります。そのため、この機能を有効にしても、GooglebotやBingbotによるサイトのインデックス登録は継続されます。
一般的に、AIクローラーによるアクセスの約80%は、ユーザーの検索要求に応答するためではなく、AIモデルの学習を目的としたものです。こうしたアクセスはサイトへの参照トラフィックを生み出さないため、「Block AI crawlers」を有効にすることをおすすめします。
設定するには、「サイト」＞（サイト名）＞「ボット対策」に移動し、「AIクローラーのブロック」のトグルをオンにします。複数サイトで一括設定する場合は、「サイト」画面で対象のサイトを選択して、「操作」＞「AIクローラーブロックの変更」をクリックします。
AIクローラーをブロックする際の懸念点としては、AIが生成する概要やコンテンツ要約での露出が減少することです。コンテンツ戦略においてこの可視性が重要である場合は、トグルを恒久的にオンにせず、その影響を監視することをおすすめします。
サーバー負荷の軽減を優先する場合は、robots.txtを編集したり、ボットごとにルールを作成したりするよりも、この方法の方がシンプルです。ボット対策は、リクエストがWordPressに到達する前のインフラレイヤーで動作するため、より効率的に不要なトラフィックを制御できます。
複数サイトの保護設定を管理する方法
サイトによって必要な対策レベルは異なります。たとえば、絞り込み機能を備えたWooCommerceストアとコンテンツサイトでは、適切な設定は同じではありません。また、クライアントごとにトラフィックの特性や連携サービス、認証プロセスへの許容度も異なります。そのため、すべてのサイトに同じポリシーを適用すると、一部のサイトでは制限が厳しすぎたり、逆に十分な保護が得られなかったりする可能性があります。
クライアントサイトでボットアクセスがコスト増加の原因になっていると判断したら、以下の手順で対応することをおすすめします。
- MyKinstaの「分析」画面の「ボットアクセス」タブから確認。人間のトラフィックが安定している一方で、自動化トラフィック、過剰アクセスAIクローラー、またはAIクローラーの活動が増加している場合、ボットによる負荷が原因である可能性が高い。
- 続いて、「分析」画面の「上位リクエスト」タブにある「受信回数上位リクエスト」チャートを確認し、キャッシュ不可のパスに対するリクエスト数が異常に多い箇所を探す。「add-to-cart」URL、絞り込み済みの商品ページ、チェックアウト画面、検索クエリ、クエリ文字列付きURLなどへのアクセスが集中している場合は、ボットによるリソース消費が発生している可能性が高いと考えられる。
- 「パフォーマンス」タブは、その影響を確認するのに便利。PHPの応答時間の増加、スループットの上昇、またはスレッド上限への到達などは、自動トラフィックがサーバーへの負荷として顕在化し始めていることを示している。
- これを踏まえて、サイトに適切な対策レベルを選択。「自動化されたアクセスをブロック」が通常良い出発点となるが、「ボットを検証」を選択すると、ボットと判定されたアクセスに対して追加の検証を要求できる。
- API連携やWordPressの自動処理を利用しているサイトでは、「通常のWordPress自動処理を許可」や「常に許可」リストの例外を適切に設定することで、正当なサービスがブロックされるリスクを抑えられる。
- 設定の変更は即座に反映される。また、設定がサイトの連携機能に対して制限が厳しすぎる場合は、すぐに元の設定へ戻すことができる。これらの制御はWordPressの外側にあるインフラレイヤーで行われるため、設定を検証している間もサイト自体に影響を与えることはない。
WordPressサイトを多数運用する制作会社や代行業者にとって、この作業は日常的な運用の一部として取り組めます。各サイトの実際のトラフィック特性に合わせて保護設定を最適化することで、リソース使用量も実際のユーザーアクセスをより正確に反映するようになります。その結果、パフォーマンス指標も実際の訪問者が体感する状況に近づきます。
「ボットアクセスを単純な『ブロックするか許可するか』の問題だと考えてしまうのは誤り。実際にはポリシー、可視性、そしてコスト管理の問題」— Cristian Lopez（HostingAdvice 編集長）
クライアントにコストについて説明する際は、原因が分からない負荷に対応するためにサーバー容量を増やしたことではなく、トラフィックをどのように管理・制御するかという判断に基づいて説明できる状態が理想です。
プランをアップグレードする前にボット対策を
サーバープランをアップグレードすると、より多くの負荷を処理できるようになります。一方、ボット対策は、サーバーに到達する負荷そのものを減らします。この2つは同じ問題に対する同等の解決策ではありません。前者は処理能力を増やす方法であり、後者は、そもそも処理能力の増強が必要になった原因を取り除く方法です。
MyKinstaの分析機能を利用すれば、アクセス数は変わらないのにリソース使用量だけが増えている場合、自動化トラフィックが原因かどうかを確認できます。そのうえで、ボット対策を設定すれば、不要なトラフィックを分類し、検証やブロックを行い、WordPressやPHP、データベースに到達する前に制御できます。
また、クローラーによる過剰なアクセスが問題となっているサイトでは、「AIクローラーのブロック」をオンにすることで、GooglebotやBingbotなどの検索エンジンクローラーには影響を与えることなく、AIクローラーによるトラフィックを削減できます。
自動化トラフィックをより細かく管理し、インフラへの不要な負荷を抑えたい場合は、Kinstaのボット対策をご利用ください。MyKinstaに組み込まれた可視化機能とフィルタリング機能により、不要なトラフィックを効果的に制御できます。
