WordPressサイトの表示や管理画面の挙動が突然変わったとき、Cloudflareの設定を手当たり次第に戻すと、原因が分からないまま別の不具合を増やしかねません。前日まで動いていたDNS、WAF、Rules、キャッシュ、SSL/TLSなどに変更がなかったか、まずAudit Logsで事実を確認します。
Cloudflare Audit Logsは、アカウント内で「誰が・いつ・何を・どの対象へ行い・成功したか」を追うための監査記録です。WordPressへのログイン履歴や記事編集履歴、Webアクセスの通信ログそのものではありません。
不具合が起きた直後に設定を上書きせず、発生時刻、現在値、該当Audit Log、変更前後の差分を先に保存してください。証拠を残してから一項目ずつ戻すと、原因と復旧結果を対応づけられます。
先に結論｜Audit Logsで分かること
Cloudflareの設定変更が疑われるときは、Audit Logs v2で対象時間を絞り、Actor、Action、Resource、Time、Resultの5項目を一組で確認します。同じリソースの変更前後を比べられる場合はResource Historyも開きます。
- メンバーがダッシュボードからDNSレコードを変更した
- API tokenを使う自動処理がRulesや設定を更新した
- Cloudflareのシステム処理がリソースを変更した
- 変更操作が成功したか、失敗したか
- 同じリソースが前後にどう変わったか
- 不具合発生時刻と設定変更時刻が近いか
一方、特定アクセスがWAFで止められた理由はCloudflare Security Eventsの見方、実際のHTTP要求はLog Explorer、条件式の仮想評価はCloudflare Traceの使い方で確認します。
Audit Logsと通信ログの違い
| 確認方法 | 記録するもの | 向く調査 | 記録しないもの |
|---|---|---|---|
| Audit Logs | Cloudflare設定への操作 | 誰が何を変更したか | 個々のWebアクセス内容 |
| Log Explorer | 有効化後の実HTTP通信 | Ray ID、URL、edge・origin応答 | 設定変更の前後差分 |
| Security Events | セキュリティ製品の検知・対処 | WAFやRate limitingの誤検知 | 無関係な設定変更全般 |
| Cloudflare Trace | 入力した仮想要求の評価結果 | Rulesの条件式と実行順 | 過去に起きた実通信 |
| WordPress活動ログ | WordPress内のログイン・編集操作 | 記事、ユーザー、プラグインの変更 | Cloudflare側の設定変更 |
たとえば「キャッシュルールを変えた直後から表示が崩れた」はAudit Logs、「ある閲覧者だけ403になった」はSecurity EventsやLog Explorer、「この条件式が管理画面URLに一致するか」はTraceの担当です。最初に調査対象を分けると、無関係な画面を探し続けずに済みます。
Audit Logs v2の利用範囲と保存期間
2026年8月20日時点のCloudflare公式Audit Logs資料では、Audit Logs v2はアカウント単位でユーザーとシステムが行った操作を記録し、保持期間は18か月です。作成・更新・削除操作を中心に、Cloudflare製品のおよそ95％をカバーすると説明されています。
Cloudflare公式の確認手順では、Audit Logsは全プランで利用できると案内されています。ダッシュボードのv2画面で検索できるのは直近90日が中心です。90日より前で18か月以内の記録が必要なら、APIまたは事前に設定したLogpushを利用します。v2画面で見つからない場合は、同じ画面から旧v1表示へ切り替えて補助確認できます。
v2は多くの作成・更新・削除を記録しますが、すべての製品・すべての操作を完全に記録するわけではありません。参照を意味するGET操作も広く記録される段階ではないため、ログがないことだけで「誰も設定を見ていない」「変更は絶対になかった」と断定しないことが大切です。
調査前に7つの証拠をそろえる
- 不具合が始まった日時とタイムゾーン
- 最後に正常だった日時
- 影響する完全なURLと対象zone
- ブラウザーに出たHTTP状態やCloudflareエラー番号
- Cloudflare Ray ID
- 直前に行ったデプロイ、プラグイン更新、DNS・Rules変更
- 現在の設定画面と値を保存したスクリーンショット
「午前中から」ではなく、正常時刻と異常時刻をできるだけ秒単位で残します。WordPress、ブラウザー、サーバー、Cloudflareで表示するタイムゾーンが違う場合があるため、JSTやUTCも併記してください。変更時刻と不具合時刻が近いことは有力な手掛かりですが、それだけで原因とは断定しません。
ダッシュボードでAudit Logsを開く
- Cloudflareダッシュボードへログインする
- 調査対象のアカウントを選ぶ
- 「Manage Account」を開く
- 「Audit Logs」を選ぶ
- Audit Logs v2が表示されていることを確認する
- 表示時刻のタイムゾーンを確認する
- 不具合時刻の前後へ期間を絞る
複数のCloudflareアカウントを管理している場合は、最初にaccount名と対象zoneを確認します。対象ドメインが別アカウントにあると、正しい時間を検索しても結果は出ません。権限が足りない場合は、必要最小限の閲覧権限を持つ管理者に確認を依頼します。
5つの項目を一組で読む
| 項目 | 確認する内容 | 判断例 |
|---|---|---|
| Time | 操作日時とタイムゾーン | 不具合開始前後か |
| Actor | ユーザー、token、Cloudflare管理者、system | 想定した実行者か |
| Action | create、update、deleteなど | 追加・変更・削除のどれか |
| Resource | 対象のaccount、zone、設定、ルールなど | 影響範囲と一致するか |
| Result | 操作の成功・失敗 | 変更が成立したか |
詳細を開いたらRawデータも確認し、表示名だけでは分からない対象ID、関連account・zone、変更内容の手掛かりを保存します。秘密情報が含まれる可能性を考え、社外共有や問い合わせ添付では必要部分だけを残します。
Actorは人のメールアドレスだけとは限りません。userはメンバー操作、account tokenはAPI tokenを使った自動処理、Cloudflare_adminはCloudflare側の管理操作、systemはシステムが開始した処理です。自分のメールアドレスがないから外部侵入と決めつけず、自動化、Terraform、デプロイ、連携サービスの実行時刻と照合します。
検索条件を狭める順番
- 不具合の前後30分など短い期間を指定する
- 対象zoneまたはドメインに関係するResourceへ絞る
- DNS、Rules、WAF、Cache、SSL/TLSなど疑う製品を絞る
create、update、deleteを順に確認する- Resultが成功した操作を優先する
- 分かっているメンバーのメールアドレスやActorを照合する
- 結果がなければ期間と対象を一段階ずつ広げる
最初から18か月分を眺めるのではなく、異常が始まった時間から逆算します。見つかった操作の直前と直後も確認し、ひとつの自動処理が複数リソースを連続更新していないか調べます。失敗した操作だけでなく、その直後に成功した再実行も確認してください。
Resource Historyで変更前後を比べる
対象のAudit LogからResource Historyを開ける場合は、同じリソースに対する操作を時系列で表示できます。前後の記録を選び、並べて差分を確認すると、現在画面だけでは分からない変更前の値を追いやすくなります。
- 原因候補のAudit Log詳細を開く
- Resource Historyを選ぶ
- 同じResourceの前後の操作を時系列で確認する
- 比較する二つの記録を選ぶ
- 追加・変更・削除された値を確認する
- 変更時刻と不具合の開始時刻を照合する
- 復旧候補の値を別のメモへ記録する
CloudflareはResource Historyの差分に、正確、近似、利用不可に相当する精度状態を設けています。製品や記録によってはリソースを完全に特定できず、履歴や差分が出ない場合もあります。
Resource Historyに値が見えても、そのまま全設定を巻き戻さないでください。差分の精度、現在の依存関係、変更後に追加された設定を確認し、対象を一項目だけ変更して表示・ログイン・フォーム・キャッシュを再検証します。
よくある4つの原因を調べる
DNSレコードが変更・削除された
A、AAAA、CNAMEの値、Proxied状態、対象ホスト名の変更を確認します。移転前のIPを戻す前に、現在のサーバー契約と正しい接続先を確認してください。誤ったorigin IPやCloudflare IPをDNSへ設定すると、Cloudflare Error 1000など別の障害につながります。
WAF・Rules・Rate limitingが更新された
Ruleの作成・更新・削除時刻を確認し、式、Action、優先順位、対象zoneを現在画面と照合します。Audit Logsで変更事実を見つけた後は、Cloudflare Rulesが効かないときの確認順で実行フェーズと条件を確認します。実アクセスが止められたかはSecurity Eventsで別に確かめます。
Cache・SSL/TLS設定が更新された
キャッシュルール、Cache Everything相当の条件、SSL/TLS暗号化モード、Edge Certificates周辺の変更を探します。表示崩れならHTMLや管理画面のキャッシュ、リダイレクトループならSSL/TLSモードとorigin側HTTPSの組み合わせを確認します。キャッシュ削除だけで直っても、原因となるルール変更を残したままにしないでください。
メンバー・API token・自動化が変更した
見覚えのないActorでも、まず連携サービス、CI/CD、Terraform、ホスティング管理画面など正規の自動処理を確認します。token名だけで用途が分からない場合は、所有者、権限範囲、最終利用、実行元を照合し、秘密値そのものをチャットやチケットへ貼り付けないでください。
不審な実行者を見つけたときの対応
- Audit Logの時刻、Actor、Action、Resource、Result、Raw情報を安全な場所へ保存する
- 同じActorによる前後の操作と影響範囲を確認する
- 現在の設定とResource Historyを保存する
- 見覚えのないログインセッションを失効する
- 疑わしいAPI tokenをロールし、古いtokenを無効化する
- メンバー権限、パスワード、二要素認証を見直す
- 変更を一項目ずつ安全な値へ戻して検証する
- WordPress側の管理者、活動ログ、プラグイン、サーバーログも確認する
証拠保存前にメンバー、セッション、tokenを一括削除しないでください。緊急遮断が必要な場合も、現在のAudit Logと影響範囲を保存してから、疑わしい対象を限定して無効化します。API tokenをロールすると旧tokenは使えなくなるため、正規の自動処理が停止しないよう所有者と更新先を確認します。
Cloudflare公式には、プロフィールのSessions画面からアクティブセッションを失効する手順と、tokenをロールして旧tokenを無効化する手順があります。WordPress側も侵害が疑われる場合は、WordPressのセキュリティ基本に沿って管理者、パスワード、更新、バックアップを確認します。
設定を安全に戻す手順
- 原因候補と根拠となるAudit Logを一件に絞る
- 現在値と変更前候補を両方保存する
- 影響するURL、ログイン、フォームなど再現確認を決める
- 本番影響が大きい場合はメンテナンス時間を確保する
- 対象設定だけを変更する
- ブラウザー、別回線、シークレットウィンドウで再検証する
- Security Events、Ray ID、originログなどで副作用を確認する
- 復旧操作そのものが新しいAudit Logへ記録されたことを確認する
変更後は「画面が開いた」だけで完了にしません。WordPressログイン、記事表示、画像、問い合わせ、購入導線、予約処理など、その設定が影響する操作を確認します。問題が続く場合は変更を重ねず、保存した現在値へ戻して別の原因候補へ進みます。
Audit Logsで見つからないとき
- Cloudflareのaccountを間違えていないか
- 対象時間とタイムゾーンが合っているか
- ダッシュボードv2の90日範囲を超えていないか
- ResourceやActionのフィルターを狭めすぎていないか
- v1表示に補助記録がないか
- 対象製品や操作がv2の記録範囲に含まれるか
- Cloudflare設定ではなくWordPress、サーバー、DNS事業者側の変更ではないか
- 設定変更ではなくアクセス条件、origin障害、キャッシュ残存ではないか
記録がない場合は、90日以内なら条件を減らして再検索し、それ以前ならAPIまたはLogpushの利用可否を確認します。ただし、Logpushは事前設定が必要です。過去に保存していないログを後から生成できるわけではありません。
よくある失敗
- Audit Logsをアクセスログだと思ってRay IDを探し続ける
- 不具合時刻を保存せず、長期間の履歴を目視する
- Actorのメールアドレスだけで原因を断定する
- 自動処理やsystem actorを不正アクセスと決めつける
- Resultが失敗した操作を成立した変更として扱う
- Resource Historyの近似差分を正確な復元値だと思う
- 現在値を保存せず、複数設定をまとめて戻す
- Cloudflare変更とWordPress内の変更を混同する
- tokenの秘密値を調査メモへ貼り付ける
- 復旧後の動作と新しいAudit Logを確認しない
確認チェックリスト
- 対象accountとzoneは正しい
- 異常開始時刻と最後の正常時刻を保存した
- タイムゾーンを合わせた
- Actor、Action、Resource、Time、Resultを一組で確認した
- Raw情報と前後の関連操作を確認した
- Resource Historyの差分精度を確認した
- Audit Logsの記録範囲と90日・18か月の違いを理解した
- 現在値を保存してから一項目だけ変更した
- 不審なセッション・tokenの所有者と影響を確認した
- 復旧後にWordPressの重要操作を再検証した
よくある質問
Audit Logsは無料プランでも見られますか？
はい。Cloudflare公式では全プランで利用できると案内されています。ただし、表示できる期間、APIやLogpushの準備、メンバー権限を確認してください。
履歴は何か月残りますか？
v2の保持期間は18か月です。ダッシュボードのv2検索は直近90日が中心で、それより前の保持期間内データはAPIまたはLogpushで確認します。
WordPressの記事やプラグイン変更も分かりますか？
分かりません。Audit Logsが記録するのはCloudflare側の操作です。WordPress内の変更はWordPress活動ログ、管理者一覧、プラグイン・テーマ更新、サーバーログで確認します。
ログがなければ変更されていないと判断できますか？
断定できません。v2はすべての製品・操作を完全に記録するものではなく、参照操作の記録も限定的です。期間、account、フィルター、v1、WordPress・サーバー側の変更も確認します。
まとめ
Cloudflare設定の変更原因を調べるときは、推測で設定を戻す前にAudit Logs v2を開き、Actor、Action、Resource、Time、Resultを一組で確認します。Resource Historyが使える場合も、差分の精度と現在の依存関係を確認してから一項目ずつ復旧します。
Audit Logsは設定操作、Security Eventsは防御イベント、Log Explorerは実通信、Traceは仮想評価、WordPress活動ログはサイト内操作です。役割を分け、不具合時刻と証拠をそろえて照合すれば、余計な設定変更を増やさずに原因へ近づけます。