リアルユーザーモニタリング（RUM）とは｜実ユーザー計測の仕組み・合成監視との違い・導入判断を実装目線で解説

リアルユーザーモニタリング（RUM／Real User Monitoring）は、実際にサイトを訪れたユーザーのブラウザからページの表示速度や操作の反応、エラーの発生状況を集めて、体験の質を継続的に計測する手法です。この記事では、RUMがJavaScriptビーコンで集めるCore Web Vitals（LCP・INP・CLS）などのフィールドデータの中身と収集の仕組みを実装者の目線で整理し、web-vitalsライブラリやSaaSのSDKでの計装、ビーコン送信のパフォーマンス配慮、そして「決まった条件で模擬実行する合成監視と、どう使い分けるか」までを判断できる形で解説します。RUMは実ユーザーの分布そのものを、合成監視は再現性を、APMはサーバー内部の処理区間を担う――この役割分担を軸に読み進めてください。

まとめ｜RUM導入の判断基準・計装の要点・合成監視との住み分け

RUMの価値は、実ユーザーが使っている多様な端末・回線・地域での「本物の体験」を、母集団の分布として数値化できる点にあります。開発機やCIの安定回線で測った速度が良好でも、地方の低速回線や型落ちスマートフォンでLCPが4秒を超えていれば、離脱は現場で起きています。RUMはその現実を、平均ではなく分位数（p75など）で可視化する道具です。

計装の起点はブラウザで動く軽量なJavaScriptです。Googleのweb-vitalsライブラリでCore Web Vitalsを取得し、自前のエンドポイントかSaaSへビーコン送信するのが最小構成になります。ページ描画をブロックしないよう非同期で読み込み、送信はnavigator.sendBeaconで離脱時にまとめる設計にすると、計測自体が体験を損ないません。

導入判断は目的で分かれます。決まったシナリオの死活・応答を24時間監視したいなら合成監視（外形監視）が向き、実ユーザー全体の体験分布と原因の内訳を見たいならRUMです。両者は競合せず、合成監視で異常を早期検知し、RUMで実害の範囲と原因を切り分ける併用が実務の基本形になります。導入後の落とし穴は、データを集めるだけで閾値アラートと改善サイクルを作らないこと、そしてビーコンの送りすぎでページ自体を重くしてしまうことです。

RUMが計測する対象と実ユーザーのデータをブラウザから集める仕組み

RUMは「実ユーザーの体験」を主語に置く計測です。サーバーが生きているか（死活）でも、決まった手順を機械が再生した結果でもなく、いま現実にアクセスしている人のブラウザで何が起きたかを対象にします。まず何を、どうやって集めるのかを分けて押さえます。

RUMが集めるCore Web Vitalsとページ表示・エラーのフィールド指標

RUMが中心に据えるのは、ユーザー体験に直結する数値です。表示速度ではTTFB（最初のバイトまで）、FCP（最初の描画）、LCP（主要コンテンツの描画完了）を、操作性ではINP（操作から次の描画までの応答）を、レイアウトの安定性ではCLS（表示のずれ量）を取ります。LCP・INP・CLSはGoogleがCore Web Vitalsと呼ぶ体験指標で、INPは2024年3月にFIDに代わって正式採用されました。加えて、JavaScriptエラーの発生率、地域・デバイス・ブラウザ・ネットワーク種別といった属性も同時に集め、体験を切り口別に分解できます。

これらの指標の定義や合否の目安はCore Web Vitalsとは：Webページパフォーマンスの重要指標の解説で整理しています。RUMは、この指標群を「実ユーザーの分布」として継続取得する計測手段だと捉えると位置づけが明確になります。目安として、LCPは2.5秒以内、INPは200ミリ秒以内、CLSは0.1以内が良好域とされます（2026年時点・しきい値は改定されうるため導入時に一次情報を確認）。

JavaScriptビーコンで実ブラウザから計測データを送る仕組み

RUMの計測本体は、ページに読み込ませる小さなJavaScript（RUMエージェント／ビーコン）です。ブラウザ標準のPerformance API（PerformanceObserver）やPaintTiming・LayoutShiftなどのエントリを購読し、描画・操作・エラーのイベントを拾います。集めた値は、ページ遷移や離脱のタイミングで収集サーバーへ送信します。

送信で使うのがnavigator.sendBeaconです。これはページがアンロードされる瞬間でも、描画をブロックせずにデータを送り切れるための仕組みで、INPやCLSのように「操作が終わってから確定する」指標を取りこぼさずに送れます。スクリプト自体はasyncで非同期読み込みし、メインスレッドを占有しないことが計装の前提になります。計測が体験を重くしては本末転倒だからです。

フィールドデータとしてのRUMとオブザーバビリティ内での位置づけ

RUMが返すのは、実環境で観測された「フィールドデータ」です。開発中に固定条件で測る「ラボデータ」（Lighthouse等）が再現性を持つ一方、実ユーザーの端末・回線・地域のばらつきは映しません。RUMはその欠けを埋め、実際の母集団で何が起きているかを示します。GoogleのCrUX（Chrome User Experience Report）も、Chromeユーザーから集めた28日移動のフィールドデータで、RUMと同じ系統です。

システム全体の可観測性という観点では、RUMはメトリクス・トレース・ログを束ねるオブザーバビリティの「フロントエンド側の目」にあたります。全体像と監視との違いはオブザーバビリティ（可観測性）とは：監視との違い・3本柱・主要ツールで体系的に扱っています。RUMを「何のために入れるのか」を上位設計から確認したい場合は、そちらを先に読むと各手法の役割分担が見通せるはずです。

RUMの実装方法とデータ収集設計・APMや合成監視との連携の要点

RUMは、ブラウザに計測コードを入れて初めて機能します。ここが実装の本体で、計装方式の選び方と送信設計が、データ品質と体験への影響を左右します。

web-vitalsライブラリ・SaaS SDK・CrUXの3つの計装入口の使い分け

計装には主に3つの入口があります。1つ目はGoogleが公開するOSSのweb-vitalsライブラリで、Core Web Vitalsを数十行のコードで取得し、送信先を自前で用意する方式です。指標だけを軽量に取りたい場合に向きます。2つ目はSaaSのRUM SDK（Datadog RUM・New Relic Browser・Akamai mPulse・SpeedCurve・Sentry など）で、スニペットを1本入れればセッションリプレイやエラー追跡まで一括で立ち上がります。

3つ目が、計装せずに使えるCrUXです。自サイトがChromeユーザーの一定数を満たせば、Google公式のフィールドデータをPageSpeed Insightsやダッシュボード経由で参照できます。指針はこうです。まずCrUXで現状を把握し、独自属性（ログイン状態・機能別）で切り分けたくなったらweb-vitalsで自前計装、セッション単位の深い調査まで要るならSaaS、という段階で選ぶと過剰投資を避けられます。

ビーコン送信のサンプリング設計とページ表示性能への影響の抑制

全ユーザーの全イベントを送ると、収集側の負荷とデータ量、そしてクライアントの通信量が増えます。そこで必要になるのがサンプリング（間引き）の設計です。トラフィックが大きいサイトほど、通常セッションは数%〜十数%に絞り、エラー発生セッションや閾値超えの遅延セッションは優先的に残す方針が効きます。全量保存は費用が先に膨らむため避けます。

• スクリプトはasync読み込みで描画をブロックしない
• 送信はnavigator.sendBeaconでまとめ、リクエスト回数を抑える
• 通常セッションはサンプリングで間引き、エラー・遅延は確実に残す
• 収集する属性を絞り、個人を特定しうる情報はビーコンに載せない

この4点を守れば、計測が体験を重くする「観測が対象を歪める」問題を避けられます。RUMは体験を測る道具なので、道具自体の負荷を最小に保つことが設計の前提になります。

APMの分散トレースやマネージドRUMサービスとの連携の設計

RUMはフロントの体験を映しますが、「なぜ遅いか」の答えはサーバー側にあることが多く、バックエンドの計測と紐づけて初めて原因まで届きます。ここで組み合わせるのがAPM（アプリケーション性能監視）です。RUMのセッションとAPMの分散トレースを同じIDで連結すると、「特定ユーザーの遅いページ表示」から「その裏で3秒かかったDBクエリ」までを一本でたどれます。バックエンド側の仕組みはAPM（アプリケーション性能監視）とは：仕組み・3種の監視データ・OpenTelemetry計装で扱っており、RUM（フロントの実ユーザー）とAPM（サーバー内部の処理区間）を対で入れると計測の死角が減ります。

クラウドではマネージドのRUMも選べます。AWSにはCloudWatch RUMがあり、収集基盤を自前で持たずにブラウザ計測を始められます。CloudWatchやX-Rayと合わせたクラウド側の計装構成はAWSオブザーバビリティの実装：ADOT・CloudWatch・Container Insightsにまとめました。RUM単体で導入するか、既存の監視基盤に寄せるかは、後述の選定で判断します。

RUM導入の判断基準と合成監視との使い分け・ツール選定の見極め

ここからは判断の章です。RUMは入れれば必ず得をする道具ではありません。合成監視で足りる場面もあり、ツール形態でも費用構造が変わります。条件を付けて言い切ります。

RUMを導入すべき条件と、合成監視だけで足りる場面の切り分け

RUMを入れるべきなのは、次の条件に当てはまる場合です。ユーザーの端末・回線・地域が多様で、開発環境の計測では実害が見えない。Core Web Vitalsが検索評価や離脱・CVに直結している。障害の「影響を受けた実ユーザーの範囲」を数で押さえたい。これらが複数当てはまるなら、RUMは改善の当たりどころを実データで示してくれます。

逆に、決まった主要導線の死活・応答を24時間監視したいだけなら、合成監視（外形監視）で足ります。合成監視は模擬実行のため、ユーザーがいない深夜でも安定して測れ、リリース前の回帰チェックにも使えます。RUMは実ユーザーがいないと何も取れず、トラフィックが極端に少ないサイトでは統計的に判断できません。両手法の違いと外形監視の実装・導入判断は外形監視とは：内部監視との違いと監視項目・実装、導入判断で整理しています。まず合成監視で異常検知を固め、実ユーザーの体験分布まで踏み込む段になってからRUMを足す進め方が堅実です。

SaaS型RUMと内製OSSスタックの費用構造と選定の判断基準

ツール形態はSaaSと内製OSSの2択です。SaaSは、スニペット1本でセッションリプレイやエラー追跡まで数時間で立ち上がる反面、収集イベント数やセッション数に応じた従量課金で、トラフィックが増えると費用が加速します。内製は、web-vitalsで計装して自前の収集エンドポイントとダッシュボード（Grafana等）へ流す構成で、従量課金はない代わりに基盤の構築と運用を自社で持ちます。

選定の指針はこうです。運用チームが小さく体験の可視化を早く始めたいならSaaS、送信データを社外に出せない要件があるか、トラフィックが大きく従量課金が読めないなら内製。指標だけを軽く取りたい段階ならweb-vitals＋自前送信で始め、深い調査が要るようになってからSaaSへ寄せる移行も現実的です。RUMのSSと合わせて、体験改善の傘全体（表示速度・可用性・エラー）を扱う考え方はデジタルエクスペリエンスモニタリングとは何か：定義と重要性でも触れています。

RUM導入でよくある失敗パターンと改善が回る運用への落とし込み

導入が空回りする典型を、条件付きで挙げます。第一に、データを集めるだけで閾値アラートと改善の担当を決めず、ダッシュボードを誰も見ない状態です。p75のLCP・INP・CLSに目標値を置き、悪化したら通知して直す運用まで作らないと、RUMは高価なグラフ置き場になります。第二に、ビーコンを同期読み込みや高頻度送信で入れてしまい、計測コード自体がページを重くするパターン。第三に、平均値だけを見て、一部の低速端末で起きている悪化を取りこぼす見方の誤りです。

これらは、目標値の設定・非同期かつサンプリング済みの送信・分位数での評価の3点を導入設計時に決めておけば防げます。既存サイトへの後付け計装や、監視を含む保守運用を内製に載せ替える際は、システムの保守運用・内製化支援で、計装方針の策定からアラート設計・改善サイクルの運用体制づくりまで併走できます。RUMを「入れて終わり」にせず、改善が回る運用へ落とすところまでが設計の対象です。

よくある質問

RUMの導入検討でよく挙がる質問に、実装の観点で簡潔に答えます。

RUMと合成監視（シンセティックモニタリング）の違いは何ですか？

RUMは実際のユーザーのブラウザから体験データを集める手法で、合成監視は決まったシナリオを機械が定期実行して測る手法です。RUMは実ユーザーの分布や実害を映しますが、ユーザーがいないと取れません。合成監視は再現性が高く24時間安定して測れますが、実ユーザーの多様な条件は反映しません。両者は競合せず併用します。

RUMとAPMはどう使い分けますか？

RUMはブラウザ側（フロントエンド）の実ユーザー体験を、APMはサーバー側（バックエンド）の処理区間や分散トレースを見ます。RUMで「遅い・エラーが出ている」を実ユーザー単位で捉え、APMで「その裏のどの処理が原因か」まで追う、という補完関係です。両者を同じIDで連結すると、体験から原因まで一本でたどれます。

RUMを入れるとページが遅くなりませんか？

計装を誤ると遅くなり得ます。スクリプトをasyncで非同期読み込みし、送信をnavigator.sendBeaconでまとめ、通常セッションはサンプリングで間引けば、体験への影響は最小に抑えられます。同期読み込みや高頻度送信は禁物です。計測が対象を重くしては目的と矛盾するため、軽量設計が前提です。

Core Web VitalsはRUMで測るべきですか、ラボで測るべきですか？

両方に役割があります。ラボ計測（Lighthouse等）は固定条件で再現性があり、リリース前の回帰チェックに向きます。RUMやCrUXは実ユーザーのフィールドデータで、検索評価や実際の離脱に効くのはこちらです。開発時はラボで作り込み、公開後はRUM/CrUXで実環境の分布を監視する使い分けが実務的です。

小規模サイトでもRUMは必要ですか？

トラフィックが極端に少ないと統計的に判断できないため、無理に入れる必要はありません。その段階ではCrUXやPageSpeed Insightsで現状を把握し、まず合成監視で死活・応答を固めるのが先です。ユーザーが増え、端末・回線のばらつきが実害として見え始めた段階が、RUM導入の目安になります。

関連記事

• オブザーバビリティ（可観測性）とは：監視との違い・3本柱・主要ツール：RUMの上位概念。フロント計測を全体設計の中に位置づけたい場合に。
• APM（アプリケーション性能監視）とは：仕組み・3種の監視データ・OpenTelemetry計装：RUM（フロント）と対になるバックエンド側の計測。原因追跡まで届かせるために。
• Core Web Vitalsとは：Webページパフォーマンスの重要指標の解説：RUMが集めるLCP・INP・CLSの定義と合否の目安。
• 外形監視とは：内部監視との違いと監視項目・実装、導入判断：RUMと使い分ける合成監視（模擬実行）の基礎と導入判断。
• AWSオブザーバビリティの実装：ADOT・CloudWatch・Container Insights：CloudWatch RUMなどクラウド上での計装構成。