Googleで優先する情報源に追加
サイトへのアクセスの多くがボットによるものだとわかると、「ブロックしたい」と思うかもしれません。実際、数値によっては早急な対応が必要になる場合もあります。
PatronViewでは最近、1日で360万件のリクエストが発生し、36万以上のIPアドレスからアクセスがあった事例を公開しています。最終的にサイト所有者は、トラフィックを抑えるため、Cloudflareでかなり厳格なルールを設定することになりました。
Kinstaのインフラでも、同じような極端なケースを確認しています。以前公開したAI・ボットに関するレポートでは、あるクローラーが24時間でカート追加URLに375万件のリクエストを送信した事例にも触れています。また、同じ処理を繰り返すループによって数億件ものリクエストが発生し、これを検出するルールを導入したケースもありました。
こうした事例が発生しているのは事実ですが、すべてのサイトで同じような状況が見られるわけではありません。
5,000以上のWordPressサイトを対象とした最新の調査結果では、AIボットが消費する帯域幅の割合は、中央値でわずか1.57%。その一方で、90パーセンタイルでは17.8%、99パーセンタイルでは90.3%に達し、AIボットによる帯域幅の消費がまったくなかったサイトは1,000以上ありました。
これほど大きな差があることから、AIボットからのアクセスがあることと、それが問題になっていることは分けて考える必要があります。
その後の対応次第では、サイトのパフォーマンスや外部サービスとの連携、検索での露出、さらにはAIツールでコンテンツが取り上げられる可能性にも影響します。設定を変更する前に、まずはボットが実際にサイトで何をしているかを確認することが重要です。
この記事では、ボットの挙動を十分に把握しないまま対策を進めることで、サイト運営者が陥りがちな間違いをご紹介します。
間違い1. 割合だけで問題の有無を判断する
サイトへのリクエストの20%がAIクローラーによるものだったとしても、その数字だけでは問題があるかどうかは判断できません。
キャッシュされた記事へのリクエストが多くても、アプリケーションへの負荷は比較的小さい可能性があります。一方、件数自体は少なくても、検索結果や絞り込み後の商品ページ、カートURLなどに繰り返しアクセスされると、はるかに大きな負荷がかかります。
したがって、ウェブ全体のボットに関する統計を個々のサイトにそのまま当てはめるのは避けましょう。
Kinstaの最新調査では、4回の測定で、サイトあたりのAIボットによる1日の平均リクエスト数は667〜928件だったのに対し、中央値はわずか33〜67件でした。また、測定日には約20〜27%のサイトでAIボットからのリクエストが1件もありませんでした。
つまり、一部のサイトにアクセスが極端に集中しており、これが平均値を押し上げています。
そのため、「ウェブトラフィックの半分以上がボット」といったデータや、別のサイト運営者による「トラフィックの99%がボットだった」という事例を目にしても、その数字だけをもとに自分のサイトで必要な対応を判断するべきではありません。
まずは、自分のサイトのトラフィックを確認しましょう。
Kinstaをご利用の場合は、MyKinstaの「ボット対策」画面で、人間の可能性が高いアクセス、検証済みボット、ボットの可能性が高いアクセス、AIクローラー、過剰な頻度でアクセスするAIクローラー、自動トラフィック、悪意のあるトラフィックなど、リクエストがどのように分類されているかを確認できます。
続いて「上位のトラフィック」では、特定のトラフィック分類について、アクセスの多いパス、ユーザーエージェント、国、IPアドレスが表示されます。
何らかのボット対策を講じる前に、まずは以下の基本的な点を確認しておきましょう。
- 実際にどの程度のAIトラフィックがサイトにアクセスしているか
- どのページやエンドポイントにリクエストが送られているか
- どのクローラー、エージェント、その他の自動化システムによるアクセスか
- パフォーマンス、帯域幅、PHPスレッド、実際の訪問者のサイト体験に影響が出ているか
最新のレポートでは、トラフィックの「アクセス量」「パターン」「アクセス元」の3つの観点から分析しています。AIトラフィックが少なく、リクエストにも特に問題が見られないサイトであれば、対策は不要かもしれません。一方、処理負荷の高い動的URLにクローラーが継続的にアクセスしている場合は、より詳しく調査する必要があります。
間違い2. 自動トラフィックというだけですべてのボットをブロックする
現在は、「AIボット」と一口に言っても、その種類やアクセスの目的はさまざまです。モデルのトレーニングやAI検索のために公開コンテンツを収集するクローラーもあれば、ユーザーからのリクエストに応じてページにアクセスするものもあります。
何を許可するかを判断するには、こうした違いを理解しなければなりません。たとえばOpenAIでは、モデルの改善に使用される可能性のあるコンテンツの収集にGPTBotを使用する一方、OAI-SearchBotはChatGPT検索でサイトを見つけられるようにするために使用されます。そのため、OAI-SearchBotをブロックすると、ChatGPTの検索結果にコンテンツが表示されるかどうかに影響する可能性があります。
Anthropicも同様に用途を区別しています。ClaudeBotはモデルのトレーニングに使用される可能性のあるウェブコンテンツを収集し、Claude-SearchBotは検索に使用されます。またClaude-Userは、Claudeのユーザーからのリクエストに応じてウェブサイトにアクセスします。
Perplexityによると、PerplexityBotは検索インデックスの作成に、Perplexity-Userはユーザーからの質問に応じたアクセスに使用されます。
Googleでは、クロールしたコンテンツをGeminiでどのように使用できるかをサイト運営者が制御できるよう、Google-Extendedという個別の設定を提供しています。この設定を変更しても、Google検索への掲載やランキングには影響しないことがGoogleから明示されています。
これらをすべて一括りに「AI」として扱ってしまうと、判断に役立つ重要な情報を見落としてしまいます。
モデルのトレーニングにサイトのリソースを使用されたくない場合は、検索や情報取得を目的とするシステムへのアクセスは許可しつつ、トレーニング用クローラーだけを制限するという選択肢があります。一方、AIエージェントが動的なエンドポイントに繰り返しアクセスしていることが問題なのであれば、トレーニング用クローラーの設定を変更しても解決にはつながらない可能性があります。
ビジネス面での影響も考慮する必要があります。Kinstaが実施した消費者調査では、AIから企業やサービスを推奨された後、「常に」または「ほとんどの場合」その企業のサイトを訪問すると回答した人が44.7%に上りました。AIクローラーのアクセスを許可すれば必ず参照トラフィックにつながるわけではありませんが、すべてを一律にブロックして露出を制限する前に、AI経由でコンテンツが発見される可能性も考慮する価値があります。
Kinstaでは、ボット対策機能の一環として「AIクローラーのブロック」設定も提供しています。これをオンにすることで、GooglebotやBingなどの従来の検索エンジンクローラーは許可しながら、検証済みのものを含むAIクローラーをブロックできます。
なお、注意点として、AIクローラーをブロックすると、AIを活用した検索結果や要約、推奨などでコンテンツが表示されにくくなる可能性があります。
間違い3. AIクローラーの急増をすべてセキュリティ上の緊急事態と捉える
ボットは、ブルートフォース攻撃やDDoS攻撃、認証情報を狙った攻撃などの不正な自動化によってセキュリティ上の問題を引き起こすことがあります。しかし、検証済みのAIクローラーから正規のリクエストが大量に送信されている場合は、別の問題として考える必要があります。
以前開催したボットアクセスに関するウェビナーでは、KinstaのCTOであるDaniel Patakiが、この2つを混同して過剰な対策を講じることについて、「この場合、対応が不十分になることよりも、過剰に反応してしまうことのほうを懸念している。これはセキュリティ上の問題ではない」と説明しています。
これはAIクローラー全般についての発言で、現在問題となっているトラフィックの多くは、攻撃者がサイトへの侵入を試みているのではなく、正規のシステムによる非効率なクロールから発生しているという点を指しています。
ただし、すでにサイトに影響が出ている場合は対応が異なります。ボットによってサーバーリソースが圧迫され、ページの表示が遅くなったり、実際の訪問者がサイトを利用できなくなったりしている場合は、まずサイトを安定させることが最優先です。ボットアクセスが実際に問題を引き起こしている場合には一時的にブロックし、サイトが安定してから原因を調査することが推奨されます。
避けたいのは、何が起きたのかを調査しないまま、この緊急措置を恒久的な対策にしてしまうことです。
Kinstaのボット対策機能では、悪意のあるトラフィックに対する基本的な保護から、自動トラフィックのブロック、より厳格な対策が必要な場合のボットの可能性があるアクセスへの検証まで、複数の保護レベルを利用できます。また、過剰な頻度でアクセスするAIクローラーに対しても検証を行うことができます。
パフォーマンスに突然問題が発生した場合は、一時的に対策レベルを上げる必要があるかもしれません。問題が収まったら、どのようなアクセスがサイトにあったのかを確認し、引き上げた設定をそのまま維持する必要があるかどうかを見直してみてください。
間違い4. リクエスト数だけを見てアクセス先を確認しない
Kinstaのインフラデータを見ると、この違いがよくわかります。キャッシュされたブログ記事へのアクセスも、キャッシュされていないWooCommerceの検索ページへのアクセスも、リクエスト数としてはどちらも1件ですが、後者は通常、サーバー側でより多くの処理が必要になります。
ボットアクセスに関するウェビナーでも使用した以下の例を見てみます。
キャッシュされたページを利用できる場合、WordPressでページを再生成する必要がないため、比較的少ない処理でリクエストに対応できます。
一方、動的なリクエストでは、WordPressがレスポンスを返すまでに、PHPスレッド（ワーカーとも呼ばれる）による処理、データベースへのクエリ、ページの生成、場合によってはセッション処理が必要になります。カートや購入手続きに関するリクエストでは、さらに処理が増えることもあります。
こうしたリクエストが何千件も発生すれば、サーバーにかかる負荷も大きくなります。
最新の調査で行った3回の測定では、人間によるアクセスでは18.3〜18.9%だったのに対し、AIクローラーからのリクエストの76.9〜90.5%が動的コンテンツに向けられていました。
インフラへの負荷を判断するうえでは、単純なリクエスト数だけでなく、どの程度が動的コンテンツへのアクセスなのかを確認することが重要です。
AIボットアクセスの調査で確認された、カート追加URLへのアクセス事例では、あるクローラーは24時間で375万件、約23ミリ秒に1回のペースでリクエストを送信していました。リクエストのたびに、実際には商品を購入することのない「訪問者」のためにWordPressで処理が発生していた可能性があります。
同じ割合のAIトラフィックが発生している2つのサイトでも、その影響が大きく異なるのはこのためです。
クローラーが主にキャッシュされた記事にアクセスするコンテンツサイトであれば、大量のリクエストがあっても大きな問題にはならないかもしれません。一方、WooCommerceストアでは、リクエスト数が少なくても、検索、絞り込み、カート操作、アカウントページなど、キャッシュされていないページへのアクセスが繰り返されると、より早い段階で影響が現れる可能性があります。
アクセスの急増を確認したら、ユーザーエージェントだけでなく、アクセス先も確認しましょう。
MyKinstaでは、「上位のトラフィック」を「AIクローラー」で絞り込み、どのパスへのリクエストが多いかを確認できます。
そのうえで、キャッシュ情報やサーバーの帯域幅、パフォーマンスデータと照らし合わせ、リクエストがアプリケーションまで到達し、実際に処理負荷を発生させているかを確認します。
レポートの上位にGPTBotなどのクローラーが表示されていれば、アクセス元を把握する手がかりになります。しかし、数千件のリクエストが/blog/に送られている場合と、検索結果やパラメータ付きのWooCommerce URLに送られている場合とでは、その意味は大きく異なります。
間違い5. クローラーだけをブロックしてクロールトラップを放置する
ボットは、URL構造にすでに潜んでいる問題を浮き彫りにするだけの存在である場合もありますが、ボットによって、URL構造に以前から潜んでいた問題が表面化することもあります。
WordPressサイトでは、クエリパラメータ、検索ページ、絞り込み後のアーカイブ、ページネーション、カレンダー、商品のバリエーション、ECサイト上の操作などによって、大量のURLが生成されることがあります。
人間であれば、少し異なる2つのURLが実質的に同じページを指していると判断できますが、クローラーには単にクロール対象となる別のリンクとして認識されます。
さらに、それぞれのページから新たにURLが次々と生成されると、クローラーはそれらを辿り続ける可能性があります。その結果、意図せず非常に大量のアクセスが発生します。
以前実施したインフラ調査でも、このような事例は確認されており、ある繰り返しパターンでは、これを検出するために設定した1つのルールだけで、30日間に5億5,000万件のリクエストを除外しました。
クローラーをブロックすれば、目の前の負荷は抑えられるかもしれませんが、クローラーが新しいページを見つけ続ける原因となったURLパターン自体は残ります。
特定のパスへのアクセスがAIクローラーのトラフィックの大部分を占めるようになった場合は、そのパス自体を確認してみてください。
- WordPressで大量のパラメータの組み合わせが生成されていないか
- クローラーがカレンダーやページネーションのURLを際限なく辿れる状態になっていないか
- 検索ページや絞り込みページから何千ものURLパターンが生成されていないか
- カート追加リンクなど、クロールする必要のない操作用URLがクロール可能になっていないか
- 生成されているすべてのURLが本当に必要で、クロール対象にする必要があるか
最終的にクローラーをブロックしたり検証したりする場合でも、まずは何が繰り返しアクセスを引き起こしていたのかを把握することが重要です。
これは特に制作会社にとって重要になります。複数のクライアントサイトで同じプラグイン、WooCommerceの設定、テーマ、URLパターンを使用している場合、同じ問題が複数のサイトで発生する可能性があります。ブロックするボットを次々と追加していくよりも、原因となる挙動そのものを修正するほうが効果的かもしれません。
間違い6. robots.txtを変更すればトラフィックが止まると思い込む
信頼できるクローラーによるサイトの一部または全体のクロールを制限したい場合は、robots.txtの変更が有効なことがあります。ただし、変更後も実際のトラフィックを確認することが重要です。
robots.txtは、クローラーが指示に従うことを前提とした仕組みであり、リクエストがサイトに到達すること自体を物理的に防ぐものではありません。
この違いについてはこちらをご覧ください。robots.txtはクロールに関する希望を伝えるもので、llms.txtはこれを読み取るツールに対して、構造化されたコンテンツのインデックスを提供するものです。実際にアクセスを制限するには、別の仕組みが必要です。
パフォーマンスに問題が発生している場合は、robots.txtを変更しただけで解決したと判断せず、その後も実際のトラフィックを確認することが重要です。
ログやボット分析を確認しましょう。robots.txtを変更した後に対象クローラーからのリクエストが減っていれば、変更が機能したと判断できます。一方、トラフィックが続いている場合や、指示に従わない別の自動化システムからアクセスされている場合は、実際にアクセスを制限できる対策が求められます。
問題がアクセスそのものではなく、リクエストの頻度にある場合も同様です。コンテンツへのアクセスを許可しているクローラーでも、サイトで無理なく処理できる範囲を超える頻度でリクエストを送信する可能性があります。
間違い7. 他のサイトのファイアウォールルールを確認せずにそのまま使う
PatronViewの事例は、実際のサイトデータに基づいて対策を講じている点が参考になります。
PatronViewの利用者は北米に集中しているため、サイト所有者は他の大陸からのアクセスに検証を行っています。また、古いバージョンのブラウザを使用する訪問者を検証対象にする前に、実際の訪問者データを確認しています。さらに、検証対象となった訪問者のうち、実際に検証を通過した割合も監視しています。ある期間では、10万件を超える検証のうち、通過したのはわずか0.24%でした。
こうしたデータがあるからこそ、このサイトではこれらのルールを適用する根拠がありますが、同じ設定を世界各地の顧客が利用するECサイトにそのまま適用すると、正規の顧客まで検証対象になってしまう可能性があります。同様のリスクは、それぞれ単体では有用に見える複数のセキュリティツールを併用する場合にも生じます。
WordPressサイトでは、サーバー側のボット対策、Cloudflareのルール、セキュリティプラグイン、レート制限、国・地域によるブロック、独自のWAFルールなど、複数の仕組みが同じリクエストを判定していることがあります。どのレイヤーで判定されたのかわからない状態では、誤検知が発生した際の原因究明が難しくなります。
Kinstaをご利用の場合は、Kinstaのボット対策機能と独自のボット対策を併用しないことを推奨します。異なる仕組みで判定が競合すると、正規の訪問者や外部サービスとの連携がブロックされる可能性があります。
また、対策レベルを高くすると、API、監視ツール、Webhook、WordPressとの連携など、正規の自動化にも影響する可能性があります。そのためMyKinstaでは、「通常のWordPress自動処理を許可」設定に加え、信頼できるIPアドレス、パス、ユーザーエージェントを常に許可する例外を設定できます。
制作会社の場合は、すべてのサイトに同じルールを適用するよりも、共通の対応手順を決めておくほうが有効です。トラフィックの種類を特定し、アクセス先のパスを確認して、パフォーマンスへの影響を調べ、対策を選択してテストし、その結果を監視するという流れであれば、20のクライアントサイトにも同じ手順を適用できます。
AIボットのトラフィックを確認したらまずやること
まずは、自分のサイトで何が起きているのかを確認しましょう。ボットアクセスが実際の訪問者に影響を与えている場合は、サイトを保護することを優先し、その後、どの程度のトラフィックが発生しているか、どのパスにアクセスしているか、どのシステムによるものかを調査します。
そのうえで、問題を解決するために必要な最小限の変更を行いましょう。robots.txtを更新する、クローラーをブロックまたは検証する、クロール可能なURLパターンを修正するといった対策が考えられます。トラフィックによる問題がなければ、何も変更する必要はありません。
Kinstaをご利用の場合は、こうした調査の多くをMyKinsta上で行うことができます。ボット対策機能の分析データでは、AIクローラー、過剰な頻度でアクセスするAIクローラー、検証済みのボット、自動トラフィックなど、リクエストの種類を分類して確認可能です。また、「上位のトラフィック」チャートで、それぞれのトラフィックについて、アクセス先のパス、ユーザーエージェント、国、IPアドレスを把握することもできます。
さらに、キャッシュの状況、サーバー帯域幅、PHPパフォーマンスと照らし合わせることで、何をブロックするか判断する前に、そのトラフィックが実際にサイトへ負荷をかけているかを確認可能です。
