RUM

セッションという記録単位で体験を数える

RUM のデータはセッションを頂点に組み立てられています。セッションとは 1 人の利用者のひとつながりの利用体験のことで、その中に画面遷移 (View)・操作 (Action)・ネットワークリクエスト (Resource)・エラー (Error) が束ねられます。セッションは最長 4 時間続き、無操作が 15 分続くと失効します。その後に操作があれば新しいセッションが自動的に始まります (2026 年 8 月時点・出典: RUM & Session Replay)。この構造の実務的な意味は、「エラーが 100 件」ではなく「エラーに遭った利用者が 23 人、うち 20 人が決済画面」という、人を単位にした語り方ができることです。バックエンドのログやメトリクスがイベントの数を数えるのに対し、RUM は体験の数を数えます。障害の優先順位を「影響を受けた人数」で決められるようになるのが、RUM を入れる前後での最も大きな変化です。

SDK を入れる 3 つの方式

ブラウザ向けの導入方式は 3 つあります (2026 年 8 月時点・出典: Browser Monitoring Setup)。第一に、npm またはスクリプトタグで SDK をフロントエンドに組み込み、アプリケーション ID とクライアントトークンで初期化する手動方式。第二に、LLM コーディングエージェントに組み込みを任せる Agentic Onboarding。第三に、Web サーバーやプロキシが返す HTML に SDK を自動注入する Auto-Instrumentation です。手動方式の中でも npm 同梱はモダンなアプリの標準で、ページ読み込み性能への影響がない一方、SDK 初期化前に起きたエラーは取りこぼす可能性があります。CDN の非同期読み込みは性能目標が厳しいサイト向けです。どの方式でも、導入自体は初期化コードを書けば完了します。難しいのはコードではなく、次節以降で扱う「何をどこまで記録するか」という設計判断の方です。モバイルは Android・iOS のネイティブアプリ向け SDK が用意されています。

Session Replay - 再現力とマスキングの既定

Session Replay は利用者のブラウザ体験を録画のように再生する機能で、オープンソースの rrweb を土台にしています (2026 年 8 月時点・出典: Session Replay)。「再現手順が分からないバグ報告」に対して、実際に起きた画面をそのまま見られる価値は、経験した人ほど大きく評価します。エラー発生時の操作列・画面状態・直前の遷移が全部残っているからです。再生データの保持は既定で 30 日です。プライバシー面では defaultPrivacyLevel という設定で記録の粒度を制御し、mask (全てマスク)・mask-user-input (入力値のみマスク)・allow (マスクなし) を選べます。設定を指定しない場合の既定は mask で、マスクされたデータはそもそも SDK が元の形で収集せず Datadog へ送られません。つまりマスキングは恒久的で、後から外して見ることはできません (2026 年 8 月時点・出典: Session Replay Privacy Options)。この「送信前に消える・不可逆」という設計を理解しておくと、後述する個人情報の議論を地に足のついた形で進められます。

セッション単位の課金を 2 層構造とサンプリングで守る

RUM の課金単位はセッション数です。2026 年 8 月時点の公式料金ページでは、機能の異なる 2 層に分かれています。

事故の型は明快で、単価の安い Measure が全トラフィック対象である一方、詳細調査用の Investigate や Session Replay をどのセッションに適用するかを設計しないまま全量に効かせると、単価差 (Measure の 20 倍・16 倍超) がそのまま請求に現れます。ボットやバズによるトラフィック急増もセッション数を直撃します。守り方の中心はサンプリングで、SDK の初期化時に sessionSampleRate (RUM として収集するセッションの割合) と sessionReplaySampleRate (そのうち再生まで記録する割合) を指定できます (出典: Client-Side Browser Monitoring Setup)。「収集は広く・高価な記録は絞って」が初期設計の定石です。料金体系の全体像は料金の読み解きで扱っています。なお本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。

APM トレースと接続し、画面の遅さを裏側まで追う

RUM 単体では「この画面のこのリクエストが遅い」までしか分かりません。APM と接続すると、フロントエンドのリクエストが対応するバックエンドのトレースに紐づき、「遅さの原因はフロントの描画か、API か、その先の DB か」を 1 本の線で追えるようになります (2026 年 8 月時点・出典: Correlate RUM Events with Other Telemetry)。設定は、対象サービス側で APM の計装が済んでいることを前提に、Browser SDK の allowedTracingUrls に自社 API のオリジンを列挙する形です。これで対象へのリクエストにトレース ID が注入され、RUM の画面から該当トレースへ直接ジャンプできます。「お客様の画面で 8 秒かかった」という事象を、営業経由の伝聞ではなくトレースの実データで再構成できるのは、フロントとバックの担当が分かれている組織ほど効きます。責任の押し付け合いが、データの読み合いに変わるからです。なお公式ドキュメントには、この接続で RUM 側が APM の有償データを利用するため APM の課金に影響し得る旨の注記があります。

「何を集めているか」を言えるようにする個人情報と同意

RUM は実ユーザーの行動データを集める仕組みである以上、プライバシーの設計から逃げられません。実務の出発点は「自社の RUM が何を収集しているかを、聞かれたら正確に答えられる状態」を作ることです。収集されるのは画面遷移・操作・リクエスト・エラーとその属性で、Session Replay を有効にすれば画面の見た目も加わります。技術的な防御は前述のマスキング (既定 mask・送信前適用・不可逆) が第一で、入力フォームや個人情報が表示される要素をどの粒度でマスクするかを、法務やプライバシー担当と共有できる 1 枚の表にしておくことを勧めます。そのうえで、Cookie や類似技術による行動収集への同意をどう取るかは、サービスが対象とする国・地域の法規制とサイトのプライバシーポリシーに依存する論点であり、Datadog の設定だけで完結する話ではありません。「ツールの既定値に任せている」ではなく「この設定を選んだ理由を説明できる」状態が、監査にも利用者にも通る唯一の姿勢です。導入前のチェックリストに、技術設定と並べて「プライバシーポリシーの記載更新」を最初から入れておいてください。

実客の観察が要るのは誰か

RUM がまず効くのは、フロントエンドの体験が事業指標に直結しているサービスです。EC の決済導線、SaaS のオンボーディング、メディアの読了体験。これらは「遅い・壊れている」が売上や解約に翻訳される場所であり、実ユーザー単位の観測に投資する根拠が立ちます。逆に、利用者が特定少数の社内ツールや、動的な操作のほぼない静的サイトでは、セッション課金を払ってまで実客を観測する意義は薄くなります。もうひとつの軸は「実客がいない時間帯・経路の監視を誰が担うか」です。RUM は実際のアクセスがあって初めてデータが生まれる受動的な仕組みなので、深夜の障害や、まだ誰も踏んでいない導線の故障は検知できません。そこは能動的に疑似アクセスを送る Synthetics の役割で、両者は競合ではなく補完関係にあります。まずは主要導線に絞って RUM を薄く入れ、影響人数でバグの優先順位を付ける運用を 1 か月回してみると、自分の組織での価値が実測で判断できます。