前回、GA4で中国からのアクセスが突然増え、Xserverのアクセスログまで調べたところ、BytespiderというUser-Agentを含む自動アクセスを確認しました。
ここで次に疑問になったのが、
「ボット対策はしたい。しかし、クローラーを全部止めてもよいのか？」
という点です。
そこで今回は、AI Business Labを運用しているXserverの管理画面で、WordPressセキュリティ、WAF、AIクローラー遮断、アクセス拒否、.htaccessなどを実際に確認しました。
最終的には、AIクローラーを一括遮断するのではなく、まずWAFを段階的に有効化し、その後のアクセス状況を観察する方針にしました。
この記事で分かること
- Xserverで利用できる主なセキュリティ機能
- WAFとボット遮断の違い
- AIクローラー遮断を今回はONにしなかった理由
- アクセス拒否や.htaccessをすぐ使わなかった理由
- ボット対策を段階的に進める考え方
まず「何を防ぎたいのか」を整理した
前回アクセスログを見て分かったのは、Webサイトには人間だけでなく、GooglebotやApplebotなどさまざまなクローラーが来ているということでした。
そのため、
Bot＝不正アクセス
とは限りません。
今回防ぎたいのは、検索などに必要なクローラーそのものではなく、サイトへ悪影響を与える不審な通信や攻撃、不要な大量アクセスです。
そこで「とにかく全部遮断する」のではなく、まずXserverにどんな機能があるのかを確認しました。
WordPressセキュリティ設定は国外アクセス対策にも使える
XserverにはWordPress専用のセキュリティ設定があり、国外からのダッシュボードやログイン画面へのアクセス制限などを設定できます。
Xserverも、国外からの /wp-admin や /wp-login.php への接続を制限する機能について、通常はONでの運用を強く推奨しています。
ただし今回の目的は、
「中国から来たアクセスをすべて拒否する」
ことではありません。
国単位のアクセスと、実際に問題となるリクエストは分けて考える必要があります。
WAFは「ボット全部を止める機能」ではない
次に確認したのがWAFです。
WAFは「Web Application Firewall」の略で、Webアプリケーションの脆弱性を狙う攻撃からサイトを保護する仕組みです。
XserverではXSS、SQLインジェクションなど、複数の攻撃パターンに対する設定が用意されています。Xserver自身も、WAFはWordPressなどの安全性向上に利用できる一方、すべての不正アクセスを完全に防ぐものではないと説明しています。
つまり、
WAF＝不正なリクエストや攻撃への防御
であって、
WAF＝すべてのBotを遮断
ではありません。
今回この違いを理解できたことは大きな収穫でした。
WAFは一気に変更せず段階的に有効化した
セキュリティ設定を見ると、「全部ONにした方が安全そう」と考えたくなります。
しかし今回は一度に変更せず、段階的に有効化することにしました。
理由は、設定変更後にWordPressやサイトの機能へ影響が出た場合、どの変更が原因なのか分からなくなるからです。
一つ変更する。
サイトを確認する。
問題がなければ次へ進む。
この方法なら、問題が起きたときにも原因を切り分けやすくなります。
なおXserverでは、WAFの設定変更後、反映まで最大30分程度かかる場合があると案内されています。
AIクローラー遮断設定も確認してみた
今回特に興味深かったのが、XserverのAIクローラー遮断設定です。
この機能は2026年1月に提供が開始され、ドメイン単位でON・OFFを切り替えられます。初期状態はOFFです。
対象には、
GPTBot、OAI-SearchBot、ClaudeBot、Google-Extended、PerplexityBot、Bytespiderなど、多数のAI関連クローラーが含まれています。
つまり、前回アクセスログで確認したBytespiderも、この機能の遮断対象に入っています。
それでもAIクローラーを一括遮断しなかった理由
Bytespiderだけを見れば、
「AIクローラー遮断をONにすればよいのでは？」
と思いました。
しかし遮断対象を見ると、BytespiderだけではなくOAI-SearchBotなどもまとめて対象になります。
さらにXserverの機能ガイドでは、この設定を有効にすると、生成AIの回答で情報源として紹介・引用されなくなる可能性があると案内されています。(レンタルサーバー 高速・高機能・高安定性の【エックスサーバー】)
AI Business Labとしては、検索エンジンだけでなく、今後AI検索やAI回答から記事が発見される可能性も残しておきたいところです。
そのため今回は、
一つの不審なクローラーを止めるために、AI関連アクセスをまとめて遮断する
という判断はしませんでした。
アクセス拒否と.htaccessも確認した
Xserverには、指定したIPアドレスからのアクセスを拒否する機能があります。また、.htaccessも管理画面から編集できます。
ただ、今回確認したBytespiderらしきアクセスは複数IPから発生していました。
一つずつIPを拒否しても、別のIPから来れば繰り返し対応が必要になります。
.htaccessを使えばより細かな制御もできますが、設定を誤ればサイト表示などへ影響する可能性があります。
そこで今回は、Xserverが標準で提供している管理画面上のセキュリティ機能を先に使うことにしました。
今回の方針は「観測→対策→再観測」
最終的に今回採用したのは、
アクセスログで状況を確認
↓
WAFを段階的に有効化
↓
サイトに問題がないか確認
↓
GA4・アクセスログを再確認
という流れです。
設定したら終わりではありません。
Bytespiderらしきアクセスが続くのか、GA4の中国アクセスはどう変わるのか、サイト表示やWordPressに問題がないかを引き続き確認します。
必要であれば、その段階でAIクローラー遮断、IP拒否、.htaccessなど次の方法を検討します。
まとめ
今回Xserverの設定を確認して分かったのは、ボット対策には一つの万能なスイッチがあるわけではないということでした。
WordPressセキュリティはログインなどへの不正アクセス対策。
WAFはWebアプリケーションへの攻撃対策。
AIクローラー遮断はAI関連クローラーのアクセス制御。
アクセス拒否や.htaccessは、より個別的なアクセス制御。
それぞれ役割が違います。
今回私は、AIクローラーを一括遮断せず、まずWAFを段階的に有効化して観察することにしました。
Webサイトを守ることは大切ですが、検索やAIなど必要な情報流通まで閉じてしまえばよいわけではありません。
観測する → 正体を調べる → 必要性を判断する → 対策する → 再び観測する。
今回の設定作業を通じて、ボット対策も一度設定して終わるものではなく、データを見ながら調整していく運用の一部だと理解できました。
※本記事は2026年9月時点のXserver公式情報と、AI Business Labで実際に確認・実施した内容をもとに整理しています。機能や遮断対象は変更される可能性があるため、設定時はXserverの最新マニュアルをご確認ください。
