AIボットによるサーバー負荷対策｜WordPressサイトを守る方法

生成AIの急速な普及に伴い、Webサイトへのアクセスの実態は急激に変化しています。 

なかでも多くのコーポレートサイト、サービスサイトで利用されているWordPressの場合、AIボットによる大量のデータ収集（スクレイピング）は、サイトの表示遅延やサーバーダウンを引き起こす大きな要因となります。

さらに、AWSなどの従量課金やオートスケーリング（自動拡張）を採用しているインフラ環境では、こうした無駄なアクセスによって「サーバー費用が予期せず高騰する」という実害に直結するケースも増えています。

自社のWebサイトを安定して運営し、無駄なコストを抑えるためにも、AIボットへの適切な対策は今や見過ごせない課題です。しかし、AIボットを効率よくブロックするには、システムの専門的な知識や、日々変化するボットの挙動に対する継続的な監視が必要になります。

「自社でそこまで技術的な設定をするのは難しい」「日々の運用リソースが足りない」

そのようにお困りの企業様に代わり、ビークリエイトが責任を持ってこのAIボット対策を代行し、安全でクリーンなサイト環境をお守りいたします。

生成AIの急速な普及に伴い、AIボットによるWebアクセスは爆発的に増加しています。

ホスティング大手のKinstaが100億件以上のリクエストを分析したレポート『AI・ボット時代におけるトラフィックの実態』によると、AIクローラーによるアクセスはこの1年間で300%以上も増加。2025年初頭には「約200回に1回」だったAIボットの割合が、同年末には「31回に1回」にまで跳ね上がっているというデータが示されています。

また、サイトによってはアクセスの過半数をボットが占めているケースも珍しくありません。

これほど急増している背景には、クローラーの種類や目的、挙動が短期間で多様化していることがあります。

例えば、多くのAI開発企業などが「AIモデルの学習」や「RAG（検索拡張生成：最新情報をAIに検索させる技術）」などAI検索サービス向けのインデックス構築のために、あらゆるWebサイトから日々膨大なコンテンツを収集（スクレイピング）しており、自社サイトが知らないうちに巨大な生成AIたちの「学習データや情報源」として24時間体制で激しく巡回されているのが現状です。

通常の静的なWebページ（ブログ記事など）であれば、キャッシュ機能（一度表示した画面を使い回す仕組み）によってサーバーへの負荷は最小限に抑えられます。しかしWordPressには、その仕組み上「どうしてもキャッシュできないページや機能」が多数存在します。

これらのページにAIボットのアクセスが集中すると、サーバーの裏側では次のような「連鎖」が引き起こされます。

①無限ループへの突入：
ボットがサイト内の「検索結果」や「絞り込みURL」を自動生成しながら巡回し、終わりなきループ（クローラートラップ）に陥る。

②プロセスの占有（PHP Workerの枯渇）：
キャッシュが効かないため、アクセスのたびにWordPressが毎回プログラムを動かし、データベース（MySQL）へ問い合わせを行う。これにより、サーバーの同時処理枠（PHP Worker）がボットだけで満杯になる。

③サイトのダウン（504エラー）：
一般のユーザー（顧客）がアクセスしたときには処理能力が残っておらず、ページが表示されない、あるいは「504 Gateway Timeout」などのエラーでサイトがクラッシュする。

つまり、対策なしでは悪意のあるDDoS攻撃（サーバーを狙った攻撃）ではなく、ただの「AIボットの巡回」だけでサイトがダウンしてしまうリスクがある、という点がWordPressの構造的な弱点となっています。

ホスティング大手のKinstaでは、AIボットが引き起こす以下の事例が報告されています。

事例1：24時間で375万回の「カート追加」
あるECサイトに襲来したAIボット（ClaudeBot）が、わずか24時間の間に375万回も「カートに入れる（add-to-cart）」を実行しました。「カート追加」はセッションの生成やDBの更新が同時に走る、サイトにとって最も重い処理の一つです。これを数百万回も繰り返された結果、サーバーは一瞬で限界を迎えました。

事例2：30日間で5億5,000万回のリクエス
別のケースでは、URLの無限ループにハマったAIボットが、30日間で5億5,000万回ものリクエストを送り続けていました。悪意のない「学習のためのクローラー」であっても、設定が不適切なボットはこれだけの超大量アクセスを平然と発生させます。

アクセス数が増えているのに売上や問い合わせに繋がらない、あるいは原因不明のサーバー遅延が起きている場合、こうした「見えないAIボットの暴走」を真っ先に疑う必要があります。

従来の検索ボット（Googleなど）は、サイトを巡回する代わりに「検索経由のアクセス流入」という恩恵を返してくれました。しかし、AI学習ボットの多くはコンテンツを持ち去るだけで、検索エンジンと比較すると、アクセス還元が限定的なケースが多いです。
さらに、これらの巡回プログラムの設計は粗雑なケースが多く、サイト内で以下のような問題行動を引き起こします。

商品検索の絞り込みや記事の並び替えページなどを、すべて「別の新しいページ」と誤認し、同じエリアを何度も不必要に巡回し続けます。

「サイト内検索」や「お買い物カートの処理」といった、サーバーやデータベースに重い処理が発生する画面に対して、短時間に大量のアクセスを集中させます。

AWSなどの環境では、ボットの大量アクセスによってオートスケールが発動し、サーバー台数やデータベースの処理能力が勝手に拡張され、翌月の利用料金が跳ね上がるリスクに直結します。

このように、現在のAIボット対策は「インフラコストの安定」と「サイトの表示速度（ユーザー体験）」を守るための重大な経営課題となっています。 ただし、すべてのボットを画一的にブロックすれば良いわけではありません。

これらを正確に見極め、WordPressサーバーに負荷がかかる手前（入り口）で適切に「交通整理」を行うことが、今強く求められています。

「ボット対策や複雑なセキュリティ設定は難しくてできない」
「セキュリティプラグインを入れてサイトの表示速度を落としたくない」

そんなWordPressサイト運営者様におすすめなのが、高性能ホスティングサービス「Kinsta（キンスタ）」へのサーバー乗り換えです。

Kinstaなら、すべてのWordPressプランに「Bot Protection（ボット対策）」機能が標準で備わっています。設定は管理画面から数秒で完了し、サイトの状況に合わせた4つの保護レベルの切り替えや、AIクローラーの遮断もトグルスイッチ一つで簡単に行えます。

正規の検索ボットを許可する設計のため、SEOへの影響を抑えながら対策でき、手軽にサーバーダウンやコスト高騰の脅威からサイトを解放できます。

「すでに大規模なシステムがあり、サーバーの乗り換えが難しい」
「WordPressではなく、独自のスクリプトや他のCMSでサイトを構築している」

という企業様もご安心ください。

ビークリエイトでは、WordPress以外のサイトや現在のサーバー環境（AWS、国内レンタルサーバー等）において、高度なボット対策の構築・運用を代行いたします。

現在のシステム構成や予算に合わせて無駄なコストを削減し、大切なWebサイトを守り抜きます。「サイトが重い」「身に覚えのない従量課金が増えた」と感じたら、まずは一度当社にご相談ください。