AI・ボット時代における
トラフィックの実態
100億件のリクエストと制御不能なクローラー。WordPressインフラの分析から見えてきた、新時代のボットアクセスの実態を紐解きます。
このレポートでわかること
今日、サイトトラフィックのかなりの割合を「人間以外」が占めているのをご存じですか？その結果、アクセス解析だけでは、実際にサイトで起きていることが見えにくくなっています。
「AIクローラーはすべてブロックするべき」という声もあれば、「AI時代には避けられない」という声もあります。さまざまな意見やアドバイスが行き交っていますが、WordPressサイトを実際に運用する立場では、いずれも役に立ちません。
この1年で、ボットアクセスは単なるセキュリティやSEOの問題を超え、インフラの問題になっています。クローラーは動的URLへアクセスし、クエリ文字列のループに陥り、キャッシュを回避しながら、通常のインデックスとはかけ離れた、大規模で制御不能なアクセスパターンを生み出しています。
主な調査結果
何が変わったのかを理解するために、業界調査をもとに分析を行い、エンジニアや実務担当者へのヒアリングを実施。さらに、Kinstaが管理するインフラ全体で100億件を超えるリクエストを分析しました。そこから見えてきたのは、「すべてをブロックする」か「すべてを許可する」かではなく、状況に応じて適切に判断していくことの重要性でした。
有識者の見解
“インフラの観点では、『単なるボットアクセス』というものは存在せず、すべてのリクエストが実際の処理負荷になる。非効率なクロールは、規模が大きくなるにつれて、単なるトラフィックの問題から、リソースの問題に変化する。”
“現在起きている問題の多くは、悪意のある攻撃ではない。ボットが大規模かつ非効率に動作していることが本当の問題。”
“ボットアクセスを単純な『ブロックするか許可するか』の問題だと考えてしまうのは誤り。実際にはポリシー、可視性、そしてコスト管理の問題。”
問題はボットの増加ではなく、
その「挙動の変化」にある
ボットアクセスをめぐる議論は長年、その「量」に焦点が当てられてきました。
どれだけのアクセスが自動化されているのかを追跡し、明らかに悪質なボットを除外して完了といった対応が一般的でした。実際、多くのボットがページをクロールし、コンテンツをインデックスした後に離脱するだけだった頃は、それでも十分に機能していました。
しかし、この2年間で、検索結果のインデックスだけでなく、モデル学習やRAG（検索拡張生成）、ユーザーからの問い合わせ処理のために、大量のコンテンツを収集するボットが急増しています。こうしたクローラーは、これまでのものよりも大量にアクセスし、速度も速く、挙動もはるかに制御しづらくなっています。
そして、2025年後半には、Cloudflareネットワーク上のHTMLリクエストのうち4.2%をAIクローラーが占めるように。さらにGooglebotなどを含めると、その割合は8.5%に達しています。同時に、サイト運営者や管理者の間では、従来のクロールとは明らかに異なる挙動も見られるようになりました。繰り返されるリクエスト、ループ、そして価値の低いURLへの大量アクセスです。
この数値は年間平均で、実際には4月上旬の2.4%から6月下旬には6.4%まで増加しており、1年の中でも約3倍の変動があった。GPTBot単体でも、2024年5月から2025年5月の間に305%増加している。また、AIクローラーによるアクセスの80%は、検索やユーザー向け機能ではなく、モデル学習のみを目的としたもので、そこからサイトへの流入は発生しない。
Cloudflare Radar 2025 Year in Review
Googlebot単体だけでも、HTMLトラフィックの約4.5%を占めており、これはGoogle以外のAIボット全体を上回る規模。また、GPTBotの3.6%に対し、Googlebotはユニークなウェブページの11.6%をクロールしている。2025年4月下旬には、GooglebotによるHTMLリクエストは全体の11%に達した。サーバー負荷を理由にGooglebotをブロックすることは、サイト運営者にとって最も逆効果な判断のひとつと言える。
Cloudflare Radar 2025 Year in Review
この変化の本質
多くのボットは攻撃ではなく、
単にループに陥っている
ほとんどのAIクローラーは、見つけたリンクをすべて辿り、固有のURLを記録するように設計されています。この仕組みは、シンプルなサイトでは問題なく機能します。しかし、現代のサイト、特にECサイトでは、実質的には同じページでも、わずかに異なるURLが大量に生成されます。
例えば、meta-externalagent（Facebook / MetaのAIクローラー）は、複数のサイトでクエリ文字列のバリエーションを繰り返し巡回していました。色違いの商品リンク、数量付きのカートURL、並び順が変わったカレンダーページは、人間から見ればどれも同じページです。しかし、URLだけを辿るボットは、そのすべてを別ページとして認識します。
ボットは最初のリンクを辿り、その先で生成された別バージョンのURLへアクセスします。そしてさらに別のURLへアクセスし、同じことを延々と繰り返します。こうした巡回が同じ場所を回り続けていることに、ボット自身は気づけません。実際、インフラ側のルールによって検知されるまで、数日間続いていたループもありました。
こうした挙動は、必ずしも高度なシステムによって引き起こされているわけではありません。
「中には、昨日まで何をしているのかも分かっていなかった人が、ノリで作って公開したようなボットもある。robots.txtすら確認していないことも珍しくない」とCloudflareのDavid Belson氏。
24時間以内にadd-to-cart URLへ送られた767万件のリクエスト
ブロックできないGoogleのクローラーでさえ、同じ罠にはまっています。
375万件のリクエストは、24時間を通して約23ミリ秒ごとに1回のアクセスが発生していた計算になります。さらにそのすべてがキャッシュ可能なリクエストではなく、サーバー側で毎回新しいリクエストとして処理されていました。
大規模になると、こうした挙動は必ずしも悪意によるものとは限りません。
「とにかく大量に投げればいい、というものではない。責任あるユーザーとして振る舞う必要がある。サイトに対して無差別に大量のリクエストを送り続けるべきではない」とCloudflareのDavid Belson氏は述べています。
サーバーはボットを区別できない
すべてのリクエストが軽量に処理できれば、ループや繰り返しアクセスも大きな問題にはなりません。そのため、挙動そのものに問題があるわけではありません。
シンプルな静的ページであれば、多くのリクエストはキャッシュから配信できます。サーバーは保存済みのページを返すだけなので、1リクエストあたりの負荷も低く抑えられます。
しかしこの前提は、実際のWordPressサイトではすぐに崩れてしまいます。特にWooCommerceや検索機能、フィルター機能、多数のプラグインを利用しているサイトでは顕著です。
多くのアクセスは、静的ページではなく、以下のようなURLへ送られています。
これらは通常のページのようにキャッシュできず、アクセスのたびにサーバー負荷が発生します。
リクエストごとに発生する処理
すべてのリクエストに対して、PHPスレッド（ワーカー）が処理完了まで専有されます。ボットによる高負荷状態が続くと、スレッドはすぐに枯渇し、通常ユーザーのアクセス待ちが発生します。
動的ページでは、アクセスのたびにデータベースへの問い合わせが発生します。こうした負荷は、大規模になるとキャッシュだけでは吸収できません。
カートや決済ページでは、アクセスごとにセッションの作成や検証が行われます。購入につながらないボットアクセスであっても、サーバー負荷は発生します。
SEOへの影響
これは攻撃なのか、通常のボットアクセスなのか、それともその中間なのか。こうした曖昧さが、対応を難しくしています。同じパターンがパフォーマンスと可視性の両方に影響する以上、何を守るべきかによって、取るべき対応も変わってきます。
何を優先するか
ボットの挙動や、それがもたらす影響を目にすると、「すべてブロックすればいいのでは？」と思うかもしれません。しかし、無差別にボットを遮断することが正解ではありません。かといって、完全に開放してしまうのも違います。
「まず必要なのは、誰を通し、誰を通さないのかを判断する『ドアマン』を置くこと」とBelson氏。
すべてのボットが有害なわけではなく、すべてのトラフィックを同じように扱うべきでもありません。サイトの発見性を高めるボットもあれば、価値を生まないままリソースだけを消費するボットも存在します（そしてその中間に位置するものも）。
インフラの観点から見ても、ボットの完全排除は好ましくありません。「一部のボットには価値があることから、すべてのボットをブロックするべきではない」とBelson氏も述べています。
今求められているのは、「ボットは善か悪か」を単純に判断することではありません。それぞれの選択がサイトにどんな影響を与えるのかを理解し、どこで折り合いをつけるのかを見極めることが重要です。
HostingAdvice編集長のCristian Lopez氏は、「ボットアクセスを単純な『ブロックするか、許可するか』の問題だと考えること自体が誤解。今や問題は、ポリシー、可視性、コスト管理にある」と指摘しています。
発見性とパフォーマンス
検索クローラーは、ユーザーがサイトを見つけるうえで欠かせない存在ですが、常に効率よく動作するとは限りません。過剰にブロックすれば検索結果での可視性が低下し、逆に無制限に許可すれば、不要なサーバー負荷を招くことになります。特に、キャッシュでは処理できない動的ページへのアクセスが増えると、その影響は顕著になります。
どちらか一方を選ぶことではなく、実際のサイトの挙動に応じて、どこまで許可するのかを調整することが重要です。
アクセスとリソースコスト
AIシステムによるコンテンツ参照、ページのインデックス、ウェブ全体のデータ収集など、一部のボットは間接的な価値をもたらします。その一方で、すべてのリクエストはCPU使用率、データベースクエリ、メモリ、帯域幅といったコストを伴います。アクセスが大規模になるにつれ、その負荷は無視できるものではなくなり、サイト運営へ目に見える影響を与え始めます。
すべてのアクセスを無制限に許可する必要はありません。ボットがもたらす価値と、それによって発生するコストを比較しながら判断しましょう。
コントロールとシンプルさ
単純なケースであれば、自動化だけでも十分にボット管理を行えますが、適切な対応は、サイトの種類、発生しているトラフィック、そして何を重視するのかによって変わります。自動化に全面的に頼れば管理はシンプルになりますが、その一方で、自分のサイトに合わせた判断基準を持ちにくくなります。
理想は、「シンプルさ」と「コントロール」を両立できること。まずはシンプルに始めながら、必要な部分だけ調整できる仕組みが重要です。
こうした要素が重なることで、判断はより複雑になります。トラフィックの急増やパフォーマンス低下が起きても、それをブロックするべきなのか、許可するべきなのか、それとも無視してよいのかは簡単には判断できません。同じパターンであっても、サイトによって最適な対応は異なります。
「ボットを許可するべきか？」
「どのボットを、サイトのどの部分で、どの条件下で許可するか？」
この問いに答えるには、これまでとは異なる視点が必要になります。次のセクションで、その考え方を整理していきましょう。
許可・検証・ブロック
を判断するための新しい考え方
すべてのサイトに通用する万能なボットポリシーは存在しません。WooCommerceサイト、コンテンツサイト、企業サイト、ステージング環境では、それぞれ抱えるリスクも必要な対策も異なります。
適切な対応は、サイトの役割、どのようなトラフィックを受けているのか、そして何を重視するのかによって変わります。多くの場合、こうした判断はインフラ側の仕組みによって自動的に行われていますが、そのロジックを理解しておくことで、自分のサイトで何が起きているのか、そしてどこで調整すべきなのかが見えてきます。
ここで重要なのは、単なるトラフィック量ではありません。検索順位を重視するのか、AIによる引用を重視するのか、それとも実際のユーザー流入を重視するのか。どのような可視性を求めるのかによって、取るべき対応も変わってきます。
パフォーマンス低下の原因は、ボットがWooCommerceのadd-to-cartやチェックアウト関連URLにアクセスしていることかもしれません。これらのリクエストはページキャッシュを完全に回避し、アクセスのたびにPHP実行とデータベースクエリを発生させます。すべてをブロックするのではなく、負荷の高い特定のパスを保護しましょう。
/cart、/checkout、?add-to-cart= は robots.txt でクロール対象から除外する。/shop?add-to-cart= と /checkout へのクロールをすべてのクローラーに対して禁止する。/shop、/product/、カテゴリページをクロールできる必要があります。制限する場合はサイト全体ではなく、特定の動的URLのみに絞りましょう。上でご紹介している設定は、ボットアクセス対策を手動で行う場合の一例です。こうしたパターンの大部分は、実際にはKinstaのボット対策機能によって自動処理されます。保護レベルを一度設定すれば、あとはシステム側で対応が行われるため、パスごとのルール設定や手動での例外管理は不要です。
多くのシステムは、
ここまでの柔軟性を備えていない
多くのプラットフォームでは、ボットアクセスを裏側で自動的に処理するか、あるいは手動設定を前提とした管理機能を提供しています。
自動化されている仕組みは、明らかな脅威を検知し、既知のクローラーを許可することはできますが、サイト内のどこで、どのような挙動が発生しているのか、そしてそれがどれほどの負荷やコストにつながっているのかまでは考慮できません。場合によっては、正規のAIクローラーがエッジ側でブロックされ、サイト運営者が気づかないまま可視性を失っているケースもあります。
一方、手動設定には柔軟性がありますが、その多くは継続的な管理を前提とした高い精度が求められ、現実的には対応しきれないことも少なくありません。さらに、適切な指針がなければ、設定ミスも起こりやすくなります。
不足しているのは単なる制御機能ではなく、「実際に使いこなせる制御」。
理想なのは、必要な部分だけを柔軟に調整できることです。重要なトラフィックを損なうことなく、変化があるたびにゼロから対策を見直す必要もありません。
ほとんどのサイトに必要なのは、完全自動化でも完全な手動管理でもなく、トラフィックパターンが変化するたびに戦略全体を見直すことなく、必要な部分だけを柔軟に調整できることです。
今の課題は、ボットアクセスを見つけ出すことではなく、実際のサイト運営に合わせて、どう管理していくかにあります。
取るべき対応は状況次第
ここまで見てきたように、すべてのケースに当てはまる万能なルールは存在しません。適切な対応は、どのようなサイトを運営しているのか、どのようなトラフィックが発生しているのか、そしてどれほど緊急性が高いのかによって異なります。
ここから先は、単なるチェックリストではなく、今の状況に合わせて次の一手を考えていきます。
まずは可視化し、その上で1つだけ対策を講じる
設定を変更する前に、まずは実際のトラフィックの内容を確認します。すべてのボットを特定する必要はなく、どのようなアクセスパターンが発生しているかを見つけることが重要です。たとえば、カートURLや大量のパラメータを含むURLなど、本来クローラーが頻繁にアクセスする必要のないページに、繰り返しリクエストが送られていないかを確認します。通常、分析ツールやサーバーログだけでも十分に傾向を把握できます。
多くのプラットフォームでは、明らかなループや既知の悪質トラフィックなど、典型的な異常パターンをすでに自動でフィルタリングしています。まずは、そうした基本的な保護機能が有効になっているかを確認し、その効果を見てみましょう。これらは通常、正規ユーザーや検索クローラーへの影響を抑えながら、不要なノイズを減らすよう設計されています。
パターンが見えてきたら、そのパターンに対してのみ対策を行います。すべてを一度に制御しようとする必要はありません。たとえば、ボットが動的URLへ繰り返しアクセスしているのであれば、そのパスだけを制限し、特定のクローラーが過剰にコンテンツを収集しているのであれば、そのアクセスに見合う価値があるかを判断します。この段階では、完璧な対策にこだわらず、新たな問題を増やさずに不要な負荷を減らすことに集中しましょう。
複数のクライアントサイトで試してみると効果的です。ECサイト、コンテンツサイト、サービスサイトでは、それぞれ異なるパターンが見えてきます。またその一方で、共通する傾向もあるため、クライアントへの提案や説明に活用できる、再現性のある判断基準を作っていくことができます。
AI・ボット時代に求められるのは、
それに適応できる戦略
ここまで見てきたように、ボットアクセスの存在は、もはや一時的なノイズとして片付けられるものではありません。エッジ側で単純にフィルタリングして終わる問題でもなく、ウェブサイトへのアクセスと負荷のあり方そのものを変えつつあります。
問題を複雑にしているのは、単純なトラフィック量だけではなく、サイトの発見性を高める仕組みが、同時にリソースを消費する存在にもなっていること。そして、一見すると通常のクロールに見えるアクセスが、大規模になると非効率な自動化トラフィックとして振る舞うことです。
だからこそ、すべてのサイトに通用する単一のルールは存在しません。
最善の対策は、サイトの種類、発生しているトラフィック、そして何を守りたいのかによって変わります。そのためには、自分のサイトで実際に何が起きているのかを理解し、その現実に合わせて判断しなければなりません。
こうした変化は、ウェブの進化の中で初めて起きているわけではありません。「SSLもかつては長い間有料オプションのような存在だったが、今ではほぼすべてのサーバープランに標準で含まれている」とHostingAdvice寄稿者のJordan Sprogis氏は述べています。
多くの場合、不要な負荷を減らし、必要な可視性を維持しながら、変化に対応できる仕組みを保つことが鍵になります。そして、これから先のトラフィックは、さらに分類が難しくなっていきます。すでに、行動を実行するために設計された自動化ツール、いわゆるエージェント型トラフィックが、インフラデータにも現れ始めています。Googleも最近、AIエージェントがサイトへアクセスした際に記録するための専用ユーザーエージェントを発表しました。適切に運用されているプラットフォームであれば、自らを識別できる形で運用し、クロール間隔を守りながら、不要なURLへの過剰アクセスを避けますが、そうではないものも存在します。人間のアクセスとエージェントによるアクセスの境界は、今後さらに曖昧になっていきます。
また、自動化トラフィックによって訪問数が水増しされる時代では、単純なアクセス数だけでは実態を把握できなくなります。本当に重要になるのは、ブランド検索数、ダイレクトトラフィック、エンゲージメントの質、そして実際のユーザー行動に紐づいた収益など、実際の成果と連動している指標です。そうした数値も一緒に伸びているのであれば、本当に価値のある場所でサイトが見つけられていると言えます。
検索可視性を損なうことなく、WordPressサイトへのボットアクセスを制御
Kinstaのボット対策機能は、環境単位での柔軟な制御を可能にしながら、適切なデフォルト設定も提供。検索エンジンをブロックしたり、サイトの発見性を損なったりすることなく、ボットアクセスを状況に応じて管理できます。
本レポートは、Kinstaが制作・公開しています。
Kinstaは、世界23万以上のサイトが利用するWordPress専用の高性能マネージドサーバーです。レビューサイトG2ではユーザー満足度No.1を獲得。日本語にも対応する専門サポートは24時間365日ご提供しています。
他のメンバーにも共有しませんか？
WordPress専用マネージドクラウドサーバー