フロントエンド可視化スキル

Real User Monitoring (RUM) を使用して DQL クエリで Web およびモバイル フロントエンドを監視します。 このスキルは新しい RUM エクスペリエンスのみを対象としています。クラシック RUM データは使用しないでください。

概要

このスキルは以下を実現します:

• Core Web Vitals とフロントエンド パフォーマンスの監視
• ユーザー セッション、エンゲージメント、動作の追跡
• エラーの分析とバックエンド トレースとの相関
• モバイル アプリの起動と安定性の最適化
• 詳細なタイミング分析を使用したパフォーマンス問題の診断

データ ソース:

• メトリクス: timeseries と dt.frontend.* (トレンド、アラート)
• イベント: fetch user.events (個別ページ ビュー、リクエスト、クリック、エラー)
• セッション: fetch user.sessions (セッション レベルの集計: 期間、バウンス、カウント)

クイック リファレンス

一般的なメトリクス

• dt.frontend.user_action.count - ユーザー アクション ボリューム
• dt.frontend.user_action.duration - ユーザー アクション期間
• dt.frontend.request.count - リクエスト ボリューム
• dt.frontend.request.duration - リクエスト レイテンシ (ms)
• dt.frontend.error.count - エラー カウント
• dt.frontend.session.active.estimated_count - アクティブ セッション
• dt.frontend.user.active.estimated_count - ユニーク ユーザー
• dt.frontend.web.page.cumulative_layout_shift - CLS メトリクス
• dt.frontend.web.navigation.dom_interactive - DOM インタラクティブ時間
• dt.frontend.web.page.first_input_delay - FID メトリクス (レガシー; INP を推奨)
• dt.frontend.web.page.largest_contentful_paint - LCP メトリクス
• dt.frontend.web.page.interaction_to_next_paint - INP メトリクス
• dt.frontend.web.navigation.load_event_end - ロード イベント終了
• dt.frontend.web.navigation.time_to_first_byte - 最初のバイトまでの時間

一般的なフィルタ

• frontend.name - フロントエンド名でフィルタ (例: my-frontend)
• dt.rum.user_type - シンセティック監視を除外
• geo.country.iso_code - 地理的フィルタリング
• device.type - モバイル、デスクトップ、タブレット
• browser.name - ブラウザ フィルタリング

一般的なタイムシリーズ ディメンション

dt.frontend.* タイムシリーズの分割とブレークダウンに使用:

• frontend.name - フロントエンド名
• geo.country.iso_code
• device.type
• browser.name
• os.name
• user_type - real_user, synthetic, robot

fetch user.events, from: now() - 2h
| filter characteristics.has_page_summary == true
| summarize page_views = count(), by: {frontend.name}
| sort page_views desc

イベント特性

• characteristics.has_page_summary - ページ ビュー (Web)
• characteristics.has_view_summary - ビュー (モバイル)
• characteristics.has_navigation - ナビゲーション イベント
• characteristics.has_user_interaction - クリック、フォーム等
• characteristics.has_request - ネットワーク リクエスト イベント
• characteristics.has_error - エラー イベント
• characteristics.has_crash - モバイル クラッシュ
• characteristics.has_long_task - 長時間 JavaScript タスク
• characteristics.has_csp_violation - CSP 違反

完全なイベント モデル: https://docs.dynatrace.com/docs/semantic-dictionary/model/rum/user-events

セッション データ (user.sessions)

user.sessions には、user.events からセッション集計サービスによって生成されたセッション レベルの集計が含まれます。フィールド名が user.events と異なります — セッションはイベントがドットを使用する場合にアンダースコアを使用します。

セッション ID とコンテキスト:

• dt.rum.session.id — セッション ID (NOT dt.rum.session_id)
• dt.rum.instance.id — インスタンス ID
• frontend.name - セッションに関連するフロントエンドの配列
• dt.rum.application.type — web または mobile
• dt.rum.user_type — real_user, synthetic, または robot

セッション集計 (アンダースコア命名 — ドット NOT):

フィールド	説明	⚠️ NOT this
navigation_count	ナビゲーション数	navigation.count
user_interaction_count	クリック、フォーム送信	user_interaction.count
user_action_count	ユーザー アクション	user_action.count
request_count	XHR/fetch リクエスト	request.count
event_count	セッション内の総イベント	event.count
page_summary_count	ページ ビュー (Web)	page_summary.count
view_summary_count	ビュー (モバイル/SPA)	view_summary.count

エラー フィールド (ドット命名 — イベントと同じ):

• error.count, error.exception_count, error.http_4xx_count, error.http_5xx_count
• error.anr_count, error.csp_violation_count, error.has_crash

セッション ライフサイクル:

• start_time, end_time, duration (ナノ秒)
• end_reason — timeout, synthetic_execution_finished 等
• characteristics.is_bounce — ブール値バウンス フラグ
• characteristics.has_replay — セッション リプレイ利用可能

ユーザー ID:

• dt.rum.user_tag — ユーザー識別子 (通常はメール、ユーザー名または customerId)、計測されたフロントエンドで dtrum.identifyUser() API 呼び出しを介して設定。常に設定されるわけではありません — フロントエンドが明示的に identifyUser() を呼び出す場合にのみ存在します。
• dt.rum.user_tag が空の場合、dt.rum.instance.id が唯一のユーザー識別子になることがあります。この値はクライアント側で RUM エージェントによって割り当てられたランダム ID なので、個人識別情報ではありませんが、user_tag が設定されていない場合にユニーク ユーザーを区別するために使用できます。Web 上ではこれは永続的な cookie に基づいているため、ユーザーによって削除できます。
• ユーザー タグは セッション レベル フィールド — user.sessions からクエリします。user.events からはクエリしないでください (セッションに 1 つある場合でも空の場合があります)。

クライアント/デバイス コンテキスト:

• browser.name, browser.version, device.type, os.name
• geo.country.iso_code, client.ip, client.isp

シンセティック専用フィールド:

• dt.entity.synthetic_test, dt.entity.synthetic_location, dt.entity.synthetic_test_step

時間ウィンドウ動作:

• fetch user.sessions, from: X, to: Y は [X, Y] で開始したセッションのみを返します — そのウィンドウ中にアクティブだったセッションではありません。
• セッションは 8 時間以上続くことができます (集計サービスはセッションを閉じるまで 30 分以上の非アクティビティを待ちます)。
• 時間ウィンドウ中にアクティブなすべてのセッションを見つけるには、ルックバックを少なくとも 8 時間延長します: 例えば、過去 24 時間のイベントをカバーするには、fetch user.sessions, from: now() - 32h をクエリします。
• これは相関クエリ (例: セッション ID で user.events を user.sessions にマッチング) に重要です — 狭い user.sessions ウィンドウは長時間実行セッションを見落とし、偽の「孤立」を生成します。

セッション作成遅延:

• セッション集計サービスは、セッションを閉じて user.sessions レコードを書き込むまで、約 30 分以上の非アクティビティを待ちます。
• つまり、最近のイベント (過去約 1 時間) にはまだ対応する user.sessions エントリがありません — これは通常であり、データ ギャップではありません。
• user.events を user.sessions と相関させる場合、進行中のセッションを孤立としてカウントしないように最近のデータを除外します (例: to: now() - 1h を使用)。

ゾンビ セッション (user.sessions レコードのないイベント):

• すべての user.events 内の dt.rum.session.id が対応する user.sessions レコードを持つわけではありません。セッション集計サービスは意図的にゾンビ セッションをスキップします — 実ユーザー アクティビティがないセッション (ナビゲーション数がゼロ、ユーザー インタラクション数がゼロ)。
• ゾンビ セッションには、ページ ビューやクリックのない、バックグラウンド、マシン駆動のアクティビティのみが含まれます (例: 自動 XHR リクエスト、ハートビート)。シリアライズしても、ユーザーに価値は追加されません。
• user.events を user.sessions と相関させる場合、多数のマッチされていないセッション ID を期待します。これは設計によるもので、データ ギャップではありません。孤立を診断する前にアクティビティを持つセッションにフィルタします:

  fetch user.events, from: now() - 2h, to: now() - 1h
  | filter isNotNull(dt.rum.session.id)
  | summarize navs = countIf(characteristics.has_navigation == true),
      interactions = countIf(characteristics.has_user_interaction == true),
      by: {dt.rum.session.id}
  | filter navs > 0 or interactions > 0
  

例 — バウンス率とセッション品質:

fetch user.sessions, from: now() - 24h
| filter dt.rum.user_type == "real_user"
| summarize
    total_sessions = count(),
    bounces = countIf(characteristics.is_bounce == true),
    zero_activity = countIf(toLong(navigation_count) == 0 and toLong(user_interaction_count) == 0),
    avg_duration_s = avg(toLong(duration)) / 1000000000
| fieldsAdd bounce_rate_pct = round((bounces * 100.0) / total_sessions, decimals: 1)

パフォーマンス しきい値

• LCP: 良好 <2.5s | 不良 >4.0s
• INP: 良好 <200ms | 不良 >500ms
• CLS: 良好 <0.1 | 不良 >0.25
• コールド スタート: 良好 <3s | 不良 >5s
• 長時間タスク: >50ms 問題あり、>250ms 深刻

コア ワークフロー

1. Web パフォーマンス監視

Core Web Vitals、ページ パフォーマンス、リクエスト レイテンシを追跡し、SEO と UX 最適化を実現します。

主要ファイル:

• references/WebVitals.md - Core Web Vitals (LCP、INP、CLS)
• references/performance-analysis.md - リクエストとページ パフォーマンス

一般的なクエリ:

• すべての Core Web Vitals サマリー
• ページ/デバイス別 Web Vitals
• リクエスト期間 SLA 監視
• ページ読み込みパフォーマンス トレンド

2. ユーザー セッション & 動作分析

ユーザー エンゲージメント、ナビゲーション パターン、セッション特性を理解します。ボタン クリック、フォーム インタラクション、ユーザー ジャーニーを分析します。

データ ソース選択:

• セッション レベルの分析に fetch user.sessions を使用 (バウンス率、セッション期間、セッション カウント)
• イベント レベルの詳細に fetch user.events を使用 (個別クリック、ナビゲーション タイミング、特定ページ)

主要ファイル:

• references/user-sessions.md - セッション追跡とユーザー分析
• references/performance-analysis.md - ナビゲーションとエンゲージメント パターン

一般的なクエリ:

• フロントエンド別アクティブ セッション
• カスタム プロパティ別セッション
• バウンス率分析 (user.sessions と characteristics.is_bounce を使用)
• セッション品質 (ゼロ アクティビティ セッション、navigation_count、user_interaction_count 経由)
• UI 要素のクリック分析 (user.events と characteristics.has_user_interaction を使用)
• 外部リファラー (トラフィック ソース)

3. エラー追跡とデバッグ

エラー率を監視し、例外を分析し、フロントエンド問題とバックエンドを相関させます。

主要ファイル:

• references/error-tracking.md - エラー分析とデバッグ
• references/performance-analysis.md - トレース相関

一般的なクエリ:

• エラー率監視
• タイプ別 JavaScript 例外
• バックエンド トレース付きの失敗したリクエスト
• リクエスト タイミング ブレークダウン

4. モバイル フロントエンド監視

iOS と Android のモバイル アプリ パフォーマンス、起動時間、クラッシュ分析を追跡します。アプリ バージョン パフォーマンスとデバイス固有の問題を分析します。

主要ファイル:

• references/mobile-monitoring.md - アプリ起動、クラッシュ、モバイル固有メトリクス

一般的なクエリ:

• アプリ バージョン別コールド スタート パフォーマンス (iOS、Android)
• ウォーム スタートとホット スタート メトリクス
• デバイス モデルと OS バージョン別クラッシュ率
• ANR イベント (Android)
• ネイティブ クラッシュ シグナル
• アプリ バージョン比較

5. 高度なパフォーマンス最適化

JavaScript プロファイリング、メイン スレッド ブロッキング、UI ジャンク分析、地理的パフォーマンスを含む深いパフォーマンス診断。

主要ファイル:

• references/performance-analysis.md - 高度な診断と長時間タスク

一般的なクエリ:

• メイン スレッドをブロックする長時間 JavaScript タスク
• UI ジャンクとレンダリング遅延
• 応答性に影響する >50ms タスク
• サードパーティ長時間タスク (iframe)
• シングルページ アプリ パフォーマンス問題
• 地理的パフォーマンス分布
• パフォーマンス低下検出

ベスト プラクティス

1. トレンドにはメトリクス、デバッグにはイベントを使用

   • メトリクス: タイムシリーズ ダッシュボード、アラート、キャパシティ プランニング
   • イベント: 根本原因分析、詳細診断

2. マルチアプリ環境でフロントエンドでフィルタ

   • 明確にするため常に frontend.name を使用

3. 間隔を時間範囲に合わせる

   • 数時間は 5m 間隔、数日は 1h、数週間は 1d

4. 実ユーザー分析時にシンセティック トラフィックを除外

   • dt.rum.user_type をフィルタして本物の動作に焦点を当てる

5. メトリクスとイベントを組み合わせて完全な洞察を得る

   • メトリクス トレンドから開始し、詳細についてはイベントに詳細化

6. 相関クエリの user.sessions 時間ウィンドウを拡張

   • user.sessions はクエリ ウィンドウで開始したセッションのみを返す
   • セッションは 8 時間以上続くことができるため、user.events と結合する場合は、ルックバックを少なくとも 8h 延長

ページ読み込み遅延プレイブック

ページ、ブラウザ、地理的位置、dt.rum.user_type で問題をセグメント化して開始します。

ヒューリスティクス:

• 高 TTFB -> 遅いバックエンド
• 高 LCP（通常 TTFB） -> レンダリング ボトルネック
• 高 CLS -> レイアウト シフト (遅延読み込みコンテンツ、広告、フォント)
• 長時間タスクが支配的 -> JavaScript 実行ボトルネック (重いフレームワーク、大きなバンドル)

バックエンド レイテンシ (高 TTFB)

fetch user.events
| filter frontend.name == "my-frontend" and characteristics.has_request == true
| filter page.url.path == "/checkout"
| summarize avg_ttfb = avg(request.time_to_first_byte), avg_duration = avg(duration)

TTFB が高い場合、dt.rum.trace_id を使用してフロントエンド イベントとバックエンド トレースを相関させることで、バックエンド スパンを分析します。

重い JavaScript 実行 (長時間タスク)

ページ別長時間タスク:

fetch user.events, from: now() - 2h
| filter characteristics.has_long_task == true
| summarize
   long_task_count = count(),
   total_blocking_time = sum(duration),
   by: {frontend.name, page.url.path}
| sort total_blocking_time desc
| limit 20

スクリプト ソース別長時間タスク:

fetch user.events, from: now() - 2h
| filter frontend.name == "my-frontend"
| filter characteristics.has_long_task == true
| summarize
   long_task_count = count(),
   total_blocking_time = sum(duration),
   by: {long_task.attribution.container_src}
| sort total_blocking_time desc
| limit 20

大きい JavaScript バンドル

fetch user.events
| filter frontend.name == "my-frontend"
| filter characteristics.has_request
| filter endsWith(url.full, ".js")
| summarize dls = max(performance.decoded_body_size), by: url.full
| sort dls desc
| limit 20

大きいリソース

fetch user.events
| filter frontend.name == "my-frontend"
| filter characteristics.has_request
| summarize dls = max(performance.decoded_body_size), by: url.full
| sort dls desc
| limit 20

キャッシュ効果

fetch user.events, from: now() - 2h
| filter frontend.name == "my-frontend"
| filter characteristics.has_request == true
| fieldsAdd cache_status = if(
   performance.incomplete_reason == "local_cache" or performance.transfer_size == 0 and
   (performance.encoded_body_size > 0 or performance.decoded_body_size > 0),
   "cached",
   else: if(performance.transfer_size > 0, "network", else: "uncached")
  )
| summarize
   request_count = count(),
   avg_duration = avg(duration),
   by: {url.domain, cache_status}

圧縮 無駄

fetch user.events, from: now() - 2h
| filter characteristics.has_request == true
| filter isNotNull(performance.encoded_body_size) and isNotNull(performance.decoded_body_size)
| filter performance.encoded_body_size > 0
| fieldsAdd
   expansion_ratio = performance.decoded_body_size / performance.encoded_body_size,
   wasted_bytes = performance.decoded_body_size - performance.encoded_body_size
| summarize
   requests = count(),
   avg_expansion_ratio = avg(expansion_ratio),
   total_wasted_bytes = sum(wasted_bytes),
   by: {request.url.host, request.url.path}
| sort total_wasted_bytes desc
| limit 50

ネットワーク問題

TTFB が高いがバックエンド パフォーマンスが良好な場合、位置とドメイン別に比較:

fetch user.events, from: now() - 2h
| filter characteristics.has_request == true
| summarize
   request_count = count(),
   avg_duration = avg(duration),
   p75_duration = percentile(duration, 75),
   p95_duration = percentile(duration, 95),
   by: {geo.country.iso_code, request.url.domain}
| sort p95_duration desc
| limit 50

DNS 時間を分析:

fetch user.events, from: now() - 2h
| filter characteristics.has_request == true
| filter isNotNull(performance.domain_lookup_start) and isNotNull(performance.domain_lookup_end)
| fieldsAdd dns_ms = performance.domain_lookup_end - performance.domain_lookup_start
| summarize
   request_count = count(),
   avg_dns_ms = avg(dns_ms),
   p75_dns_ms = percentile(dns_ms, 75),
   p95_dns_ms = percentile(dns_ms, 95),
   by: {request.url.domain}
| sort p95_dns_ms desc
| limit 50

プロトコル (http/1.1、h2、h3) 別に分析:

fetch user.events
| filter characteristics.has_request
| summarize cnt = count(), by: {url.domain, performance.next_hop_protocol}
| sort cnt desc
| limit 50

サードパーティ依存関係

ドメイン別リクエスト パフォーマンスを分析:

fetch user.events, from: now() - 2h
| filter characteristics.has_request == true
| summarize
   request_count = count(),
   avg_duration = avg(duration),
   p75_duration = percentile(duration, 75),
   p95_duration = percentile(duration, 95),
   by: {request.url.domain}
| sort p95_duration desc
| limit 50

トラブルシューティング

ゼロ結果の処理

クエリがデータを返さない場合、この診断ワークフローに従います:

1. 時間枠を検証

   • 時間枠がデータ タイプに適しているか確認
   • RUM データに遅延がある場合があります (最近のイベントで 1-2 分)
   • 時間枠の構文を確認: now()-1h to now() または同様
   • 時間枠を拡張してみます: 初期探索には now()-24h

2. フロントエンド構成を確認

   • フロントエンドが計測され、RUM データを送信していることを確認
   • frontend.name フィルタが正しいか確認
   • フロントエンド フィルタなしでクエリしてみて、RUM データが存在するか確認
   • フロントエンド名が環境と一致することを確認

3. データ可用性を確認

   • 基本クエリを実行: fetch user.events | limit 1
   • イベントが存在しない場合、RUM が構成されていない可能性があります
   • 時間枠がフロントエンド展開前のものでないか確認
   • ユーザーが環境にアクセスできることを確認

4. クエリ構文を確認

   • フィルタが制限的すぎないか検証
   • フィールド名またはメトリクス名のタイプミスがないか確認
   • クエリを段階的にテスト: 単純に開始し、フィルタを段階的に追加
   • 特性フィルタがイベント タイプと一致するか確認

ユーザーに説明を求める場合:

• 環境にRUMデータが存在しない → "このフロントエンドに対して RUM は構成されていますか?"
• 時間枠が不明 → "どの期間を分析する必要がありますか?"
• 予期されるデータがない → "このフロントエンドは最近データを送信していますか?"

異常な結果の処理

クエリ結果が予期しない、または疑わしいように見える場合:

予期しない高い値:

• メトリクス スパイク: 間隔集計 (avg vs. max vs. sum) を確認
• セッション カウント: ボット トラフィックまたはシンセティック監視をチェック
• エラー率: エラー定義が予期と一致することを確認
• パフォーマンス低下: デプロイメントまたはインフラストラクチャの変更を確認

予期しない低い値:

• 欠けているセッション: dt.rum.user_type フィルタが実ユーザーを除外していないか確認
• 低リクエスト カウント: フロントエンド フィルタが狭すぎないか確認
• 少ないエラー: エラー特性フィルタが正しいか確認
• モバイル データなし: プラットフォーム固有のフィールドが存在するか確認

一貫性のないデータ:

• メトリクス vs. イベント 不一致: 異なる集計方法が予期されます
• 地理的異常: タイムゾーン仮定を確認
• デバイス分布の歪み: 実際のユーザー ベースを反映する可能性があります
• バージョン不一致: アプリ バージョン フィルタリング ロジックを確認

判定ツリー: 質問 対 調査

クエリが予期しない結果を返す
│
├─ これはゼロ結果シナリオですか?
│  ├─ はい → 「ゼロ結果の処理」ワークフローに従う
│  └─ いいえ → 続行
│
├─ 結果を独立して検証できますか?
│  ├─ はい → 検証クエリを実行
│  │        ├─ 検証が結果を確認 → 結果を報告
│  │        └─ 検証が矛盾 → さらに調査
│  └─ いいえ → 続行
│
├─ 異常がデータによって明確に説明できますか?
│  ├─ はい → 説明付きで報告
│  └─ いいえ → 続行
│
├─ 解釈に領域知識が必要ですか?
│  ├─ はい → ユーザーに内容を尋ねる
│  │        例: 「エラー率は 15% です。これはフロントエンドで予期されていますか?」
│  └─ いいえ → 続行
│
└─ 問題が曖昧であるか、明確化が必要ですか?
   ├─ はい → データ コンテキスト付き特定の質問を尋ねる
   │        例: 「'web-app' という名前のフロントエンドが 2 つ見つかりました。どのフロントエンド名を使用する必要がありますか?」
   └─ いいえ → 注意事項付きで調査と報告の結果を報告

一般的な調査ステップ

パフォーマンス問題の場合:

1. ベースラインと比較: 前週の同じメトリクスをクエリ
2. ディメンション別にセグメント化: デバイス、ブラウザ、地理別に分解
3. 外れ値をチェック: 平均値対パーセンタイル (p50、p95、p99) を使用
4. デプロイメントと相関: アプリ バージョンまたは時間ウィンドウ別にフィルタ

データ可用性問題の場合:

1. 広く始める: フィルタなしで all RUM データをクエリ
2. フィルタを段階的に追加: どのフィルタがデータを削除するか分離
3. 関連メトリクスを確認: イベントがない場合、タイムシリーズを試す
4. エンティティ関係を検証: フロントエンドからサービス リンクを確認

予期しないパターンの場合:

1. 時間枠を拡張: 履歴コンテキストを探す
2. データ ソースを相互参照: イベントとメトリクスを比較
3. サンプリングを確認: サンプリングが結果に影響していないか確認
4. 外部要因を考慮: 休日、停止、トラフィック変化

赤旗: 停止して質問する場合

常にユーザーに質問:

• ❌ 環境のどこにも RUM データが存在しない
• ❌ 複数のフロントエンドがユーザーの説明と一致する
• ❌ 結果がユーザーの明確な期待と矛盾する
• ❌ データが監視の誤構成を示唆している
• ❌ クエリに業務コンテキストが必要 (例: 「許容可能なエラー率」)
• ❌ 時間枠が曖昧で、解釈に影響を与える

説明クエリの例:

• "I found two frontends named 'checkout'. Which one: checkout-web or checkout-mobile?" (「'checkout' という名前のフロントエンドが 2 つ見つかりました。どちらですか: checkout-web または checkout-mobile?」)
• "The query returns 0 results for the past hour. Should I expand the timeframe, or do you expect real-time data?" (「クエリは過去 1 時間の 0 件の結果を返しています。時間枠を拡張する必要がありますか、またはリアルタイム データを期待していますか?」)
• "The average LCP is 8 seconds, which exceeds the 4-second threshold. Is this frontend known to have performance issues?" (「平均 LCP は 8 秒で、4 秒のしきい値を超えています。このフロントエンドはパフォーマンス問題で知られていますか?」)
• "I see only synthetic traffic. Should I include dt.rum.user_type='REAL_USER' to focus on real users?" (「シンセティック トラフィックのみが表示されます。実ユーザーに焦点を当てるために dt.rum.user_type='REAL_USER' を含める必要がありますか?」)

このスキルを使用する場合

フロントエンド可視化スキルを使用:

• Web またはモバイル フロントエンド パフォーマンスの監視
• SEO のための Core Web Vitals の分析
• ユーザー セッション、エンゲージメント、または動作の追跡
• クリック イベントとボタン インタラクションの分析
• フロントエンド エラーまたは遅いリクエストのデバッグ
• フロントエンド問題とバックエンド トレースの相関
• モバイル アプリの起動またはクラッシュ率の最適化 (iOS、Android)
• アプリ バージョン パフォーマンスの分析
• UI ジャンクおよびメイン スレッド ブロッキングの診断
• セキュリティ コンプライアンスの分析 (CSP 違反)
• JavaScript パフォーマンスのプロファイリング (長時間タスク)

使用しないでください:

• バックエンド サービス監視 (サービス スキルを使用)
• インフラストラクチャ メトリクス (インフラストラクチャ スキルを使用)
• ログ分析 (ログ スキルを使用)
• ビジネス プロセス監視 (ビジネス イベント スキルを使用)

段階的な開示

常に利用可能

• FrontendBasics.md - RUM 基礎とクイック リファレンス

ワークフローで読み込み

• Web パフォーマンス: WebVitals.md、performance-analysis.md
• ユーザー動作: user-sessions.md、performance-analysis.md
• エラー分析: error-tracking.md、performance-analysis.md
• モバイル アプリ: mobile-monitoring.md

明示的リクエストで読み込み

• 高度な診断 (長時間タスク、ユーザー アクション)
• セキュリティ コンプライアンス (CSP 違反、可視化追跡)
• 特殊なモバイル機能 (プラットフォーム固有フェーズ)

リファレンス ファイル

コア リファレンス ドキュメント

• references/WebVitals.md - Core Web Vitals 監視
• references/user-sessions.md - セッションとユーザー分析
• references/error-tracking.md - エラー分析とデバッグ
• references/mobile-monitoring.md - モバイル アプリ パフォーマンスとクラッシュ
• references/performance-analysis.md - 高度なパフォーマンス診断