WordPressでCloudflare Log Explorerを使う方法｜通信ログから原因を調べる手順

WordPressで403、429、520、524、記事保存失敗などが起きたとき、Cloudflare Security Eventsだけでは正常通信やオリジン応答まで追えない場合があります。Cloudflare Log Explorerを使うと、実際に発生したHTTP要求をRay ID、URL、時刻、応答コードなどで検索できます。

ただし、Log Explorerは2026年8月20日時点で有料アドオンです。データセットを有効にした時点からログを取り込み、取り込み・保存量に応じて課金されます。障害が起きてから契約しても、有効化前の過去通信は表示されません。

契約やデータセットを有効にする前に、対象zone、必要なログ、月間通信量、保存する個人情報、利用停止手順を確認してください。調査に必要な範囲だけを保存し、Cookieや認証ヘッダーを無目的に記録しないことが重要です。

先に結論｜Log Explorerが必要な場面

Log Explorerが向くのは、実際の本番通信を後から検索し、Cloudflare edgeとオリジンの応答を同じ要求で照合したい場面です。特定のRay ID、時間帯、URL、HTTPメソッド、応答コード、利用地域などから、対象要求を一件ずつ確認できます。

Security Eventsで対象イベントが見つからない
Cloudflareで返した状態とオリジンが返した状態を分けたい
同じURLで成功する要求と失敗する要求を比較したい
エラー発生時のIP、国、User-Agent、キャッシュ状態を確認したい
サポートへ実通信の証拠を渡したい
数千件の要求から同じ傾向を探したい

一方、無料で誤ブロックしたルールを探すだけなら、まずCloudflare Security Eventsの見方を使います。条件式や実行順を仮想要求で試すなら、Cloudflare Traceの使い方が先です。

Log Explorerと他の確認方法の違い

確認方法	対象	向く調査	主な注意
Log Explorer	有効化後に保存された実通信ログ	Ray ID、URL、時刻、edge・origin応答の照合	有料。事前のデータセット有効化が必要
Security Events	セキュリティ製品が対処・検知したイベント	WAF、Rate limiting、IP遮断などの原因特定	全通信ではなく、サンプリングされる場合がある
Security Analytics	対処されなかった要求を含む受信トラフィック	全体傾向、正常通信との比較、ルール設計	プランや画面で利用できる範囲が異なる
Cloudflare Trace	入力した仮想要求	条件式、フェーズ、評価順の確認	過去の実通信を示すログではない
Audit Logs	Cloudflare設定への変更操作	誰が・いつ・何を変えたかの確認	Webアクセスの通信ログではない

Cloudflare公式も、Log Explorerは実際の本番通信、Traceは「この条件ならどう評価されるか」というシミュレーションに使うと区別しています。実通信の結果をLog Explorerで見つけ、その条件をTraceへ移して設定評価を確認すると、事実と仮説を混ぜずに調査できます。

利用条件と料金を先に確認する

2026年8月20日時点のCloudflare公式料金資料では、Log ExplorerはApplication ServicesまたはZero Trust購入者向けの有料アドオンで、無料版や試用版はありません。取り込んで保存したログ量をGB単位で課金し、保存済みログを何回検索しても検索回数による追加料金は発生しない仕組みです。

確認項目	契約前に決めること
対象zone	本番、検証、複数ドメインのどれを保存するか
データセット	WordPress調査ならHTTP Requestsを基本に、必要時だけFirewall Eventsなどを追加
保存フィールド	Ray ID、Host、Path、Method、時刻、edge・origin状態など必要項目へ絞る
通信量	Analyticsのリクエスト量から取り込み量を見積もる
個人情報	IP、User-Agent、ヘッダー、Cookieを保存する目的と管理範囲を決める
停止方法	データセット停止とサブスクリプション解約の両方を把握する

Log Explorer画面が見えない場合は、契約の有無だけでなく権限も確認します。データセットの追加・停止にはLogs Edit、ログ検索にはLogs Read、検索条件の保存にはLogs Writeが必要です。zone単位のログはzone範囲の権限で確認します。

HTTP Requestsデータセットを有効にする

Cloudflareダッシュボードで対象アカウントを選ぶ
Log Explorerの「Manage datasets」を開く
「Add dataset」を選ぶ
zone単位のHTTP Requestsを選ぶ
対象のWordPressドメインを選ぶ
保存するフィールドと対象範囲を確認する
追加後、取り込みが有効になったことを確認する
少数のテストアクセスを行い、数分後にLog Searchで確認する

公式のManage datasets資料では、有効化後にログが検索可能になるまで数分かかる場合があると案内されています。また、Log Explorerは有効化した時点から取り込みを始めます。有効化前に起きた障害のログは遡って表示されません。

障害調査のために全zone・全データセット・全フィールドを一度に有効化しないでください。対象zoneとHTTP Requestsから始め、月間使用量を確認してから追加します。攻撃通信も原則として課金対象に含まれるため、アクセス急増時は使用量通知も設定します。

調査前に6つの証拠を保存する

失敗した完全なURL
秒までの発生時刻とタイムゾーン
Cloudflare Ray ID
GET、POST、PUTなどのHTTPメソッド
ブラウザーに出たHTTP状態・Cloudflareエラー番号
同じ操作が成功する環境と失敗する環境の差

記事保存やフォーム送信では、ページ本体とは別のFetch・XHRが失敗している場合があります。ブラウザー開発者ツールのNetworkで失敗要求を選び、その要求自身のURL、時刻、Ray ID、応答コードを保存します。ページ本体のRay IDと混同しないでください。

7つの条件で実通信を絞る

Log Explorerの「Log Search」を開く
DatasetでHTTP Requestsを選ぶ
対象zoneを一つ選ぶ
発生日と前後数分のTime periodを指定する
結果上限を50件程度から始める
Ray IDがあれば最初に完全一致で検索する
Ray IDがなければHost、Path、Method、edge status、origin status、IP、Countryを一条件ずつ追加する

公式Log Search資料を参考に、Columnsには調査目的に応じてRayID、要求Host・Path・Method、edge処理時刻、edge応答状態、origin応答状態、Client IP・Countryなどを選びます。最初から全列を表示せず、対象要求の識別とCloudflare・オリジン切り分けに必要な列へ絞ります。

Ray IDをCustom SQLで探す例

SELECT
  clientRequestScheme,
  clientRequestHost,
  clientRequestMethod,
  edgeResponseStatus,
  clientRequestUserAgent
FROM http_requests
WHERE RayID = '確認したRay ID'
LIMIT 1

上記はCloudflare公式の検索例を基にした形です。実際には「確認したRay ID」を保存した値へ置き換えます。Ray IDが見つからない場合は日付と短い時刻範囲を先に合わせ、Host・Path・IPでも照合します。

24時間や全期間を対象に、全列・全要求を一度に検索しないでください。公式FAQでも短い期間へ絞ることが推奨されています。広い検索はタイムアウトしやすいため、日付、時刻、zone、Hostの順に範囲を狭めます。

edgeとoriginの応答を分けて読む

確認結果	考えられる範囲	次に見る場所
edge 403、origin状態なし	Cloudflare側で停止した可能性	Security Events、WAF、IP・Rate limiting
edge 5xx、originも同じ5xx	オリジンがエラーを返した可能性	Webサーバー、PHP、WordPressログ
edge 520、origin応答が異常	不明・不正なorigin応答	ヘッダー、空応答、PHPクラッシュ
edge 524、origin応答未完了	Cloudflare接続後にorigin処理が長時間化	PHP、DB、外部API、長い処理
同じURLで成功・失敗が混在	メソッド、Cookie、IP、地域、キャッシュなどの条件差	成功・失敗の列を一項目ずつ比較

状態コードだけで担当範囲を断定せず、時刻、Ray ID、URL、メソッドと合わせます。520ならCloudflare Error 520の直し方、524ならCloudflare Error 524の直し方へ進み、オリジンログと同時刻を照合してください。

ログが0件のときに確認すること

対象zoneを間違えていないか
HTTP Requestsデータセットが有効か
有効化後に発生した新しい要求か
取り込み開始から数分待ったか
時刻とタイムゾーンが合っているか
Host、Path、Ray IDの入力に余分な文字がないか
対象ホストがCloudflareのProxied DNSを通っているか
キャッシュやService Workerでネットワーク要求自体が発生しているか
保存対象フィールドから必要列を外していないか

0件でも、通信が存在しなかったとは限りません。まずフィルターを日付・zone・Hostだけへ戻し、少数の安全なGET要求を新しく発生させて確認します。POST、決済、フォーム送信、記事保存を確認目的で何度も繰り返すのは避けてください。

ヘッダーとCookieは事前設定が必要

Log Explorerで要求・応答ヘッダーやCookieを検索するには、対象項目をCustom fieldsで事前に保存設定する必要があります。障害後に設定しても、過去のヘッダーやCookieは復元されません。必要な名前だけを明示的に選びます。

AuthorizationやセッションCookieを安易に保存しない
WordPressログインCookieの値を調査担当者間で共有しない
問い合わせ本文や個人情報を含むヘッダーを保存しない
保存目的、閲覧権限、保持期間、削除方法を先に決める
調査終了後も必要なフィールドか見直す

URLのクエリにもメールアドレスやトークンが入る設計があります。ログを共有するときは、Ray ID、時刻、状態コードなど調査に必要な部分を優先し、秘密情報や個人情報を削除します。

Security Analyticsから条件を引き継ぐ

Security Analyticsで国、IP、Host、Path、状態などを絞ってからLog Explorerへ移動すると、そのフィルターを引き継げます。最初からSQLを書く必要はありません。全体傾向をSecurity Analyticsで見つけ、個別要求をLog Explorerで確認する順にすると迷いにくくなります。

防御機能が対処した通信ならSecurity Events、対処されなかった通信を含む傾向ならSecurity Analytics、保存された実通信の詳細ならLog Explorer、条件式の再現ならTraceという役割です。Cloudflare Rulesが効かないときの確認順と組み合わせると、ログと設定の両側から原因を追えます。

調査後に課金と保存範囲を見直す

Log Explorerを止めるときは、データセット停止とサブスクリプション解約を分けて行います。公式資料では、データセットを停止すると追加の取り込み料金が止まり、サブスクリプション解約は次回更新を止める手順です。解約だけでは当該請求期間中の取り込みが自動停止しない場合があります。

Manage datasetsでaccount・zone両方の有効データセットを確認する
不要なデータセットを停止する
当月使用量が増えなくなったか確認する
BillingのSubscriptionsでLog Explorerを解約する
保存済みログの扱いとアクセス権を確認する
変更内容を記録し、必要ならAudit Logsでも確認する

よくある失敗

無料機能だと思って全データセットを有効にする
有効化前の過去ログを探し続ける
ページ本体と失敗したFetch・XHRを混同する
Ray IDだけを保存し、時刻やURLを残さない
24時間・全列・全zoneを一度に検索する
edge状態だけでCloudflare原因と断定する
origin状態だけでWordPress原因と断定する
CookieやAuthorizationを無目的に保存する
調査終了後も不要な取り込みを継続する
解約だけ行い、データセットを停止しない

確認チェックリスト

□ 有料アドオンと課金単位を確認した
□ 対象zoneとHTTP Requestsだけから始めた
□ Logs Read・Editの権限を確認した
□ 有効化後の通信だけが対象だと理解した
□ URL、時刻、タイムゾーン、Ray ID、Method、状態を保存した
□ 短い時間帯と少ない列から検索した
□ edgeとoriginの状態を分けて読んだ
□ ヘッダー・Cookieの秘密情報を保存していない
□ 月間使用量と通知を確認した
□ 調査後にデータセットと契約を見直した

よくある質問

Log Explorerは無料で使えますか？

2026年8月20日時点では有料アドオンで、無料版や試用版はありません。取り込み・保存量に応じた料金のため、対象zone、データセット、保存フィールド、通信量を確認してから導入します。

契約すれば昨日の障害も確認できますか？

データセット有効化前のログは表示されません。昨日の時点で取り込みを有効にしていなければ、Security Events、サーバーログ、ブラウザーの記録など残っている証拠を使います。

Security Eventsがあれば不要ですか？

誤ブロックの原因特定だけならSecurity Eventsが先です。正常通信を含む実HTTPログ、edge・origin状態、長期傾向、サポート用証拠まで必要なときにLog Explorerを検討します。

SQLが分からなくても使えますか？

画面でDataset、Columns、Time period、Field、Operator、Valueを選んで検索できます。まず画面操作で一件を探し、繰り返す調査だけ保存クエリやCustom SQLへ進めば十分です。

まとめ

Cloudflare Log Explorerは、実際の本番通信をRay ID、URL、時刻、edge・origin応答などで検索する有料の調査機能です。Traceの仮想評価、Security Eventsの対処イベント、Audit Logsの設定変更履歴とは役割を分けてください。

対象zoneとHTTP Requestsだけから始め、短い時間帯へ絞り、必要な列だけを確認することが基本です。有効化前のログは遡れません。費用と個人情報を管理しながら、実通信の証拠を設定変更より先に保存しましょう。