Cloudflare 32：分析とログ ― 何が起きているかを見る

Cloudflare では、見る場所が大きく6つある

Cloudflare の「見る」ための道具は、何を知りたいかによって分かれています。

最初に押さえておきたいのは、「ブラウザで計る」と「エッジで計る」は別物だということです。ブラウザで計る Web Analytics は、実際にページを開いた人を数えます。エッジで計るゾーンの分析は、ボットや API の呼び出しも含め、Cloudflare を通ったすべての通信を数えます。同じ「アクセス数」でも、数字が違って当たり前です。

次のページから、1つずつ見ていきます。

Web Analytics：訪問者の数とページの速さを、Cookie なしで

Web Analytics は、Web サイトの訪問者を数える無料の道具です。Google Analytics のような道具と同じ目的ですが、プライバシーを最優先に作られているのが特徴です。

仕組みは、ページに小さなスクリプト（ビーコン）を置き、ページが表示されたときに、どのページが、どのくらいの速さで表示されたかを Cloudflare に送る、というものです。

サイトが Cloudflare のプロキシを通っているなら、管理画面で有効にするだけで、Cloudflare がエッジでビーコンを自動的にページに差し込めます。Cloudflare を通っていないサイトでも、渡されるスクリプトのタグを HTML に貼れば使えます。

「誰が」は分かりませんが、「何人が、どのページを、どの国から、どのくらいの速さで見たか」は分かります。多くのサイトには、これで十分です。

ゾーンの分析：エッジを通ったすべての通信を数える

ドメイン（ゾーン）を Cloudflare に追加すると、管理画面の分析のページで、そのゾーンを通った通信の様子が見られるようになります。特別な設定は要りません。

Web Analytics との違いは、ブラウザ以外の通信も全部数えることです。検索エンジンのクローラー、他のサービスからの API の呼び出し、攻撃のためのアクセスも含まれます。逆に、キャッシュされたページの中で JavaScript が動かなかった、といったことは分かりません。

ですから、「人が何人来たか」は Web Analytics で、「サーバーやエッジにどれだけの負荷が来ているか」はゾーンの分析で、と使い分けます。どこまで細かく、どのくらい過去までさかのぼって見られるかは、プランによって違います。

Workers Logs：Worker の console.log を保存して検索する

Worker（18号）の中で何が起きているかを知る基本は、ログです。コードの中で console.log() や console.error() を書くと、その内容がログとして出ます。

Workers Logs は、これらのログを Cloudflare の中に保存し、あとから検索できるようにする機能です。wrangler の設定ファイルに次の1行を足してデプロイするだけで有効になります。

[observability]
enabled = true

有効にすると、管理画面の Worker のページで、ログを時間や内容で絞り込んだり、「エラーの件数を1時間ごとに数える」といった集計をしたりできます。例外（キャッチされなかったエラー）や、リクエストの基本情報（URL、状態コード、処理時間など）も自動で記録されます。

アクセスの多い Worker では、全部を残すと量が多くなりすぎます。そういうときは head_sampling_rate で、リクエストの何割だけを記録するかを決めます。1 なら全部、0.1 なら1割です。

ログは、文字列ではなくオブジェクトで書くのがおすすめです。console.log({ event: "checkout", userId, ms }) のように書くと、項目ごとに検索や集計ができるようになります。

その場で見る：wrangler tail でログを流す

Workers Logs が「あとから探す」ための道具だとすれば、wrangler tail は「今まさに起きていること」を眺めるための道具です。

npx wrangler tail my-worker --format pretty
npx wrangler tail my-worker --status error

実行すると、本番で動いている Worker に届いたリクエストと、そのとき出たログが、手元の端末にリアルタイムで流れてきます。--status error を付けると失敗したものだけ、ほかにも HTTP メソッドや検索語で絞り込むオプションがあります。管理画面にも、同じようにリアルタイムでログを見る画面があります。

ただし、tail は流れているものを見るだけで、端末を閉じたら何も残りません。本番では Workers Logs を有効にしておき、tail は「今この瞬間を見たい」ときの補助として使いましょう。

ログに書く内容には注意が要ります。パスワード、トークン、クレジットカードの番号、個人を特定できる情報は、ログに書かないのが原則です。ログは多くの人が見られる場所に、長く残るからです。

トレース：1回の処理が、どこで時間を使ったか

「この API は遅い」と分かっても、どこで遅いのかが分からなければ直せません。自分のコードの計算なのか、KV（20号）や D1（23号）からの読み出しなのか、外部の API の待ち時間なのか。

トレースは、1回のリクエストの処理を、中で呼んだものごとに区切って、それぞれにかかった時間を記録する仕組みです。管理画面では、横に並んだ線の長さとして表示されるので、どこで長く待っていたかが一目で分かります。

Workers では、設定ファイルに次のように書くと、トレースが有効になります。

[observability.traces]
enabled = true

fetch() による外部への呼び出しや、KV・D1・R2 などのバインディングの呼び出しは、コードを書き換えなくても自動で記録されます。

トレースは比較的新しい機能で、料金や提供の条件が変わっている途中です。使う前に公式のページで現在の扱いを確かめてください。また、OpenTelemetry に対応した外部のサービスへ、ログやトレースを送り出すこともできます。

Logpush：生のログを、外の保存先へ送り続ける

ここまでの道具は、Cloudflare の管理画面の中で見るものでした。でも、次のような要望もあります。

「1年分のログを残しておきたい（監査や法令のため）」「他のシステムのログと合わせて調べたい」「自分たちのセキュリティ監視の仕組み（SIEM）に入れたい」

Logpush は、Cloudflare が記録した1件1件の生のログを、決めた保存先へ自動で送り続ける機能です。

送れるログには、ゾーンの HTTP リクエストのログ、ファイアウォールのイベント、Workers の実行のログ（Workers Trace Events）などがあります。「どの種類のログの、どの項目を、どこへ」を登録すると、あとは Cloudflare が一定の間隔でまとめて送ってくれます。

ゾーンの HTTP ログの Logpush は上位のプラン（Business・Enterprise）の機能です。Workers のログの Logpush は Workers Paid プランで使え、wrangler の設定に logpush = true を書いて有効にします。

GraphQL Analytics API：数字をプログラムで取り出す

管理画面のグラフの元になっている数字は、GraphQL Analytics API から取り出せます。GraphQL は、「どのデータの、どの項目が欲しいか」を1つの問い合わせで指定できる API の形式です。

たとえば、あるゾーンの直近のリクエスト数・転送量・キャッシュから返した数を日ごとに取るなら、次のように問い合わせます。

POST https://api.cloudflare.com/client/v4/graphql

query {
  viewer {
    zones(filter: { zoneTag: "ゾーンID" }) {
      httpRequests1dGroups(limit: 7, filter: { date_geq: "2026-09-01" }) {
        dimensions { date }
        sum { requests bytes cachedRequests }
      }
    }
  }
}

認証には、分析の読み取り権限を持つ API トークンを使います。

ゾーンの通信だけでなく、Workers の実行回数や、ほかの製品の数字も取り出せます。どんなデータセットがあるかは、公式のスキーマの説明で確かめられます。無料プランでも使えますが、さかのぼれる期間や細かさはプランによって違います。

導入：それぞれの有効にしかた

6つの道具を、どう有効にするかをまとめます。

新しくサイトやアプリを作ったら、まず Web Analytics と Workers Logs をオンにしておくのがおすすめです。どちらも手間がほとんどかからず、問題が起きたときに「記録が無い」という事態を避けられます。

Logpush や GraphQL API は、運用が本格的になってから、必要に応じて足していけば十分です。

料金と制限：無料で見られる範囲は広い

2026年9月時点の料金と主な制限の骨格です。

Workers Logs の件数は、ログ1行ごと（とリクエストの記録）で数えます。1回のリクエストで console.log を10回書けば、それだけ件数が増えます。アクセスの多い Worker では、head_sampling_rate で記録する割合を下げるか、ログの量を見直しましょう。

保存期間を過ぎたログは消えます。長く残したいものは、Logpush で R2 などに送っておきます。

数字は変わることがあるので、公式の Pricing と Limits のページで確かめてください。

よくある落とし穴

分析とログでつまずきやすい点です。

とくに最初の点は、事故につながります。ログは、開発者や運用の担当者、場合によっては外部のサービスまで、多くの人や仕組みが見る場所です。「ログに書いたものは、誰かに見られる」と考えて書きましょう。

他の機能とのつながり

「見る」ための道具は、ほかのすべての号の機能の効き目を確かめる場所です。

また、アプリ独自の数字（「今日の購入数」「AI の回答にかかった時間」など）を記録して集計したいときは、Workers から書き込める Workers Analytics Engine という仕組みもあります。数字を大量に書き込み、あとで SQL で集計する用途に向いています。