Kinstaがサーバーインフラ全体で100億件を超えるHTTPリクエストを分析したところ、わずか24時間のうちに、WordPressサイトのカート追加（add-to-cart）URLへボットから767万回ものアクセスが発生していたことがわかりました。あるクローラーに至っては、ルールによってブロックされるまでの30日間で、単独で5億5,000万件ものリクエストを送信していました。
こうしたアクセスは当然、コンバージョンには一切つながらず、サイトへの訪問者を呼び込むこともありません。ただひたすら、カートページ、絞り込み条件付きの商品URL、検索クエリ、AJAXエンドポイントなどにアクセスし続けていました。そのたびにサーバーではPHPが実行され、データベースへのクエリが発生し、顧客になることのないトラフィックのためにセッション処理が行われていました。
こうした負荷を受けていたサイトは、ダウンすることはなく、ページは表示され、決済も正常に機能していました。従来の一般的な指標だけを見れば、何の問題もないように見えます。今回は、この「見えない問題」を掘り下げます。
ボットはもはや無視できない存在
2025年には、ウェブトラフィック全体の53%をボットが占め、年間を通じて自動化されたトラフィックが人間によるトラフィックを初めて上回りました。Cloudflare Radarによると、2026年6月にはその割合は57.5%に達しており、CloudflareのCEOも、予想より数年早くこの逆転が起きたと述べています。
WordPressサイトの運営者にとって重要なのは、こうした割合そのものよりも、ボットの中身が変化していることです。現在では、検索エンジンのクローラーだけでなく、AIの学習用クローラー、スクレイピングツール、SEO監査ボット、稼働監視ボット、偽装されたユーザーエージェント、さらには従来のクローラーよりも積極的にリンクをたどるエージェント型AIツールなど、さまざまな自動トラフィックが存在します。
コンテンツをインデックスするものもあれば、情報を収集するもの、エンドポイントを調べるものもあり、URLパラメータの組み合わせをそれぞれ別のページとして認識し、一つひとつクロールするボットも存在します。
WordPressにとって特に大きな負荷につながるのが、この最後の挙動です。人間にとっては1つの商品ページでも、色、サイズ、並び順、ページネーション、在庫状況などの絞り込み条件が加わることで、ボットには数百もの異なるURLとして認識され、そのすべてがクロールされる可能性があります。
AIボットアクセスは、わずか1年間で300%増加しています。2025年初頭には200回のウェブアクセスに1回だったAIボットからのアクセスが、年末にはTollBitのネットワークで31回に1回まで増えており、この流れが今後も続くことは明らかです。一方で、こうしたトラフィックが実際にどれほどのコストをもたらしているのかは、まだ十分に認識されていません。
帯域幅は最もわかりやすいコスト
帯域幅とは、ページ、画像、スクリプト、ファイルなどがリクエストされた際に、サイトから転送されるデータ量です。人間の訪問者だけでなく、ボットによるアクセスでも消費されます。当然ながら、ボットがその後商品を購入することはありません。
クローラーがブログ記事に一度アクセスする程度なら問題にはなりません。しかし、アーカイブ、タグページ、画像ファイル、フィード、スクリプト、絞り込み条件付きのURLなどをボットが繰り返しクロールすれば、ビジネス上の価値を生み出すことなく、実際の帯域幅が消費されていきます。
Kinstaが先日公開した『AI・ボット時代におけるトラフィックの実態』レポートで引用しているCloudflareの2025年のデータでは、AIによるクロールの80%は検索やユーザーからのリクエストではなく、モデルの学習を目的としたものです。こうしたクロールからサイトへの参照トラフィックが生まれることはありません。コンテンツ量の多いWordPressサイトでは、価値の高いページほど、配信にかかるコストも大きくなり得ます。
厄介なのは、こうした帯域幅の無駄が、目に見えるパフォーマンスの問題を引き起こさないまま積み重なっていくことです。サイトは問題なく表示され、サーバーも正常に応答している一方で、人間の訪問者には必要のないページやファイルを自動トラフィックが繰り返しリクエストし、使用量だけが増え続けます。
帯域幅にかかるコストが目に見える形で現れた頃には、ビジネスに何の利益ももたらさないトラフィックを、すでに数日、場合によっては数週間にわたって処理し続けていた、ということもあり得ます。
見えにくいコストはバックエンドへの負荷
すべてのリクエストが、同じ処理コストで済むわけではありません。キャッシュされたブログ記事であれば、サーバーは保存済みのデータを返すだけなので、比較的少ない負荷で処理できます。しかし、動的なリクエストはそうはいきません。
ボットがWooCommerceのカート操作、絞り込み条件付きの商品ページ、検索クエリURL、ログインページ、AJAXエンドポイントなどにアクセスすると、キャッシュを利用できないため、リクエストのたびにサーバー側で以下の処理が発生します。
- PHPの実行：リクエストの処理が完了するまで、PHPスレッドが占有される
- データベースクエリ：キャッシュを利用できないため、ページが読み込まれるたびにデータベースへの問い合わせが発生する
- セッション処理：カートや決済ページでは、実際に購入することのないボットからのアクセスでも、リクエストごとにセッションの作成や検証が行われる
- プラグインの処理：リクエストにフックするプラグインがあれば、アクセスのたびにそのコードが実行される
- キャッシュのバイパス：リクエストがキャッシュされないため、同じリクエストが再び届いても、その都度同じ処理が必要になる
ボットによるアクセスには、見た目以上のコストがかかります。問題は、ボットがどれだけのデータをダウンロードするかだけではありません。そのデータを返すまでにインフラ側で発生する処理も、コストにつながります。
Kinstaのインフラデータを見ると、わずか24時間で、ボットによるカート追加（add-to-cart）URLへのアクセスは767万回に達し、そのうち375万回はClaudeBotだけで発生していました。いずれもサーバー側では新規リクエストとして処理され、そのたびにPHPが実行され、データベースへのクエリが発生しています。しかし、そのどれも実際の顧客によるアクセスではありませんでした。
ボット対策といえば、「ブロックする」か「そのまま許可する」かの二択で語られがちですが、大規模な環境ではどちらも現実的な解決策とは言えません。
「ダウンしていない」だけでは十分ではない理由
稼働率が高いということは、サイトがオンラインの状態を維持できているということです。しかし、それだけでサイトが効率よく稼働しているとは限りません。
WordPressサイトは、訪問者が異常に気づくよりもはるかに多くの不要なトラフィックを処理できることがあります。ページは表示され、決済も機能し、管理画面も問題なく操作できる。一見すると正常でも、動的なエンドポイントに届くボットからのリクエストは、その都度インフラ側で処理されています。そして、その処理には実際にコストがかかっています。
その影響は、サイトのダウンほど目立たない形で現れます。
- 帯域幅の使用量が増え、徐々にプランの上限に近づく
- PHPワーカーやデータベース接続への負荷が高まる
- 実際のアクセスが急増した際に利用できるリソースの余裕が減る
- ボットによるセッションが人間のエンゲージメントと混在し、アクセス解析の精度が低下する
- コンバージョンする意図のないトラフィックによって、A/Bテストの結果やコンバージョン率が歪められる
- 実際のユーザー行動を反映していないデータをもとに、インフラに関する判断を下してしまう
- 大量のボットトラフィックに埋もれて本来のパフォーマンス上の問題を見つけにくくなり、トラブルシューティングが難しくなる
そのため、「ダウンしていない」という事実だけでは、サイトが健全に稼働しているとは判断できません。インフラが余分な処理を吸収しているからこそ、表面上は安定して見えることもあります。不要な処理にもコストはかかります。ただ、そのコストが目に見えにくいだけです。
クライアントが問題に気づく前に制作会社が対策すべき理由
一般的に、制作会社がボット問題を認識するのは、目に見える影響が出てからです。サーバーの使用量が増えた、管理画面が遅くなった、決済処理に時間がかかるようになった、不自然なトラフィックが増えた、アクセス解析の数値と実際のビジネス成果が一致しない、といった変化にクライアントが気づいて初めて問題が表面化します。その段階では、制作会社側は何が起きたのか、なぜ問題なのか、どのような対策が必要なのかを説明しなければならず、どうしても事後対応になってしまいます。
しかし、ボットについてあらかじめ説明しておけば、問題が起きる前に対策を提案できます。
必要以上に不安を煽る必要はなく、例えば、次のように実用的な観点から説明できます。
- 「サイトは問題なく動いていても、すべてのアクセスが実際の訪問者によるものとは限りません」
- 「検索エンジンのクローラーや監視ツールなど有益なボットもありますが、リソースを消費するだけのボットも存在します」
- 「必要なトラフィックには影響を与えず、不要なリソース消費だけを抑えることができます」
- 「適切に対策することで、アクセスが増えたときに使えるリソースの余裕を確保し、使用量も予測しやすくなります」
このように説明すれば、ボット対策を、クライアントにもわかりやすいコスト、効率、信頼性といった課題に結びつけることができます。また、問題が起きてから対応する存在ではなく、インフラを先回りして改善するパートナーとして制作会社の価値を高め、より長期的な関係構築にもつながります。
すべてのボットをブロックするのは間違い
すべてのボットが悪ではありません。検索エンジンのクローラーは、ページが検索結果に表示されるために必要です。監視ツールはサイトの稼働状況を確認し、SEOツールはページを分析します。また、決済サービスや外部サービスとの連携、API、WordPressの自動化機能なども、正当な処理を行うためにサイトへアクセスすることがあります。
AIクローラーに関してはもう少し複雑になります。AIを活用したサービス上での露出を増やしたいサイト運営者もいる一方で、大量のコンテンツを収集するだけで、サイトへの有意義な参照トラフィックにつながらないのであれば、得られる価値よりもコストの方が大きいと判断するケースもあります。
だからこそ、すべての自動リクエストを一律にブロックすればいいというわけではありません。過剰にブロックすると、SEOに悪影響を及ぼしたり、外部サービスとの連携や監視を妨げたり、WordPressの通常のワークフローに支障をきたしたりする可能性があります。
効果的なのは、トラフィックに応じて適切に制御することです。
- 有益なトラフィックは許可する
- 明らかに不要な自動アクセスはブロックする
- 不審なトラフィックにはチャレンジを実行する
- 処理負荷の高いパスを保護する
- 対策後の結果を継続的に監視する
すべてのボットを同等に扱うのではなく、必要に応じて制御することで、より柔軟なボット対策が可能になります。ビジネスに役立つトラフィックやツール、ワークフローを維持しながら、不要な処理を減らすことが重要です。
Kinstaのボット対策の仕組み
ボットのアクセスがインフラに負荷を与えるようになったら、サイトの実際の状況に応じた対策が必要です。
MyKinstaに組み込まれたボット対策機能は、サイトごとに異なる状況に柔軟に対応できるよう設計されています。すべてのプランに標準装備されており、環境単位で設定可能です。また設定の変更はすぐに反映されます。
対策レベル
MyKinstaにログイン後、「サイト」＞（サイト名）＞「ボット対策」に移動し、「対策レベル」セクションの「変更する」をクリックします。4つのレベルから選択でき、環境ごとに個別に適用可能です。ステージング、開発、本番環境で異なる設定を行うことができます。
- 悪意のあるトラフィックをブロック：デフォルト設定。DDoS攻撃を軽減し、既知の攻撃パターンに関連するIPアドレスやエンドポイントをブロック。Kinstaでホストするすべてのサイトで標準で有効になっているもの。
- 自動トラフィックをブロック：ボットによる負荷が発生している多くのサイトで、最初に試したい設定。検証済みのボットや実際の訪問者からのアクセスは許可しながら、自動トラフィックや悪意のあるトラフィックをブロック。人間の訪問者には影響を与えず、動的URLへの繰り返しアクセスを抑えたい場合に効果的。
- ボットを検証：ボットの可能性が高いトラフィックや、分類されていないトラフィックを検証。一度通過すると、同じブラウザとIPアドレスでは10日間、再度検証を求められることはない。アクセスの急増時やセール期間、スクレイピングが活発になっている場合など、ブロックによる保護と訪問者への影響のバランスを細かく調整したい場合に便利。
- すべてのトラフィックを検証：最も厳しいレベルで、攻撃や継続的な不正アクセスが発生している際の一時的な使用を想定。人間の可能性が高いアクセスを含め、未検証のトラフィックすべてに認証を求める。必要時にのみ使用。
「悪意のあるトラフィックをブロック」よりも上位のレベルに引き上げる場合は、ビジネスに不可欠な外部サービスがCloudflareの認証済みボット一覧に登録されているかどうかを確認してください。「ボットを検証」以上のレベルでは、プログラムからサイトに接続するツールが認証済みでない場合、検証またはブロックの対象になります。
AIクローラーのブロック
「AIクローラーのブロック」設定は、対策レベルとは別に設定できる機能です。オンにすることで、GPTBotなどの認証済みボットを含むAIクローラーを対象にブロックすることができます。GooglebotやBingbotには影響しないため、検索エンジンによるインデックスは通常どおり行われます。
コンテンツ量の多いサイトやメディア、ドキュメントサイト、有料コンテンツを提供するサイトなどでは、AIクローラーが記事ページやアーカイブページ、キャッシュされていないファイルに大量かつ繰り返しアクセスすることがあります。この設定を有効にすれば、検索結果での表示に影響を与えることなく、こうした負荷を軽減できます。
ただし、AIクローラーをブロックすることにはトレードオフもあり、AIが生成する回答や要約に自社のコンテンツが表示される機会が減少します。AIサービス上での露出を重視するサイトであれば、「自動トラフィックをブロック」または「ボットを検証」の方が適している場合があります。悪質なボットの挙動を抑えながら、AIクローラーからのアクセスを維持できるためです。
一方、AIサービス上での露出よりも、サーバーリソースの消費やプランの使用量を抑えることを優先する場合は、AIクローラーをブロックする方がシンプルで効果的です。
通常のWordPress自動処理を許可する
対策レベルをデフォルトより高く設定する場合は、同時に「通常のWordPress自動処理を許可する」をオンにしてください。
これを有効にすると、REST APIリクエスト、WooCommerceのルート、バックグラウンドタスク、スケジュールされたジョブ、プラグイン連携など、WordPressで一般的に使用されるパスやサービスが管理対象の許可リストに追加されます。これにより、ボット対策を強化しても、サイトの運用に必要な処理や連携が意図せず中断されるのを防ぐことができます。
「自動トラフィックをブロック」以上の対策レベルを使用する場合は、この設定をオンにしてください。不要なトラフィックを抑えながら、サイトに必要な処理を維持することができます。
常に許可
対策レベルを問わず、常にアクセスを許可したいサービスは、「常に許可」セクションを利用してください。IPアドレス、URLパス、またはユーザーエージェントを指定して、最大50件まで個別に例外を追加できます。
以下のような用途に使用できます。
- 決済サービスのWebhook（Stripe、PayPalなど）
- 信頼できる監視サービス（UptimeRobot、Pingdomなど）
- 信頼できるパートナーサービスとの連携やAPIクライアント
- 開発者や社内ネットワークのIPアドレス範囲
- WordPress自動化の許可リストに含まれていない場合、/wp-json/*や/wp-admin/admin-ajax.phpなどの特定のWordPressパス
リクエストの内訳とボット対策状況
リクエストがどのように分類され、処理されているかを把握できなければ、ボット対策を最適化することはできません。
設定を変更する前に、まず「ボット対策」画面を確認してください。「リクエストの内訳」グラフでは、過去24時間にサイトに送信されたすべてのリクエストを、「人間の可能性が高い」「検証済みのボット」「ボットの可能性が高い」「AIクローラー」「過剰アクセスAIクローラー」「未分類のトラフィック」「自動トラフィック」「悪意のあるトラフィック」「カスタムルール」「WordPressの自動処理」の10つに分類して確認できます。
問われるべきことは変わっている
これまでサーバーを評価する際には、稼働率、速度、パフォーマンスなど、主に目に見えるいくつかの指標が重視されてきました。
もちろん、これらの指標は今でも重要ですが、それだけではサイトの状態を十分に判断できなくなっています。
今回ご紹介したように、サイトが正常に稼働していても、帯域幅が無駄に消費されている可能性があります。ページが高速に表示されていても、ボットがPHPスレッドやデータベース接続を消費し、実際の訪問者が利用できるリソースを圧迫しているかもしれません。火曜日の午後には速度テストで良好な結果が出ていても、木曜日にキャンペーンを開始してアクセスが急増すると、サイトの処理が追いつかなくなる可能性もあります。本来そのときに利用できるはずだったリソースの余裕が、ビジネスに貢献しないトラフィックの処理にすでに使われているためです。
今問うべきなのは、単に「サイトがこの負荷に耐えられるか」ではなく、「そもそも、この負荷のうちどれだけをサイトが処理する必要があるのか」という点です。
ボットによるアクセスは、サイトをダウンさせなくてもコストを発生させます。実際の処理を必要とするパスへ大量のアクセスを繰り返すだけで、ダッシュボード上では通常のアクセスに見えながら、リソースを消費し続けます。
状況を変えるには、こうしたトラフィックを可視化し、その内容に応じて対処できる仕組みが必要です。そして、可視化できていたとしても、「すべてブロックする」か「何もしない」かしか選択肢がなければ、適切な対策を取ることはできません。
KinstaのWordPress専用マネージドクラウドサーバーでは、コンテンツ量の多いサイト、WooCommerceストア、多数のクライアントサイトなどを管理する企業向けに、こうした制御機能を追加料金なしですべてのプランに提供しています。環境ごとに設定でき、サポートへの問い合わせも不要です。まずは『AI・ボット時代におけるトラフィックの実態』レポートで、WordPressインフラにどのようなトラフィックが届き、どのようなコストにつながっているのかをぜひご覧ください。
