2026.08.15 インフラ

Datadog RUM導入の実装手順｜ブラウザSDK設定からAPMトレース紐付けまで

Datadog RUMは、ブラウザ上の実ユーザーが体験した表示速度と操作を、1,000セッション単位の課金で記録するプロダクトです。導入はSDKを1つ読み込んで初期化するだけで終わります。詰まるのはその先。サンプリング率をいくつに置くか、どのオリジンまでトレースIDを注入するか、入力値をどこまで伏せるか。2026年8月時点の公式ドキュメントとnpmレジストリの実測をもとに、実装目線で整理します。

まとめ：Datadog RUM導入で先に決めるサンプリング率と計装範囲

結論から示します。先に決めるべきはSDKの入れ方ではありません。sessionSampleRateをいくつに置くか、allowedTracingUrlsにどのオリジンを載せるか、defaultPrivacyLevelをどの強度にするか。この3つを決めずに本番へ入れると、課金の膨張・トレースの断線・個人情報の流入という形で後からコストを払います。

順序はこうです。まずnpmまたはCDN非同期でSDKを読み込み、applicationIdとclientTokenだけの最小構成で疎通を確認する。次に自社APIのオリジンをallowedTracingUrlsへ追加し、バックエンド側のAccess-Control-Allow-Headersを通してからAPM紐付けを有効にします。サンプリングを絞るのは最後です。

採否の線引きも先に述べておきます。APMを既に入れている組織ならRUMは投資に見合い、社内向け管理画面だけの計装・月間数千セッション規模のサイト・フロント改修予算が付いていない状態での導入は見送りが妥当。理由は判断章で条件付きに示します。

Datadog RUMが収集するセッション・ビュー・アクションのデータ構造

設定値を決める前に、Datadogが何を1件と数えているかを押さえます。この数え方が課金単位にも検索単位にもそのまま効いてきます。

セッションが切れる15分の無操作と最大4時間という課金の区切り

Datadogのセッションは、ユーザーが操作を止めてから15分で失効します。操作が続いていても最大4時間で区切られ、そこから新しいセッションが始まる仕組みです。この2つの数字は公式の課金ドキュメントに明記された値で、Datadogは「RUMに取り込まれた1,000セッションあたり」で課金します。

含意は単純です。1人が朝と夕方に訪れれば2セッション、長時間開きっぱなしの業務画面なら1人が1日で6セッション以上を生む計算になる。BtoCサイトの月間セッション数はユニークユーザー数の1.2〜1.5倍に落ち着きますが、滞在の長い業務系アプリケーションでは何倍にもなります。見積もりをユーザー数から立てると外れます。

ビュー・アクション・リソース・エラーの4イベント型と使い分け

セッションの中身は4種類のイベントに分かれます。ページ表示ごとに1件立つビュー、クリックやタップを拾うアクション、XHRや画像取得を拾うリソース、JavaScript例外を拾うエラーです。ダッシュボードを作るときは、この型を意識して集計軸を選びます。

  • ビュー：LCPやINPなどの表示性能はここに付く。SPAのルート遷移でも1件立つ
  • アクション：trackUserInteractionsを有効にすると要素名から操作名が生成される
  • リソース：trackResourcesで制御。APIの応答をフロント側から見る際の主役
  • エラー：未捕捉例外とコンソールエラー。ソースマップを上げれば難読化前の行番号で読める

注意したいのは、これらのイベント件数では課金されない点。イベントを増やしても請求は増えず、セッションを増やすと増えます。この非対称性が、後述するサンプリング設計の前提になります。

RUMとAPM・合成監視の計測点の違いと実務での役割分担の線引き

同じ「遅い」を扱う3つの仕組みは、測っている場所が違います。RUMは実ユーザーのブラウザ、APMはサーバー側の処理、合成監視は決まったシナリオを定期実行する仮想的な計測点。RUMだけでは、遅い原因がサーバーなのかフロントなのかを切り分けられません。

計測手法としての成り立ちや合成監視との使い分けはリアルユーザーモニタリング（RUM）とはで製品非依存に整理しています。製品全体の構成が先に必要であればDatadogとは何かから入ってください。本記事はDatadog製品での実装に絞ります。

ブラウザSDKの導入方式3種とinit初期化パラメータの設定判断

公式ドキュメントはnpm・CDN非同期・CDN同期の3方式を示しています。どれを選ぶかで、取りこぼすイベントとページ読み込みへの影響が変わります。

npm・CDN非同期・CDN同期の3方式とページ読み込みへの影響

公式ドキュメントの記述に沿うと、npm方式とCDN非同期方式はページ読み込み性能に影響を与えません。一方でCDN同期方式は読み込みを止める代わりに、初期化前に発生したエラーやリソースまで確実に捕捉できます。

方式 読み込み性能 取りこぼし
npm 影響なし バンドル後の実行時点から
CDN非同期 影響なし 初期化前のイベントは欠落
CDN同期 影響あり すべて捕捉できる

ビルドパイプラインを持つSPAならnpmを選びます。ブラウザRUM用のnpmパッケージは2026年8月15日時点のレジストリで7.8.0系が最新として配信されており、ロックファイルで版を固定できる点も有利です。既存のCMSにタグを1行足す形しか取れない場合はCDN非同期、初期表示のエラー計測が主目的ならCDN同期を選びます。

applicationIdとclientTokenの発行とsite指定の落とし穴

必須パラメータは3つあります。管理画面でRUMアプリケーションを作成したときに発行されるapplicationIdとclientToken、そして組織が属するDatadogサイトを指すsiteです。

事故が起きやすいのはsiteです。組織がEUサイトやAP1などUS1以外に属しているのに既定値のまま入れると、SDKは正常に動いて見えるのにイベントだけが管理画面に出てきません。開発者ツールで送信先ホストを確認してください。clientTokenはフロントに露出する前提のトークンで、APIキーとは別物です。

service・env・versionは任意扱いですが、実務では最初から入れます。envがないとステージングと本番のセッションが同じ画面に混ざり、versionがないとデプロイ前後の性能比較ができません。後から足しても過去データは遡って埋まらないため、初回リリースに含めてください。

defaultPrivacyLevelとユーザー操作追跡の初期設定の決め方

個人情報の扱いはdefaultPrivacyLevelで決まります。セッションリプレイを有効にする場合、この設定がテキストや入力値をどこまでマスクするかを制御する。会員情報やフォーム入力を扱う画面では、マスク強度の高い設定から始めて必要な箇所だけ属性で解除する方向に倒してください。逆順にすると、伏せ忘れた1画面から個人情報がSaaS側へ渡ります。

trackUserInteractionsを有効にすると、クリックした要素のテキストからアクション名が自動生成されます。ボタンのラベルに氏名や注文番号が入るUIでは、この自動命名が個人情報の持ち出し経路になり得る。要素側に固定のアクション名を指定する属性を付けるか、当該画面だけ操作追跡を切る運用が現実的です。

Core Web VitalsをRUM実測値で追う際のLighthouseとの差

RUMを入れる動機として多いのがCore Web Vitalsの計測です。ここで合成計測との数値差に驚いて止まる現場が多いため、先に読み方を決めておきます。

LCP2.5秒・INP200ミリ秒・CLS0.1という判定しきい値

Datadog公式ドキュメントが良好とする水準は、LCPが2.5秒未満、INPが200ミリ秒未満、CLSが0.1未満です。加えてDatadogはFCP、view.first_byteとして収集されるTTFB、旧指標のFID、そしてSPAのルート遷移まで含めて計測する独自のLoading Timeを持ちます。

3指標の定義や改善手法はWeb標準側の話なので、意味から確認したい場合は関連記事のコアウェブバイタル解説を先に読んでください。ここではDatadog上でどの数値を信じてどう動くかに絞ります。

INPがFIDを置き換えた経緯とSDKバージョン要件の確認点

INPはFIDを置き換えた応答性の指標で、ユーザー操作から次の描画までの最長時間を測ります。FIDが最初の入力の遅延しか見なかったのに対し、INPはセッション中の操作全体が対象。無限スクロールやモーダルの多い画面では評価が厳しく出ます。

実装上の注意はSDKのバージョンです。公式ドキュメントはINPの収集にRUM SDK v5.1.0以降を要求すると記載しています。数年前に導入したまま更新していないサイトでは、管理画面にINPの列が出ないという形で不足が表面化する。INPが出ないときに疑うのは設定ではなくSDKのバージョンです。

合成監視の数値とRUM実測値がずれる原因と改善優先度の付け方

Lighthouseや合成監視が示す値とRUMの実測値は、ほぼ一致しません。合成計測は固定された端末性能・固定回線・キャッシュなしの初回訪問で走るのに対し、RUMは実際の端末性能と回線品質、キャッシュ済みの再訪問まで含めた分布を返すからです。中央値で3倍近く開くこともある。

優先度の付け方は決めておきます。合成監視の値は改善施策の効果検証に使い、投資判断はRUMの75パーセンタイルで行う。Core Web Vitalsの評価基準が75パーセンタイルで定義されているため、この軸を揃えると社内の議論が噛み合います。平均値は外れ値に引きずられるので既定集計から外して構いません。

RUMとAPMトレースを紐付けるallowedTracingUrlsとCORS設定

RUM単体で分かるのは「遅かった」という事実までです。原因をサーバー側のどの処理まで辿るには、ブラウザのリソースイベントとAPMのトレースを接続します。

allowedTracingUrlsに前方一致・正規表現・関数を渡す使い分け

接続の起点はallowedTracingUrlsです。ここに載せたオリジンへの通信にだけ、SDKがトレース識別用のヘッダを注入します。指定形式は3つあり、文字列を渡すとURLの前方一致、正規表現を渡すとパターン一致、関数を渡すと呼び出しごとの判定になります。

サブドメインが動的に増えるマルチテナント構成では正規表現、環境変数でAPIホストが切り替わる構成では関数、単一のAPIゲートウェイに集約されているなら文字列。この順で選べば十分です。ここに第三者のドメインを載せてはいけません。管理していないサーバーへ独自ヘッダを送ると、次に述べるプリフライトで弾かれます。

x-datadog系ヘッダとtraceparentの伝播方式の選び方

注入されるヘッダは伝播方式で変わります。Datadog独自方式ではx-datadog-trace-id、x-datadog-parent-id、値がrumのx-datadog-origin、サンプリング判定を1か0で示すx-datadog-sampling-priority。W3C標準方式ではtraceparentとtracestateで、b3とb3multiも選べます。

公式ドキュメントの既定はW3C標準とDatadog方式の併用です。バックエンドがDatadogのトレーサーだけなら既定のままで動く。OpenTelemetryのCollectorを経由する構成や他社トレーサーが混在する構成では、W3C標準に寄せると取りこぼしが減ります。計装の考え方はAPM（アプリケーション性能監視）とはで先に押さえてください。

Access-Control-Allow-Headers未設定で起きるプリフライト失敗

ここが最大の落とし穴です。x-datadog-trace-idのような独自ヘッダはCORSの安全リストに含まれません。フロントエンドとAPIのオリジンが異なる場合、ブラウザはOPTIONSメソッドのプリフライトを先に飛ばし、サーバーがAccess-Control-Allow-Headersで該当ヘッダを許可していなければ本リクエストごと失敗します。

症状の出方が厄介で、RUM側には「トレースが紐付いていない」としか出ません。実際にはAPI呼び出し自体が落ちている。設定を入れた直後に本番機能が動かなくなる事故はこの経路で起きます。allowedTracingUrlsの追加は必ずCORS設定とセットで扱い、サーバー側の許可ヘッダ追加を先にデプロイしてください。

traceSampleRateとセッションサンプリングの独立した関係

混同されやすい2つの設定を切り分けます。traceSampleRateはブラウザ起点のリクエストからバックエンドのトレースをどれだけ保持するかを決める値で、公式ドキュメントによれば既定は100%。この値はRUMセッションのサンプリングには影響せず、間引かれるのはバックエンドのトレースだけだと明記されています。

APMのスパン課金を抑えたいときに触るのはtraceSampleRate、RUMの請求を抑えたいときに触るのはsessionSampleRateです。traceSampleRateを20%に下げてもRUMのセッション数と請求は動きません。この対応関係を取り違えると、狙った側のコストが下がらないまま調査可能性だけを失います。

1,000セッション課金に対するサンプリング設計とコスト抑制

RUMの請求はセッション数で決まります。ここを設計せずに全量計測のまま走らせると、トラフィックが伸びた月に請求だけが跳ねます。

sessionSampleRateを100%から下げる判断のトラフィック水準

判断軸は統計的な必要数です。Core Web Vitalsの75パーセンタイルを画面単位で安定して読むには、対象画面あたり月1,000セッション前後は残したい。ここから逆算します。

主要画面が10枚あり月間10万セッションのサイトなら、20%まで絞っても画面あたり2,000セッションが残る。同じ10枚で月間2万セッションなら、絞った時点で画面単位の分布が読めなくなるため100%のまま置きます。エラー調査が主目的なら話は別で、再現性の低い不具合ほどサンプリングで消えるため、障害調査フェーズだけ一時的に100%へ戻してください。

セッションリプレイを別勘定で持つべき理由と撮る対象の絞り込み

セッションリプレイはRUM本体とは別のプランで課金され、録画が収集されたセッションがその対象になります。sessionReplaySampleRateはRUMのサンプリングとは別に指定できるため、RUMを100%、リプレイを10%といった組み合わせが取れます。

全画面を録るのはおすすめしません。決済フローや申込フォームなど離脱が売上に直結する画面に絞れば、調査能力を保ったまま録画対象を減らせます。課金単位ごとの内訳はDatadogの料金体系と費用が膨らむ課金単位にまとめてあります。

ボット・監視ツールの通信を除外して無駄セッションを減らす設定

請求されているセッションの中身を一度分解すると、人間ではないアクセスが混ざっています。合成監視のシナリオ実行、外形監視サービス、クローラー、社内のE2Eテスト。いずれもJavaScriptを実行するため、素の設定ではRUMセッションとして課金対象に入ります。

対処は2段構えです。SDK側では初期化前にユーザーエージェントや専用のクエリパラメータを見て、該当する場合は初期化そのものを行わない分岐を入れる。ステージングはenvで分けたうえで、本番以外にSDKを配らないビルド設定にするのが確実です。E2Eテスト時だけ初期化を止めるフラグを1つ用意しておくと、CIの実行回数が増えても請求が連動しません。

Datadog RUMを採用する条件と導入を見送るべき場面の線引き

ここは判断を言い切ります。RUMは入れれば効く道具ではなく、前提条件を満たしたときだけ投資に見合う道具です。

APMを先に入れている組織だけがRUMの投資を回収できる理由

RUMが返すのは「このユーザーのこの画面が3.2秒かかった」という事実だけです。原因がフロントのバンドルサイズなのか、APIの応答なのか、その先のデータベースなのかまでは分かりません。APMが入っていれば、遅いビューから該当のトレースへ飛び、サーバー側のどのスパンが時間を食ったかを1画面で辿れます。

順序としては、サーバー側の計装を先に入れ、そのうえでRUMを足す。逆順で入れた組織は、遅いという事実だけが毎日ダッシュボードに並び、打ち手が決まらないまま契約更新を迎えます。計装の設計や運用体制に外部の手を借りるなら、システム保守運用・内製化支援のように監視基盤の設計から内製化までを一緒に進める形が現実的です。

社内管理画面と低トラフィックサイトでRUM導入を見送る判断基準

見送るべき場面を条件付きで示します。第一に、社内向け管理画面だけを計装するケース。利用者が特定できていて母数も小さく、実ユーザー分布を統計的に読む価値が出ません。遅いという報告は直接届く。しかも業務画面は長時間開かれるため、4時間の上限で切られたセッションが人数に不釣り合いなペースで積み上がります。

第二に、月間セッションが数千規模のサイト。画面単位の75パーセンタイルが安定せず、数字を見ても改善判断ができません。この規模なら合成監視の定期実行のほうが安く済みます。第三に、フロント改修の予算が確保されていない状態。RUMは遅い画面を直す工数とセットで初めて回収されるため、直せない前提の導入は未処理課題リストを作るだけです。

個人情報のマスキング設計を省いたまま本番投入する失敗パターン

典型的な失敗はこれです。検証環境でセッションリプレイの見え方に納得し、マスキング設計を詰めないまま本番へ広げる。氏名・住所・カード番号の入力過程が録画として外部SaaSへ渡り、社内のセキュリティ審査で全面停止になります。防ぐには、導入前に録画対象の画面一覧・伏せる要素の指定方法・保持期間・閲覧権限の4点を文書化し、法務やセキュリティ部門の確認を通しておくしかありません。

よくある質問

Datadog RUMの導入検討でよく挙がる質問を、実装と費用の観点からまとめます。

Datadog RUMの料金はどのように決まりますか？

公式の課金ドキュメントによれば、RUMに取り込まれた1,000セッション単位で課金されます。セッションは無操作15分で失効し、最大4時間で区切られる。リプレイを収集する場合はリプレイを含むプランでの課金になり、録画を止めればその分は発生しません。イベント件数では課金されないため、計測項目を増やしても請求額は動きません。

RUMとAPMのトレースが紐付かないときはどこを見ますか？

確認は3点です。allowedTracingUrlsに対象APIのオリジンが含まれているか。バックエンドのAccess-Control-Allow-Headersが独自ヘッダを許可しているか。トレーサーの伝播方式とSDK側の設定が一致しているか。開発者ツールでリクエストヘッダを見て、そもそもヘッダが注入されているかを確かめると、フロント側とサーバー側のどちらの問題かを切り分けられます。

サンプリング率を下げるとエラー調査に支障は出ますか？

出ます。sessionSampleRateで間引かれたセッションのイベントは送信されず、後から遡ることはできません。発生率の低い不具合ほどサンプリングで消える。恒常的には20〜50%で運用し、障害調査や新機能のリリース直後だけ100%へ戻すのが現実的です。設定はSDKの初期化パラメータなので、環境変数で切り替えられる形にしておくと切り戻しが数分で済みます。

SPAでもページごとの表示速度を計測できますか？

できます。DatadogのRUMはSPAのルート遷移も1つのビューとして記録し、初回ロードとルート変更の両方に適用されるLoading Timeという独自指標を持ちます。ReactやVueのルーターを使っていれば、SDKが履歴APIの変化を検知して自動でビューを切り替える。ビュー名にIDなどの可変値が入ると集計が分散するため、パスをパターン化して渡す設計にしてください。

Core Web VitalsはCrUXの値と一致しますか？

一致しません。検索側のレポートが参照するCrUXはChromeの実利用データを集約したもので、対象はChromeユーザーかつ一定数以上のトラフィックがあるURLに限られます。RUMは自社が計装したすべてのブラウザから収集するため母集団が異なる。しきい値はLCP2.5秒・INP200ミリ秒・CLS0.1で共通なので、日々の傾向追跡はRUM、検索評価上の最終確認はCrUX側という分担にしてください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る