検証した主張
「Cloudflareのアクセス総数を一つ監視すれば、攻撃・障害・利用者体験をすべて把握できる。」
発見元は調査の入口であり、判定の根拠には使用していません。問いごとにパネルを分ける
異常アクセスならTrafficのパス・国・メソッド、WAFのアクションを並べます。障害なら5xxの割合、対象URL、Workersの失敗・リソース超過を並べます。利用者体験ならWeb AnalyticsのLCP・INP・CLSを見ます。
Custom Dashboardsは既存の分析データをまとめる道具です。全件ログの代わりや、アプリの認証ログの代わりにはなりません。
平常値と判断線を決める
日ごとの上下ではなく、曜日・時刻・更新直後の基準値と比較します。どの程度の変化で誰が確認するか、どの設定を勝手に変えないか、先に運用ルールを決めます。
たとえばアクセス数が倍でも、公開記事の正規閲覧なら対処は不要かもしれません。5xxが少数でも決済やログインに集中するなら優先度が高くなります。
ダッシュボードで分からないものも記録
サンプリング、保持期間、対象外のWorkersサブリクエスト、アプリ内部の操作結果は、ダッシュボードだけでは補えません。事故後に必要な証跡は別途保存設計します。
見たい画面が契約プランで利用できるか、公式の提供条件と対象アカウントで確認してください。
検証条件・対象環境
| 対象プラン | 製品・契約プランで機能と表示範囲が異なる |
|---|---|
| 地域 | 提供地域・利用環境で表示や条件が異なる場合あり |
| 利用面 | Cloudflare Dashboard / Webサイト・API |
| 提供状態 | 2026年9月22日時点の公式公開資料。ダッシュボードの名称・契約条件は変更され得る |
| 実機確認 | Cloudflare公式資料で機能と制限を照合しました。個別のサイト・アカウントで設定変更や攻撃の再現はしていません。 |
| 次回見直し | 2026.10.22 |
よくある質問
Cloudflareのアクセス数だけでサイトの安全性を判断できますか？
監視画面は目的別に分け、トラフィック量、WAFイベント、5xx、Workers失敗、Web Analyticsを同じ意味の数値として足し合わせないことが重要です。
更新履歴
公式資料を確認し、固有の利用情報を含まない一般的な手順・注意点として整理。
実機検証は未実施のため、根拠レベルを公開基準に合わせてAからBに訂正。
情報源
一次情報と発見元を区別し、各ページの公開日と確認日を記録しています。
- Custom Dashboards
ダッシュボードの作成と監視。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Security Analytics (new dashboard)
TrafficとEventsの対象・Workersサブリクエストの扱い。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Workers metrics and analytics
Workerの実行・失敗・リソース超過指標。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Core Web Vitals
実ユーザー計測のLCP・INP・CLS。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22