WEBサイトCloudflare Tracesは、1つのリクエストが規則・書き換え・キャッシュ・オリジンのどこで時間を使ったかを追える ── 12月1日からの新料金の前に、使うかを決めて確認する14項目（2026年10月時点）
Cloudflare Tracesは、1つのリクエストが規則・書き換え・キャッシュ・オリジンのどこで時間を使ったかを追える ── 12月1日からの新料金の前に、使うかを決めて確認する14項目（2026年10月時点）
目次
01 何が起きたか — Cloudflare Tracesが、2026年10月2日にオープンベータになった
Workersの外にも、自動のトレースが広がった
Cloudflareは2026年10月2日に、公式ブログで「Introducing Cloudflare Traces」（訳: Cloudflare Tracesの紹介）を公開した。2026年10月12日に開いて確かめた。冒頭の文は、次のとおりである。
"Today, we’re introducing Cloudflare Traces in open beta, extending automatic tracing beyond Workers to the rest of the request path."
（訳: 本日、Cloudflare Tracesをオープンベータで紹介する。自動のトレースを、Workersの外の、リクエストの経路の残りの部分にまで広げる。）
「トレース」は、1つのリクエストが通った道筋を、時間つきで記録したものである。これまでCloudflareでは、Workers（Cloudflare上でコードを動かす仕組み）の中だけが自動で追えた。今回は、Workersを使っていないサイトでも、Cloudflareを手前に置いていれば、その通り道を見られる、というのが発表の要点である。
1つのトレースで、6つの場所が見える
ブログは、1つのトレースで見える範囲を、次のように書いている。
"In one trace, you can see supported security rules, transformations, cache decisions, routing, Worker execution, and origin handling, then continue that trace through services running on Cloudflare, at your origin, or elsewhere in your stack."
（訳: 1つのトレースの中で、対応しているセキュリティの規則、変換、キャッシュの判断、ルーティング、Workerの実行、オリジンでの処理を見られる。そのうえで、そのトレースを、Cloudflare上で動くサービス、自社のオリジン、または別のところに続けられる。）
「supported」（訳: 対応している）が付く点は、読むときに外せない。すべての処理が見えるわけではなく、対応している区間だけが見える。何が未対応かは、04章で整理する。
同じ日の「8つの更新」の1つで、新しい料金も一緒に出た
Cloudflareは同じ日に、もう1本のブログ「8 major updates to Cloudflare Observability」（訳: Cloudflare Observabilityの8つの大きな更新）を出した。ログ、トレース、分析、アラート、ダッシュボード、書き出しを1つの観測の仕組みにまとめる、という内容で、Tracesはその2つ目にあたる。2026年12月1日から、ログとトレースに新しい料金の仕組みが始まる。この記事は、Tracesが何を見せるかと、料金が変わる前に確かめることを扱う。
一次情報
2本のブログ（2026年10月2日）に加えて、Cloudflareのドキュメントの「Traces」（最終更新2026年10月9日）と「Pricing」（最終更新2026年10月5日）も、2026年10月12日に開いて読んだ。料金の数字は、ブログとドキュメントの表記のままで、換算や丸めはしていない。
02 なぜ・背景 — Cloudflareが黒い箱のようだという声に、時間の内訳で答えた
設定と処理時間が、別々の画面にあった
ブログは、動機をこう書いている。
"We hear you when you say Cloudflare can feel like a black box."
（訳: Cloudflareが黒い箱のように感じられる、という声を聞いている。）
画面が遅い、ある訪問者だけが止められた、という報告を受けたとき、手がかりは、別々のログと設定に分かれて残る。設定が処理時間にどう響いたかを、1件のリクエストでつなぐのが、Tracesの狙いである。
Workers Tracingが、先に1年あった
ブログによると、Workersの自動トレースは「Last year」（訳: 昨年）に始まった。Workerの呼び出し、外部への取得、KV・R2・D1などの呼び出しが、追加のコードなしで見える仕組みだった。今回の発表は、その見え方を、Workersを使わない利用者にも広げる、という位置づけである。
ログと、トレースの違い
ログは、1件ずつの出来事の記録である。トレースは、1件のリクエストの内側を、区間に分けて時間で並べたものである。ブログは、別々のログと設定からリクエストを組み立て直す代わりに、通り道を1か所で見られる、と書いている。記録を残す道具と、中を追う道具は、役割が違う。
料金も、数え方が変わる
料金は、スパンやイベントの数ではなく、取り込んだ量と、保持した期間で決まる形に変わる。ブログは、理由を次のように書いている。
"Because logs and traces can vary dramatically in size, the new model is based on the volume you ingest and store rather than an event-based count."
（訳: ログとトレースは大きさが大きく異なりうるので、新しい仕組みは、イベントの数ではなく、取り込んで保存する量に基づく。）
03 用語 — トレース・スパン・サンプリングなどを、先に分けておく
トレースとスパン
トレースは、1つのリクエストの全体の道筋で、スパンは、その中の1つ1つの作業の区間である。Cloudflareのブログは、「Cloudflare Traces records each supported step as a span, including its timing, outcome, and relevant attributes.」（訳: Cloudflare Tracesは、対応している各段階を、時間、結果、関連する属性を含めて、スパンとして記録する。）と書く。OpenTelemetryの文書の定義も同じ向きである。
"A span represents a unit of work or operation."
（訳: スパンは、1つの作業または操作の単位を表す。）
サンプリングとTrace Rules
すべてのリクエストを記録せず、一部だけを記録するのが、サンプリングである。基準になる割合を決め、特定の条件に合うリクエストだけ、割合を上げる決まりが、Trace Rulesである。
traceparentとOTLP
traceparentは、トレースをつなぐためのHTTPヘッダーで、W3Cが標準にしている。W3Cの文書は、次のように書く。
"The traceparent header represents the incoming request in a tracing system in a common format, understood by all vendors."
（訳: traceparentヘッダーは、トレースの仕組みの中で、受け取ったリクエストを、すべての提供元が理解できる共通の形で表す。）
OTLPは、OpenTelemetryのデータを送る決まりである。Cloudflareは、OTLPに対応した送り先なら、スパンを書き出せる、と書いている。
取り込み（ingestion）と、GB-month
取り込みは、受け取ったデータの量（GB）である。GB-monthは、保存の量の単位で、ドキュメントによると、「毎日の保存量の最大値を足して30で割る」計算である。1GBを30日間保存すると1GB-monthになる。
Ray IDと、Cloudflare Trace（単数）
Ray IDは、Cloudflareが1件のリクエストに付ける識別子で、ダッシュボードでトレースを探すときの手がかりになる。名前が似たものに、「Cloudflare Trace」（単数）がある。ドキュメントは、こう書いている。
注意
「Cloudflare Trace simulates how Cloudflare configurations would handle a request. It does not show actual production traffic.」（訳: Cloudflare Traceは、Cloudflareの設定がリクエストをどう扱うかを模擬する。実際の本番のトラフィックは表示しない。）とある。複数形のTracesは本番の記録、単数形のTraceは模擬である。画面で取り違えると、見ているものが本番でない。
04 型別 — 何が見えて、何が見えないかを、手順と料金に分けて読む
適用範囲: ドメインごとに有効にする
有効にするのは、ドメインごとである。ドキュメントは、「Enable tracing separately for each domain in your account.」（訳: アカウントの中のドメインごとに、別々にトレースを有効にする。）と書く。ブログは、追加の準備を「There is no special instrumentation, config, or plugins required.」（訳: 特別な計測コード、設定、プラグインは要らない。）とし、有効にすれば、スパンが自動で作られる、と書いている。
追える問いを、スパンと対にして読む
ブログは、答えられる問いを、4つ挙げている。表では、各問いで見るスパンと、自社で確かめることを並べた。スパンの名前は、ブログに出てくるものだけを書いている。
| 問い | 見る場所 | 自社で確かめること |
|---|---|---|
| 止められた理由 | 規則を評価したスパンのイベント（どの規則が動いたか） | 止められた1件のRay IDを控える手順があるか |
| URLの書き換え | http_request_transformのスパン | 書き換え規則を、どこで管理しているか |
| 扱った規則・Workers | workers_routingのスパン | Workersを使っているか、使っていないか |
| 時間の使い先 | キャッシュ、上流、オリジンの入れ子のスパン | キャッシュに当たらない種類のページは何か |
サンプリングは、リクエストが届いた時点で決まる
ドキュメントは、遅いリクエストやエラーだけを記録できるか、という質問に、こう答えている。
"Tail-based sampling is not currently supported."
（訳: 結果を見てから決めるサンプリングには、今は対応していない。）
決めるのは、リクエストが届いた時点で、結果は分からない。だから、遅かった1件を、あとから狙って拾うことはできない。拾うには、あらかじめ割合を決めるか、特定のヘッダーに対して100%にするTrace Rulesを置く。ドキュメントも、「create a trace rule that matches a custom debug header and sets the sample rate to 100%」（訳: 調査用のヘッダーに一致して、サンプルの割合を100%にするTrace Ruleを作る）と案内している。
実務のヒント
取り込み量は、記録する割合で減らせる。ドキュメントは、「Sampling data before storage reduces both ingestion and storage usage.」（訳: 保存の前にデータをサンプリングすると、取り込みと保存の両方の使用量が減る。）と書く。割合を下げるほど料金は下がり、調査で拾える件数も減る。
記録される・されないもの
ドキュメントは、スパンに残るものを、次のように書く。
"Header names and the operations performed on them are captured. Header values are not captured. URLs and query strings are captured."
（訳: ヘッダーの名前と、それに行った操作は記録される。ヘッダーの値は記録されない。URLとクエリ文字列は記録される。）
URLの「?」より後ろ（クエリ文字列）は記録される。そこに、氏名やメールアドレス、トークンが入る作りなら、トレースにも残る。先に自社のURLの作りを確かめる必要がある。
まだ無いもの
ブログは、オープンベータの後に出す予定のものを列挙している。
"Ad hoc tracing: Capture a specific request on demand without changing the baseline sampling rate."
（訳: その場限りのトレース: 基準のサンプリングの割合を変えずに、特定のリクエストを、その場で記録する。）
"Broader automatic instrumentation: Add more spans across both the HTTP request path (e.g. DDoS rules, Access) and the Workers execution path (e.g. Workflows, Queues, Pipelines)."
（訳: より広い自動の計測: HTTPのリクエストの経路（たとえばDDoSの規則、Access）と、Workersの実行の経路（たとえばWorkflows、Queues、Pipelines）の両方に、スパンを増やす。）
ほかに、信頼した呼び出し元だけがトレースを続けられる「認証つきの伝播」と、最大365日の保持も、予定に入っている。つまり、今は、DDoSの規則やAccessの処理が、スパンに出ない可能性がある。ドキュメントは、スパンの名前や構造も、変わりうる、と注意している。
"Span names and structure may change as the product evolves. Do not build hard dependencies on the exact shape of Cloudflare-emitted spans."
（訳: スパンの名前と構造は、製品の進化に合わせて変わりうる。Cloudflareが出すスパンの正確な形に、強く依存しないこと。）
手順: サンプリング、規則、受け渡し、書き出し
手順は、4段である。1段目で、ドメインのトレースを有効にし、基準のサンプリングの割合を決める。ブログは、通常時に「1% of requests」（訳: リクエストの1%）を例に挙げている。2段目で、Trace Rulesを置く。ブログは、特定のホスト名、送信元のIP、識別できるヘッダーに対して、100%にする例を書いている。3段目で、traceparentの受け取りと、オリジンへの受け渡しを決める。4段目で、アカウント単位の送り先を決め、ドメインごとに送る。
"If one customer reports a problem, you can trace 100% of traffic for their hostname, source IP, or identifying request header while leaving everyone else at 1%."
（訳: ある顧客が問題を報告したら、その顧客のホスト名、送信元のIP、識別できるリクエストのヘッダーの通信を100%トレースし、ほかのすべての人は1%のままにできる。）
料金: 取り込みと保存を、別々に数える
新しい料金は、2026年12月1日から始まる。ブログの文は、次のとおりである。
"Beginning December 1, 2026, this pricing model will apply across all plans (effective upon renewal for all Enterprise customers) and cover existing Developer Platform logs, including Workers, Containers, AI Gateway, as well as all tracing data."
（訳: 2026年12月1日から、この料金の仕組みは、すべてのプランに適用される（Enterpriseの利用者は更新時に有効）。既存のDeveloper Platformのログ（Workers、Containers、AI Gatewayなど）と、すべてのトレースのデータを対象にする。）
表記は、ブログの料金の表と、ドキュメントのとおりである。
注意
Freeは、日の上限に達すると新しいデータの取り込みが止まる。ドキュメントは、「Ingestion resumes when the allowance resets at 00:00 UTC.」（訳: 取り込みは、枠が00:00 UTCに戻ったときに再開する。）と書く。00:00 UTCは、日本時間の午前9時である。また、「Allowances do not roll over between billing cycles.」（訳: 枠は請求期間をまたいで繰り越されない。）ので、使い残しは、次の期間に持ち越せない。
Paid・Enterpriseの保持は、ブログの表に「Up to 1 year (coming soon)」（訳: 最大1年（近日対応））とあり、読み違えやすい。ドキュメントは、「Logs and traces in the shared allowance have a default seven-day retention.」（訳: 共有の枠のログとトレースは、既定で7日の保持である。）と書き、30日・90日・365日の選択は「plans to add」（訳: 追加する予定）としている。今すぐ1年保存できる、とは読めない。
05 自分のサイトで確認するチェックリスト
下の14項目は、1項目5分ほどでできる作業である。項目2の答えが「ない」なら、項目3〜12は飛ばして、項目13へ進んでよい。チェックの状態は、ブラウザの中にだけ保存される。
- Cloudflareのブログ2本（Introducing Cloudflare Traces、8 major updates to Cloudflare Observability）を開き、公開日（2026年10月2日）と、新料金が始まる日（2026年12月1日）をメモに書き写す
- 自社のトップページにcurl -Iを送り、応答ヘッダーにcf-rayの行があるかを「ある」「ない」で書く
- Cloudflareのダッシュボードで自社のドメインを開き、契約のプランを「Free」「Pro」「Business」「Enterprise」のどれかで書く
- ダッシュボードのObservabilityの項目を開き、「Traces」と「Cloudflare Trace」（単数）の2つの名前が出ているかを、見えた名前のまま書き写す
- Workers LogsかWorkers Observabilityを使っているかを調べ、使っているなら、12月1日から新しい料金に移ることを、日付つきで書く
- 1か月に取り込むログとトレースの量の見込みをGBで書き、（見込み − 50）× 0.25の式で、Paidの取り込みの超過分をドルで書く
- 障害や遅延の調査で遡りたい日数を「◯日」で書き、既定の保持の7日で足りるかを「足りる」「足りない」で書く
- 通常時にトレースする割合を、1%を出発点にして数字で書き、その理由を1行で書く
- Trace Rulesで100%にする条件を、ホスト名・送信元のIP・ヘッダーの3つから1つ選び、具体的な値（たとえば調査用のヘッダー名）を書く
- 自社のフォームやリンクのURLを3つ開き、「?」より後ろに入る値（氏名、メールアドレス、トークンなど）を、種類だけ書き出す
- OpenTelemetryで計測しているアプリがあるかを担当者に聞き、あれば、traceparentヘッダーを受け取る設定があるかを「ある」「ない」「不明」で書く
- いま使っているLogpush・分析（30日）・Logs・Tracesのうち、どれを何のために使うかを、1行ずつ書く
- Cloudflareを通っていないなら、トップページと記事ページ1本にcurlを5回ずつ送り、応答が始まるまでの時間（time_starttransfer）の最短と最長を、ミリ秒で書く
- Cloudflareが料金の変更の前に送るはずの通知の宛先メールアドレスを確かめ、担当者が受け取れるかを「受け取れる」「受け取れない」で書く
06 代替・他の選択肢 — 記録を残す、遡る、中を追う、を使い分ける
Logpushは、記録を自社に残す
1つ目は、Logpushである。ブログは、「Logpush, previously available only to Enterprise, is now available on all self-serve plans」（訳: Logpushは、以前はEnterpriseだけだったが、すべてのセルフサービスのプランで使える）と書く。書き出しの料金は、Cloudflareの送り先が25GBまで含まれ、超過は1GBあたり0.03ドル、外部の送り先が25GBまで含まれ、超過は1GBあたり0.10ドルである。詳しくは、当サイトの記事「CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）」で扱った。
分析は、30日を遡れる
2つ目は、分析である。ブログは、「In addition, you now get 30 days of domain analytics on every plan.」（訳: さらに、すべてのプランで、ドメインの分析が30日分見られるようになった。）と書く。先月の同じ曜日と比べる使い方である。残す数字の決め方は、当サイトの記事「Cloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点）」にまとめた。
Logsは、1件ずつ調べる
3つ目は、新しいLogsの画面である。ブログによると、Workersの観測と、セキュリティのログの検索を1つにまとめ、Ray IDで1件ずつ調べられる。Tracesは、そのうちの1件の中の時間を、区間に分けて見る道具で、Logsを置き換えるものではない。
| 道具 | 分かること | 保持・料金の表記 | 向く場面 |
|---|---|---|---|
| Logpush | 送ったログの全体 | 自社の保管場所の分は自社で決める | 記録を手元に残す |
| 分析（30日） | 集計した数字の推移 | すべてのプランで30日 | 先月と今月を比べる |
| Logs | 1件ずつの出来事 | 共有の枠は既定で7日（セキュリティのログの一部は30日） | Ray IDで1件を探す |
| Traces | 1件の中の区間ごとの時間 | 共有の枠で既定は7日 | どの区間で遅れたかを見る |
外部の観測の道具へ送る
OTLPに対応した送り先があるなら、スパンをそちらへ書き出して、自社のアプリの記録と並べられる。ドキュメントには、Honeycomb、Grafana Cloud、Axiom、Sentry、PostHogへの書き出しの案内がある。どの送り先を選ぶかは、自社の既存の道具に合わせる。この記事では、各送り先の料金や機能の違いは確かめていない。
サイト全体の遅さを、Cloudflareを使わずに調べるときは、当サイトの無料ツール🔧 WEBサイト総合分析・レポートツールや、ログインして使う🔧 WEBサイトの 最大３ページ Lighthouse監査・チェックツールで、ページ単位の様子を見られる。
07 当サイトで確かめたこと
当サイトはCloudflareを通していないので、Tracesは使えない
2026年10月12日に、当サイトのトップページへcurlで応答ヘッダーを取得した。cf-rayの行は無かった。当サイトは、Cloudflareを通していない。したがって、Tracesで1件の中を見ることはできず、05章の項目2の答えは「ない」になる。
Tracesが無くても、粗い切り分けはできる
Tracesの代わりにはならないが、curlの時間の内訳で、どこで時間を使ったかを大きく分けられる。2026年10月12日の午後5時台に、6ページへ5回ずつ、自分のパソコンから送った。表は、応答が始まるまでの時間（time_starttransfer）の最短から最長と、内訳の中央値である。
| ページ | 応答開始まで（最短〜最長） | 名前解決 | 接続 | 暗号化の確立 | 応答待ち |
|---|---|---|---|---|---|
| トップページ | 200〜1,927ミリ秒 | 21 | 61 | 377 | 290 |
| サイトマップ | 262〜455ミリ秒 | 21 | 62 | 113 | 153 |
| robots.txt | 161〜896ミリ秒 | 19 | 43 | 89 | 121 |
| ブログ記事 | 375〜14,482ミリ秒 | 40 | 137 | 159 | 328 |
| 解説記事 | 385〜809ミリ秒 | 25 | 52 | 126 | 208 |
| ツール | 229〜4,639ミリ秒 | 16 | 66 | 68 | 138 |
この数字から言えることと、言えないこと
内訳の4列は、各段階までの時間の中央値から、前の段階の中央値を引いた概算で、単位はミリ秒である。6ページとも、200で返った。目立つのは、ページによって、最長が最短の数倍から数十倍になったことである。ブログ記事の最長は14,482ミリ秒、ツールは4,639ミリ秒だった。この外れ値の原因は、1回の測り方では分からない。自分のパソコンからの回線の揺れか、サーバーの側かも、切り分けていない。
言えるのは、時間が、名前解決・接続・暗号化の確立・応答待ちのどこに多く出たか、までである。サーバーの中のどの処理が待ちを作ったかは、この方法では見えない。そこを区間で見せるのが、Tracesのような仕組みである。遅さの比べ方は、当サイトの記事「CloudflareのBEACONは、大手1万サイトをドメインを外して集計した公開データで、自社の数字は引けない ── 「他社より遅い」と言われたとき、比べる相手を確かめる13項目（2026年10月時点）」でも扱った。
測っていないこと
1か所、5回ずつの測定で、時間帯も1つである。Cloudflareのダッシュボードの画面は、当サイトでは使っていないので、見ていない。Tracesの実際の画面は、この記事を書いた時点で、触っていない。
08 このテーマの、これまで
Cloudflareの観測の機能の、これまでの流れ
ブログによると、Workersの自動トレースは「Last year」（昨年）に始まった。2026年10月2日の発表は、トレースの対象を広げ、分析の30日保持やLogpushの開放、新しい料金を、同じ日に1つの観測の仕組みとしてまとめた。昨年の具体的な月日は、確かめていない。
公式の文書の、最終更新日
- Introducing Cloudflare Traces（訳: Cloudflare Tracesの紹介）: 2026年10月2日（Cloudflare Blog）
- 8 major updates to Cloudflare Observability（訳: Cloudflare Observabilityの8つの大きな更新）: 2026年10月2日（Cloudflare Blog）
- Traces（Cloudflare Observabilityのドキュメント）: 最終更新2026年10月9日
- Pricing（Cloudflare Observabilityのドキュメント）: 最終更新2026年10月5日
- Logpush（Cloudflare Logsのドキュメント）: 最終更新2026年9月30日
当サイトの、これまでの記事
- CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点） — 記録を残す側
- Cloudflareの分析データが、すべてのプランで最低30日分になった ── 先月の同じ曜日や障害の日を遡る前に、残す数字を決める13項目（2026年10月時点） — 30日遡る側
- CloudflareのBEACONは、大手1万サイトをドメインを外して集計した公開データで、自社の数字は引けない ── 「他社より遅い」と言われたとき、比べる相手を確かめる13項目（2026年10月時点） — 他社の数字と比べる前の確認
- AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた — ログは、見る範囲で結論が変わる
現在の貴方のIPアドレス
このサイトで書いている人
