New Relic Mobile × Browser 連携：WebViewのセッションを紐付けてエンドツーエンドのユーザー分析を実現する

ハイブリッドアプリの運用で、ユーザーから『画面が白くなった』『動かない』という報告を受けた際、原因がネイティブ側のWebView制御にあるのか、それとも中のAngularアプリのJSエラーやAPI遅延にあるのか、切り分けに苦労していませんか？

通常、New Relic MobileとBrowserのデータは独立して計測されます。しかし、それぞれのデータを『セッションID』で紐付けるだけで、ネイティブの画面遷移からWebView内のAjaxリクエストまでを一本のタイムラインで可視化できるようになります。

本記事では、iOS (Swift) と Angular を例に、Native Bridgeを活用した連携実装例を紹介します。

最新のアップデートの詳細はこちら
New Relic アップデート一覧

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！

何ができるようになるのか

実装を完了すると、New Relic上で 「ネイティブとWebの壁」を意識しない分析 が可能になります。

• 1セッションの横断追跡: Mobileの画面遷移から、その中で開いたWebView内のAjaxリクエスト、発生したJSエラーまでを、一つのタイムライン（時系列）で把握できます

• シームレスな障害調査: 「アプリが重い」という報告に対し、原因が「ネイティブ側のWebView呼び出し」にあるのか「Web側のAPI遅延」にあるのかを即座に特定できます

実装の要点：3つのステップによるデータ連携

本実装の核心は、「Native層のコンテキストを抽出し、WebView層のAgentへ注入する」 というプロセスにあります。これを以下の3ステップで実現しています。

1. 【抽出】Mobile Agent からセッション識別子を取得

iOSネイティブ側で、New Relic Mobile SDKが管理しているランタイム情報を取得します。

• 技術ポイント: NewRelic.currentSessionId()
• 役割: Native Agentが計測に使用している一意のセッションIDを特定し、Web側へ渡す準備をします。

2. 【転送】Native Bridge を介したデータの受け渡し

WKWebView のメッセージハンドリング機構（Native Bridge）を利用し、Web側からの要求に応じて情報を転送します。

• 技術ポイント: 非同期通信によるメタデータのデリバリー
• 役割: WebViewのサンドボックス制限を越えて、ネイティブが持つセッション情報をAngular（TypeScript）側へ安全に届けます

3. 【注入】Browser Agentへのカスタム属性設定

受け取った識別子を、Browser Agentが生成するイベントのメタデータとして登録します。

Angular

// Angular側の実装イメージ
newrelic.setCustomAttribute('mobileSessionId', sessionIdFromNative, true);

• 技術ポイント: setCustomAttribute (persist: true)
• 役割: Browser Agentが送出する全イベント（PageViewやAjaxRequestなど）にモバイルのIDを付帯させ、New Relic上での 「共通の結合キー」 を確立します

システム構成：今回の技術スタック（Architecture）

今回の実装で使用する環境と、紐付けに使用するデータ項目は以下の通りです。

技術スタック

• Native: iOS (Swift / WKWebView) + New Relic Mobile Agent
• Web: Angular (SPA) + New Relic Browser Agent (npm)
• Communication: NativeBridge (TypeScriptからNativeの機能を呼び出す仕組み)

データの紐付け設計

Mobile Agentが持つIDを、Browser Agentの「カスタム属性」としてコピーすることで紐付けを実現します。

項目	Mobile側 (Source)	Browser側 (Custom Attribute)
セッションID	NewRelic.currentSessionId()	mobileSessionId
デバイスUUID	UIDevice.current.identifierForVendor	mobileUuid

前提条件

1. iOS に New Relic Mobile Agent を導入済みであること
2. Web に New Relic Browser Agent（npm）を導入済みであること
3. WebViewブリッジが動作していること（JS → Native、Native → JS 応答）

実装手順（iOS）

iOSネイティブ側の主な役割は、「New Relic Mobile Agent が保持している動的なセッション情報を、Web 側からのリクエストに応じて提供できる Bridge を作ること」 です。これにより、Web 側は必要なタイミングで最新のコンテキストを取得できるようになります。

Mobile Agent の sessionId を返す Handler を追加

Web側からのリクエストに応じて、New Relic SDKから最新のセッション情報を取得し、Bridge経由で返却するためのハンドラーを定義します。

Dispatcher に Handler を登録

定義したハンドラーをアプリケーションのコマンドディスパッチャーに追加し、Web側からの getMobileAgentContext 呼び出しに反応できるようにします。

実装手順（Web）

Web（Angular） 側の役割は、「アプリ起動時に iOS 側へセッション情報を問い合わせ、取得したセッションID を Browser Agent の初期化プロセスに組み込むこと」 です。これにより、Web 側で発生する全イベント（PageView, AjaxRequestなど）にモバイル由来のセッションID を自動付与させます。

起動時に sessionId を取得してカスタム属性へ設定

Angularアプリの起動プロセスの中で Native Bridge を介して Mobile 側のセッションIDを取得し、Browser Agentのカスタム属性として反映させます。

setCustomAttribute ヘルパー

New Relic Browser AgentのAPIをラップし、persist: true を指定することで、永続化し遷移やリロードが発生した場合も自動的に属性が付与されるようにします。

persist: true の挙動についてはこちらの記事でご確認ください。

New Relicでの確認方法

実装後は、New Relic の NRQL(New Relic Query Language) を使用して、データが正しく紐付いているかと、それによって何が見えるようになったかを確認します。Mobile イベント側では sessionId ですが、Browser イベント側では（カスタム属性名によりますが） mobileSessionId を検索キーにする必要があります。

Browserに属性が入っているか確認

まず、Web側（PageView）にモバイルのIDがどの程度付与されているかを確認します。これにより、Bridgeの実装が正しく機能しているかを定量的に把握できます。

FROM PageView
SELECT percentage(count(*), WHERE mobileSessionId IS NOT NULL) AS linkedRate
WHERE deviceType = 'Mobile'
SINCE 1 hour ago

1セッションの横断タイムライン

特定のユーザーやセッションで問題が発生した際、MobileとBrowserのイベントを一本の時系列に結合して調査します。

NRQL

FROM Mobile, BrowserInteraction, AjaxRequest, JavaScriptError
SELECT
  timestamp, 
  eventType(),
  -- イベントごとに最適な表示項目を選択
  if(eventType() = 'Mobile', name,
    if(eventType() = 'BrowserInteraction', browserInteractionName, 
      if(eventType() = 'AjaxRequest', groupedRequestUrl, 
        if(eventType() = 'JavaScriptError', errorMessage, 'Other Event')
      )
    )
  ) AS 'Summary',
  -- 補助情報の出力
  category, 
  httpResponseCode AS 'Status'
WHERE sessionId = 'REPLACE_SESSION_ID'
   OR mobileSessionId = 'REPLACE_SESSION_ID'
ORDER BY timestamp ASC
LIMIT 500
SINCE 24 hours ago

複数のEvent Typeを1つの NRQL の中で使用することにより Native と Web の動作を1つのタイムラインで確認することができるようになります。

注意事項

本実装を進めるにあたり、以下の点にご注意ください。

• デバイスUUID について:
  UIDevice.current.identifierForVendor をカスタム属性として送信する場合、自社のセキュリティポリシーやプライバシーポリシーに照らし合わせ、ハッシュ化やマスキングが必要ないか必ず確認してください。

• PII（個人を特定できる情報）の取り扱い:
  New Relic へのデータ送信において、メールアドレスや氏名などの PII を含めないよう、各エージェントの設定やデータクレンジングの運用ルールを遵守してください。

まとめ

ハイブリッドアプリにおけるオブザーバビリティの鍵は、「NativeとWebの境界をデータでいかに埋めるか」 にあります。

今回の実装によって得られる最大のメリットは、単にセッションIDが共通化されることではありません。これまで「点」として独立していた各エージェントの監視データが、mobileSessionId という共通キーによって一本の「線」として繋がったことにあります。

New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！

New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！