Mobile RUM
iOS や Android などのネイティブアプリに SDK を入れ、クラッシュや起動時間、画面ごとの遅さを実ユーザーの端末側から記録する RUM です。課金の単位はブラウザー RUM と同じセッションで、見える項目だけがモバイル固有です。
何ができるか
iOS、Android、React Native、Flutter、Kotlin Multiplatform、.NET MAUI、Unity、Roku、C++ 向けの SDK で、セッション、画面 (View)、操作、エラーを端末から収集します。クラッシュレポートは dSYM や mapping ファイルで記号化し、起動時間、ハング、ANR、描画の遅れをモバイル Vitals として集めます。
どのような場面で使うか
「ストアのレビューで初めてクラッシュを知る」状態を抜けるときに使います。新バージョン配信後にクラッシュ率が上がったかを版ごとに見る、起動が遅くなった版を見つける、特定の画面で操作が固まる原因をトレースまで追う、といった使い方です。
身近な例え
客先に持ち出した営業車に付けた走行記録装置です。店 (サーバー) では見えない路上の急ブレーキ (クラッシュ) や渋滞 (起動の遅さ) を、車自身が記録して帰ってきます。どの車種 (アプリの版) とどの道 (画面) で多いかが並びます。
結論 - 数え方はブラウザー RUM と同じセッション、見えるものがモバイル固有
モバイル RUM は RUM の一部です。公式ドキュメントはブラウザー、Android、iOS、React Native、Flutter、Kotlin Multiplatform、.NET MAUI、Unity、Roku、C++ に対応します (2026 年 9 月時点・出典: Application Monitoring)。Android SDK は Android 6.0 以上に対応します (出典: Android and Android TV Monitoring)。課金の単位はブラウザーと同じセッションで、RUM Measure と RUM Investigate の 2 層がいずれも 1,000 セッションあたりの月額で課金されます (出典: Datadog Pricing)。2 層の仕組みは RUM の解説に譲ります。違うのは中身で、サーバーのログに残らないクラッシュ、起動の遅さ、画面の固まりが実ユーザーの端末から届きます。
クラッシュレポートと記号化 - dSYM と mapping ファイル
第一の価値はクラッシュです。iOS では記号化されたスタックトレースを得るため、ビルド時の .dSYM ファイルを Datadog へアップロードします。テスト用クラッシュで到着を確かめる手順もあります (2026 年 9 月時点・出典: Apple Platform Crash Reporting and Error Tracking)。Android は mapping で難読化を解いたレポート、C / C++ 向けの NDK クラッシュ、ANR の報告に対応します (出典: Android Crash Reporting and Error Tracking)。iOS 固有のアプリハングは、応答せず終了した致命的なものに Error Tracking と RUM Explorer で「Crash」の印が付き、回復したものは印なしです。鍵が無いと、届いたスタックトレースは読めません。CI に dSYM と mapping のアップロードを組み込むことが導入の実質的な第一歩です。
| 項目 | iOS SDK | Android SDK |
|---|---|---|
| 記号化 / 難読化の解除に使うもの | .dSYM ファイル | mapping ファイル |
| ネイティブコードのクラッシュ | 記載なし (本記事の参照範囲) | NDK クラッシュレポート (C / C++) |
| 応答なしの検知 | アプリハング (致命的なものは Crash の印付き、非致命的なものは印なし) | ANR の報告 |
| 導入後の確認 | テスト用クラッシュを起こして再起動し、到着を確認 | 難読化を解いたスタックトレースの到着を確認 |
起動時間とモバイル Vitals は端末の側で測る
端末側の性能は、サーバーのログには残りません。Application Launch Monitoring は、最初のフレームが描かれるまでの時間 (time to initial display) と操作可能になるまでの時間 (time to full display) を iOS と Android で測ります (2026 年 9 月時点・出典: Apple Platform Monitoring)。モバイル Vitals は端末の指標群で、リフレッシュレート、遅い描画、700 ミリ秒を超えて止まるフローズンフレーム、CPU ティック、メモリ使用率、iOS ではハング率が並びます。バージョンごとのクラッシュフリーセッション率も同じ画面にあり、RUM Explorer で画面を選ぶと推奨の基準範囲が示されます (出典: Mobile Vitals)。これらはトレースでもログでも代替できません。サーバーが 50 ミリ秒で返しても、端末で 700 ミリ秒止まれば利用者には固まったアプリです。
| 指標 | 何を測るか |
|---|---|
| リフレッシュレート | メインスレッドの描画が滑らかに保たれているか |
| 遅い描画 (slow renders) | フレームの描画が基準より遅れた割合 |
| フローズンフレーム | 700 ミリ秒を超えて描画が止まり、固まって見えるフレーム |
| CPU ティック / 秒 | 画面ごとの CPU 消費 (電池への影響) |
| メモリ使用率 | メモリ不足によるクラッシュの手前の状態 |
| ハング率 (iOS) | Apple の定義で、1 時間あたりに応答しなかった秒数 |
| クラッシュフリーセッション率 | アプリのバージョンごとに、クラッシュしなかったセッションの割合 |
画面 (View) を単位に、アプリのバージョンで比べる
記録単位は画面 (View) です。View timings で画面ごとの性能を捉え、読み込み完了を知らせる API もあります (2026 年 9 月時点・出典: Apple Platform Monitoring App Performance)。Vitals もクラッシュも View に紐づき、「決済画面だけ遅い」が画面名で並びます。もう 1 つの軸がバージョンで、Vitals の画面は版をまたぐ推移を出し、版で絞り込めます (出典: Mobile Vitals)。利用者が更新するまで古い版が動くため、「直したはずのクラッシュがまだ届く」のは古い版の分で、版別に並べると修正版の普及とクラッシュの残りが同じグラフで読めます。バックグラウンドの追跡とオフライン時の後送りも含まれ (出典: Android and Android TV Monitoring)、機内でも記録が欠けません。Frustration Signals と Web View Tracking も両 OS にあります。
ブラウザー RUM と同じ SKU で数えることの意味
課金はブラウザーと共通で、Measure と Investigate の 2 層は RUM の解説に譲ります。ここではモバイル特有の数え方だけ押さえます。セッションは無操作 15 分で失効し、最長 4 時間と定義されています。通勤中に 1 分開いて閉じる使い方が 1 日 10 回あれば、15 分の失効を挟むため 10 セッションになり、Web の長い 1 訪問とは数え方の実感が変わります。見積もりは「月間アクティブ利用者 × 1 人あたりの起動回数」から始めると桁を外しません。Session Replay の追加分と SDK 間の再現範囲の差は Session Replay の解説に譲ります。料金体系の全体は料金の読み解きにまとめています。
- 仮定: 月間アクティブ利用者 5 万人、1 人あたり月 20 回起動、起動 1 回 = 1 セッション
- 月間セッション = 100 万 = 1,000 セッション単位で 1,000
- RUM Measure: 1,000 × Measure の単価 (1,000 セッションあたり)
- RUM Investigate: 全セッションを対象にすると 1,000 × Investigate の単価、フィルターで 10% に絞れば 100 × Investigate の単価
Mobile App Testing と混同しない
名前が近く取り違えやすいのが Mobile App Testing で、Synthetics 側の実機テストです。公式料金ページでは 100 テスト実行あたりの月額として、RUM とは別の SKU で数えます (出典: Datadog Pricing)。RUM は実ユーザーの端末で起きたことの観察、Mobile App Testing は利用者がいなくても実機で操作して確かめる検証で、役割は補完です。深夜にクラッシュが増えたことは RUM が教え、リリース前のビルドが起動するかは Mobile App Testing が教えます。単位も違い、RUM はセッション数、Mobile App Testing は実行回数で、どちらか一方で他方を代替できません。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
| 観点 | モバイル RUM | Mobile App Testing |
|---|---|---|
| 製品の系統 | RUM (実ユーザー監視) | Synthetics (外形監視) |
| 誰が操作するか | 実ユーザー | Datadog が実機で疑似操作 |
| 見えるもの | クラッシュ、起動時間、Vitals、画面ごとの遅さ | 定めたシナリオが実機で通るか |
| 課金の単位 | 1,000 セッションあたり (Measure / Investigate の 2 層) | 100 テスト実行あたり |
| 向く問い | 利用者の端末で何が起きているか | リリース前のビルドが動くか |
Error Tracking と Session Replay をどう重ねるか
導入後の積み方は 3 段です。1 段目が RUM 本体で、クラッシュ、ANR やハング、起動時間、Vitals が画面とバージョンの単位で並びます。2 段目が Error Tracking で、同じ原因のクラッシュを 1 つの Issue に束ね、新しい Issue が出たときだけ通知します。3 段目が Session Replay で、クラッシュ直前に利用者が何をしていたかを再現します。順番の理由は費用と手間で、1 段目は SDK と dSYM や mapping のアップロードで成立し、2 段目は追加の SDK を要しません。3 段目は 1,000 セッションあたりの追加単価が乗るため、クラッシュが集中する画面に絞るのが順当です。導入直後は Issue 一覧を毎朝見る運用だけで、ストアのレビューより先にクラッシュを知る状態に到達します。「遅いのは端末側かサーバー側か」の切り分けは、その後で APM と接続すれば足ります。
注意点
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。対応プラットフォームと SDK の機能は追加され得るため、導入時は各プラットフォームのセットアップページを優先してください。
- 本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
- クラッシュレポートを読める形で受け取るには、iOS の .dSYM と Android の mapping ファイルをビルドごとにアップロードする必要があります (2026 年 9 月時点)。CI の工程に組み込んでから本番配信することを推奨します。