何が変わった？ログが消えたとは限らない

Cloudflareは2026年10月7日、Log Explorerの検索をダッシュボードの Observability > Logs で行うよう変更したと発表しました。従来のLog Explorerメニューはナビゲーションに表示されなくなりますが、有効なデータセット、保存した検索、SQLは新しい画面で引き続き利用できると説明しています。旧Log Search画面も直接URLから利用可能です。公式発表

対象はLog Explorerの検索導線です。この告知だけで「すべてのログが無料になった」「過去に収集していないログも見られる」とは判断できません。

移動先で確認する順序

公式のLog Search手順に沿って、まず次の順序で確認します。

  1. 調べたいサービスを管理しているCloudflareアカウントを選びます。
  2. Observability > Logsを開き、データセットの選択欄から目的のLog Explorerデータセットを選びます。例としてHTTP requestsが案内されています。
  3. ドメイン単位のデータなら、対象ドメインと検索期間を指定します。
  4. フィールド・演算子・値で条件を絞ります。SQLを使う場合はOpen SQL editorへ進みます。SQLの利用対象はLog Explorerデータセットです。
  5. 以前の検索を使う場合はSaved searchesを確認します。データセットを管理する場合は、選択欄の該当Log Explorerデータセット横にあるConfigureを確認します。

画面項目の日本語訳や配置は個別環境で未確認です。この記事は公式資料の案内であり、当サイトのアカウントで検索を再現した記録ではありません。

「0件」と「異常なし」を同じにしない

以下は当サイトの調査上の提案です。結果が空でも、直ちに設定を作り直したり、課金を伴う機能を有効化したりする必要があるとは限りません。

まずアカウント、データセット、ドメイン、期間、絞り込み条件を一つずつ点検します。Logsの公式概要では、利用できるフィールドと保持期間はデータセットごとに異なり、一部は元の製品で有効化が必要とされています。収集対象外・保持期間外であれば、その検索結果だけで過去の障害の有無は判断できません。

架空の例：問い合わせ時刻の前後を調べる

架空の店舗サイトで、ある日の14時ごろにページ表示が遅かったとします。担当者は最初に、そのサイトと短い対象期間を指定してHTTPリクエストを調べます。結果がなければ条件と収集範囲を確かめ、結果があれば応答ステータスなど必要な項目を見ます。これは説明用の例で、実際の障害事例ではありません。

「メニューが消えたから再設定」ではなく「何を、いつ、どの範囲で探しているか」を揃えると、別ドメインのログや別時刻の結果を誤って調べることを防ぎやすくなります。

便利になる点と、残る限界

公式発表では、Log ExplorerとWorkers Observabilityのデータセットを、共通のフィルター、SQLエディター、可視化を持つLogs画面にまとめると説明しています。当サイトの評価では、Web配信とWorkersを併用する担当者が、調査の入口を揃えやすくなる点が有用です。ただし、入口の統合は、各データセットの項目・保持期間・利用条件が同一になることではありません。

また、公式資料では、実際の通信を調べるLog Explorerと、仮のリクエストでルールを試すCloudflare Trace（画面上のRule simulator）を区別しています。過去に何が起きたかの確認と、設定がどう働くかの試験は使い分けましょう。

ログを相談資料にするときの注意

当サイトの運用上の提案として、実ログを記事や公開リポジトリへそのまま貼らないでください。必要な時刻・症状・集計結果だけに絞り、実ドメイン、個人の識別情報、認証情報、URLに含まれる秘密値などが混ざっていないか点検します。見本はexample.comなど架空の値に書き換え、実データではないことも明記します。

今回確認したのは公式資料の本文までです。個別契約の料金、権限、保存検索の移行結果や検索速度は確認していません。既存設定の削除や再作成を急ぐより、まず移動先と検索範囲を確認するための記事として利用してください。