Cloudflare WAF の誤検知は、ブロック画面の Ray ID からセキュリティイベントを探し、「どの機能の・どのルールが」止めたのかを特定してから、パスや送信元を絞った例外（スキップ）を作るのが基本の対処です。この記事では、ブロックが本当に Cloudflare によるものかの見分け方、イベントの読み方、マネージドルールとカスタムルールそれぞれでの例外の作り方、WordPress で誤検知が起きやすい操作までを説明します。
Cloudflare のダッシュボードはメニュー構成や表記の変更が多く、プランによって使える機能も異なります（2026年10月現在）。以下ではメニュー名を目安として示しますので、実際の画面と異なる場合は Cloudflare の公式ドキュメント（WAF の Exceptions や Security Events の項目）を参照してください。
まず、止めたのは本当に Cloudflare か
403 や「ブロックされました」という画面が出たとき、Cloudflare ではなくオリジンサーバー側（WordPress のセキュリティプラグインや、サーバー会社の WAF、ModSecurity など）が止めていることがよくあります。最初にここを切り分けます。
- Cloudflare のブロック画面には Ray ID が表示されます。画面のデザインがサイト独自のものやプラグインのものなら、オリジン側の可能性が高いです
- オリジンのアクセスログに該当時刻のリクエストが残っていれば、Cloudflare は通過しています。Cloudflare で止められたリクエストはオリジンに届きません
- コマンドで再現できる場合は、レスポンスヘッダーを確認します
curl -sS -o /dev/null -D - -X POST "https://example.com/wp-admin/admin-ajax.php" -d "action=test"cf-ray ヘッダーは Cloudflare を経由したレスポンスに付きます。ステータスが 403 でも、本文がサーバー側のエラーページなら、オリジン側のブロックを疑います。
手順1：Ray ID からセキュリティイベントを探す
ブロック画面に表示された Ray ID を控え、ダッシュボードのセキュリティイベント（Security の Events に相当する画面）で検索します。Ray ID が分からない場合は、利用者の IP アドレスと時刻で絞り込みます。
イベントの詳細で確認する項目は次のとおりです。
- サービス（どの機能が反応したか）：マネージドルール、カスタムルール、レート制限、ボット対策、IP アクセスルールなど
- ルール ID とルール名（マネージドルールの場合）
- アクション：ブロック、マネージドチャレンジ、ログなど
- リクエストのパス、メソッド、送信元 IP、国、ユーザーエージェント
ここで重要なのは「サービス」です。誤検知だと思って WAF のマネージドルールを調べていたら、実はボット対策やレート制限が止めていた、ということは珍しくありません。サービスごとに対処の場所が違うので、最初に確定させます。
手順2：誤検知かどうかを判定する
イベントの内容と、利用者の操作を突き合わせます。
- 送信元が自社の管理者や連携サービスで、その時刻に投稿の保存やフォーム送信をしていた → 誤検知の可能性が高い
- 送信元が不特定多数で、パスやクエリに攻撃文字列が並んでいる → 本物の攻撃をブロックできている状態。例外は作りません
- 正規の利用者だが、送信内容に SQL やスクリプトの断片が含まれていた（技術記事の本文など） → 誤検知。例外はそのパスと条件に絞ります
OWASP Core Ruleset を有効にしている場合は、個々のルールではなく「異常スコアの合計がしきい値を超えたか」でブロックが決まります。イベントに複数のルールが並んでいるのはこのためで、どれか一つを外すより、該当パスでの感度（パラノイアレベルやスコアのしきい値）を見直すほうが筋がよい場合もあります。
手順3：例外を作る（マネージドルール）
マネージドルールの誤検知には、条件を絞った例外（WAF の Exceptions、以前のスキップルールに相当）を作ります。例外では「この条件に一致したリクエストについて、指定したルール（またはルールセット）を評価しない」と指定します。
条件の例を Cloudflare のルール言語で書くと次のようになります。
(http.request.uri.path eq "/wp-admin/admin-ajax.php" and http.request.method eq "POST" and ip.src in {192.0.2.10 192.0.2.11})スキップの対象は、可能な限り「ルールセット全体」ではなく「イベントに出た特定のルール ID」にします。条件と対象の両方を絞るのが、誤検知対応で最も大事な点です。
管理者の IP が固定でない場合は、IP の代わりにパスとメソッドで絞ることになりますが、そのぶん攻撃者も例外の恩恵を受けます。ログイン状態を示す Cookie で絞る方法も見かけますが、Cookie の有無は攻撃者が自由に付けられるため、単独の条件にはしないでください。
また、例外は評価順に依存します。例外がマネージドルールより後に評価される位置にあると効きません。作成後にイベントを再確認し、同じ操作でブロックが出なくなったことを確かめます。
手順4：例外を作る（カスタムルール・その他の機能）
自分で作ったカスタムルールが原因なら、そのルールの条件式を見直すのが先です。たとえば国やユーザーエージェントでブロックしているルールに、連携サービスのアクセスが巻き込まれているなら、そのサービスの送信元を除外する条件を加えます。
(not ip.src in {198.51.100.0/24}) and (http.request.uri.path contains "/xmlrpc.php")カスタムルールのアクションに「スキップ」を使って、後続のルールや機能を飛ばすこともできます。ただし、何をスキップできるかはプランや機能によって異なるため、設定画面の選択肢と公式ドキュメントで確認してください。
レート制限やボット対策が原因の場合は、WAF の例外ではなくそれぞれの設定で対処します。監視サービスや Webhook の送信元が止められているなら、そのサービスが公開している送信元 IP の一覧を確認し、条件に加えます。
手順5：反映後の確認と記録
例外を作ったら、次の点を確認します。
- 同じ操作（投稿の保存、フォーム送信など）で、ブロックが出なくなったか
- セキュリティイベントに、同じパスで別のルールが反応していないか
- 例外の条件を満たさないリクエスト（別の IP や別のパス）では、引き続きブロックされるか
最後の確認は見落とされがちです。テスト用の無害なリクエストを、例外条件の外から送ってみるとよいでしょう。自分の管理するサイト以外には送らないでください。
例外には、作成理由と対象のルール ID、見直し予定日を説明欄やメモに残します。例外は増える一方になりやすいので、四半期ごとなどに棚卸しをして、不要になったものを削除します。
WordPress で誤検知が起きやすい操作
Cloudflare の WAF を WordPress の前に置いたとき、次の操作がマネージドルールに反応しやすい傾向があります。
- ブロックエディターでの保存：REST API（
/wp-json/wp/v2/）への JSON の POST。本文にコードや SQL の説明を含む記事で起きやすいです admin-ajax.phpへの POST：ページビルダーやフォームプラグインの保存・送信- テーマやプラグインのファイル編集画面からの保存（そもそも本番では無効化しておくのが望ましい機能です）
- メディアのアップロードや、インポートツールの大きな POST
これらの対処として、/wp-admin/ 以下全体を WAF の対象から外す設定を見かけますが、管理画面への攻撃も通すことになるため勧めません。パスとルール ID を絞り、可能なら送信元 IP も組み合わせてください。ログイン画面への総当たり対策は、例外とは別に、レート制限やチャレンジで守ると両立しやすくなります。
オリジン側でも、Cloudflare 経由のリクエストの本当の送信元 IP（CF-Connecting-IP ヘッダー）をログに記録しておくと、Cloudflare のイベントとオリジンのログを照合しやすくなります。
まとめ
- 最初に、ブロックしたのが Cloudflare かオリジン側かを、Ray ID・ブロック画面・オリジンのログで切り分けます
- セキュリティイベントで「サービス」と「ルール ID」を特定し、誤検知かどうかを利用者の操作と照合して判定します
- 例外は、条件（パス・メソッド・送信元）と対象（特定のルール ID）の両方を絞って作ります。Cookie だけを条件にしない、
/wp-admin/全体を外さない、が要点です - 作成後は、同じ操作で通ること・条件外では止まることの両方を確認し、理由と見直し日を記録します
- ダッシュボードの表記やプランごとの機能は変わるため、公式ドキュメントで最新の画面を確認してください