RUM ツールの選び方：操作、リプレイ、バックエンドのトレース

既にバックエンドの APM を運用しているなら、私はブラウザーのリクエストを既存のトレースにつなげられるか、先に確認します。フロントエンドのダッシュボードが増えても、調査のたびに別のシステムでバージョンやリクエストを探す作業が残るかもしれません。一方、ページの読み込みや操作の性能低下を直すことが主目的なら、インフラ全体の統合から始める必要はありません。

リアルユーザーモニタリング（RUM）ツールを選ぶ際は、残る証拠を見ると違いが分かります。INP の分布、セッションの時系列、DOM のリプレイ、バックエンドのトレースは、それぞれ別の問いに答えます。収集と保持の経路も同じではありません。「RUM 対応」だけでは、調査をどこまで進められるかは見えてきません。

ユーザー側の待ち時間からサービスやログまで追いたく、接続を維持する担当者もいないなら、Guance のように RUM と APM の調査経路を持つサービスを先に比較します。成熟したツールチェーンがあるなら、まずそれを活用する方が自然です。狭い Web 性能要件には、専門ツールや少数の自社収集指標が合う場合もあります。

Guance 編集部 · 2026 年 10 月 28 日。公式資料に基づく比較であり、発行者の Guance も対象です。サンプリング例は明示した仮定による計算です。同一負荷での性能試験、コンバージョン向上や費用削減の検証は行っていません。

グラフの INP は何を表しているのか

INP は 2024 年 3 月 12 日に FID に代わり、Core Web Vitals の操作応答性の指標になりました。ページ訪問中の対象となるクリック、タップ、キーボード操作について、入力遅延、処理、描画までの待ち時間を観測し、外れ値の扱いにも規則があります。最初の入力遅延だけでも、スクロールなどすべての動作の時間でもありません。対象の操作がない訪問には INP 値がない場合があります。INP の定義・切り替え日

過去の FID は旧バージョンの状況を理解するために残せますが、観測範囲が異なるため、INP と一つの連続したトレンドにはつなぎません。

実ユーザーデータでの評価は、ページ訪問ごとの INP の 75 パーセンタイルを使い、モバイルとデスクトップを分けます。200 ms 以下が良好です。すべてのクリックを一つに集めた p75 や、複数ページの p75 の平均とは異なります。長時間開き、多くの操作を行うページでは特に差が出ます。SPA の仮想ルートとブラウザーの文書のライフサイクルも一致するとは限らず、SDK が View に指標を割り当てる仕組みを理解する必要があります。

LCP は主要コンテンツの表示、INP は操作への応答、CLS は視覚的な安定性を見ます。ホームページが速く表示されても、ログイン後の絞り込み操作まで速いとは言えません。デバイス、ページの種類、リリース別に分布を見ると、直すコードを絞れます。サイト全体の平均では、少数の低速デバイスに起きた深刻な性能低下を見落とすことがあります。

CrUX は公開データの基準として役立ちますが、ユーザー、ブラウザー、ページに採用条件があります。PageSpeed Insights がページまたはオリジンの実ユーザーデータを表示するには十分なサンプルが必要です。CrUX API は通常、直近 28 日の移動集計で、特定の訪問のリアルタイム履歴ではありません。昨日の修正で、その期間の過去データすべてがすぐ入れ替わるわけでもありません。URL のデータがなくても、訪問がなかったとは判断できません。CrUX の方法・API の集計期間

外形監視も引き続き有用です。選んだ拠点、デバイス、シナリオを繰り返し実行でき、実トラフィックがなくても可用性やリリースの問題を見つけられます。RUM は計装され、収集が許可され、正常に届いたデータを扱います。母集団が違うため、外形監視が正常でも、特定の端末、ログイン状態、長いセッションの問題は否定できません。

ブラウザーとバックエンドはタグだけではつながらない

ブラウザーのウォーターフォールにある API 時間は、クライアントが見た待ち時間全体です。接続、ネットワーク、ゲートウェイ、サービス処理のいずれも含まれ得ます。長いリクエストだけで、データベースが遅いとは言えません。サーバー側を説明するには、バックエンドが継続できる追跡コンテキストを送り、該当する Span を実際に収集、保持する必要があります。

現在の Guance Web SDK は allowedTracingUrls で追跡ヘッダーを付ける XHR/Fetch を限定し、traceType で伝播形式を選びます。次は CDN 接続の初期化オプションに入れる断片です。例の API パスだけを対象に、W3C 形式を使います。NPM/TypeScript では、現行資料の TraceType 列挙型を使用します。Web SDK の接続と設定

const tracingOptions = {
  allowedTracingUrls: [/^https:\/\/api\.example\.com\/v1\//],
  traceType: "w3c_traceparent"
};

これでサーバーの計装まで完了するわけではありません。また、許可対象を任意の外部ドメインへ広げるべきでもありません。クロスオリジンの場合は、API とゲートウェイで実際に付けるヘッダーを許可します。この例では少なくとも traceparent を確認します。セーフリスト外のヘッダーを追加すると CORS プリフライトが発生することがあり、拒否されると業務リクエスト自体がブラウザーに止められます。到着後はバックエンドがコンテキストを読み、伝播を続けます。CORS のプリフライトとヘッダー

service、env、version は環境やリリースを探す手がかりですが、同じ値だけでは分散トレースは生まれません。ブラウザーで採取されても、バックエンドでサンプル対象外になったり、保持期間が過ぎたりすることがあります。Guance の allowTraceHeaderWithoutSession は、RUM の対象外となったセッションでも、URL 条件を満たすリクエストにヘッダーを付けられます。ただし Session は作らず、その View、Error、Resource、Action も補って送信しません。

接続できると、Guance の RUM リクエスト詳細から関連トレースへ進み、既存の APM 経路でサービス、ログ、リソースを調べられます。リクエスト詳細・トレース詳細Datadog、Dynatrace、New Relic を既に使うチームも、まず各製品のブラウザー連携を確認できます。フロントエンドの計装のためにバックエンド全体を移す必要はありません。Sentry もフロントエンドとバックエンドをまたぐ分散トレースに対応しており、エラー調査から始まった製品だからといってフロント専用とは言えません。Sentry の伝播設定

セッション、リプレイ、集計指標では履歴が違う

セッションの時系列は、取得したページ、エラー、操作、リクエストを並べます。Session Replay は、それに加えて画面を再構築するための記録を使います。Guance の Web リプレイは DOM のスナップショットと変更に基づき、画面の動画ではありません。フォントや画像の URL と参照権限、クロスオリジンや Canvas の対応範囲、記録の完全性によって、後から見える内容が変わります。Web リプレイ接続・データの完全性

Guance Web では、リプレイを含む SDK ビルドを使い、startSessionReplayRecording() で記録を開始します。View や Session が届いていても、その RUM データが送られたことを示すだけで、リプレイが記録中とは限りません。

リプレイのサンプリングは、RUM セッションのサンプリングを前提にする場合があります。Datadog Browser SDK では、sessionSampleRate で選ばれたセッションに sessionReplaySampleRate を適用します。収集条件を満たす 100 万セッション、RUM を 20%、その中の 10% をリプレイ対象とし、追加の保持やエラー発生時の規則がないと仮定します。

RUM セッションの期待数 = 1,000,000 × 20% = 200,000
リプレイ候補の期待数 = 200,000 × 10% = 20,000

二段階のランダムサンプリングの期待値であり、送達保証や請求予測ではありません。収集許可、SDK の読み込み、録画開始、ネットワーク送達、製品の課金規則も実数を変えます。二つの割合を足したり、ある製品の既定値を別の製品に当てたりはできません。エラー時の記録には別の経路が加わる場合もあります。Datadog のサンプリング

指標の保持期間と訪問の詳細も別です。現在の Datadog RUM Measure は送信されたセッション全体の集計指標を扱い、RUM Investigate は残す詳細セッションを制御します。公開プランでは該当する標準指標を 15 か月、セッションとリプレイを 30 日保持します。採用する SKU と契約を確認し、3 か月前のグラフから全訪問者の記録を開けるとは考えないことです。Datadog のプランと保持

Guance Web のリプレイ保持は RUM の保持と連動し、RUM の設定変更もリプレイの利用期限に影響します。一方、バックエンドのトレースとログには独自の方針があります。問い合わせ対応にセッションを 7 日残しても、Trace が 3 日なら、4 日目以降はサーバー側の証拠が一部失われます。リプレイの参照と保持

プライバシー設定が、後から見える内容を決める

リプレイの空白は、必ずしもパケット損失ではありません。Guance Web の現在の既定値は mask-user-input で、一部の入力と指定領域がマスクされます。パスワード、メール、電話、決済関連のフィールドや独自要素は、実際の規則で確認します。名前が URL、ボタン、属性、手動イベントにも含まれるなら、入力欄だけを隠しても他の経路までは処理されません。プライバシーと意図的な欠落

Action 名も具体例です。enablePrivacyForActionName は現在、既定で無効です。有効にすると、自動推定される Action 名に DOM のプライバシー規則を適用します。業務属性で明示する名前や addAction() の内容は、引き続きアプリケーションが管理します。リプレイのマスクは、RUM の全ペイロードを一括して匿名化するスイッチではありません。操作とプライバシー

SDK は端末でも処理を行います。ダウンロード容量のほかに、DOM 監視、長いタスクやネットワークの追跡、シリアル化、圧縮、記録が実行時の資源を使います。Guance の標準版と軽量版では機能が異なり、軽量版は Session Replay を提供しません。その容量でリプレイ有効時の負荷を説明することはできません。対象の低性能端末で、実際の構成による読み込み、操作、長時間の利用を比べる必要があります。SDK ビルドと範囲

Web、Android/iOS、ミニアプリは、SDK もイベントの意味も異なります。Web 対応はミニアプリへの自動対応を意味せず、ネイティブの性能記録が DOM リプレイまで保証するわけでもありません。収集、送信ドメイン、保存、サポートのアクセス、外部呼び出し、削除を実際の配備に沿って確認します。企業の所在地や「プライベート配備」だけでは、すべての答えは得られません。

チームが既に進めている仕事からツールを絞る

すべての製品を固定した分類に入れる前に、必要な作業から経路を選べます。

SpeedCurve と DebugBear は実ユーザーとラボのビューを資料で説明しています。取得元ごとに解釈し、一回のラボのスコアを全訪問者の体験とは扱いません。SpeedCurve CWV・DebugBear 実ユーザーデータ

web-vitals は計測ライブラリで、完成したセッション基盤ではありません。beacon を自社エンドポイントに送り、ClickHouse や BigQuery に保存して、独自指標と関連付けを実装することは可能です。ただし送信失敗、ルートとリリース、権限、保持、クエリ、アラートは運用が必要です。Grafana は結果を可視化できますが、収集経路までは作りません。既存基盤があれば追加作業は小さくても、ゼロからリプレイまで作るなら別の開発です。web-vitals の計測と送信

収集と保持の範囲で費用を計算する

同じ 100 万訪問でも、訪問、セッション、保持セッション、イベント、データ量のどれで計量するかで請求が変わります。長いセッションではリソースや操作が増え、リプレイにも独自のデータと記録条件があります。「訪問数 × 単価」だけではすべての製品を見積もれず、保存ファイルの圧縮率から別 SDK の送信量も求められません。

Datadog では現行の Measure、Investigate、リプレイを分けます。Dynatrace の現在の資料は RUM、任意の Session Replay、RUM プロパティを別の消費項目にしています。New Relic は採用するデータ、ユーザー、計算資源のモデルで計算し、古い GB 単価だけで Browser 全体の費用を出さないようにします。Dynatrace の計量・New Relic の料金

Guance Enterprise Plan も全範囲で計算します。取り込みは圧縮後の送信バイト、保存は保持する RUM とリプレイファイルを含み、該当する加工、関連バックエンド信号、専用計算資源も含めます。セッション単位のプランは対応する料金表を使い、Enterprise Plan の単位と混ぜません。SDK、業務フィールド、プライバシー設定は顧客側の管理が残ります。Enterprise Plan の課金範囲

既存のバックエンドがあるなら、まずブラウザーを接続し、伝播と保持を揃え、リクエストを何度も探す作業を減らせるか考えます。CWV が主目的なら、操作とリリース差分を説明する証拠に予算を使います。成熟したデータ基盤と狭い要件があれば、自社計測も合理的です。ユーザー、サービス、ログを一つの調査経路にし、その接続やクエリ基盤を維持するつもりがないなら、Guance が担う提供範囲で比較します。

性能とコンバージョンは一緒に分析できますが、端末、流入経路、ユーザーの意図も結果を変えます。修正の効果は、自社の利用経路に対する対照実験や慎重に設計した分析で判断します。RUM は変化を経験したユーザーを特定し、説明する証拠を残せますが、単純な公開前後の比較を因果関係の証明には変えません。