ボット対策プラグインを入れるとき、最初に確認したいのは「攻撃を止められるか」だけではありません。「検知ログが残るか」「正常な操作を妨げないか」「どの情報を根拠に遮断するか」も分けて確認する必要があります。

この記事では、WebDecoy Bot Detectionを使い、ステージング環境で1件の検知を発生させ、WP-CLIで前後の状態を比較します。筆者はWebDecoyの開発者です。紹介するローカル機能は無料・オープンソースで、アカウントやAPIキーは不要です。クラウド連携は任意です。

検証環境と範囲

2026年9月28日に、独立したDocker環境で次の構成を検証しました。

項目	構成
WordPress	7.1
PHP	8.3.33
WebDecoy	2.10.1、GitHubコミット `d386344d65a7487d153125c20705ee594da83a5f`
公開範囲	`127.0.0.1:18079` のみ
モード	`monitor`
クラウド	未接続

これは検知・記録の動作確認です。検知率、誤検知率、性能、WooCommerce決済の互換性を測ったテストではありません。WordPress.orgの配布版とGitHubのコードは更新時期が異なる場合があるため、再現時はバージョンも記録してください。

1. インストールしてモードを確認する

以下は、自分が管理するステージングのWordPressルートで実行する例です。WP-CLIが利用でき、対象サイトのバックアップがあることを前提とします。

wp plugin install webdecoy --activate
wp webdecoy config set mode monitor
wp webdecoy config get mode
wp webdecoy status

すでにインストール済みの場合は、最初の行を省略できます。今回の検証ではGitHubの上記コミットをプラグインとして配置し、wp plugin activate webdecoy で有効化しました。その後のモード設定と状態確認は同じです。

config get mode では monitor を確認します。status では次の項目を記録します。

version：検証対象のバージョン
mode：monitorになっているか
cloud：クラウド未接続か
detections_total：検知記録の総数
active_blocks：有効なIPブロックの数

wp-config.php の WEBDECOY_DEFAULT_MODE でモードが固定されている場合、CLIからの変更は拒否されます。設定が変更できたと決めつけず、出力を確認してください。

monitorモードは検知結果を記録し、プラグインによる遮断を適用する前に評価するためのモードです。ただし、コード実行やデータベースへの記録は行うので、性能や他のプラグインとの相性の確認は必要です。

2. 自分のテスト環境に1リクエストを送る

今回の環境には実際の .env ファイルを置いていません。プラグインの既定のトリップワイヤー対象パスへのリクエストを使いました。

TEST_BASE='http://localhost:18079'
curl -sS -A 'python-requests/2.31' \
  -o /dev/null -w 'HTTP %{http_code}\n' \
  "$TEST_BASE/.env"

このURLは検証用の例です。自分が管理する隔離環境に合わせて変更してください。第三者サイトや実際の秘密情報を置いたパスでは試さないでください。認証、キャッシュ、WAFなどでWordPressへの到達が止まる環境では、このテストだけでプラグインの動作を確認できません。

3. HTTPステータスと検知結果を分けて読む

リクエスト後にもう一度確認します。

wp webdecoy status

今回、curlの結果は HTTP 301 でした。一方、WP-CLIで確認した値は次のように変化しました。

項目	リクエスト前	リクエスト後
`mode`	monitor	monitor
`detections_total`	0	1
`active_blocks`	0	0

さらに保存レコードには、tripwire_rule フラグと /.env のパスメタデータがありました。

HTTPステータスだけで「未検知」「遮断成功」と判定しないことがポイントです。301などの応答は、アプリケーションや配信経路の別の処理でも発生します。逆に検知数の増加だけで、そのリクエストが遮断されたとも言えません。今回確認したのは「対象リクエストの記録が増え、IPブロック数は増えなかった」という結果です。

管理画面のWebDecoy検知ログでも、テスト時刻、User-Agent、検知フラグを照合します。並行して別のアクセスがあるサイトでは、総数の差だけでは自分のテストと結び付けられないので、個別レコードを確認してください。IPアドレスやUser-Agentだけで利用者本人を特定することもできません。

4. 正常な操作も確認する

検知できたことと、本番で遮断を有効にしてよいことは別の判断です。monitorのまま、サイトで使う操作を確認します。

管理者と一般ユーザーのログイン
会員登録、パスワード再設定、コメント投稿
キャッシュやCDNを経由した通常の閲覧
WooCommerce利用時は、テスト用決済環境でカートから注文完了まで

共有IPやリバースプロキシがある場合は、ログに記録されるIPの解釈にも注意が必要です。正常な操作と検知が重なる場合は、理由と設定を確認してから対応範囲を決めます。この段階では遮断を有効にする必要はありません。

試用を終了する場合は、次のコマンドでプラグインを停止できます。

wp plugin deactivate webdecoy

無効化とアンインストールは異なります。このコマンドをログの削除手段として扱わないでください。

参考資料

今回の手順が確認するのは、検知を発生させ、モードと記録を照合するところまでです。利用中のテーマやプラグインを含めた評価は、そのサイトのステージングで行ってください。