Cloudflare の WAF を設定する方法｜マネージドルール・カスタムルール・レート制限と、WordPress で誤検知を避ける手順

Cloudflare の WAF 設定は、マネージドルールを有効にする → ログイン画面などにレート制限を掛ける → 必要なところだけカスタムルールで補う → Security Events で誤検知を確かめて直す、という順番で進めると迷いません。WordPress サイトなら、攻撃の大半が集まる wp-login.php と xmlrpc.php の 2 か所を先に守るだけでも効果があります。

結論を先にまとめます。

• Cloudflare の WAF は「マネージドルール」「カスタムルール」「レート制限ルール」の 3 種類のルールでできています。使えるルールセットや本数はプランによって違います（2026年11月現在、Free プランではマネージドルールは Free Managed Ruleset のみ、カスタムルール 5 本、レート制限 1 本）。
• 新しいルールはまず「ログ」や「Managed Challenge」のような弱い動作で入れ、Security Events で正当なアクセスが止まっていないか見てから「Block」に上げます。
• 誤検知は「スキップルール（例外）」か「上書き（override）」で、ルール単位に絞って直します。マネージドルール全体を切らないことが大切です。
• Cloudflare 経由にすると、サーバー側のログの接続元 IP が Cloudflare の IP になります。WordPress 側で実 IP を復元しないと、国別制限やログイン制限が正しく働きません。

Cloudflare の WAF とは

Cloudflare の WAF（Web Application Firewall）は、Cloudflare を通過する HTTP リクエストを「ルールセット」と照らし合わせ、攻撃と判断したものを遮断したり、確認（チャレンジ）を求めたりする仕組みです。ルールは Cloudflare の Rules 言語で書かれ、接続元 IP、URL のパス、ヘッダー、リクエストボディなどを条件にできます。

マネージドルールのうち Cloudflare Managed Ruleset は Cloudflare のセキュリティチームが保守する中心のルールセットで、OWASP Core Ruleset は OWASP ModSecurity Core Rule Set を Cloudflare 流に実装したものです。OWASP の方は 1 つのルールで判定せず、一致したルールの点数を足し合わせ、しきい値を超えたときに動作します。そのため大きなリクエストボディを送るフォームで誤検知が出やすい、という性質があります。

Free プランの Free Managed Ruleset は「影響が大きく広く悪用されている脆弱性」に絞ったもので、ほとんどのサイトで安全に使えるとされています。Cloudflare Managed Ruleset を有効にしていれば重複になります。

手順 1: マネージドルールを有効にする

1. Cloudflare のダッシュボードで対象のドメイン（ゾーン）を開き、Security → Settings に進みます。
2. 「Web application exploits」の項目で、使えるルールセット（Free Managed Ruleset、または Cloudflare Managed Ruleset・OWASP Core Ruleset）をオンにします。これで「Execute」動作のルールが 1 本作られます。
3. 保存したら、そのままの設定で数日間運用し、Security Events（後述）に正当なアクセスの遮断が出ていないか見ます。

OWASP Core Ruleset を有効にする場合は、最初は 感度（paranoia level）を低く、動作を Managed Challenge や Log にして様子を見るのが無難です。WordPress の投稿画面は HTML や長い本文をそのまま送るので、OWASP の点数が上がりやすい代表例です。

手順 2: ログイン画面にレート制限を掛ける

WordPress で一番多い攻撃は wp-login.php と xmlrpc.php へのパスワード総当たりです。レート制限ルールで「同じ IP から短時間に何回も来たら止める」とします。

Rules 言語で書くと、式は次のようになります。

(http.request.uri.path eq "/wp-login.php")

xmlrpc.php を使っていない（スマートフォンアプリや Jetpack などで XML-RPC を使っていない）サイトなら、レート制限ではなくカスタムルールで xmlrpc.php を Block してしまう方が簡単です。使っているかどうかの確認と WordPress 側での無効化は XML-RPC を無効化してセキュリティを高める方法 を参照してください。

レート制限は厳密な回数ではなく、カウンターが数秒遅れることがあると公式ドキュメントに書かれています。多少の超過はサーバーに届く前提で、WordPress 側の対策（ログイン試行の制限プラグイン、2 要素認証）と組み合わせます。

手順 3: カスタムルールで管理画面を絞る

カスタムルールは、Security → Security rules（旧 WAF → Custom rules）で作ります。条件は Rules 言語の式、動作は Block・Managed Challenge・Skip などです。順番に評価され、Block のような終端の動作に一致したらそれ以降のルールは見ません。

WordPress でよく使う例を挙げます。

# 例 1: xmlrpc.php を遮断（XML-RPC を使っていないサイト向け）
(http.request.uri.path eq "/xmlrpc.php")
→ Block

# 例 2: 管理画面とログイン画面を日本以外から遮断
(http.request.uri.path contains "/wp-admin/" or http.request.uri.path eq "/wp-login.php")
and not ip.src.country eq "JP"
and not http.request.uri.path eq "/wp-admin/admin-ajax.php"
→ Block（運営者が海外から更新することがあるなら Managed Challenge）

# 例 3: 自社の固定 IP からは WAF を通さない
(ip.src eq 203.0.113.10)
→ Skip（スキップする機能を選ぶ）

例 2 で admin-ajax.php を除いているのは、テーマやプラグインが訪問者向けの処理（絞り込み検索、いいねボタンなど）に admin-ajax.php を使うことがあり、ここを塞ぐと表側の機能が止まるからです。

国別の制限は VPN や中継で回避できるので、総当たりの量を減らす補助策として考えます。サーバー側（Nginx）で国別に制限する方法は Nginx の GeoIP2 で国別にアクセスを制限する方法 に書いています。

手順 4: Security Events で誤検知を見つけて直す

WAF を入れた後の確認は、ダッシュボードの Analytics → Events（Security Events）で行います。ここには Cloudflare が何かの動作をしたリクエスト（イベント）が並びます。Free プランでは「Sampled logs」（抽出されたログ）だけが見られます。

1. 期間を直近に絞り、動作で「Block」や「Managed Challenge」をフィルターします。
2. 「Top events by source」で、止められている IP・パス・User-Agent を見ます。自社の IP や、正当な連携先（決済サービスの通知、監視サービスなど）が並んでいたら誤検知です。
3. 各イベントを開くと、どのルールセットのどのルール ID が一致したかが分かります。

誤検知の直し方は 2 つあります。

どちらも、ルールセット全体を無効にするのではなく、問題のルール ID か条件に絞るのが要点です。「投稿を保存すると 403 になる」という症状なら、/wp-admin/post.php と admin-ajax.php へのリクエストに限ってスキップ、のように範囲を狭めます。

WordPress の観点: 実 IP の復元とキャッシュ

Cloudflare を通すと、サーバーが見る接続元 IP は Cloudflare のエッジサーバーの IP になります。訪問者の本来の IP は CF-Connecting-IP ヘッダーに入っています。これを復元しないと、

• WordPress のログイン制限プラグインが「全員同じ IP」と見て、正当な利用者まで締め出す
• サーバー側のアクセス制限（Nginx の allow / deny、GeoIP）が全部 Cloudflare の国・IP で判定される
• コメントスパムの IP 判定が働かない

といった不具合が出ます。Cloudflare の公式 WordPress プラグインや、Nginx の set_real_ip_from と real_ip_header CF-Connecting-IP で復元します。設定の流れは WordPress に Cloudflare を設定する完全ガイド にまとめています。

もう 1 つ、Cloudflare のキャッシュと WAF は別の機能です。WAF でログイン画面を守っていても、ページキャッシュの設定でログイン中の画面がキャッシュされてしまうと別の問題（他人の管理バーが見える等）が起きます。wp-admin と wp-login.php はキャッシュをバイパスする設定にしておきます。

よくある質問

Free プランの WAF だけで WordPress は守れますか

Free Managed Ruleset、カスタムルール 5 本、レート制限 1 本でも、wp-login.php の総当たりと xmlrpc.php の悪用、既知の重大な脆弱性の攻撃は減らせます。ただし OWASP Core Ruleset のような広い検知は Pro 以上です。WordPress 側の更新と、Wordfence などのプラグインによる監視（Wordfence の初期設定）は引き続き必要です。

WAF を入れたら投稿が保存できなくなりました

OWASP Core Ruleset かマネージドルールの誤検知が典型です。Security Events で、/wp-admin/post.php への POST がどのルール ID で止まっているかを確かめ、そのルールだけ上書きで Log にするか、/wp-admin/ 配下へのリクエストに限ってスキップルールを作ります。ルールセット全体を切る前に、ルール単位で直してください。

Cloudflare の WAF とサーバー側の ModSecurity は両方必要ですか

役割は重なりますが、Cloudflare はサーバーに届く前に止めるので負荷が減り、サーバー側はオリジンに直接来る通信（Cloudflare を迂回した接続）を守ります。オリジンの IP を公開せず、Cloudflare の IP 範囲からだけ 80/443 を受け付けるようにしておくと、迂回そのものを防げます。

誤検知かどうか分からないイベントはどうしますか

まずは動作を Block から Managed Challenge に下げ、正当な利用者が通れるかを見ます。それでも苦情が続くなら、そのイベントの IP・パス・ルール ID を控えて、該当する条件だけ例外にします。

まとめ

• Cloudflare の WAF はマネージドルール・カスタムルール・レート制限の 3 本立てで、プランによって使える本数とルールセットが違います。
• WordPress では wp-login.php のレート制限と xmlrpc.php の遮断、wp-admin の国・IP 制限から始め、admin-ajax.php は除外します。
• 新しいルールは弱い動作から入れ、Security Events で誤検知を確かめ、ルール単位のスキップや上書きで直します。実 IP の復元も忘れずに行います。

関連記事

• WordPress に Cloudflare を設定する完全ガイド
• XML-RPC を無効化してセキュリティを高める方法
• Nginx の GeoIP2 で国別にアクセスを制限する方法
• Wordfence の初期設定

参考: Cloudflare WAF（公式ドキュメント）、WAF Managed Rules、Custom rules、Rate limiting rules、Security Events、Cloudflare HTTP headers（CF-Connecting-IP）

更新履歴: 2026-11-09 全面改訂（定型文の記事を、マネージドルール・カスタムルール・レート制限の役割分担と WordPress 向けの設定例、Security Events での誤検知の直し方に置き換え）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。