この1年で、ボットアクセスは「サイト運営者が気にしなくてもよいもの」から、「インフラの挙動そのものに影響を与える存在」へと変化しています。
その変化は単純なアクセス数の増加だけではありません。特にWooCommerceストアのようなサイトでは、自動化されたアクセスがどのようにサイトとやり取りするかが重要になっています。一見すると、リクエストはどれも同じように見えるかもしれませんが、実際にはリクエストによって生じる負荷は異なり、WooCommerceではその違いがより顕著に現れます。
この記事では、WooCommerceサイトがボットアクセスの影響を受けやすい理由、ボットが重要なURLにアクセスした際にバックグラウンドで何が起きているのか、そしてトラフィックとパフォーマンスに関する一般的な考え方がECサイトには当てはまらない理由を解説していきます。
WooCommerceではトラフィックがそのまま負荷になってしまう理由
一般的なWordPressサイトでは、ほとんどのページがCloudflareのようなCDNのエッジでキャッシュされるため、リクエストはオリジンサーバーを介さずに処理されます。そのため、アクセス数が増えてもキャッシュされたコンテンツを配信するだけで済み、負荷は比較的低く抑えられます。
しかし、WooCommerceでは事情が異なります。多くのリクエストがリアルタイムのデータやユーザーごとのコンテキストに依存しているため、キャッシュから配信することができず、すべてのリクエストをオリジンサーバーで個別に処理する必要があります。具体的には、以下のような処理が発生します。
- リクエスト処理ロジックを実行するためのPHPの実行
- 商品情報、価格情報、セッションデータを取得するためのデータベースクエリの実行
- レスポンスを動的に生成して返す処理
PHPの実行にはPHPスレッドが使用され、リクエストの処理中はそのスレッドが占有されます。一方で、サイトで利用できるPHPスレッド数には上限があり、すべてのスレッドが使用中になると、新規リクエストは待機状態になります。また、サイトが継続的にPHPスレッドの上限に達することもあります。
同時に、データベースでは商品データやセッション情報を取得するためのクエリが実行されます。さらに、バックグラウンドではセッション処理も行われています。
ボットアクセスを考慮しなくても、WooCommerceのリクエストは本質的にコストの高い処理です。そこに自動化されたアクセスが加わることで、その負荷はさらに増大します。
WooCommerceサイトでボットアクセスの影響が最も大きい箇所
WooCommerceサイトにおけるボットアクセスの影響は、主に実際のユーザー操作を前提として設計された特定の機能やURLに集中します。
特に負荷が高く、キャッシュの効果も得にくいのが以下のような箇所です。
- カートおよびチェックアウトページ（
/cart/checkout?add-to-cart=） - サイト内検索
- フィルタリングやパラメータを使用する商品ページ
- AJAXベースのインタラクションや動的コンポーネント
これらはそれぞれ動作の仕組みが異なりますが、いずれの場合もリクエストごとにサーバー側で実際の処理が発生します。
最もわかりやすい例が、カートおよびチェックアウト関連のページです。/cartへのアクセスや、?add-to-cart=を含むリクエストでは、セッションの検証、カート状態の更新、商品データの取得、そしてユーザーごとに異なるレスポンスの生成といったアプリケーションロジックが実行されます。このような処理が大規模に繰り返されると、サーバーリソースは急速に消費されます。
先日Kinstaが公開したレポート『AI・ボット時代におけるトラフィックの実態』でもご紹介していますが、Kinstaのエンジニアリングチームが、24時間で700万件を超えるボットリクエストが、Kinstaのインフラ上のadd-to-cart URLに到達していたことを確認しました。
この規模をイメージしやすくすると、ClaudeBotによる375万件のリクエストは、24時間を通して約23ミリ秒ごとに1件のリクエストが送信されている計算になります。そして、そのすべてが新規リクエストとして処理されます。
カートやチェックアウトページ以外にも、検索や絞り込み機能は別の形でサーバーに負荷をかけます。WooCommerceストアでは、価格、カテゴリ、サイズ、在庫状況といった属性を使って商品を絞り込めることが一般的です。こうした条件の組み合わせごとに異なるURLが生成されるため、クローラーから見ると、それぞれがクロール対象になります。
実際にKinstaのレポートでは、meta-externalagent（Facebook/Meta AIのクローラー）がWooCommerceの商品比較ページを巡回し続けたり、カレンダーページの意味のないバリエーションを延々とクロールしたりするケースが確認されています。
これは、クローラーがページの文脈を理解していないためです。クローラーは最初のバリエーションをたどり、次に少しだけ異なる別のバリエーションを見つけ、さらに別のバリエーションへと進みます。そして、その探索を延々と続けていきます。その過程で、自分が実質的には同じページを何度も訪問していることを認識することはありません。
WooCommerceサイトでは、多くのバリエーションが動的な機能と結びついているため、この問題は特に深刻になります。
ボットアクセスは攻撃ではないが、システムへの影響は似ている
この問題が見過ごされやすい理由のひとつは、悪意のある攻撃のようには見えない点にあります。
悪意のある攻撃であれば、単一の送信元からの急激なアクセス増加や、明らかな不正利用の兆候、場合によっては悪意のあるペイロードなどが見られます。一方、ボットアクセスはサイトの構造に従って有効なURLにアクセスし、有効なレスポンスを受け取るため、一見すると通常のリクエストに見えます。
外部から見ると、正当なクローリング活動のように見えることも少なくありません。しかし、システムはアクセスの意図を判断するわけではなく、処理するのはリクエストそのものです。
非効率なクローラーや適切に動作していないクローラーが大規模に稼働すると、結果として不正アクセスに似たパターンが生まれます。たとえそれが本来の目的でなかったとしても、繰り返しのリクエストやループ、動的なURLへの高頻度アクセスは、継続的なサーバー負荷につながります。
そのため、実際の運用では「良いボット」か「悪いボット」かという分類は、それほど重要ではありません。
クローラーが正当なものであっても、パフォーマンスを低下させるようなアクセスパターンを生み出す可能性があります。問題は、誰がリクエストを送信しているかではなく、そのリクエストによってシステムにどのような処理が発生するかにあります。
WooCommerceのパフォーマンスへの影響
このようなアクセスが増加すると、その影響は以下のような形で現れます。
- 特にアクセスが集中する時間帯にページの読み込み速度が低下する
- チェックアウト処理の応答が遅くなったり、不安定になったりする
- 場合によっては、PHPスレッドが繰り返し発生する自動化されたアクセスの処理に占有され、リクエストが待機状態になる
表面的にはパフォーマンスの問題に見えますが、その根本的な原因は、キャッシュされないURLに対する自動化されたアクセスが継続的に負荷をかけていることにあるケースが少なくありません。
こうしたアクセスは、トラフィックの解釈にも影響を与えます。大量の自動化されたアクセスによって訪問数が増加していても、それが実際のユーザーアクティビティを反映しているとは限りません。アクセス数が急増していても、エンゲージメントやコンバージョン、売上が同じように増加するとは限らないのです。どのようなアクセスが発生しているのかを把握できなければ、実際の需要によるものなのか、自動化されたアクセスによる負荷なのかを見分けることは困難になります。
大規模な環境では、これは単なるパフォーマンスの問題ではなく、意思決定にも影響を与える問題となります。
「とりあえずブロック」は危険
ボットアクセスについて十分に理解していない場合、このような挙動に対する自然な反応は「ブロックすればいい」かもしれません。実際、それで解決できるケースもありますが、多くの場合は新たなトレードオフが生まれます。
実際には、すべての自動化されたアクセスが有害というわけではありません。検索エンジンのクローラーは検索結果での可視性を維持するために不可欠です。また、AIクローラーは、コンテンツがAIエージェント上でどのように参照・表示されるかに関わる重要な役割を担っています。これは現在、GEO（Generative Engine Optimization、生成エンジン最適化）やAEO（Answer Engine Optimization、アンサーエンジン最適化）と呼ばれる取り組みの一部として注目されています。
すべてをブロックすればアクセスの問題は解消できますが、その恩恵も失うことになります。一方で、すべてを許可すれば運用上の支障は少ないものの、不必要な負荷にさらされ続けることになります。
問題は、WooCommerceサイトではすべてのアクセスに対して単一のルールを適用すればよいわけではないことです。重要なのは、アクセス先やアクセス元に応じて異なる対応を取ることです。
ボットアクセスに対する現実的なアプローチとは
ボットを許可するべきか、それともブロックするべきかを考えるよりも、「どの種類のアクセスを、サイトのどの部分まで許可するべきか」を考える方が実用的です。
例えば、カートやチェックアウトページにクローラーがアクセスする必要はありません。検索結果ページや絞り込みページも、サイトの主要な機能に影響を与えることなくアクセスを制限できます。一方で、商品ページやカテゴリーページは検索エンジンからアクセスできる状態を維持する必要があります。
こうしたアクセス制御の切り分けこそが、ボットアクセスを適切に管理する鍵になります。
Kinstaが管理するインフラで観測された100億件を超えるリクエストを分析したところ、これらのパターンは実際のWooCommerceサイトで繰り返し確認される傾向であることがわかりました（より詳細なデータや、サイトの種類ごとにこれらのパターンがどのように変化するのかについては、『AI・ボット時代におけるトラフィックの実態』レポートをぜひご覧ください）。
とはいえ、こうした対応を手作業で継続するのは現実的ではありません。定期的な設定の見直しに加え、トラフィックパターンを把握するための可視性や、正当なアクセスを妨げることなくルールを適用する仕組みが必要になります。Kinstaのボット対策機能は、まさにこの課題を解決するために設計されています。画一的なルールに頼ることなく、アクセスの種類に応じて柔軟に制御できるため、サイト運営者はボットアクセスへの対応をより効果的に行えます。
詳しくはドキュメントをご覧いただくか、お気軽にカスタマーサポートまでお問い合わせください。お客様のサイトや制作会社運営の環境でどのように活用できるかをご案内いたします。
