--- title: "デジタルエクスペリエンスモニタリング（DEM）とは？RUM・合成監視・エンドポイント監視の3構成と導入判断" url: "https://www.issoh.co.jp/column/details/3806/" published: 2024-10-10 updated: 2026-10-12 categories: ["ガイドライン"] publisher: "株式会社一創" --- # デジタルエクスペリエンスモニタリング（DEM）とは？RUM・合成監視・エンドポイント監視の3構成と導入判断 デジタルエクスペリエンスモニタリング（DEM）は、サーバやネットワーク機器の稼働状況ではなく、エンドユーザーが実際に受け取った応答速度と操作品質を測る監視分野です。サーバのCPU使用率もアプリのエラー率も正常なのに「業務システムが重い」という申告が止まらない。この切り分けができないという運用課題から生まれた領域で、リアルユーザーモニタリング（RUM）、合成監視（STM）、エンドポイント監視という3つの計測手法で構成されます。 ## まとめ - DEMはGartnerが定義した監視分野。対象は「エンドユーザー（または機械のデジタルエージェント）がアプリと基盤を使ったときの可用性・パフォーマンス・体験品質」で、測る主語がサーバからユーザーへ移っている点が従来監視との差。 - 構成要素は**RUM（実ユーザーの計測）**・**合成監視／STM（スクリプトによる能動計測）**・**エンドポイント監視（端末・VDI側からの計測）**の3つ。1つだけでは無人時間帯や端末固有の劣化を取りこぼす。 - APMの主語は「アプリ内部の処理」、オブザーバビリティは「未知の障害を説明できる状態」、DEXは「従業員の業務端末の快適さ」。DEMと重なる部分はあるが同義ではない。 - 製品選定の一次資料はGartnerのMagic Quadrant for Digital Experience Monitoring。2025年版は2025年10月27日発行で14社を評価している。 - RUMで取るLCP・INP・CLSはCore Web Vitalsと同じ指標で、判定は75パーセンタイル。ただしDEMは検索順位対策の道具ではなく、体験劣化の検知と切り分けが本来の役目。 - SASE／ゼロトラスト構成では通信が自社ネットワークを通らないため、社内監視だけでは原因箇所を特定できない。ZDXやADEMなどSASE付属のDEMが要るのはこのため。 - OpenTelemetryによる自前構築は可能。ただしブラウザ計装は公式に「実験的でほぼ未仕様」の段階で、本番のRUM基盤を全面的に載せるにはまだ早い。 以下、定義・3つの構成要素・類似用語との境界・SASE環境での位置づけ・導入を見送るべき条件の順に整理します。 ## デジタルエクスペリエンスモニタリング（DEM）の定義と対象範囲 ### Gartnerの定義：可用性・パフォーマンス・体験品質という3つの測定軸 Gartnerは DEM を、エンドユーザーまたはデジタルエージェントがアプリケーションとその基盤とやり取りする際の「可用性・パフォーマンス・体験品質」を監視する技術群と定義しています。ここで見落とされやすいのが**「デジタルエージェント」＝人間に限らない**という点です。API経由で叩いてくる機械的なクライアントや、業務を代行するボットも計測対象に含まれます。RPAが夜間に走らせるバッチ処理の応答劣化も、定義上はDEMの守備範囲です。 DEMを「ユーザー体験の可視化ツール」と紹介する解説は多いものの、可視化そのものは目的ではありません。定義の力点は、体験の劣化を運用上の判断材料へ変換する分析規律という位置づけにあります。 ### 従来の稼働監視との差分：測定起点がデータセンターから端末へ移る 従来の監視が指標にしてきたのは、サーバのCPU・メモリ、ネットワークのトラフィック量、アプリケーションログといった「システム側の正常性」でした。監視項目の分類と役割分担は[システム監視とは？監視項目の種類と死活監視・性能監視の違いを発注者視点で解説](/column/details/13447/)で整理しています。この方式の弱点は明確で、監視対象が全て正常でもユーザーが遅さを感じる状況を説明できません。原因はデータセンターの外側——ユーザーの自宅ISP、Wi-Fi、端末のCPU、ブラウザ拡張、経路上のCDNやプロキシ——に散らばっているためです。 DEMは計測の起点を端末側・ユーザー側に置き直し、「原因不明」で閉じられていた申告に対して、劣化がどの区間で起きたかを示す根拠を与えます。逆にいえば、社内LANに閉じた業務システムしか持たない環境では、この起点移動の価値は小さくなります。 ## DEMを構成する3つの監視手法 DEMは単一の製品ジャンルではなく、計測方式の異なる3つの技術の組み合わせです。それぞれ取れるデータと死角が違います。 ### リアルユーザーモニタリング（RUM）：実トラフィック由来の実測と、その死角 RUMは、実際のユーザーのブラウザやモバイルアプリにJavaScriptタグやSDKを仕込み、発生した全トランザクションの表示時間・操作応答・エラーを収集する方式です。実測値である以上、端末性能や回線品質のばらつきがそのまま反映されます。代表的な実装はDatadog RUM、New Relic Browser／Mobile、Dynatraceなど。計測の仕組みと導入手順は[リアルユーザーモニタリング（RUM）とは｜実ユーザー計測の仕組み・合成監視との違い・導入判断を実装目線で解説](/tech/details/15707/)で詳述しています。 RUMの死角は**「ユーザーが来ないと何も測れない」**点にあります。深夜帯のリリース直後や、利用者の少ない管理画面の劣化は検知が遅れる。社内規定でサードパーティスクリプトの埋め込みが禁じられている業務システムでは、そもそも導入できないこともあります。 ### 合成監視（STM）：無人時間帯を埋める定点観測と、その限界 合成監視（Synthetic Transaction Monitoring）は、ログイン・検索・カート投入といった一連の操作をスクリプト化し、各地の拠点から定期実行してレスポンスを計測します。実ユーザーの有無に関係なく一定間隔で値が取れるため基準値が安定し、SaaS事業者のSLA違反を指摘する材料としても機能します。New Relic Synthetic monitoring、Catchpoint、Site24x7などがこの領域です。Cisco ThousandEyesも合成的なプローブを持ちますが、主戦場はインターネット経路の可視化（IPM）で、性格がやや異なります。外形からの監視設計は[外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説](/tech/details/15223/)で扱っています。 測っているのはあくまで擬似的な操作です。スクリプトに書いた導線しか見ないため、想定外の使われ方で起きる劣化は検知できません。RUMと合成監視は代替関係ではなく、**実測の網羅性と定点観測の安定性を補い合う関係**として設計するのが妥当です。 ### エンドポイント監視：端末・VDIまで含む計測範囲 エンドポイント監視は、デスクトップ・ノートPC・モバイル端末にエージェントを常駐させ、その端末上でアプリケーションがどう動いているかを計測します。GartnerのDEM定義でもVDI（仮想デスクトップ）のサポートが明示されており、仮想デスクトップ環境における体感遅延の切り分けが主要ユースケースの一つです。 この方式でしか取れないのが、端末のCPU・メモリ逼迫、Wi-Fiの電波品質、常駐セキュリティソフトによるオーバーヘッドといった**ブラウザの外側の要因**。「特定の支店だけ遅い」「特定の機種だけ遅い」という申告は、RUMや合成監視では原因まで届かず、エンドポイント側のデータで初めて確定できます。 | 手法 | 計測起点 | 実ユーザー不在時 | 主な死角 | 代表製品 | | --------- | ----------- | -------- | ----------- | ----------------------------- | | RUM | ブラウザ／アプリSDK | 計測不可 | 低トラフィック画面 | Datadog RUM／New Relic Browser | | 合成監視（STM） | 各地の実行拠点 | 計測可能 | スクリプト外の導線 | Catchpoint／Site24x7 | | エンドポイント監視 | 端末常駐エージェント | 端末稼働時のみ | エージェント未導入端末 | Zscaler ZDX／Palo Alto ADEM | 3手法をすべて入れればコストは積み上がります。課金方式も手法ごとに違い、RUMはセッション数、合成監視は実行回数と拠点数、エンドポイント監視は端末数が単価の掛け目になるため、利用者数が同じでも見積もりの伸び方が揃いません。単価は改定されるので必ず各社の料金ページで確認したうえで、「まず合成監視で外形の基準値を作り、劣化の申告が続く領域にRUMを足す」という順序から入るのが、本稿の推奨です。エンドポイント監視は、VDIやリモートワーク端末の申告が多い組織で初めて必要になります。 ## DEM・APM・オブザーバビリティ・DEXの境界 この4語はベンダー資料で頻繁に混用されますが、主語が違います。混同したまま製品選定に入ると、必要な区間のデータが取れないまま契約する事故につながります。 | 用語 | 主語（誰の何を測るか） | 主なデータ源 | 典型的な利用者 | | --------- | ------------- | -------------- | ------------ | | DEM | エンドユーザーが受けた体験 | ブラウザ／端末／合成実行 | IT運用・情シス | | APM | アプリ内部の処理性能 | サーバ側の計装・トレース | 開発・SRE | | オブザーバビリティ | システム全体の説明可能性 | メトリクス／ログ／トレース | SRE・プラットフォーム | | DEX | 従業員の業務端末の快適さ | 端末エージェント・満足度調査 | 情シス・人事IT | DEMとAPMが見ているのは、同じ遅延の別の断面です。APMは「注文APIのDB問い合わせが800ミリ秒かかった」ところまでは示せるものの、そのAPIを呼んだ利用者の画面が実際に何秒で描画されたかは持ちません。逆にRUMは画面の遅さを捉えても、原因がどのクエリかまでは降りられない。サーバ側の内部処理をどう計装するかは[APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説](/tech/details/15414/)で扱っています。 オブザーバビリティはさらに上位の概念で、「事前に想定していなかった障害でも、収集済みのテレメトリだけで原因を説明できる状態」を指します。DEMはその状態を作るための入力の一つ、という関係です。両者の距離感は[オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説](/column/details/3077/)で整理しています。 もっとも紛らわしいのがDEXです。DEM（Digital Experience Monitoring）とDEX（Digital Employee Experience）は略語が一字違いで、エンドポイント監視という共通の実装基盤まで持ちます。分岐点は目的です。DEMが測るのは**アプリケーションやサービスの品質**、DEXが指標化するのは**従業員の働きやすさ**そのもので、後者は端末の刷新計画やヘルプデスクの負荷削減に接続します。両者が別カテゴリであることは製品評価の対象範囲にも表れており、DEXを主戦場とするNexthinkやLakeside Softwareは、2025年版のDEM Magic Quadrantで評価された14社に入っていません。カテゴリの詳細は[デジタル従業員エクスペリエンス（DEX）とは何か？その概念と基本定義を企業IT管理者向けにわかりやすく解説](/column/details/8573/)を参照してください。 製品選定に入る段階では、Gartnerが発行するMagic Quadrant for Digital Experience Monitoringが一次資料になります。2025年版は2025年10月27日発行で14社を評価しており、Dynatraceが2年連続でリーダーに位置づけられ、CatchpointはIPM（インターネットパフォーマンス監視）としての評価でリーダーに入りました。日本語のベンダー用語集ではまず触れられない情報ですが、**「どのベンダーがどの評価軸で入っているか」を先に押さえておくと、機能比較表だけでは見えない守備範囲の違いに気づけます。** ## RUMで見る指標とCore Web Vitalsの対応関係 Webアプリを対象にRUMを入れると、収集される表示・操作系の指標はGoogleのCore Web Vitalsと重なります。web.devが定める良好の基準は、LCP（最大コンテンツの描画）が2.5秒以内、INP（次の描画までの応答）が200ミリ秒以内、CLS（レイアウトのずれ）が0.1以下。いずれも平均値ではなく**75パーセンタイル**で判定するため、「平均は速いが上位25%が極端に遅い」構成では基準を満たしません。 指標の入れ替わりも押さえておく必要があります。応答性の指標は2024年3月にINPが安定版のCore Web Vitalsへ昇格し、それまでのFID（First Input Delay）を置き換えました。FIDが見ていたのは最初の入力に対する遅延だけで、INPはページ滞在中のインタラクション全体を評価します。旧世代の監視ダッシュボードをそのまま使い続けている場合、FIDが良好でもINPで不合格になる構成は珍しくありません。各指標の測定条件は[コアウェブバイタルとは？3指標（LCP・INP・CLS）の基準と改善方法【2026年版】](/column/details/3761/)で解説しています。 ここで区別が要るのが、Googleが公開するフィールドデータ（CrUX）と自前のRUMです。CrUXに載るのは、オプトインしたChromeユーザーが訪れた公開URLのうち十分なトラフィックがあるものに限られ、集計も28日間のローリングです。ログイン後の業務画面や社内システムは、この条件では実質的に入りません。**自社サービスの体験を継続的に改善したいなら、RUMを自前で持つ以外に手はない**というのが実務上の結論です。体験という語自体の定義については[ユーザーエクスペリエンス（UX）とは何かをわかりやすく解説](/column/details/6868/)で扱っています。 ## SASE／ゼロトラスト環境でDEMが必要になる理由 ### 経路変化で失われる可視性 DEMの導入が問われるようになった直接の要因は、通信経路の変化です。従来は「社内端末→社内ネットワーク→自社データセンター」で完結していた通信が、SASE構成では「自宅や外出先の端末→ISP→SASEベンダーのクラウド拠点→SaaS」へと変わりました。この経路上で自社が所有・監視できる区間は、ほぼ端末だけです。構成要素の全体像は[SASEとは？構成要素とゼロトラスト・SSEとの違い、導入判断を解説](/tech/details/13271/)を参照してください。 遅延の申告に対して情シスが持てる情報は、この構成でほぼ消えます。ユーザーの自宅回線が原因なのか、SASEベンダーの拠点が詰まっているのか、SaaS側の障害なのか。社内の監視装置からは判別できません。 ### SASE付属DEMの守備範囲と限界 この空白を埋めるため、主要なSASEベンダーはDEM機能を製品に組み込んでいます。Zscaler Digital Experience（ZDX）、Palo Alto NetworksのAutonomous Digital Experience Management（ADEM、Prisma SASE配下で提供）、Netskope One Digital Experience Managementがその例です。ZDXのCloud Pathのように、端末からアプリまでの経路をホップ単位で計測し、劣化区間を指し示す機能を備えます。 選定時に確認すべきなのは**「そのベンダーの経路を外れたときに何が見えなくなるか」**です。SASE付属のDEMは自社の経路を詳細に見せる一方、そのSASEを経由しない通信——ローカルブレイクアウトさせているSaaSや、別ベンダーのVPN——では、SASEクラウド内部区間のテレメトリが得られず切り分けの精度が落ちます。エージェントを配れない端末が対象外になる点も同じ制約です。マルチベンダー構成の組織では、経路非依存の独立系DEMを別に持つ判断が現実的になります。 ## OpenTelemetryでDEMを自前構築する場合の現在地 OpenTelemetryで計装を標準化してバックエンドだけ差し替えられる形にする、というロックイン回避の方針は、サーバ側については現実的です。ただし**ブラウザ側は事情が違います**。公式ドキュメントは、ブラウザ向けのクライアント計装について「実験的であり、ほとんど仕様化されていない（experimental and mostly unspecified）」と明記し、関心のある開発者にはBrowser SIGへの参加を案内している段階です（2026年7月時点）。実装自体は存在し、`@opentelemetry/sdk-trace-web` を軸に `@opentelemetry/instrumentation-document-load`、`@opentelemetry/context-zone`、まとめて導入する `@opentelemetry/auto-instrumentations-web` といったパッケージが提供されています。 この状況での判断は明快です。**本番のRUM基盤をOpenTelemetryのブラウザ計装だけで組むのは、現時点では推奨できません。**セマンティック規約が固まっていない以上、収集した属性名が将来の仕様確定時に変わり、蓄積したダッシュボードとアラートを作り直す負債を抱えます。 誤解されやすいのは、既製のRUM SDKを選べばこのリスクを回避できる、という理解です。たとえばGrafana Faroのweb-tracingは内部でOpenTelemetryのブラウザ計装を駆動しているため、トレース側の規約変更の影響は等しく受けます。それでも自前実装より安いのは、SDKの保守・Web Vitalsの収集・バックエンドへの送信が既製で揃っており、規約が動いたときの追随をSDK側が引き受けるためです。**選ぶ基準は「OTelを避けられるか」ではなく「規約が動いたときに誰が直すか」**だと考えてください。 ## DEMを導入すべきでない場面と、導入後に失敗する典型 DEMは万能ではなく、条件が合わない組織では費用に見合いません。次のいずれかに当てはまるなら、導入を急ぐ必要はありません。 - **対象システムが社内LAN内で完結している**：経路上の変数が少なく、既存のインフラ監視とAPMで原因まで届く。DEMの主眼である経路の切り分けが不要になる。もっとも本質的な除外条件はこれです。 - **監視結果を受け取る運用体制がない**：劣化を検知しても、切り分け後に誰がどこへエスカレーションするかが決まっていなければ、ダッシュボードが増えるだけで[MTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】](/tech/details/13801/)で扱う平均復旧時間は動きません。 - **個人単位のデータ取得に合意が取れていない**：エンドポイント監視は従業員の端末操作に近いデータを扱う。利用目的と取得範囲を事前に説明・合意しないまま入れると、労使間の不信を招き運用が止まる。 - **対象がネイティブアプリのみで、SDK更新の配布サイクルが長い**：計測仕様を変えるたびにストア審査と利用者の更新を待つことになり、改善のループが四半期単位まで伸びる。Web側から着手するほうが投資回収が早い。 導入後に起こりやすいのは、閾値をベンダーの初期値のまま運用してアラートが飽和するパターンです。DEMが返す値は端末性能や回線品質を含むため、社内システムの実測分布を取ってから75パーセンタイルを基準に自社の閾値を引き直す作業が要ります。期間の目安としては、Core Web Vitalsの評価がCrUXで28日間のローリング集計である点に合わせておくと、外部の評価と比較しやすくなります。飽和したアラートを畳む手順は[アラート疲れとは｜原因と対策を監視の実装視点で解説【2026年時点】](/tech/details/15720/)にまとめました。 もう一つは、RUMだけを入れて「夜間のリリース直後は誰も使っていないので何も検知されない」状態に気づかないケースです。リリース直後の品質確認を目的に含めるなら、合成監視を同時に用意しておく必要があります。 ## よくある質問 ### デジタルエクスペリエンスモニタリングとは何ですか？ エンドユーザー（または機械のデジタルエージェント）がアプリケーションと基盤を利用する際の可用性・パフォーマンス・体験品質を計測する監視分野です。サーバやネットワーク側の正常性を見る従来の監視と異なり、計測の起点を端末側・ユーザー側に置く点が特徴です。 ### DEMとAPMの違いは何ですか？ 測る対象が違います。APMはアプリケーション内部の処理性能（APIの応答時間、DBクエリ、例外）をサーバ側の計装から捉えます。DEMが捉えるのは、その処理を呼び出したユーザーの画面が実際にどう見えたか、どれだけ待たされたか。遅延の原因究明では両方が必要になる場面が多く、対立する概念ではありません。 ### デジタル体験監視とDEX（デジタル従業員エクスペリエンス）は同じものですか？ 異なります。エンドポイント監視という実装基盤は共通するものの、DEMがアプリケーションやサービスの品質を主語にするのに対し、DEXは従業員の業務端末の快適さを主語にし、端末更改やヘルプデスク改善に接続します。製品カテゴリも分かれており、DEX側の代表であるNexthinkやLakeside Softwareは2025年版のDEM Magic Quadrantの評価対象14社に含まれていません。 ### エンドユーザーエクスペリエンスの監視はどの手法で行いますか？ 3手法の組み合わせで行います。実利用の体験はRUM、無人時間帯や定点比較は合成監視（STM）、端末やVDI固有の劣化はエンドポイント監視が担当します。「特定の拠点や機種だけ遅い」という申告に答えるにはエンドポイント監視のデータが必要で、RUMだけでは原因の特定まで届きません。 ### DEMを入れると検索順位は上がりますか？ 直接的な順位改善の施策ではありません。ただしRUMで収集するLCP・INP・CLSはCore Web Vitalsと同じ指標であり、75パーセンタイルの実測値を継続的に確認できるようになります。CrUXでは対象外になるログイン後の画面まで測れるため、ページ表示品質を改善する材料としては有効です。順位はコンテンツの妥当性など他の要因に強く左右されるため、DEMの目的は体験劣化の検知と切り分けに置くのが適切です。 ## 関連記事 - [リアルユーザーモニタリング（RUM）とは｜実ユーザー計測の仕組み・合成監視との違い・導入判断を実装目線で解説](/tech/details/15707/) - [外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説](/tech/details/15223/) - [オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説](/column/details/3077/) - [APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説](/tech/details/15414/) - [デジタル従業員エクスペリエンス（DEX）とは何か？その概念と基本定義を企業IT管理者向けにわかりやすく解説](/column/details/8573/) --- 出典: [デジタルエクスペリエンスモニタリング（DEM）とは？RUM・合成監視・エンドポイント監視の3構成と導入判断]()（株式会社一創）