WordPressでボットを除外する設定方法｜UA判定・ハニーポット・レート制限の多層対策

ボットトラフィックの混入 — なぜ今、除外設定が必要なのか

WordPressで運営するBtoB企業サイトでは、アクセスログの相当数をボットが占めているケースが少なくありません。以前は検索エンジンのクローラーが主な対象でしたが、近年はAIを活用したスクレイパーや悪意のある自動巡回ツールが急増しており、適切な除外設定を行わないままでいると、複数の業務上のリスクにつながります。

アクセス解析の数値が信頼できなくなるケース

ボットが混入したアクセスデータは、マーケティング施策の判断精度を落とします。たとえば、特定のランディングページのセッション数が急増しても、その大部分がボットによるものであれば、コンテンツ改善や広告予算の配分に誤った根拠を与えてしまいます。直帰率・平均滞在時間・コンバージョン率といった指標も歪むため、Google Analyticsのデータを正しく読み取れない状態に陥りやすくなります。WordPress上でアクセス解析ツールを運用する場合、ボットの除去は計測精度を保つための前提条件です。

AIクローラー・スクレイパーが増加している背景

大規模言語モデル（LLM）の学習データ収集を目的としたAIクローラーが、2023年以降に急速に増えています。これらは従来の検索エンジンクローラーと異なり、robots.txtを無視するものも確認されています。BtoB企業のオウンドメディアや製品ページは情報密度が高く、スクレイピングの標的になりやすい傾向があります。サーバーリソースを消費するだけでなく、コンテンツを無断で学習データとして利用されるリスクも伴います。

チャットボットや問い合わせフォームへの誤作動リスク

自動送信ボットは、問い合わせフォームやチャット機能にも到達します。スパム送信によって担当者の対応コストが増加するだけでなく、AIチャット機能を搭載したプラグインでは、ボットの起動が利用上限のトークン数を無駄に消費する原因にもなります。月間の利用枠を人間ではないアクセスに費やすことは、直接的なコスト損失につながるため、ボット対策はサイト運営コストの最適化とも切り離せない課題です。

ボットの種類と挙動の整理 — 何を除外すべきかを判断するための前提知識

ボットの除外設定を進める前に、まず「どのボットを除外すべきか」を整理しておく必要があります。一口にボットといっても、サイト運営に欠かせない正規のものから、即座にブロックすべき悪意あるものまで、性質は大きく異なります。種類ごとに対応方針を明確にしておくことが、適切な設定判断の前提となります。

許容すべきボット — Googlebot・BingBotなど正規クローラー

検索エンジンのクローラーは、サイトをインデックスするために定期的にアクセスします。代表的なものとして、GoogleのGooglebot、MicrosoftのBingBotが挙げられます。これらはUser-Agent（UA）情報を正直に開示しており、逆引きDNSで実際のIPアドレスを確認することも可能です。SEOの観点からアクセスを許可することが基本方針となります。アクセス解析ツール側では計測対象から除外しつつ、サイトへのアクセス自体はブロックしないことが重要です。

除外・ブロックすべきボット — スパム・スクレイパー・ブルートフォース

以下のボットは、計測の汚染または直接的なセキュリティリスクにつながるため、優先的に対処が必要です。

• スパムボット：お問い合わせフォームやコメント欄に自動で迷惑投稿を行います。
• スクレイパー：コンテンツや価格情報を無断で大量収集します。サーバー負荷の原因にもなります。
• ブルートフォースボット：WordPressのログイン画面（wp-login.php）に対して、パスワードを総当たりで試みる不正ログイン試行です。

グレーゾーンのボット — AIクローラー・SNSプレビュー・監視ツール

対応判断が難しいボットも存在します。たとえば、OpenAIやAnthropicが運用するAIクローラーは学習目的でコンテンツを収集しますが、SEOへの貢献はありません。SNSのOGPプレビュー生成ボット（FacebookやSlackなど）は人間の操作に紐づいており、完全な自動アクセスとは性質が異なります。また、死活監視やパフォーマンス計測に使う外部監視ツールも、自社が意図して動かしているボットです。これらは一律にブロックするのではなく、目的・リスク・計測への影響を踏まえて個別に判断することが求められます。

UA判定によるボットフィルタリング — User-Agentを使った識別と除外の設定手順

User-Agentとは何か — ボット判定の基本的な仕組み

User-Agent（UA）とは、WebブラウザやクローラーがWebサーバーにアクセスする際に送信する、自己申告型の識別文字列です。たとえばGoogleのクローラーであれば Googlebot、BingであればBingbotといった文字列がUAに含まれます。サーバーはこの文字列を読み取ることで、アクセス元がどのようなソフトウェアかを判定できます。

ボットフィルタリングにおいてUA判定が基本とされるのは、設定が比較的シンプルで、既知のクローラーや悪質なスクレイパーを素早く識別・除外できるためです。ただしUAはあくまで自己申告であり、偽装（スプーフィング）が容易という構造的な限界も持っています。

.htaccessを使ったUA判定とアクセス遮断の記述例

Apache環境のWordPressサイトであれば、.htaccess にRewriteCondディレクティブを記述することで、特定のUAを持つアクセスをサーバーレベルでブロックできます。以下は代表的な記述例です。

• 悪質なスクレイパーの遮断例：RewriteCond %{HTTP_USER_AGENT} (scrapy|curl|wget|python-requests) [NC,OR] のように複数のUA文字列をOR条件で列挙し、RewriteRule .* - [F,L] でアクセスを403（Forbidden）で返します。
• 特定クローラーのみ許可する場合：Googlebotなど正規クローラーのUAをホワイトリストとして定義し、それ以外の未知のボットをまとめて拒否する方針も取れます。

WordPressの場合、プラグインを使う方法も現実的です。WP Cerber や Wordfence といったセキュリティプラグインはUA判定によるブロック機能を備えており、管理画面から文字列を登録するだけで設定が完了します。技術担当者が不在でも運用しやすい点がメリットです。

UAスプーフィングへの対応 — UA判定だけでは防げないケース

UA判定の最大の弱点は、UAが自己申告に過ぎないことです。悪意のあるボットの多くは、GooglebotやChrome等の正規UAに成りすますUAスプーフィングを行います。この場合、UA文字列だけを根拠にしたフィルタリングはすり抜けられてしまいます。

こうしたケースに対応するには、IPアドレスの逆引きDNS検証（Googlebotであれば googlebot.com ドメインから発信されているか確認する）や、後述するハニーポット・レート制限との組み合わせが必要になります。UA判定は対策の起点として有効ですが、単独で完結する手法ではありません。複数の判定軸を重ねることで、実効性のあるボット除外が実現できます。

ハニーポットによるボット検知 — 人間には見えないフィールドで自動送信を検出する

ハニーポットの仕組み — 不可視フィールドへの書き込みでボットを識別する

ハニーポットとは、フォームに人間には見えない入力フィールドを仕込み、そこに値が入力された送信をボットと判定する手法です。CSSでdisplay:noneまたはvisibility:hiddenを指定したフィールドは、通常のブラウザ操作では表示されません。人間のユーザーはそのフィールドの存在に気づかないため、値を入力することはありません。一方、フォームのHTMLを機械的に解析して自動送信するボットは、非表示フィールドにも値を書き込む傾向があります。この差異を検知することで、追加の認証を挟まずにボットを識別できます。

Contact Form 7・WPFormsでのハニーポット設定手順

WordPressの主要フォームプラグインでは、比較的容易にハニーポットを導入できます。

• Contact Form 7：「Honeypot for Contact Form 7」プラグインを追加インストールし、フォームのショートコードに [honeypot honeypot-field] を挿入するだけで設定が完了します。
• WPForms：有料版（Pro以上）の設定画面に「スパム対策」タブが用意されており、ハニーポットのオン・オフをトグルで切り替えるだけで有効化できます。コード編集は不要です。

いずれも設定後の動作確認として、別ブラウザや自動化ツールで空送信テストを行い、ハニーポットフィールドへの書き込みがあった送信が確実にブロックされているかを確認しておくことが望ましいです。

reCAPTCHAとハニーポットの使い分け — UX影響と検知精度の比較

reCAPTCHA（特にv3）は高い検知精度を持つ一方、外部スクリプトの読み込みによりページ表示速度に影響するケースがあります。また、v2では「私はロボットではありません」のクリックや画像選択が発生し、ユーザーに操作負荷をかけます。ハニーポットはサーバー側の処理のみで完結するため、ユーザー体験への影響がほぼありません。ただし、近年の高度なボットはJavaScriptを実行して非表示フィールドを識別し、書き込みを回避するケースも報告されています。このため、問い合わせフォームのようにスパムリスクが高い箇所にはreCAPTCHAとハニーポットを併用し、一般的なコンテンツページへのアクセス制御にはハニーポット単体で対応するといった使い分けが現実的です。

レート制限によるアクセス制御 — 短時間大量アクセスをブロックする仕組み

スパムボットやスクレイパーは、短時間に数十〜数百件のリクエストを送り続けるという特徴的な挙動を示します。UA判定やハニーポットでは捕捉しにくいこの挙動に対して有効なのが、レート制限（Rate Limiting）です。一定時間内のアクセス数に上限を設け、超過した接続元を自動的にブロックする仕組みです。

レート制限の考え方 — しきい値の設定と正規ユーザーへの影響

しきい値の設定は「正規ユーザーを誤ってブロックしない」ことを前提に行います。一般的には、同一IPから1分間に30〜60リクエストを超えた場合にブロックするケースが多いです。ただし、チャットボット機能を実装したページでは、1ユーザーあたりのリクエスト数が増えやすいため、エンドポイント別に上限値を分けて設定することが推奨されます。

Cloudflareを使ったレート制限の設定手順

CloudflareのRate Limitingは、管理画面から直感的に設定できます。手順は以下の通りです。

1. Cloudflareダッシュボードで対象ドメインを選択し、「セキュリティ」→「WAF」→「レート制限ルール」を開く
2. 対象URLのパス（例：/wp-login.php や /contact/）を指定する
3. しきい値（例：60秒間に50リクエスト）とアクション（ブロックまたはチャレンジ）を設定する
4. ルールを保存し、ログで誤検知がないか確認する

無料プランでは利用できない機能のため、Pro以上のプランが必要です。

WordPress向けセキュリティプラグイン（Wordfence・SiteGuardなど）での設定

サーバー側の設定が難しい場合は、プラグインでの対応が現実的です。Wordfenceでは「Firewall」→「Rate Limiting」から、ログイン試行やクローラーのリクエスト数を制限できます。SiteGuard WP Pluginは国内環境向けに最適化されており、ログインページの保護に強みがあります。いずれも管理画面から設定が完結するため、サーバー知識が限られた担当者でも導入しやすい選択肢です。

Google Analyticsでのボット除外 — 計測データを正確に保つための設定

サーバーレベルでのブロックが難しいボットであっても、アクセス解析ツール側でフィルタリングすることで、計測データへの影響を最小限に抑えられます。ここではGA4（Google Analytics 4）を使った除外設定の手順と、その意義を整理します。

GA4の「内部トラフィックの除外」設定手順

GA4では、自社からのアクセスやボットによる流入を除外するために「内部トラフィックの定義」機能を利用します。設定手順は以下のとおりです。

1. GA4管理画面の「管理」→「データストリーム」→対象ストリームを選択
2. 「タグ付けの詳細設定」→「内部トラフィックの定義」を開く
3. 除外したいIPアドレスを登録し、traffic_typeパラメータに「internal」を設定する
4. 「管理」→「データフィルタ」で「内部トラフィック」フィルタを「有効」に切り替える

この設定により、登録したIPアドレスからのセッションがレポートから除外されます。自社オフィスのIPだけでなく、ボットのアクセス元として確認されたIPアドレスも同様に登録できます。

IPアドレスフィルタとUAフィルタの組み合わせ方

GA4単体の機能ではUser-Agent（UA）ベースのフィルタを直接設定できません。そのため、UAによる除外はサーバー側（.htaccessやnginx設定）またはWordPressプラグインで先に処理し、そもそもGAのトラッキングコードを発火させない構成が理想です。

一方、IPフィルタはGA4側で有効に機能します。既知のクローラーやスクレイピングツールのIPレンジが判明している場合は、GA4の内部トラフィック定義に追加することで、計測データへの混入を防げます。両方を組み合わせることで、漏れのない多層的なフィルタリングが実現します。

計測データの正確性が経営判断に与える影響

ボットトラフィックが混入したアクセスデータは、直帰率・セッション数・コンバージョン率といった主要指標を歪めます。たとえば、ボットによる大量アクセスが原因でセッション数が水増しされると、コンバージョン率が実態より低く見え、施策の評価を誤るリスクがあります。

Webサイトの改善投資や広告予算の配分は、こうした計測データをもとに意思決定されます。サーバー側のブロックとGA4側のフィルタリングを併用する多層対策は、単なる技術的な整備ではなく、経営判断の前提となるデータ品質を守るための取り組みとして位置づけることが重要です。

多層対策の組み合わせ方 — 規模・目的別の推奨構成

各手法の限界と補完関係 — なぜ単一対策では不十分なのか

UA判定・ハニーポット・レート制限・GA4フィルタのいずれも、単独では対処できない領域があります。それぞれの限界を整理しておきます。

• UA判定：既知のボットは排除できますが、UAを人間のブラウザに偽装した高度なボットは素通りします。
• ハニーポット：フォーム送信型のボットには効果的ですが、フォームを操作しないクローラーやスキャン系ボットには機能しません。
• レート制限：短時間の大量アクセスを遮断できますが、間隔を空けてアクセスするボットや、正規ユーザーと同じ頻度で動くものは検知が困難です。
• GA4フィルタ：計測データの精度は上がりますが、サーバーへの負荷やフォームへの不正送信そのものは防げません。

これらを組み合わせることで、一方の手法が取りこぼしたボットを別の手法が補足できる構造になります。完全な排除は難しいケースがほとんどですが、多層化によって対応できる範囲は大幅に広がります。

規模・運用体制別の推奨構成一覧（表）

以下に、BtoB企業サイトの規模・運用体制別の推奨構成をまとめます。

優先して導入すべき対策はどれか — 最低限の構成から始める考え方

リソースが限られている場合は、GA4フィルタとハニーポットの2点から始めることをお勧めします。GA4フィルタはWordPressの設定変更を伴わず、計測精度をすぐに改善できます。ハニーポットはContact Form 7などの主要プラグインに標準搭載されているものも多く、追加コストなしで導入できるケースがあります。

その後、UA判定やレート制限はサーバー環境やプラグイン構成を確認しながら段階的に追加するのが現実的な進め方です。WordPress上でのボット除外設定は、一度にすべてを実装しようとすると運用の負担が増えます。最小構成で効果を確認しながら、必要に応じて対策を重ねていく方針が長続きしやすいです。

AIチャット機能を持つWordPressプラグインにおけるボット除外の実例 — Site Conciergeの設計から見える考え方

AIチャットプラグインがボット対策を必要とする理由

一般的なフォームやページビューへのボット混入は、計測精度の問題にとどまります。しかしAIチャット型のWordPressプラグインでは、ボットの誤応答が直接コストに影響します。

CLANEが提供するWordPressプラグイン「Site Concierge」は、サイト上のコンテンツをAIが読み込み、訪問者の質問に自動応答するコンテンツ連動型のチャットプラグインです。AIの応答処理にはAPIコールが発生するため、月ごとの利用上限が設定されています。この構造において、ボットがチャットインターフェースにアクセスして応答をトリガーしてしまうと、本来の訪問者向けの処理枠が意図しない形で消費されていきます。

WordPress上で動作するチャット機能は、ページ読み込み時にスクリプトが起動するため、クローラーやスクレイピングボットがページを巡回するだけで誤作動が起きるケースも少なくありません。利用上限の無駄消費は、サービスの応答品質低下や想定外のコスト増加に直結します。

UA判定と利用上限管理を組み合わせた設計の考え方

Site ConciergeではUser-Agent（UA）情報を参照し、既知のボットからのリクエストをフィルタリングする設計を採用しています。Googlebot・Bingbotといった主要検索エンジンのクローラーをはじめ、一般的なボットのUAパターンを判定対象とし、チャット機能の起動処理そのものを行わないよう制御しています。

この設計には二つの意図があります。一つは利用上限の保護です。AIへのAPIコールをボット分だけ削減することで、実際の訪問者に対して処理枠を確保します。もう一つはログの精度維持です。チャットの利用状況ログにボット由来のデータが混入すると、どのコンテンツが訪問者の疑問を引き起こしているかという分析の精度が落ちます。

AIチャットプラグインを運用する場合、ボット対策はセキュリティの問題だけでなく、運用コストと分析品質の問題でもあります。UA判定による除外を利用上限管理と組み合わせて設計することが、安定した運用の前提条件になります。

まとめ — WordPressボット除外設定の要点と対応順序

WordPressサイトへのボットトラフィックは、アクセス解析の歪みとセキュリティリスクという二つの問題を同時に引き起こします。対策を整理すると、除外すべきボットは「悪意あるスクレイパー・スパムボット」と「過剰クロールする自動巡回ツール」の二種類に大別されます。一方、GooglebotなどのSEO上有益なクローラーは除外対象から外す判断が必要です。

各手法の役割は以下のとおりです。

• UA（User-Agent）判定によるフィルタリング：既知の悪質ボットを入口でブロックする第一線の対策
• ハニーポット：フォームへの自動送信を検出し、スパムボットを識別する手法
• レート制限：短時間の大量アクセスをIPレベルで遮断し、DoS的な負荷を防ぐ
• Google Analyticsのボット除外設定：計測データの純化を目的とした後処理の仕組み

推奨する組み合わせは、サイトの規模と目的によって異なります。小規模サイトであればUA判定とAnalyticsの除外設定だけでも一定の効果が得られます。フォームを持つBtoBサイトにはハニーポットの追加が有効です。アクセス数が多いメディアや会員制サービスでは、レート制限まで含めた三層構成が現実的な選択肢になります。

対応の優先順位としては、まずAnalyticsの設定変更から着手するのが最も低コストです。次にプラグインを活用したUA判定とハニーポットを導入し、それでも不審なアクセスが続く場合にレート制限を追加するという順序が、リスクと工数のバランスを保ちやすい進め方です。