大東 信仁（ものくろ） 
WordPress のログイン画面に、Cloudflare のロボットチェックを付けたい。
あの「人間ですか？」を確認してくれるやつ、Turnstile（ターンスタイル）です。
（最初、名前が出てこなくて、Claude Code に「トランスリートだったっけ、あのロボットチェックするやつ」と聞いてました）
簡単に設定できるプラグインがあるのかな、と思って相談したら、
プラグインは要らなかったんですよね。
このブログは、もともと Cloudflare を通して配信しているので、Cloudflare の管理画面で「カスタムルール」を1本作るだけで済みました。無料プランのままで。
設定したあとに見えた数字が、ログイン画面と xmlrpc.php へのアクセスが、30日で115.93k。
約11.6万件。
ほとんどがボットらしいです。
プラグインを探すつもりが、Cloudflare 側で済む話だった
相談すると、Claude Code が最初に mono96.jp のネームサーバーを調べ始めまして。
Cloudflare 経由で配信されているのが分かると、「それなら WAF のカスタムルールで、ログイン画面にマネージドチャレンジを出すのが簡単」という提案でした。
マネージドチャレンジは、中身は Turnstile と同じロボット判定の仕組みらしい。
ちなみに、プラグインで設定するなら、定番は Simple Cloudflare Turnstile。
ただ、Claude が調べたところ、このプラグインは2026年に入ってから、CAPTCHA のすり抜け、コンテンツの注入、ショートコードの実行といった脆弱性が、いくつも報告されている様子。修正版は 1.42.3 以降とのことです。
ロボット対策のプラグインに脆弱性があるのは、ちょっと困りますよね。
なので、プラグインを増やさずに済む Cloudflare 側の設定を選びました。
無料プランでできるのか？も気になったので確認してもらうと、無料プランでもカスタムルールは5本まで作れて、マネージドチャレンジも選べる、とのこと。
実際、管理画面にも「カスタム ルール 0/5 rules」と表示されていました。
設定は、カスタムルールを1本作るだけ
Cloudflare のダッシュボードで、対象のドメインを開く。
左のメニューの「セキュリティ」→「セキュリティ ルール」を開く。
「カスタム ルール」の「ルールを作成」をクリック。
ルール名は、わかりやすく「ログインWAF」にした。
「受信リクエストが一致する場合…」の欄に、次の式を入力する。
(http.request.uri.path eq "/wp-login.php")
式を入れると、その条件に一致したリクエスト数が表示されます。
wp-login.php だけで、36.69k。最後の30日で、全トラフィックの1.0%。
1日あたり、約1,200回。
このほとんどは、パスワードを総当たりで試しているボットらしいです。
アクションは「マネージドチャレンジ」を選ぶ。
ステータスは「アクティブ」のまま。
「デプロイ」を押すと、「ルールを本番環境にデプロイしますか？」と確認が出るので、もう一度「デプロイ」。
これで、設定は完了です。
xmlrpc.php も一緒に止めた
ここで Claude から、ログイン画面だけだと、まだ入口が残っている、という指摘がありまして。
xmlrpc.php という、ログイン画面を通らずにパスワードを試せる入口があって、ここも狙われやすいらしい。
なので、条件に「または（OR）」で xmlrpc.php を追加した。
(http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")
一致したリクエストの総数は、115.93k。全トラフィックの3.2%。
差し引きすると、xmlrpc.php だけで約7.9万件。
ログイン画面より、xmlrpc.php の方が狙われていたんですよね。
ただし、Jetpack や WordPress 公式アプリ、外部の投稿ツールで xmlrpc.php を使っている場合は、止めると動かなくなるので注意。
（僕は WordPress 公式アプリを使いたかったので、ここから先にも続きがありました。その話は、別の記事に書きます）
ちゃんと効いているかの確認
設定のあと、Claude Code がコマンドで確認してくれました。
wp-login.php と xmlrpc.php は、どちらも「403」と「cf-mitigated: challenge」が返ってきて、確認ページが出る状態。
トップページは、いつもどおり「200」で普通に表示される。
読者が見るページには、影響なし。
自分で確認するときは、スマホのモバイル回線（Wi-Fi は切る）で、シークレットウィンドウから wp-login.php を開くのが確実です。「確認中…」のページを通ってから、ログイン画面に進めばOK。
ここで1つ、Claude から注意がありまして。
Cloudflare の「IP アクセス ルール」で「許可」にしている IP アドレスがあると、そこからのアクセスにはカスタムルールが効かないらしいんですよね。
なので、許可している回線から試すと、確認ページが出なくて「効いていない？」と勘違いしてしまう。
設定するときの注意点
wp-admin/admin-ajax.php は、ルールに含めない方がいいです。サイトの表側の機能が動かなくなることがあるらしい。
REST API（/wp-json/）も止めない。ブロックエディターや公式アプリが使っています。
（このブログの下書きも、REST API 経由で Claude Code に入れてもらっています。この記事もそうです）
それと、この設定で守れるのは、ログインの入口だけ。
プラグインやテーマの脆弱性を突いてくる攻撃は防げないし、確認ページは人間なら通れます。
強いパスワード、2段階認証、プラグインのこまめな更新は、引き続き必要です。
設定を間違えたときは、Cloudflare の管理画面でルールを「無効」にすれば、すぐ元に戻せます。
まとめ
WordPress のログイン画面のボット対策は、サイトが Cloudflare を通っているなら、プラグインを入れなくても、無料プランのカスタムルール1本でできました。
wp-login.php と xmlrpc.php に、マネージドチャレンジ。
月に約11.6万件のアクセスが、サーバーに届く前に止まるようになりました。
プラグインを探す前に、Cloudflare の管理画面を見てみるのがオススメです。
お試しください。
