過去18ヶ月で、ボットアクセスへの注目点は、クロールやインデックス登録から、サーバーのパフォーマンスやサーバー費用、そして実際のユーザーに安定したサービスを提供する能力への影響へと移っています。
Kinstaが管理するインフラ全体で100億件を超えるリクエストを分析した結果、見えてきたのは攻撃の実態ではありませんでした。問題の本質は、リソース消費にあります。というのも、インフラの観点では、「ただのボットアクセス」というものは存在しません。すべてのリクエストはサーバー側で何らかの処理を伴い、規模が大きくなるほど、非効率なクロールは単なるトラフィックの問題ではなく、「サーバーリソースの問題」へと変わっていきます。
そこで今回は、なぜこのような変化が起きているのか、ボットアクセスがWordPressサイトにどのようなコストをもたらしているのか、そしてボットアクセスへの向き合い方を見直すべき理由について見ていきます。
もはや従来のボット対策では対応できない
従来のボット対策は、「悪意のあるボットはブロックし、正当なボットは通す」というシンプルな考え方を前提としており、長年、このアプローチで十分に機能してきました。たとえば、Googlebotはサイトをクロールしてコンテンツをインデックス登録し、その役目を終えると離れます。一方で、悪意のあるボットはログインページへの侵入を試みます。この2つは性質が異なるため、それぞれに適した対策を講じれば十分でした。
しかし、この従来の考え方では見落とされていた存在があります。それが、悪意はなくブロック対象でもない一方で、大量のアクセスによってサイトのパフォーマンスに大きな影響を与える自動化トラフィックです。
AIクローラーは、検索エンジン向けにページをインデックス登録するだけでなく、AIモデルの学習やRAG（検索拡張生成）、リアルタイムのAI検索への応答に利用するためにコンテンツを収集します。そのアクセス規模は、従来のクローラーとは比較にならないほど。実際、GPTBotのトラフィックは2024年5月から2025年5月の1年間で305%増加しています。2025年初頭にはサイトへのアクセス200回に1回程度だったAIボットの割合は、年末には31回に1回にまで急増しました。
さらに、2025年後半には、Cloudflareのネットワーク全体におけるHTMLリクエストの4.2%をAIクローラーが占めるようになりました。2025年4月初旬には2.4%だった割合が、6月下旬には6.4%まで上昇しており、わずか1年足らずで約3倍に増えています。
こうしたAIクローラーは継続的かつ高頻度でアクセスを行い、従来の検索エンジンクローラーとは異なる挙動を示します。特に、キャッシュできない動的なエンドポイントへ大量のリクエストを送るため、サーバー側では実際の処理が発生し、大きな負荷につながります。
WordPressサイトで「実際の処理」が発生する仕組み
ここで、ボットアクセスがインフラに与える影響が明らかになります。しかし、この点はボットアクセスに関する多くの議論で見落とされがちです。
WordPressサイトで訪問者がキャッシュされたページを表示する場合、サーバー側の処理はほとんど発生しません。あらかじめ生成されたHTMLを、画像やCSSファイルと同じように返すだけで済むため、オリジンサーバーへの負荷はごくわずか。これがキャッシュの目的です。
一方、実際のWordPressサイト、特にWooCommerceストアでは、以下のような多くのリクエストがキャッシュでは処理できません。
- カートやチェックアウト関連のURL（
?add-to-cart=、/cart、/checkout） - URLパラメータ付きの絞り込み商品ページ
- サイト内検索
- AJAXを利用した動的な処理（ウィッシュリストへの追加、価格のリアルタイム更新、動的ポップアップなど）
- サーバー側でユーザーセッションの作成や検証が必要なページ
ボットがこれらのエンドポイントにアクセスすると、サーバーでは次のような処理が発生します。
- PHPスレッドが占領される：WordPressでは、動的なリクエストごとにPHPスレッドが1つ割り当てられ、通常は200〜500ミリ秒程度、複雑なページではさらに長い時間占有される。この間、そのスレッドはほかのリクエストには使用できない。また、利用できるPHPスレッド数はサーバープランごとに決まっている。
- データベースへのクエリが実行される：動的ページでは、ページが表示されるたびにデータベースへの問い合わせが発生する。通常のアクセス量であれば問題ないが、キャッシュされないページにボットが継続的にアクセスすると、データベースは絶えずクエリを実行することになる。さらに、キャッシュが効かない異なるURLへアクセスが繰り返されると、それぞれのリクエストごとに新たなクエリが実行される。
- セッション処理が発生する：カートやチェックアウトページでは、購入につながらないボットアクセスであっても、リクエストごとにセッションの作成や検証が行われる。その結果、不要な処理負荷が積み重なっていく。
- PHPスレッドが不足する：利用可能なPHPスレッドがすべて使用中になると、正当な訪問者のリクエストはすぐに処理されず、待機状態に。待機リクエストが増え続けると、ページの表示速度低下やチェックアウト処理の停滞、504エラーなどが発生し、実際のユーザーからはサイトが正常に動作していないように見えてしまう。
このように、自動化されたリクエストが動的なエンドポイントに集中すると、ボットアクセスは単なるアクセスではなく、インフラ全体に影響を及ぼす問題へと発展します。
Kinstaのインフラデータから見る実態
この問題は、Kinstaが大規模に運用するインフラの実データを見ると、より明確になります。
特に印象的だったのは、ClaudeBotという単一のボットが、24時間で「add-to-cart」URLに対して375万件ものリクエストを送信していたことです。これは約23ミリ秒に1回というペースで、昼夜を問わずリクエストを送り続けていた計算になります。また、カート関連のエンドポイントは動的ページであるため、サーバーはこれらをすべて新しいリクエストとして処理しなければなりません。
ちなみに、「add-to-cart」へのリクエストは、WooCommerceストアの中でも特にサーバー負荷が大きいURLの1つです。リクエストごとにセッションの作成やデータベースへのクエリ、カート情報の更新といった処理が実行されるため、1件ごとにサーバーリソースを消費します。つまり、単一のボットから24時間で375万件ものリクエストが送られると、サイトが停止してもおかしくないほどの負荷が発生する可能性があります。
さらに、このようなボットの挙動が継続的に発生するケースも確認されています。たとえば、あるクローリングのループによって、30日間で5億5,000万件ものリクエストが発生しました。このトラフィック量は、Kinstaのインフラ側で専用の緩和ルールを設ける必要があったほどです。これはDDoS攻撃やマルウェアによるものではなく、同じURLを繰り返し巡回し続けるボットが原因でした。
こうした事例は決して特殊なケースではなく、Kinstaのプラットフォームでは、このようなパターンが継続的に確認されています。
クローリングのループが生み出す過剰なアクセス
現在のボットアクセスで見落とされがちなのは、インフラに大きな負荷を与えている原因の多くが、悪意のある攻撃ではないという点です。問題なのは、大規模かつ非効率な自動クロールです。
特にECサイトなどの最近のサイトでは、実質的には同じページでも、URLが少しずつ異なるケースが数多くあります。たとえば、以下のようなものです。
- 色で絞り込みを行った商品ページ
- セッショントークンが付与されたカートページ
- 並び替えパラメータが付いたカテゴリページ
人間の目にはこれらすべては「同じページ」に見えますが、URLをたどって巡回するボットは、それぞれを異なるページとして認識します。その結果、同じようなページを何度もクロールし続け、不要なリクエストを大量に発生させてしまいます。
ボットが最初のリンクをたどると、そのページが別のURLパターンを生成し、ボットはそのリンクもたどります。そしてまた次のリンクへ、さらにその次のリンクへと進んでいきます。ボットには同じ場所をループしていることを認識する仕組みがありません。中には、対策ルールが検知するまで数日間にわたって監視対象のインフラ上で動き続けていたものもありました。
先日Kinstaが公開したレポート『AI・ボット時代におけるトラフィックの実態』の中で、Cloudflareの元データインサイト部門責任者、David Belson氏は、「中には、昨日まで何をしているのかも分かっていなかった人が、ノリで作って公開したようなボットもある。robots.txtすら確認していないことも珍しくない」と述べています。
こうした挙動は、必ずしも悪意のある攻撃者によるものではありません。多くは、ファセットナビゲーションやURLパラメータの増殖、セッションごとに生成されるURLといった、現代のWordPressサイトでは一般的な仕組みを考慮せずに設計されたAIクローラーによるものです。
実際、Googleもファセットナビゲーションやパラメータ付きURLがクロール効率を低下させる要因であると明示しており、ボットが同じページのほぼ無限ともいえるバリエーションを巡回してしまう可能性があると指摘しています。
サーバー料金を押し上げるボットアクセス
これまで多くのサーバープランでは、訪問数を基準に料金が決められていました。これは、訪問数がおおむね実際のユーザー利用を反映しているという前提に基づいており、現実の利用状況を測る指標として一定の妥当性がありました。訪問数はサイトを利用する実際のユーザー数とおおむね比例していると考えられていたためです。
しかし現在では、自動化されたボットアクセスによって訪問数が大きく水増しされるケースが増えています。ボットによるリクエストは訪問数だけを増やし、ユーザーのエンゲージメントやコンバージョン、売上にはつながりません。その結果、サイト運営者は、自ら招いたわけでも制御できるわけでもないボットアクセスによって、訪問数ベースのプランで超過料金を請求されるケースが増えていました。
こうした状況は業界全体で見られるほど顕著になり、Kinstaはこれを受け、実際のリソース消費と訪問数の乖離が大きくなっていたサイト向けに、帯域幅ベースのプランを導入しました。
サイトの訪問数だけが増え、帯域幅の使用量がそれに比例して増えていない場合、その原因はほぼボットであると判断できます。帯域幅ベースのプランへ切り替えることで、ボットによって簡単に水増しできる「訪問数」という指標から課金を切り離すことが可能になります。
この課金の問題は、状況を把握することも、対策を講じることも可能です。より深刻なのは、多くのサイト運営者が管理画面だけでは実態を把握できず、この問題そのものに気付いていないことです。
アクセス解析で見えること、見えないこと
これほど大規模なボットアクセスが発生するようになると、一般的なアクセス解析ツールだけでは、サイトの実際のパフォーマンスを正確に把握することが難しくなります。
例えば、訪問数は増えているにもかかわらず、売上やページ滞在時間、直帰率などの指標がそれに比例して変化していない場合は、ボットアクセスが影響している可能性があります。また、コンテンツの公開やマーケティング施策によるアクセス増加がないにもかかわらず、サーバーのパフォーマンスが低下している場合は、キャッシュされていないURLへのボットアクセスを疑う価値があります。
Kinstaでは、既知のボットのユーザーエージェントをアクセス解析やプラン利用量の計算から自動的に除外しています。ただし、人間のアクセスに近い挙動をする高度なボットは、引き続きアクセス解析に含まれる場合があります。
特に、次のような傾向が見られる場合は注意が必要です。
- 同じ種類のURLへのリクエストが繰り返されている（特にパラメータ付きURLやセッションベースのURL）
- 記事の公開やキャンペーン、季節要因などに心当たりがない時間帯にアクセスが急増している
- 実際のイベントとは無関係にアクセスが増えたタイミングで、TTFB（Time to First Byte）の増加やPHPスレッドの不足エラーなど、サーバーのパフォーマンス低下が発生している
- 訪問数だけが、帯域幅の使用量やコンバージョン数、エンゲージメント指標を上回るペースで増加している
これらの兆候だけでボットアクセスと断定することはできませんが、複数の兆候が同時に見られる場合は、それをビジネスの成長によるものと判断する前に、ボットアクセスの影響がないか調査することをおすすめします。
ボットアクセス問題が想像よりも複雑である理由
ボットアクセスの実態を知ると、多くの人はまず「すべてブロックしてしまえばいい」と考えます。またその一方で、「AIはこれからの時代に欠かせないから、すべて受け入れるべき」と意見する人も存在します。
しかし、そのどちらも適切な解決策とは言えません。
無差別にブロックしてしまうと、Googlebotをはじめとする正規のクローラーまで遮断してしまいます。Googlebotのクロール状況は、コンテンツが検索結果に表示されるかどうかを左右する重要な要素です。また、AI検索やAIによるレコメンド、回答エンジンでコンテンツを発見するAIクローラーまでブロックしてしまう可能性があります。WooCommerceストアやコンテンツ配信サイトにとっては、こうした露出機会を失うことは大きな機会損失につながります。
逆にすべてのボットを受け入れてしまうと、ビジネス上の利益を生まないアクセスのためにインフラコストを負担し続けることになります。特に、ボットが集中的にアクセスする動的エンドポイントでは、そのコストは決して小さくありません。自動アクセスが継続すればするほど、負荷とコストは積み重なっていきます。
「すべて許可する」か「すべてブロックする」の二択では解決できません。ボットを一括りに扱うのではなく、それぞれの種類や目的を理解した上で、適切に対応を分けることが重要です。
HostingAdviceの編集長であるCristian Lopez氏も、「ボットアクセスを単純な『ブロックするか許可するか』の問題だと考えてしまうのは誤り。実際にはポリシー、可視性、そしてコスト管理の問題」とレポートの中で述べています。
GooglebotやBing、正規の監視ツールなど、認証済みのボットは基本的には許可すべきです。ただし、検索エンジンがクロールする必要のないページについては、アクセスを制限しても問題ありません（たとえば、チェックアウトページは検索順位に影響しない）。
一方で、正体が不明なボットや目的が明らかでないボットについては、より慎重に扱う必要があります。また、動的エンドポイントへ大量のリクエストを送るAI学習用クローラーは、サイトの種類や運営方針に応じて、ブロックやレート制限の対象とすることを検討すべきでしょう。
『AI・ボット時代におけるトラフィックの実態』の後半では、サイトの種類別にベストな対応策を確認することができます。以下は、サイトのパフォーマンスと安定性を重視するWooCommerceストア向けの推奨設定の一例です。
このように、ボットの種類や目的に応じてきめ細かく制御できる機能は、現在の多くのツールには備わっていません。
Kinstaのボット対策アプローチ
Kinstaのボット対策機能は、これまで説明してきたインフラ運用上の課題を解決するために設計されました。
この機能では、アクセスを「検証済みボット」「人間の可能性が高い」「ボットの可能性が高い」「自動化トラフィック」「悪意のあるトラフィック」といったカテゴリに分類し、サイトの用途や運用方針に応じて適切な保護レベルを設定できます。
対策レベルは4種類あり、「自動化されたアクセスをブロック」は、検証済みのボットには影響を与えず、既知の自動化トラフィックのみをブロックします。「ボットを検証」は、認証されていない自動化トラフィックに対してのみ認証プロセスを要求するため、正規のユーザー体験を損なうことはありません。また、大規模なアクセス集中時には「すべてのアクセスを検証」を選択することもできますが、その分ユーザー体験への影響があることも考慮する必要があります。
この機能は、Cloudflareのエンタープライズ向けボット判定技術を採用しています。リアルタイムの機械学習によって、ユーザーエージェントだけでなく実際のアクセス挙動も分析し、すべてのアクセスに対して1〜99のボットスコアを割り当てます。現在では、AIボットの12.9%がrobots.txtの指示を無視しており、わずか1四半期前の3.3%から大幅に増加しています。そのため、ユーザーエージェントだけに依存した判定では十分ではなく、行動ベースの分析によって初めて検知できるボットが増えています。
また、過剰なブロックもコストにつながるため、信頼できる外部サービスや監視ツール、業務上欠かせない自動化システムを保護対象から除外できる「常に許可」リストも便利です。特に、注文の自動同期や決済サービスとの連携、稼働監視ツールなどを利用するWooCommerceストアでは、必要な自動通信まで遮断しないよう柔軟に設定できることが重要です。
「AIクローラーのブロック」トグルは、GooglebotやBingbotなどの検索エンジンクローラーには影響を与えず、AIトレーニングボットのみを対象にブロックします。AIクローラーによるアクセスがサイトのパフォーマンスに影響を与えている場合は、個別のルールを設定することなく、この設定を有効にするだけで対策できます。
ツールがあることを知っているだけでは十分ではありません。重要なのは、どのような場面で、どのように活用すべきかを理解することです。
ボットアクセスが問題になっている場合の対処法
前述したような兆候が見られる場合は、これからご紹介する手順を実践してみてください。効果の高い順にご紹介します。
まずは、トラフィックの発生元を確認しましょう。 MyKinstaのボット保護画面にある「リクエストの内訳」チャートを使えば、サイトへのアクセスがどのようなカテゴリに分類されているかを確認できます。
自動化トラフィックや未認証のボットが大きな割合を占めている場合は、対策を講じるべきサインです。何を対象に保護しようとしているのかを把握しないまま設定を変更すると、誤った構成になってしまう恐れがあるため、この確認は不可欠です。
続いて、サイトの種類に合わせて対策レベルを設定します。例えば、WooCommerceストアとコンテンツ配信サイト、ステージング環境では、それぞれ重視すべきポイントが異なります。動的エンドポイントを多く持つWooCommerceストアでは、「自動化されたアクセスをブロック」や「ボットを検証」といった設定が適しています。一方、コンテンツサイトでは、AIによるコンテンツ発見用のクローラーは許可しつつ、AI学習用クローラーはブロックするといった方針が考えられます。ステージング環境であれば、用途を問わず外部からのアクセスを厳しく制限するのが望ましいです。
次に、負荷の大きいURLを優先して保護しましょう。 サイト全体に広く保護ルールを適用する前に、カートやチェックアウト、AJAXハンドラーなど、サーバー負荷が高いエンドポイントへ不要なクローラーがアクセスしていないかを確認しましょう。まずはrobots.txtで/cartや?add-to-cart=へのアクセスを既知のボットに対して制限することが第一歩です。ただし、実際にアクセスを防ぐには、robots.txtで通知するだけでなく、WAF（ウェブアプリケーションファイアウォール）でアクセスを強制的に制御することが重要です。
最後に、継続的に監視しながら、必要に応じて設定を更新しましょう。 ボットアクセスの傾向は、思っている以上に速いペースで変化しています。GPTBotのトラフィックシェアは、わずか1年で3倍に増加しています。一度設定したルールを放置するのではなく、MyKinstaの「ボット対策」画面にある「ボット対策の結果」チャートを活用し、様子をみながら、どのトラフィックがブロック・検証・許可されているのかを継続的に確認することが重要です。
これらのデータを参考にしながら、サイトの状況に合わせて保護設定を調整していきます。
また、訪問数ベースのプランでボットアクセスによる超過料金が発生している場合は、Kinstaの帯域幅ベースのプランへの移行もあわせて検討してみてください。帯域幅ベースのプランに変更しても、ボットアクセスそのものが解決するわけではありませんが、実際のインフラ利用状況に応じた料金体系となるため、通常訪問数ベースよりも、実際のトラフィックに見合ったコストで運用できるようになります。
今後、さらに複雑化していくボットアクセス
すでにエージェント型AIによるトラフィックは、インフラのログに現れ始めています。Googleも、AIエージェントがサイトとやり取りする際に使用する専用のユーザーエージェントを発表しました。こうした自動化システムは、リンクをクリックし、フォームに入力し、リクエストを送信するなど、人間のセッションと見分けがつきにくい挙動をするようになっています。
その結果、ユーザーエージェント文字列やリクエスト頻度、行動分析によるスコアリングといった、現在のボット判定で利用されている手法だけでは、ボットと人間を明確に区別することがますます難しくなっています。
多くのサイト運営者が、この変化に独力で対応し続けるのは現実的ではありません。ボットの挙動は手動で設定したルールよりも速いペースで変化するため、3ヶ月前まで有効だった対策が、すでに十分ではなくなっている可能性もあります。そして、対応を誤った場合の代償は決して小さくありません。サーバーリソースの無駄遣いや超過料金の発生だけでなく、本来のユーザーがチェックアウト時に504エラーに遭遇するといった、ビジネスへの直接的な影響も生じます。
だからこそ、こうした問題をインフラ側で吸収できる環境が重要になります。Kinstaのプラットフォームは、Cloudflareのエンタープライズネットワーク上で動作し、悪意のあるトラフィックの15〜20%をサイトへ到達する前にブロックします。さらに、サイトの実際のトラフィック状況に応じて調整できるボット対策機能も追加。ボットアクセスが今後さらに進化していく中で、この問題をインフラレベルで解決するサーバーと、単なる付加機能として扱うサーバーとの差は、ますます大きくなっていくことが予想されます。
最終的に重要なのは、できる限り多くのボットをブロックすることではありません。ボットアクセスを適切に処理できるインフラの上でサイトを運用することこそが、これからのサイト運営の鍵となるでしょう。
