WordPressの公開ページ、ログイン、記事保存、REST API、問い合わせフォームなどがCloudflareに拒否されたとき、最初にWAFを停止すると原因が分からなくなります。Cloudflare Security Eventsを使えば、実際にどのセキュリティ製品が要求を検知し、どのActionを実行したかを調べられます。
ただし、Security Eventsは全アクセスの完全な通信履歴ではありません。Cloudflareのセキュリティ製品が対処または検知したイベントを扱い、表示がサンプリングされる場合もあります。発生時刻、Ray ID、IP、Host、Pathなどを保存してから、狭い条件で絞ることが重要です。
失敗した操作を何度も繰り返さず、完全なURL、正確な時刻とタイムゾーン、Ray ID、HTTPメソッド、応答コードを先に保存してください。その証拠をSecurity Eventsへ移し、原因ルールだけを一項目ずつ確認します。
先に結論：Security Eventsは8段階で確認する
- エラーが起きた完全なURL、時刻、Ray ID、メソッド、応答コードを保存する
- Cloudflareダッシュボードで対象アカウントとドメインを選ぶ
- AnalyticsのEvents画面を開き、発生時刻の前後へ期間を狭める
- Ray IDがあれば最優先で絞り、なければIP、Host、Pathを重ねる
- ActionとServiceから、どの製品が何をしたか確認する
- Sampled logsのイベントを開き、ルール名・ルールID・要求条件を保存する
- 正常な要求と異常な要求を比較し、誤ブロックか正当な防御か判断する
- 原因ルールの対象条件だけを修正し、WordPressの代表URLを再確認する
一覧にイベントが出ない場合も、すぐに「Cloudflareは関係ない」とは判断しません。時間帯のずれ、入力したフィルター、サンプリング、保持期間、Security Eventsへ表示されない処理を順に確認します。
Cloudflare Security Eventsとは？
Cloudflare公式のSecurity Events資料では、Cloudflareのセキュリティ製品が対処または検知した要求を確認し、誤検知の調査やルール調整に使う画面と説明されています。WAF Custom Rules、Managed Rules、Rate limiting、Bot関連機能、IP Access rules、Browser Integrity Checkなど、複数の機能がイベントを生成します。
Security Eventsに表示される単位は、必ずしもHTTP要求そのものではありません。一つの要求が複数のセキュリティ機能に触れれば、複数イベントとして表示される場合があります。同じRay IDや時刻に複数行があっても、別々の訪問者と決めつけないでください。
また、Blockだけを見る画面でもありません。Challenge、Managed Challenge、Log、Skip、Allowなどが表示される場合があります。Action名だけで良否を判断せず、どのServiceとルールが、どの要求条件へ作用したかを読みます。
Security Eventsと他の確認方法の違い
| 確認方法 | 主に分かること | 向く場面 | 限界 |
|---|---|---|---|
| Security Events | セキュリティ製品が対処・検知したイベント | 誤ブロック、Challenge、Rate limitの原因特定 | 全通信ではなく、サンプリングされる場合がある |
| Security Analytics | 対処されなかった要求を含む受信HTTPトラフィック | 全体傾向、正常通信との比較、ルール設計 | 表示内容や保持期間にプラン差がある |
| Cloudflare Trace | 指定した仮想要求で評価される設定と順序 | 条件式、フェーズ、非一致ルールの確認 | 実際に発生した通信履歴ではない |
| オリジンログ | サーバーへ届いた要求とWordPress側の処理 | PHP、Webサーバー、プラグインとの照合 | Cloudflareで止まった要求は残らない |
Cloudflare公式のSecurity Analytics資料では、Security AnalyticsはCloudflareが対処しなかった要求を含む全受信HTTPトラフィック、Security Eventsは対処・検知されたイベントを見る役割と分けられています。実際の誤ブロックはSecurity Events、正常通信を含む比較はSecurity Analytics、仮想条件の評価はCloudflare Traceの使い方という順に使い分けます。
画面を開く前に保存する情報
- 失敗した完全なURLと、正常に動く比較URL
- 発生日時、秒まで分かる時刻、タイムゾーン
- エラーページまたは応答ヘッダーのRay ID
- GET、POST、PUTなどのHTTPメソッド
- 403、429、5xxなどの応答コード
- ログイン中・未ログイン、管理者・一般利用者の別
- 利用者のIPアドレス、国、ASNが分かる場合はその値
- User-Agent、利用ブラウザー、アプリ、外部サービス
- 対象Host、Path、必要ならQuery
- 直前に変更したWAF、Rate limiting、IP Access、Bot、Rules設定
- WordPress、サーバー、プラグイン側の同時刻ログ
IPアドレス、Cookie、User-Agent、フォーム内容には利用者情報が含まれる場合があります。社外へ共有する資料では、原因調査に不要な値を伏せてください。Ray IDも完全URL・時刻と組み合わせて必要な相手だけに渡します。
Security Eventsを開く手順
- Cloudflareダッシュボードへログインする
- 対象サイトを管理する正しいアカウントを選ぶ
- 対象ドメインのzoneを開く
- Analyticsページへ進む
- Eventsタブを開く
- 発生した時刻を含む期間へ変更する
- フィルターを一つずつ追加する
ダッシュボードの名称や配置は更新される場合があります。メニュー名を探すことだけに時間を使わず、「対象zoneのAnalyticsで、セキュリティイベントとSampled logsを見る」という目的を基準にしてください。別アカウントや別サブドメインを開いていないかも確認します。
7つの条件で対象イベントを絞る
1. 発生時刻の前後へ期間を狭める
最初から24時間全体を眺めず、発生時刻の前後数分を選びます。Cloudflare公式は、時間範囲を狭めるとデータ量が減り、サンプリングを減らせる場合があると案内しています。ブラウザーの表示時刻とCloudflare画面のタイムゾーンを混同しないでください。
2. Ray IDを使う
エラーページや応答ヘッダーにRay IDがある場合は、最も具体的な手掛かりの一つです。入力位置が分からない場合や取得方法が不明な場合は、Cloudflare Ray IDの確認方法で、エラーページ・開発者ツール・ログから保存する手順を確認してください。
3. IPアドレスを重ねる
Ray IDがない場合は、発生時IPを使います。固定回線、モバイル回線、VPNなどでIPが変わるため、後から現在のIPだけを確認しても一致しない場合があります。利用者から連絡を受けた時点のIPと時刻を一組で保存します。
4. HostとPathを確認する
example.comとwww.example.com、公開URLとプレビューURL、/wp-login.phpと/wp-admin/を分けます。Pathの大文字・小文字、末尾スラッシュ、クエリの有無で条件が変わる場合もあるため、ブラウザーに表示された完全なURLを使います。
5. Actionを確認する
Block、Managed Challenge、Challenge、Log、Skip、Allowなどを確認します。画面が開かなかったからBlockとは限らず、Challengeが完了できなかった場合やRate limitで一時的に止まった場合もあります。利用者が見た現象とActionを照合します。
6. Serviceとルールを確認する
WAF Custom Rules、Managed Rules、Rate limiting、IP Access rules、Bot関連機能など、どのServiceがイベントを生成したかを確認します。Cloudflare Error 1020ならWAF・Access Deniedの確認手順、1015ならレート制限の確認手順へ進むと、修正項目を絞れます。
7. User-Agent・Country・ASNを補助条件にする
同時刻に似た要求が多い場合は、User-Agent、Country、ASNなどを追加します。ASNを手入力するときはASを付けず数字だけを入力し、値へ引用符を付けません。公式資料ではワイルドカードも非対応とされています。条件を一度に増やしすぎず、一つ追加するたび件数を確認します。
フィルター結果が0件でも、イベントが存在しなかったとは限りません。時刻、タイムゾーン、zone、IP、Host、Pathの入力を戻し、期間を短くして再確認します。サンプリングや保持期間も考慮してください。
Sampled logsのイベント詳細を読む
| 確認項目 | 読み取ること | 注意点 |
|---|---|---|
| Timestamp | 利用者の報告時刻と一致するか | タイムゾーンと秒単位を確認 |
| Ray ID | エラーページや応答ヘッダーと対応するか | Ray IDだけで原因を断定しない |
| Action | Block、Challenge、Log、Skipなど何をしたか | 現象とActionが合うか確認 |
| Service・Source | どのセキュリティ機能が検知したか | 製品ごとに修正場所が違う |
| Rule name・Rule ID | 原因候補の設定を特定する | 削除済みルールは表示が限定される場合がある |
| Host・Path・Method | 対象URLと操作に一致するか | GETとPOST、公開と管理画面を分ける |
| IP・Country・ASN | 影響範囲と条件を確認する | 広いAllowの根拠にしない |
| User-Agent | ブラウザー、ボット、外部サービスを区別する | 偽装可能なので単独で決めない |
同じ要求が複数イベントを生成している場合は、時刻とRay IDを軸に並べ、ServiceとActionの組み合わせを確認します。先にLogされたイベントと、後でBlockされたイベントが同じ要求に属する可能性もあります。最終的に利用者へ影響したActionだけでなく、途中で一致したルールも保存します。
イベント詳細をJSONで保存できる場合は、変更前の証拠として保管します。複数イベントの一括Exportやレポート機能にはプラン差があるため、表示されない機能を無理に探さず、必要項目を安全な記録へ転記してください。
WordPressで誤ブロックを判断する
| 失敗した操作 | 確認する要求 | 誤ブロックで疑う条件 |
|---|---|---|
| 公開ページ閲覧 | GET、Host、Path、Country | 広すぎる国・ASN・パス条件 |
| ログイン | /wp-login.php、POST、Cookie | 正規管理者まで対象にしたBot・Rate limit |
| 管理画面 | /wp-admin/、ログイン状態 | 管理画面除外と認証条件の不一致 |
| 記事保存 | /wp-json/、POST・PUT、JSON | REST API本文やメソッドを一律遮断 |
| フォーム送信 | 送信先Path、POST、送信間隔 | 正規送信を攻撃・連打と誤判定 |
| Cron・Webhook | 送信元IP、User-Agent、固定Path | 外部サービスの通信だけChallenge |
誤ブロックとは、単にサイト運営者に不便なイベントではありません。正規利用者の必要な操作がルールの意図を外れて拒否され、正常条件との比較でその差を説明できる状態です。攻撃要求までAllowする修正は誤ブロック解消ではありません。
ASN遮断が原因ならCloudflare Error 1005の確認順、個別IP遮断ならError 1006・1007・1008・1106の確認順を参照し、広いネットワーク全体ではなく原因設定を確認します。
表示されないイベントと保持期間に注意する
| プラン | Security Eventsの保持期間 | 最大確認期間 | 主な画面差 |
|---|---|---|---|
| Free | 最大24時間 | 24時間 | Sampled logsのみ |
| Pro | 最大24時間 | 24時間 | 主要ダッシュボード機能 |
| Business | 最大3日 | 3日 | 主要機能、条件付きExport |
| Enterprise | 最大30日 | 31日 | アカウント単位画面など |
上表は2026年8月19日にCloudflare公式資料で確認した内容です。契約や画面更新で変わる可能性があるため、実際のダッシュボードと最新のAvailabilityを優先してください。Free・Proでは古いイベントを後日探そうとしても保持期間外になります。問題発生時にすぐ証拠を保存します。
Sampled logsは選択期間のイベントの一部です。大量アクセス時はすべての個別イベントが表示されるとは限りません。期間を短くし、Ray ID、IP、Pathを正確にしても見つからない場合は、Security Analytics、Log Explorer、オリジンログ、関連機能の設定画面へ確認範囲を広げます。
削除済みのCustom RuleやRate limiting ruleは、Rule unavailableと表示される場合があります。ルールを削除してから原因を調べるのではなく、まず状態、式、Action、順序を保存します。削除・変更済みならAudit logsで誰がいつ変更したかも確認してください。
原因ルールを一項目だけ修正する
| 原因 | 修正方針 | 再確認 |
|---|---|---|
| Path条件が広い | 必要なPathとメソッドへ絞る | 対象外ページの防御が残るか |
| Rate limitが厳しい | 正規操作の回数・期間を測って最小調整 | 連打と通常操作の両方 |
| 国・ASN条件 | 必要な通信だけ例外化 | 別地域・別回線への影響 |
| Bot・User-Agent条件 | 送信元と認証条件を追加 | 偽装要求を通していないか |
| 管理画面・REST API | 認証済み操作と公開APIを分ける | ログイン、保存、公開表示 |
| 重複ルール | 目的と責任を整理し一方を狭める | 他のServiceで再度止まらないか |
WAF全体の停止、全IPのAllow、true条件の広いSkipを恒久対策にしないでください。原因イベントと正常要求の差を説明できる条件だけを修正し、変更前の式へ戻せる状態を残します。
修正後に確認するWordPressのURL
- トップページと通常の記事ページ
/wp-login.phpの表示と正規ログイン/wp-admin/の管理画面- 記事編集画面の下書き保存とプレビュー
/wp-json/を使うブロックエディターや連携/wp-admin/admin-ajax.phpを使う機能- 問い合わせ、検索、コメントなどのフォーム
- Cron、Webhook、決済、外部API連携
- 変更対象外の攻撃的なテスト要求
修正後は、同じ正常条件と異常条件でSecurity Eventsを再確認します。正規操作が通ったことだけで終わらず、攻撃的な条件や対象外URLが引き続き防御されているかを確認してください。本番の決済・投稿・フォームでは重複処理を避け、必要ならテスト環境や安全なデータで試します。
やってはいけない確認方法
- 発生時刻やRay IDを保存せず設定を変更する
- Security Eventsを全通信の完全なログだと思い込む
- 0件を根拠にCloudflareと無関係だと断定する
- 一つのHTTP要求と一つのイベントを同一視する
- WAF、Rate limiting、Bot、IP Accessを一度に止める
- 広いIP・国・ASNをAllowへ入れる
- 削除前にルール名、式、Actionを保存しない
- Cookie、IP、フォーム内容を無加工で共有する
- 本番のログイン、決済、送信を繰り返す
- 正規操作だけ確認し、防御が残るか確認しない
よくある質問
FreeプランでもSecurity Eventsを見られますか？
2026年8月19日の公式資料では全プランで利用できます。ただしFreeはSampled logsのみで、保持期間は最大24時間です。問題が起きたら翌日以降へ持ち越さず、イベント詳細を早めに保存してください。
Ray IDで検索しても出ないのはなぜですか？
zoneや時刻が違う、保持期間外、値の入力違い、サンプリング、Security Eventsの対象外処理などが考えられます。期間を短くし、時刻・IP・Host・Pathでも照合し、必要ならオリジンログやLog Explorerへ進みます。
イベントが見つかれば誤ブロックと判断できますか？
イベントが見つかっただけでは判断できません。要求内容が正規操作か、ルールの本来の目的から外れているか、正常条件との差を説明できるかを確認します。攻撃要求を正しく止めたイベントは誤ブロックではありません。
イベントを見つけたらルールを削除してよいですか？
先に削除しないでください。ルール名、ID、式、Action、順序とイベント詳細を保存し、対象条件だけを狭くします。削除するとRule unavailableになり、後から原因を追いにくくなる場合があります。
まとめ
Cloudflare Security Eventsは、セキュリティ製品が対処または検知したイベントを確認し、WordPressの誤ブロック原因を絞るための画面です。発生時刻、Ray ID、IP、Host、Path、Action、Serviceを一つずつ重ね、Sampled logsの詳細から原因ルールを特定します。
Security Eventsは全通信の完全な履歴ではなく、サンプリングや保持期間の制限があります。0件でも断定せず、Security Analytics、Trace、オリジンログと役割を分けてください。原因となる一項目だけを修正し、正規操作と防御の両方を確認することが安全な復旧につながります。