2025年には、ウェブトラフィック全体の53%をボットが占め、年間を通じて自動化されたトラフィックが人間によるトラフィックを初めて上回りました。2026年6月には、Cloudflare Radarによるとその割合は57.5%に達しており、CloudflareのCEO自身も、当初の予測より数年早くこの逆転が起きたと述べています。
しかし、実際にWordPressサイトを運営している中で、この変化はなかなか可視化されません。ダッシュボードには特に異常がなく、アクセス数が順調に伸びていても、その数字を押し上げているトラフィックには、顧客や見込み客ではないものが含まれている可能性があります。その正体は、言語モデルに取り込むコンテンツを収集するAIクローラーです。従来の検索エンジンのボットとは比較にならないほどの頻度と規模でコンテンツをクロールしています。
今回は、AIクローラーによるアクセスが従来のクローリングとは異なる形でWordPressサイトに影響を及ぼす理由と、そのトラフィックを特定し、MyKinstaから直接対処する方法をご紹介します。
AIクローラーとは？
AIクローラーとは、一般公開されているウェブページを自動で読み取り、そのコンテンツをAIシステムで利用するために収集するボットです。一見、従来の検索エンジンクローラーと同じように見えますが、その目的は異なります。
Googlebotなどの検索クローラーは、ページをインデックスして検索順位を決定するために読み取り、ユーザーがそのページを見つけられるようにします。その一方で、AIクローラーは同じページを読み取り、その内容を言語モデルや学習モデルに取り込みます。これには、主に以下のような種類があります。
- 学習クローラー（GPTBotやClaudeBotなど）：大規模言語モデルの学習に使用するテキストを収集
- 検索クローラー：最新情報を必要とする質問がAIツールに入力された際に、リアルタイムでページの情報を取得
- インデックス作成クローラー：サードパーティへの依存を減らすため、AIプロバイダ独自の検索データベースを構築
これらの共通点として、サイトへの訪問者の流入にはつながりません。また、AIクローラーの識別方法はさまざまであるため、その動きを予測するのは容易ではありません。明確なユーザーエージェントを使用し、公開されているIPアドレス範囲内で動作するAIクローラーもあれば、正規のブラウザのユーザーエージェントを流用したり、アクセス元のIPアドレスを切り替えたり、確実に識別できる情報を一切提供しなかったりするものもあります。
AIクローラーによるトラフィックは発信元の特定が難しい上に、急速に増加しています。Cloudflareの2025 Radar Year in Reviewによると、Googlebot以外のAIクローラーはHTMLリクエスト全体の平均4.2%を占め、4月の2.4%から6月には6.4%まで増加しました。現在では検索インデックス作成とAIモデルの学習の両方を目的にクロールするGooglebotを加えると、2025年にはAI関連のクローリングがHTMLリクエスト全体の約8.7%に達しています。
検索エンジンクローラーが確立したクロールの慣習
この変化を理解するには、従来のクローリングがどのような「取り決め」のもとで行われてきたかを知ることが重要です。検索エンジンによるクローリングには、サイト所有者がそれを前提に運用計画を立てられるよう、共通の慣習が存在していました。Robots Exclusion Protocolが1994年に登場し、2022年にはインターネット標準として正式に策定されました。このプロトコルを中心に、従来のクローラーを想定したインフラ構築を可能にする、以下4つの慣習が定着していきました。
robots.txtの遵守：クローラーはこのファイルを読み取り、アクセスが禁止されているパスを確認して、その領域をクロールしないようにする。- 自動的なクロール頻度の調整：主要なクローラーは、サーバーに負荷がかかっていることを検知するとクロール頻度を下げるため、サイトの処理能力が低下しているときにはリクエストが増えるのではなく、減少する。
- 一貫した識別情報：安定したユーザーエージェントを使用することで、クローラーを検証し、それぞれにどのように対応するかを判断できる。
- 「クロールバジェット」の範囲内での動作：Googleは、サイトのクロールバジェットを、Googlebotがクロール可能かつクロールを希望するURLの集合と定義しており、これにより1つのサイトが際限なくクロールされることが防止される。
これに関連する概念として、クローラーがページへのリクエストと次のリクエストの間に待機する時間を意味する「Crawl-delay（クロール間隔）」というものがあります。ただし、これは非公式のディレクティブであり、Googleではサポートされておらず、正式な標準にも含まれていません。その代わり、Googlebotはサーバーの応答状況に応じてクロール頻度を自動的に調整します。つまり、サーバーへの負荷が高まると、クローラー側でアクセス頻度を抑える仕組みになっています。
こうした慣習は、サーバーの仕組みにも組み込まれています。たとえば、適切に動作するクローラーは同じページにある程度予測可能な形でリクエストを送るため、キャッシュからコンテンツを配信できることを前提にキャッシュレイヤーが機能します。このモデル全体は、クローラーがルールを守って動作するという前提の上に成り立っています。
AIクローラーが従来の慣習に従わない点
AIクローラーは、主に以下の3つの点で従来とは異なるルールで動作しています。
robots.txtを必ずしも遵守しない：TollBitのレポートによると、robots.txtのディレクティブを無視するボットが大幅に増加している。同レポートでは、明示的にアクセスを禁止しているサイトのコンテンツに、大手AI検索プロバイダがアクセスしていたことをCloudflareが検出した事例も報告されている。- アクセス頻度を自動調整しない：多くのAIクローラーは、サーバーの応答状況にかかわらず、一定の高い頻度でリクエストを送信する。こうした動作は必ずしも意図的なものではなく、
robots.txtへの対応などを十分に考慮せず、AIを使って手軽にボットを構築し、そのまま稼働させているケースもある。 - クローラーがループに陥る：これは悪意によるものではなく、クローラーの仕組みそのものから生じる、リソース消費の大きな問題。多くのクローラーは、見つけたリンクをすべてたどり、一意のURLをそれぞれ別のページとして記録する。AIクローラーがあるURLのバリエーションをたどると、そこからさらに別のバリエーションが生成され、それを再びたどるという動作が繰り返される。クローラー自身には同じところを巡回しているという認識がないため、ループが続いてしまう。
さらに問題なのは、AIクローリングの大部分が検索やユーザーからの質問への回答ではなく、モデルの学習を目的としていることです。そのため、クローリングされてもサイトへの参照トラフィックは発生しません。
AIクローラーがサーバーのパフォーマンスに影響を与える理由
ここで問題になるのは、単純なトラフィック量ではありません。たとえば、キャッシュから配信される静的ページはサーバーにほとんど負荷をかけないため、1,000件のアクセスがあっても、その影響はごくわずかです。問題は、キャッシュを経由しないトラフィックが発生したときです。ループに陥ったクローラーは、このような経路を見つけて繰り返しアクセスする傾向があります。
WooCommerceを使用するWordPressサイトでは、検索や絞り込みなどのリクエストの多くが、通常のページではなく動的なURLに送信されます。代表的なものとして、カート操作、?add-to-cart=パラメータを含むURLのバリエーション、絞り込み後の商品ページ、検索クエリ、admin-ajax.phpを経由するAJAXによる処理などがあります。これらはブログ記事のようにキャッシュできないため、リクエストが届くたびにサーバー側で処理が発生します。
- PHPの実行：各リクエストの処理が完了するまで、1つのPHPスレッドが占有される。ボットからの大量のリクエストが続くと、利用可能なスレッドが枯渇し、実際の訪問者はボットの処理が終わるまで待機することになる。
- データベースクエリ：動的ページでは、クエリを吸収するキャッシュレイヤーがないため、ページが読み込まれるたびにデータベースへのアクセスが発生する。
- セッション処理：カートや決済ページでは、リクエストのたびにセッションの作成または検証が行われる。購入することのないボットからのアクセスであっても、サーバーに余分な負荷がかかる。
Kinstaのインフラデータでは、ある1つのボットが24時間でadd-to-cart URLに375万件ものリクエストを送信した事例が確認されています。これは、24時間休むことなく約23ミリ秒に1回のペースでリクエストを送信していた計算になります。その結果、使用量の異常な増加、帯域幅の超過、PHPプロセスの枯渇、実際の訪問者に対する応答時間の低下などが発生します。一方で、アクセス自体は攻撃ではなく通常のクローリングのように見えるため、問題を見落としやすいという厄介な側面があります。
MyKinstaでAIクローラーのアクティビティを特定する方法
設定を変更する前に、まずクローラーが原因であることを確かめる必要があります。MyKinstaの場合は3つの確認方法があり、これらを組み合わせることで、推測ではなく実際のデータに基づいて原因を特定できます。
まず、MyKinstaで「サイト」＞（サイト名）＞「ボット対策」に移動します。この画面の「リクエストの内訳」グラフには、過去24時間にサイトに送信されたすべてのリクエストと、それぞれがKinstaによってどのように分類されているかが表示されます。
「過剰アクセスAIクローラー」カテゴリを確認することで、サイトのパフォーマンスに影響を与えるほど大量のリクエストを生成しているボットを特定できます。グラフの大部分をこのカテゴリが占めている場合、アクセス増加の原因は実際の読者ではなく、クローラーによる負荷である可能性が高いと言えます。
サイトの「分析」画面の「ボットアクセス」タブに表示される「ボット対策状況」グラフでは、トラフィックがどのように処理されたかを、「許可」「チャレンジ」「ブロック」に分けて確認できます。これにより、現在どの程度の自動トラフィックがサイトまで到達しているのか、また、サイトに到達する前にどの程度がフィルタリングされているのかを把握できます。2つのグラフをあわせて確認することで、クローラーによる負荷がすでに適切に処理されているのか、それともそのままサーバーまで到達しているのかを判断できます。
トラフィックとサイトの速度低下に関連性があるかを確認するには、同じ「分析」画面の「位置情報とIP」タブの「上位クライアントIP」を確認できます。
このセクションでは、サイトに最も多くのリクエストを送信しているIPアドレスを確認できます。各IPアドレスにはIP検索サービスへのリンクがあり、アクセス元を調べることができます。最後に「パフォーマンス」タブを開き、応答時間が急増している時間帯と、クローラーからのアクセスが集中している時間帯を照らし合わせます。リソース使用量とボットのトラフィックが連動して増減している場合は、受信トラフィックを制御する必要があると判断できます。
Kinstaのボット対策でAIクローラーを管理する方法
トラフィックの発生元を特定したら、Kinstaのボット対策を使用して、トラフィックのカテゴリごとに処理方法を設定することができます。この機能は、明らかに悪意のあるトラフィックを除外する既存のプラットフォームレベルの防御機能に加えて利用でき、すべてのプランに標準搭載されています。
MyKinstaの「ボット対策」画面にある「対策レベル」セクションでは、以下の4つの設定から任意のものを適用することができます。
- 悪意のあるトラフィックをブロック：デフォルトの設定。DDoS攻撃を軽減し、既知の攻撃元に関連するIPアドレスやアクセス先をブロック。
- 自動トラフィックをブロック：自動化されたことが確認されたトラフィックをブロックする保護レイヤーを追加し、検証済みのボットと実際の訪問者からのアクセスは許可。
- ボットを検証：ボットの可能性が高いトラフィックを検証。一度検証に成功した訪問者は、同じブラウザとIPアドレスを使用している限り、その後10日間は再度検証受けることはない。
- すべてのトラフィックを検証：最も厳しい対策レベルで、検証済みのボットのみアクセスを許可。トラフィックが急増している際に、一時的に使用するための設定。
「ボットを検証」以上の対策レベルでは、自動的にサイトへアクセスするツールのうち、Cloudflareの検証済みボット一覧に登録されていないものは、検証またはブロックの対象になります。そのため、対策レベルを引き上げる前に、サイトの運営に欠かせないツールがこの一覧に含まれていることを確認してください。
Kinstaでは、Cloudflareの検証済みボット一覧に独自のルールを追加しています。これにより、検証済みのAIボットであっても、大量のリクエストを生成するものは「過剰アクセスAIクローラー」という別のカテゴリに再分類されます。
これは、クローラーの認証情報ではなく、その挙動に基づいて判断するための仕組みです。つまり、検証済みのボットであっても、サイトに大量のリクエストを送り始めれば、問題のあるトラフィックとして扱われます。対策レベルを「ボットを検証」以上に設定すると、正当な高トラフィックのサービスには検証の機会を与えながら、ループに陥ったクローラーなどを除外できます。
MyKinstaのその他のボット対策機能
「AIクローラーのブロック」設定は、対策レベルとは別に設定できる機能で、GPTBotなどの検証済みボットを含むAIクローラーをブロックできます。GooglebotとBingbotによるサイトのインデックス登録には影響しないため、検索結果でのサイトの可視性を維持しながら、AIクローラーによる負荷を軽減できます。
robots.txtを自分で編集したり、ボットごとに個別のルールを管理したりするよりも手軽な方法ですが、有効にする前にその影響を検討することが重要です。
AIクローラーをブロックすると、AIが生成する回答や要約にコンテンツが表示される機会が減少します。AIツールが一部のユーザーにとって重要な情報発見チャネルになりつつあることを考えると、AIクローラーを完全にブロックすることは、サーバー負荷の軽減以外にも影響を及ぼします。
WooCommerceストア、トラフィックの多いコンテンツサイト、会員制サイトなど、パフォーマンスを重視するサイトでは、AIクローリングによるリソース消費が大きい一方で得られるメリットは小さいため、問題が発生している場合はブロックが有効な選択肢になります。一方、AIプラットフォーム上での露出を重視するコンテンツ中心のサイトでは、対策レベルを「自動トラフィックをブロック」または「ボットを検証」に設定することで、特に問題のある動作を抑えながら、AIプラットフォームによるコンテンツのインデックスを許可できます。
どの設定が適しているかは、サイトの用途や優先事項によって異なります。「AIクローラーのブロック」設定は、サイトの状況に応じて必要かどうかを判断してオンにしてください。
対策を強化すると、サイトの運営に必要な自動トラフィックまで対象になる可能性があります。そのため、必要なトラフィックを引き続き許可するための設定が2つ用意されています。「常に許可」セクションでは、IPアドレス、パス、またはユーザーエージェントを指定して、最大50件の例外を追加できます。監視サービス、決済Webhook、信頼できるオフィスやクライアントのIPアドレスなど、検証の対象にすべきでないものをここに登録してください。
また、「通常のWordPress自動処理を許可」をオンにすると、REST APIやバックグラウンドタスクなど、WordPressで一般的に使用されるエンドポイントやサービスが、管理された許可リストに追加されます。
プラグイン、外部サービスとの連携、定期実行タスクなどで自動リクエストが発生するサイトでは、対策レベルを強化する際にこの設定も有効にすることで、既存の処理や連携が意図せず機能しなくなるのを防ぐことができます。
新たなウェブクローリングの時代には、よりきめ細かな管理が必須
インターネット上のクローリングのあり方は変化していますが、すべてのサーバー環境が必ずしもそれに対応しているとは限りません。AIクローラーは、検索エンジンが20年以上かけて築いてきたルールに従うとは限りません。robots.txtを遵守せず、一定の高い頻度でクロールを続けることもあります。さらに、消費されたリソースに対して、サイトへのトラフィックという見返りが得られるわけでもありません。その結果、実際にはクローラーが原因であるにもかかわらず、サイト自体のパフォーマンスが低下しているように見える、パフォーマンスとコストの問題が発生します。
Kinstaのボット対策はシンプルで、すべてMyKinsta上で管理できます。まず、MyKinstaの分析機能で原因を確認。次に、適切なボット対策レベルを設定し、「AIクローラーのブロック」をオンにして、検索結果での可視性を維持しながらAIクローラーによる負荷を軽減します。さらに「常に許可」を使用して、必要なサービスやツールを保護し、設定を強化しても信頼できる連携が機能し続けるようにします。いずれの変更もサイトのダウンなしで反映されるため、トラフィックの傾向に応じて設定を調整できます。
多数のクライアントサイトを管理している場合は、Kinstaのエージェンシーパートナープログラムをご利用いただくことで、こうした管理機能に加えて専任サポートもご利用いただけます。サイトのトラフィックを効率的に管理するなら、KinstaのWordPress専用マネージドクラウドサーバーもぜひご覧ください。
