Amazon Web Services ブログ
Amazon CloudWatch RUM がモバイルアプリケーションモニタリングをサポート
本記事は 2025 年 12 月 9 日 に公開された「Amazon CloudWatch RUM now supports mobile application monitoring」を翻訳したものです。
Amazon CloudWatch RUM のモバイル対応を発表できることを嬉しく思います。これにより、AWS のリアルユーザーモニタリング (RUM) 機能が iOS および Android アプリケーションにも拡張されます。これまで Web アプリケーションでのみ利用可能だったモニタリングツールが、モバイル開発者にも提供されるようになりました。
モバイルデバイスが日常生活においてますます重要になる中、モバイルアプリの最適なパフォーマンスとユーザーエクスペリエンスを確保することがこれまで以上に重要になっています。しかし、モバイルアプリのモニタリングには、デバイス、オペレーティングシステム、アプリケーションバージョン、ネットワーク、ユーザーインタラクションの多様性により、独特の課題があります。モバイルアプリ開発者は、「テストでは完璧に動作するのに、実環境ではパフォーマンスの問題が発生する」という継続的な課題に直面しています。合成テストや従来のモニタリング手法は実世界のパフォーマンスに関する洞察を提供しますが、エンドユーザーエクスペリエンスを理解するために必要なデータが不足しています。そこで CloudWatch RUM Mobile の出番です。実際のユーザーの手の中でモバイルアプリがどのように動作しているかについて深い洞察を提供するメトリクスを収集できます。
モバイル向け Amazon CloudWatch RUM
モバイル向け Amazon CloudWatch RUM は、エンドユーザーのモバイルアプリが使用される際に、非常に重要なパフォーマンスデータとユーザー行動メトリクスを収集するのに役立ちます。軽量な SDK を Android または iOS アプリに実装することで、アプリのパフォーマンス、ユーザーインタラクション、ユーザーエクスペリエンスに影響を与える潜在的な問題に関する豊富な情報をキャプチャできます。
開始するには、CloudWatch RUM コンソールで「アプリケーションモニター」を作成し、SDK をアプリに統合してデプロイするだけです。SDK はユーザーがアプリを操作する際にバックグラウンドで実行され、貴重なデータを RUM に送信して集約と分析を行います。このツールは単独で使用することも、Amazon CloudWatch Application Signals や AWS X-Ray などの他の AWS サービスと組み合わせて使用することもでき、Web およびモバイルプラットフォーム全体でアプリケーションのパフォーマンスを包括的に把握できます。
開発プロセスを変革する主なメリット
CloudWatch RUM Mobile は、開発チームがリアクティブなデバッグからプロアクティブな最適化へと移行できるようにします。実際のユーザーからリアルタイムのパフォーマンスメトリクスを収集し、ユーザー満足度に影響を与える前にパフォーマンスの問題を特定できます。システムは画面の読み込み時間を監視し、アプリのクラッシュ、Android の ANR (Application Not Responding) または iOS のアプリハングを完全なコンテキストとともに追跡し、これらすべてのデータを包括的なダッシュボードで視覚化します。
変革は即座に起こります。ユーザーからの苦情を待ったり、バグを再現しようとしたりする代わりに、ユーザーがアプリとやり取りするたびに何を経験しているかについて、明確で実用的な洞察が得られます。
はじめに: モバイルモニタリング強化への道
このブログでは、Amazon CloudWatch RUM を Android および iOS モバイルアプリに統合する方法を学びます。モバイル向け CloudWatch RUM の使用を開始するには、以下の詳細な手順に従って、Android または iOS アプリのモニタリングをセットアップして実装します。
Android 用アプリケーションモニターのセットアップ
開始するには、まず「アプリケーションモニター」を作成する必要があります。これを行うには、AWS CloudWatch コンソールを開き、Application Signals に移動して RUM を選択します。次に「Add app monitor」をクリックします。

図 1: AWS CloudWatch コンソールからアプリモニターを作成
これで「Android」と「iOS」という 2 つの新しいオプションが表示されます。「App monitor name」の下でアプリモニターに名前を付け、プラットフォームとして「Android」または「iOS」のいずれかを選択して続行します (ここでは Android を選択します)。

図 2: アプリケーションモニターの作成 – Android と iOS のオプション
要件に基づいて有効にできるいくつかの「オプション」フィールドがあります。
- RUM テレメトリを Amazon CloudWatch Logs で利用できるようにする場合は、「Data Storage」オプションをチェックします
- リソースベースのポリシーを使用してアクセスを制御する場合は、「Attach a public Resource Based Policy」をチェックします
- スパンを X-Ray で利用できるようにする場合は、「Active tracing」オプションをチェックします

図 3: アプリケーションモニターの作成 – オプションフィールド
Add app monitor をクリックして完了します。
コンソールは、データの収集を開始するために Android アプリケーションに追加する必要があるコードスニペットを提供します。コードは「手動計装」と「ゼロコード計装」の両方で提供されます。
スニペットを保存しましょう。これは、このブログの後半の「Android アプリの計装」セクションで使用します。

図 4: アプリモニターの作成 – 手動およびゼロコード計装用のコードスニペット
Android アプリの計装: 実装パスの選択
アプリケーションモニターが作成されたので、テレメトリデータをアプリケーションモニターに送信するようにモバイルアプリを計装しましょう。上記で気づいたように、モバイルアプリを計装または設定するには、ゼロコード計装と手動計装の 2 つのオプションがあります。
まず、「アプリケーションモニターのセットアップ」セクションのコードスニペットを手元に用意してください。このセクションを完了するために必要になります。コードは https://github.com/aws-observability/aws-otel-android でも入手できます。それでは、これらの各オプションを確認しましょう。
オプション 1: ゼロコード計装 (エージェント)
これには、まずアプリケーションの "app/build.gradle" ファイルにいくつかの依存関係を注入する必要があります。以下は Kotlin DSL の例です。
次に、ゼロコード設定では、アプリケーションの "res/raw" ディレクトリの下に "aws_config.json" というファイルを作成し、以下のコードスニペットを記述する必要があります (各パラメータの値を必ず置き換えてください)。
これで完了です! これは、Android エージェントを初期化し、CloudWatch RUM アプリケーションモニターへのテレメトリの収集を開始するために必要な最小限のものです。
オプション 2: 手動計装
クライアントをプログラムで設定するには、オプション 1 で使用した「agent」モジュールの代わりに、軽量な「core」モジュールを使用します。これには、アプリケーションの "app/build.gradle" ファイルに以下の SDK を追加しましょう。
次に、アプリケーションで AWS Distro for OpenTelemetry (ADOT) Android エージェントを初期化する必要があります。
最後に、Application クラスがまだない場合は、この新しい「MyApplication」を Android マニフェストに登録する必要があります。
この後、アプリケーションを実行して、アプリケーションモニターへのテレメトリの受信を開始できるはずです。
iOS 用アプリケーションモニターのセットアップ
iOS アプリケーション用のアプリケーションモニターを作成するプロセスは、上記で示した Android アプリケーションの場合と同じです。iOS 用のアプリモニターが作成されたら、テレメトリデータの送信を開始するためにアプリケーションを計装する方法を見てみましょう。iOS のコードも https://github.com/aws-observability/aws-otel-swift で入手できます。
オプション 1: ゼロコード計装 (エージェント)
Android の「アプリケーションモニター」と同様に、「アプリケーションモニター」作成の最終ページで iOS アプリを計装するための「コードスニペット」を取得できます。これらの手順に基づいて、Swift SDK の依存関係をアプリケーションの "Package.swift" ファイルに注入します。
SDK は、「AwsOpenTelemetryAgent」モジュールがアプリにインポートされると自動的に初期化されます。アプリバンドルのルートディレクトリで "aws_config.json" という名前のファイルを探します (各パラメータの値を必ず置き換えてください)。
オプション 2: 手動計装
クライアントをプログラムで設定するには、プロジェクトの "Package.swift" ファイルに以下の依存関係を追加します。
次に、アプリケーションで ADOT Swift エージェントを初期化します。
アプリのパフォーマンスの可視化: データが洞察に変わる場所
モバイル向け CloudWatch RUM がデータの収集を開始すると、CloudWatch RUM はモバイルパフォーマンスのコマンドセンターに変わり、生のパフォーマンスデータを実用的な洞察に変える複数の専門的なビューを提供します。
表示される RUM アプリケーションモニターのリストから、上記のセクションで作成したアプリケーションモニターを選択します。これにより、Performance、Errors、Sessions、Metrics、Configuration などのさまざまなタブを持つダッシュボードが表示され、画面、アプリバージョン、OS バージョン、デバイス、国、リージョン、地域によるフィルタリング機能が提供されます。
Performance タブ: 速度と応答性の詳細な分析
CloudWatch RUM コンソールの Performance タブは、モバイルアプリのパフォーマンスに関する洞察を提供します。この詳細ビューでは、画面読み込み時間を画面名、OS バージョン、アプリバージョン、デバイス、国別に分類して表示します。以前は見えなかったパターンが明確になります。特定の国ではネットワークインフラストラクチャの違いによりアプリのパフォーマンスが異なる、または特定のデバイスモデルが特定の機能で苦労しているなどです。チャート内の画面読み込み時間のデータポイントをクリックすると、右側に診断パネルが開き、データポイントに関連する詳細な洞察 (最新の関連セッションなど) と、1 つまたは他の類似セッションのトラブルシューティングを行うための Sessions タブへのリンクが提供されます。
App Launch time ビューでは、アプリケーションの起動パフォーマンスを詳細に分析し、起動タイプ (コールド/ウォーム)、OS バージョン、アプリバージョン、デバイス、国別に起動時間を分類します。この詳細なビューは、パフォーマンスのボトルネックを特定するのに役立ちます。特定の OS バージョンでコールドスタートが遅い、または特定のデバイスモデルが初期化で苦労しているなど、最も影響力のあるユーザーセグメントに対して的を絞った最適化の取り組みを可能にします。
Locations タブは、アプリケーションパフォーマンスに関する地理的な洞察を提供し、国、リージョン、地域全体のメトリクスを表示して、場所ベースのパフォーマンスパターンを明らかにします。このビューは、地域のインフラストラクチャの課題、ネットワークレイテンシーの問題、またはユーザーがパフォーマンスの低下を経験している地理的エリアを特定するのに役立ちます。

図 5: AWS CloudWatch RUM – Performance タブ
Errors タブ: デバッグの相棒
Errors タブは、エラー追跡を体系的な問題解決に変換します。アプリケーションの問題を 3 つのカテゴリに分類します: Network Errors、Crashes、ANRs/App hangs。Network Errors タブには、HTTP リクエストの折れ線グラフがあり、HTTP パフォーマンスメトリクスを表示し、左の Y 軸に失敗率 (HTTP エラー、HTTP フォールト、ネットワーク障害) を、右の Y 軸に HTTP レイテンシーを示します。この時系列データポイントにより、ユーザーはクリックして、診断パネルでトラブルシューティングのために関連するスパンとセッションを表示できます。下部のテーブルには、最も一般的な 100 のネットワークルートがリストされます。
同様に、Crashes および ANRs/App hangs タブには、各エラーのカウントの折れ線系列が表示されます。下部のテーブルには、最も一般的な上位のクラッシュメッセージ/ANR スタックトレースが表示されます。エラーメッセージをクリックすると、クイックリファレンス用にスタックトレース全体がポップアップ表示されます。

図 6: AWS CloudWatch RUM – Errors タブ
Sessions タブ: ユーザージャーニーの追跡
次に、Sessions タブでは、詳細なウォーターフォール表示を使用して、アプリ内の個々のユーザージャーニーを追跡できます。これらの可視化は、ユーザーインタラクション中に時間がどこで費やされているか、ユーザーがどこで摩擦や遅延を経験しているかを正確に示します。このユーザー中心のビューは、技術的なパフォーマンスだけでなく、全体的なユーザーエクスペリエンスを最適化するのに役立ちます。
すべてのセッションをリストするテーブルがあり、時刻の降順にソートされています。下部には、選択したセッションのすべてのテレメトリを視覚化するウォーターフォールがあります。ウォーターフォールの各行を選択して、診断パネルを開くことができます。行が HTTP リクエストの場合、トレースコンソールにディープリンクされた traceId があります。例外、クラッシュ、または ANR/App hang を受信した HTTP リクエストの場合、診断パネルにはスタックトレースを表示する Exception タブもあります。ウォーターフォールの「View」ボタンは、ワンクリックで例外に直接移動する簡単な方法でもあります。

図 7: AWS CloudWatch RUM – Sessions タブ – ARN

図 8: AWS CloudWatch RUM – Sessions タブ – HTTP traceId
Metrics タブ: アプリケーションヘルスのモニタリング
Metrics タブは、レイテンシー、エラー、ボリューム、拡張メトリクスに関するアプリケーションのパフォーマンスに関するリアルタイムデータを視覚化するのに役立つ包括的なダッシュボードを提供します。
このタブには、右上に「Add to dashboard」というオプションもあり、このデータを他の CloudWatch ダッシュボードにエクスポートできます。

図 9: AWS CloudWatch RUM – Metrics タブ
Configuration タブ: 継続的な管理
最後に、Configuration タブは、アプリモニター設定とインストルメンテーションコードスニペットへのアクセスを容易にし、モニタリングのニーズが進化しても、継続的な管理と更新を容易に行えます。

図 10: AWS CloudWatch RUM – Configuration タブ
まとめ
モバイル向け Amazon CloudWatch RUM は、モバイルアプリケーションのオブザーバビリティをリアクティブなトラブルシューティングからプロアクティブな最適化に変革し、パフォーマンスモニタリングを通じてビジネスインパクトをもたらします。チームは、地域のクラッシュを引き起こすローカライゼーションのバグや、コールドスタートのパフォーマンスを低下させるサードパーティ SDK などの重要な問題を特定して解決できます。CloudWatch Application Signals とのシームレスな統合により、モバイルユーザーエクスペリエンスからバックエンドの依存関係までのエンドツーエンドのトレースが可能になります。
この機能は、CloudWatch RUM が動作するすべての商用リージョンで利用できます。この実装により、チームは既存の開発ワークフローを維持しながらパフォーマンスデータを収集でき、アプリケーションスタック全体でトレースされたユーザーセッションからのメトリクスを使用して、組織がモバイルアプリ開発にアプローチする方法を変えます。
この新機能の詳細については、ドキュメントをご覧ください。また、Android および iOS の入門ガイドもご覧ください。最後に、料金 の詳細もご確認いただけます。
著者について
この記事は Kiro が翻訳を担当し、Solutions Architect の Aya Hara がレビューしました。