Cloudflare Traces がオープンベータ。計装なしでリクエストの通過経路をスパン分解し、Trace Rules で特定トラフィックだけ深掘りできる

要約

Cloudflare Traces がオープンベータに入りました。リクエストが Cloudflare のプラットフォームをどう通過したかを、1本のタイムラインとして出します。

この機能が埋めるのは、障害調査で一番困る空白です。 Cloudflare を前段に置く構成では、クライアントから見た応答時間と、オリジンサーバーのログに残る処理時間が合いません。その差分が Cloudflare の内部で起きていることは分かっても、何に時間がかかったのか、どのルールが介入したのかは見えませんでした。 「Cloudflare を疑っているが証拠がない」という状態で止まる調査は珍しくありません。

Traces は、この区間をスパン（処理1ステップの記録。所要時間・結果・属性を持つ）に分解します。 対象はセキュリティルール、Transform Rules、キャッシュ、ルーティング、Workers 実行、オリジン処理です。

計装（instrumentation）が要らない点が重要です。 アプリケーション側にコードを足す必要はなく、Cloudflare 側で自動的にスパンが生成されます。「調査したい事象が起きてから有効化しても、過去は見られない」という制約はあるものの、導入のハードルはほぼゼロです。

サンプリングは2段構えです。 まずベースラインのサンプリング率を決めます（通常時は1%など）。そのうえで Trace Rules により、Cloudflare の Rules 言語で特定のトラフィックだけベースラインを上書きできます。

この2段構えが実用上の肝です。 「特定の顧客からのリクエストだけ失敗する」類の、再現しないが報告はある事象では、全体のサンプリング率を上げると費用もノイズも跳ね上がります。該当IPだけ 100% トレースすれば、費用を抑えたまま証拠が取れます。

何が変わったか

• Cloudflare Traces がオープンベータとして全プランで利用可能に
• 計装不要。 Cloudflare 側が自動でスパンを生成する
• 追える対象: どのセキュリティルールがブロック / チャレンジしたか、Transform Rules が URL を書き換えたか、レスポンスがキャッシュとオリジンのどちらから返ったか、どの Page Rules / Snippets / Workers が処理したか
• ベースラインのサンプリング率を設定可能
• Trace Rules で、ホスト名・IPアドレス・ヘッダーなどを条件に特定トラフィックのサンプリング率を上書き
• OTLP で任意のオブザーバビリティ基盤へエクスポート可能
• W3C traceparent ヘッダーを受け取り、新しいヘッダーをオリジンへ転送。前後のトレースがつながる
• 料金は 2026-12-01 発効の Observability 新体系に従う。Free は1日0.5GB取り込み・保持7日（エクスポート不可）、有料 / Enterprise は 50GB取り込み + 10GB・月込みで保持は最長1年

業務インパクト（一般企業向け）

切り分けの会話が変わります。 「Cloudflare が遅いのでは」という疑いに対し、従来は双方が推測で話すしかありませんでした。スパン単位のデータがあれば、どこで何ミリ秒使われたかを示して終わります。 ベンダーとの折衝でも、社内の部門間でも、議論の時間が減ります。

WAF の誤検知調査が、特に楽になります。 「一部のユーザーだけフォーム送信が失敗する」事象で、どのセキュリティルールが介入したかが即座に分かるのは大きい変化です。従来は WAF のログを別途探し、該当リクエストを特定する手順が必要でした。

導入時にまず決めるのは、ベースラインのサンプリング率です。 1% が例として挙げられていますが、トラフィック量と 2026-12-01 からの容量課金を踏まえて決めるべき数字です。低すぎると日常の傾向が見えず、高すぎると費用がかさみます。まず低め（0.1〜1%）で始め、Trace Rules で必要な調査だけ深掘りする運用が無難です。

W3C trace context の対応は、既存の分散トレース環境がある組織に効きます。 オリジン側で OpenTelemetry を既に使っているなら、Cloudflare の区間が同じトレースの一部として表示されます。 これまで「Cloudflare の手前と後ろで別のトレース」だったものが1本になります。

Free プランではエクスポートができない点は、検証段階で把握しておくべき制約です。Cloudflare の画面内で見ることはできますが、既存基盤への統合は有料プランからになります。

オープンベータである点も、前提として共有が要ります。 本番の障害対応手順に組み込む前に、仕様変更の可能性を運用ドキュメントに明記しておくと、後で困りません。

副業・個人活用視点

受託案件での「原因不明」を減らせます。 小規模案件では、監視基盤に予算が付かないまま本番運用が始まることがよくあります。計装不要で、Free プランでも画面内で見られるという条件は、この状況に素直に合います。

提案の場面では、「調査できる状態を最初から作る」と言えるようになります。 障害が起きてから監視を入れる提案は通りにくいものですが、追加コストがほぼ無いなら、初期構成に入れておく理由が立ちます。

Trace Rules は、クレーム対応の実務で効きます。 「○○さんだけログインできない」という報告に対し、その人のIPだけ 100% トレースして再現を待つという手が使えます。全体のログを漁る作業と比べて、時間の差が大きいです。

スキルとしての価値は、OpenTelemetry との接続部分にあります。 Cloudflare 単体で見るだけなら誰でもできますが、OTLP でエクスポートして既存基盤と統合し、前後のトレースをつなぐ構成を組んだ経験は、そのまま提案力になります。W3C trace context の伝播を理解していることが前提になるため、学習の投資先として悪くありません。

2026-12-01 の課金変更は、Traces にもかかります。 「とりあえず全部トレース」の設定で放置すると、12月に請求が跳ねます。サンプリング率の設定を顧客へ引き渡す前に説明しておくのが、後のトラブルを防ぎます。