Azure MonitorでWebアプリの利用状況やブラウザー上のエラーを見たい場合、まず確認すべきなのはApplication Insights JavaScript SDKの設定方法です。2026年5月時点の公式情報では、ブラウザー側のReal User Monitoring、つまりRUMはOpenTelemetryへ置き換えるのではなく、Application Insights JavaScript SDKを使う方針が明確に示されています。ページビューは既定で収集されますが、クリック操作、SPAのルート変更、Cookie、接続文字列、CORS相関ヘッダー、テレメトリ量の制御は、導入前に必ず確認しておきたいポイントです。(Microsoft Learn)
この記事では、Azure Monitorの「Application Insights JavaScript SDK Setup in Azure Monitor」について、何が重要なのか、誰に影響するのか、管理者・開発者がどの設定を見直すべきかを実務目線で整理します。
Azure MonitorのApplication Insights JavaScript SDK Setupとは
Azure MonitorのApplication Insights JavaScript SDK Setupは、JavaScriptで動くWebアプリケーションにブラウザー側の監視を組み込むための公式手順です。
対象になるのは、たとえば次のようなアプリケーションです。
- 静的HTMLや通常のWebサイト
- React、AngularなどのSPA
- フロントエンドとAPIサーバーを分離したWebアプリ
- ユーザー操作やページ表示速度をAzure Monitorで追跡したいサービス
- JavaScriptエラーやAjax/Fetchの失敗を運用監視に含めたいシステム
Application Insights JavaScript SDKを導入すると、ブラウザーで発生したページビュー、依存関係呼び出し、例外、カスタムイベントなどをApplication Insightsへ送信できます。これにより、サーバー側のログだけでは見えない「実際のユーザー環境で何が起きているか」を確認できます。(Microsoft Learn)
たとえば、サーバーのCPU使用率やAPIの応答時間が正常でも、ユーザーのブラウザーでは次のような問題が起きていることがあります。
- 特定のブラウザーだけJavaScriptエラーが発生している
- CDNや外部APIの読み込み失敗で画面が崩れている
- SPAの画面遷移は成功しているが、ページビューとして記録されていない
- 会員登録ボタンのクリック率が急に下がっている
- 一部地域のユーザーだけフロントエンドの読み込みが遅い
こうした問題を検知するために使うのが、Application Insights JavaScript SDKによるブラウザーRUMです。
今回押さえるべき変更点・重要ポイント
今回の公式情報で特に重要なのは、「新機能が一つ追加された」というより、ブラウザー監視の推奨ルートと運用上の注意点が整理されていることです。
特に影響が大きいポイントは次の4つです。
| 確認ポイント | 内容 | 影響を受ける人 |
|---|---|---|
| ブラウザー監視はApplication Insights JavaScript SDKを使う | ブラウザー側のJavaScript監視はOpenTelemetryへ移行する前提ではない | 開発者、アーキテクト |
| 導入方法はLoader Scriptまたはnpm | 多くのケースではJavaScript Web SDK Loader Script、細かい制御やフレームワーク拡張ではnpmを使う | フロントエンド開発者 |
| 接続文字列の扱いに注意 | 接続文字列はブラウザー上で見える。シークレットではないが、認証・分離設計は必要 | Azure管理者、セキュリティ担当 |
| クリックやSPAの画面遷移は追加設定が必要な場合がある | ページビューは既定で収集されるが、クリック分析やルート変更は要件に応じて設定する | 開発者、運用担当 |
ここで誤解しやすいのは、Azure MonitorやApplication InsightsでOpenTelemetryの利用が進んでいるため、「ブラウザー側もOpenTelemetryへ移行しなければならない」と考えてしまう点です。
公式情報では、Application Insights JavaScript SDKはApplication Insightsでサポートされるクライアント側ブラウザーインストルメンテーションのパスであり、ブラウザーJavaScript監視をOpenTelemetryへ移行することは想定されていません。Node.jsなどのサーバー側コードではOpenTelemetryのガイダンスを使い、ブラウザー側はApplication Insights JavaScript SDKを使う、という切り分けで考えるのが安全です。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
Application Insights JavaScript SDKの設定は、単にフロントエンドにスクリプトを貼るだけの作業ではありません。Azure管理、セキュリティ、開発、運用監視のすべてに関係します。
Azure管理者が確認すべきこと
Azure管理者は、まずApplication Insightsリソースと接続文字列の管理方針を確認します。
接続文字列は、テレメトリを送信するApplication Insightsリソースを指定するための情報です。公式情報では、接続文字列に含まれるInstrumentation Keyはセキュリティトークンやシークレットではないと説明されています。一方で、ブラウザーに埋め込む以上、誰でも文字列を確認できる点は前提にする必要があります。(Microsoft Learn)
確認すべき観点は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| 本番・検証・開発のリソース分離 | 本番データと開発テストのイベントが混ざらないよう、Application Insightsリソースを分ける |
| 接続文字列の配布方法 | ビルド時の環境変数や構成管理で差し替え、誤って本番接続文字列を検証環境に使わない |
| ローカル認証の扱い | 組織でMicrosoft Entra IDベースの認証を強制する場合、ブラウザーテレメトリの送信方式を別途設計する |
| 取り込み量とコスト | ページビュー、Ajax、クリックイベントの量を見積もり、必要に応じてサンプリングを検討する |
| ネットワーク制御 | CSP、プロキシ、ファイアウォール、CDN許可リストを確認する |
特に、組織でApplication Insightsのローカル認証を無効化し、Microsoft Entra IDによる認証を強制している場合は注意が必要です。公式情報では、JavaScript SDKがブラウザーベースのテレメトリに対して直接認証できず、テレメトリの流れが止まる可能性があると説明されています。その場合の実用的なパターンとして、Azure API Managementを経由してブラウザーテレメトリをルーティングする構成が示されています。(Microsoft Learn)
開発者が確認すべきこと
開発者が最初に決めるべきなのは、SDKの導入方法です。
公式情報では、Application Insights JavaScript SDKを追加する方法として、JavaScript Web SDK Loader Scriptとnpmパッケージの2種類が示されています。多くの利用者にはLoader Scriptが推奨され、カスタムイベントや細かな構成、React・React Native・Angularのフレームワーク拡張を使う場合はnpmパッケージが必要になります。(Microsoft Learn)
| 導入方法 | 向いているケース | 注意点 |
|---|---|---|
| JavaScript Web SDK Loader Script | 通常のWebサイト、すばやくRUMを有効化したい場合、対象ページを個別に制御したい場合 | 公式スニペットを最新状態で使う。CSPやCDNの読み込み許可を確認する |
| npmパッケージ | React、Angular、ビルド環境のあるSPA、カスタムイベントや詳細設定を多用する場合 | パッケージ更新、バンドルサイズ、フレームワーク拡張との互換性を管理する |
シンプルなWebサイトならLoader Scriptで十分なことが多いです。一方、React Routerの画面遷移、Angularの例外ハンドリング、Click Analyticsプラグイン、テレメトリ初期化子を体系的に管理したい場合は、npmで組み込んだ方が保守しやすくなります。
運用担当者が確認すべきこと
運用担当者は、SDK導入後に「データが流れているか」「どのイベントを監視対象にするか」を確認します。
公式手順では、Application InsightsリソースのSearchペインでイベント種類を選び、Page ViewやClick AnalyticsプラグインのCustom Eventを確認する流れが示されています。データがポータルに表示されるまで数分かかる場合があり、読み込みエラーの例外しか表示されない場合はSDKロード失敗のトラブルシューティングを確認する必要があります。(Microsoft Learn)
運用では、次のようなKPIやアラートに落とし込むと実用的です。
| 監視したいこと | 見るべきデータの例 |
|---|---|
| ページが表示されているか | pageViews |
| ブラウザーエラーが増えていないか | exceptions |
| API呼び出しが失敗していないか | dependencies |
| CTAボタンがクリックされているか | customEvents |
| 特定バージョンで障害が増えていないか | カスタムプロパティ、cloud role、リリースバージョン |
導入直後は、アラートを細かく作りすぎるよりも、まず主要画面のページビュー、JavaScript例外、主要APIの依存関係、重要クリックイベントの4つに絞ると運用しやすくなります。
OpenTelemetryへ移行する必要はあるのか
結論から言うと、ブラウザー側のJavaScript監視をOpenTelemetryへ移行する必要はありません。
Azure Monitorではサーバー側アプリケーションの可観測性でOpenTelemetryを利用する場面が増えています。しかし、ブラウザーで動くJavaScriptアプリケーションの監視については、Application Insights JavaScript SDKがサポートされるルートです。公式情報でも、サーバー側のOpenTelemetryインストルメンテーションはクライアント側のブラウザーテレメトリを置き換えないと説明されています。(Microsoft Learn)
実務では次のように分けると分かりやすいです。
| 対象 | 推奨される考え方 |
|---|---|
| ブラウザーで動くJavaScript | Application Insights JavaScript SDK |
| Node.jsなどのサーバー側コード | Azure Monitor OpenTelemetryのガイダンスを確認 |
| ASP.NET Coreなどのバックエンド | サーバー側の公式インストルメンテーションを別途設定 |
| フロントエンドとバックエンドの関連付け | 分散トレース、相関ヘッダー、接続文字列、Application Mapを確認 |
つまり、フルスタック監視をしたい場合は、フロントエンドにApplication Insights JavaScript SDKを入れ、バックエンドにはサーバー側の監視を別途入れます。片方だけでは、ユーザー体験からサーバー処理までを一気通貫で追跡しにくくなります。
導入方法の選び方
Application Insights JavaScript SDKの導入方法は、アプリケーションの構成で選ぶのが基本です。
通常のWebサイトならLoader Scriptを優先する
HTMLに直接スクリプトを追加できるWebサイトでは、JavaScript Web SDK Loader Scriptが使いやすい選択肢です。
公式手順では、Application Insightsを有効にしたい各ページの上部にLoader Scriptを貼り付け、可能であれば<head>内の最初のスクリプトとして追加することが推奨されています。早い段階で読み込むことで、依存関係の読み込み時に発生する問題も監視しやすくなります。(Microsoft Learn)
ただし、すべてのページへ無条件に入れるのが正解とは限りません。管理画面、ログイン画面、個人情報入力画面などでは、取得するテレメトリの内容やプライバシー要件を確認してから有効化します。
ReactやAngularならnpmパッケージを検討する
React、Angular、React Nativeなどのアプリでは、npmパッケージを使う方が自然です。
公式情報では、Reactプラグインでルーター履歴の追跡、例外追跡、コンポーネント使用状況の追跡、React Contextでの利用が可能になると説明されています。Angularプラグインではルーター履歴や例外追跡などがサポートされます。(Microsoft Learn)
基本形は次のような構成です。
import { ApplicationInsights } from '@microsoft/applicationinsights-web';
const appInsights = new ApplicationInsights({
config: {
connectionString: 'YOUR_CONNECTION_STRING'
}
});
appInsights.loadAppInsights();
appInsights.trackPageView();実務では、接続文字列をコードに直書きするのではなく、ビルド環境ごとの設定から差し込む形にします。
たとえば、ViteやNext.jsなどのフロントエンド環境では、公開される環境変数であることを理解したうえで、本番・検証・開発の接続先を分けます。接続文字列はシークレットではありませんが、誤ったリソースへ大量のテレメトリを送ると、分析精度やコストに影響します。
接続文字列で失敗しやすいポイント
Application Insights JavaScript SDKの設定で最もよくある失敗は、接続文字列まわりです。
公式手順では、Application InsightsリソースのOverviewペインからConnection Stringをコピーし、JavaScriptコード内のYOUR_CONNECTION_STRINGを置き換える流れが示されています。また、connectionStringはInstrumentationKey=xxxx;...の形式に従う必要があり、形式が不正だとSDKの読み込みプロセスが失敗します。(Microsoft Learn)
よくあるミスは次のとおりです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| Instrumentation Keyだけを古い設定として使い続ける | 新しい構成やエンドポイント制御と合わない場合がある | 接続文字列ベースの設定へ移行する |
| 検証環境に本番の接続文字列を入れる | テストデータが本番Application Insightsに混入する | 環境ごとにリソースと接続文字列を分ける |
| 接続文字列を秘密情報として扱いすぎる | ブラウザーに露出する前提の設計ができない | 露出前提でリソース分離、取り込み制御、認証方針を設計する |
| Entra ID認証を強制しているのにブラウザー送信を考慮しない | テレメトリが送れない可能性がある | APIMプロキシなどの方式を検討する |
| CSPでSDKや送信先を許可していない | SDK読み込みやテレメトリ送信が失敗する | script-src、connect-srcなどを確認する |
特にセキュリティ部門との認識合わせでは、「接続文字列は見えてもよいのか」という論点が出やすいです。公式情報では接続文字列やInstrumentation Keyはシークレットではないと説明されていますが、だからといって無制限に使い回してよいわけではありません。リソースの分離、送信元の監視、異常な取り込み量の検知をセットで設計することが重要です。(Microsoft Learn)
ページビュー、クリック、SPAの画面遷移をどう扱うか
Application Insights JavaScript SDKでは、ページビューは既定で収集されます。一方、クリックイベントを既定で収集したい場合は、Click Analytics Auto-Collectionプラグインの追加を検討します。(Microsoft Learn)
ページビューだけで十分なケース
次のような場合は、まずページビューと例外の収集から始めるのが現実的です。
- コーポレートサイトやドキュメントサイト
- ページ単位でURLが変わる従来型Webアプリ
- まず表示速度やエラーを把握したい段階
- クリック分析の要件がまだ固まっていない段階
この場合、最初からクリックイベントを大量に収集するよりも、主要ページの表示数、JavaScript例外、API失敗を見える化する方が費用対効果は高くなります。
クリック分析が必要なケース
Click Analyticsプラグインは、Webページ上のクリックイベントを自動追跡し、HTML要素のdata-*属性やカスタムタグを使ってイベントテレメトリを設定できる拡張機能です。プラグインが有効な場合、クリック座標、ページ名、親要素ID、クリックまでの時間などのデータを扱えます。(Microsoft Learn)
クリック分析が役立つのは、次のような場面です。
- 購入ボタン、問い合わせボタン、資料請求ボタンのクリックを見たい
- UI変更後にユーザー行動が変わったか確認したい
- A/Bテストや導線改善の効果を測りたい
- HEARTワークブックなどを使ってユーザー体験を分析したい
ただし、クリックイベントは設計せずに収集すると、分析しにくいデータが大量に増えます。idやdata-*属性の命名を決め、重要なUI要素だけ意味のある名前で追跡できるようにしておくことが大切です。
SPAではルート変更の追跡を確認する
ReactやAngularなどのSPAでは、URLや画面表示が変わっても通常のページ読み込みが発生しないことがあります。そのため、ページビューが期待通りに記録されているかを必ず確認します。
設定ではenableAutoRouteTrackingなどのルート追跡関連項目が関係します。公式構成情報では、SPAのルート変更を自動的に追跡し、ルート変更ごとに新しいページビューをApplication Insightsへ送信する設定が説明されています。ただし、設定の組み合わせによって複数のページビューイベントが発生する可能性があるため、実装後は必ずSearchやLogsで件数を確認します。(Microsoft Learn)
CORS相関ヘッダーと分散トレースの注意点
フロントエンドからAPIを呼び出す構成では、ブラウザーのAjax/Fetchとサーバー側のリクエストを関連付けられると、障害調査が大幅に楽になります。
Application Insightsでは、分散トレースのためにoperation_Idなどのデータを使って、ページビュー、依存関係、サーバー要求を関連付けます。また、W3C Trace Contextに基づくtraceparentなどのヘッダーを使うことで、呼び出しのつながりを追跡できます。(Microsoft Learn)
ただし、CORSをまたぐリクエストで相関ヘッダーを有効にする場合は注意が必要です。公式情報では、enableCorsCorrelationをtrueにすると、すべてのXMLHttpRequest要求とFetch Ajax要求に相関ヘッダーが含まれると説明されています。その結果、呼び出し先サーバーがtraceparentヘッダーをサポートしていない場合、ブラウザーやサーバーの検証条件によってリクエストが失敗する可能性があります。(Microsoft Learn)
実務での確認ポイントは次のとおりです。
| 確認項目 | 注意点 |
|---|---|
| APIサーバーのCORS許可ヘッダー | traceparentなどのヘッダーを許可しているか |
| 外部認証サービスへのリクエスト | Auth0など外部ドメインへ相関ヘッダーを送る必要があるか |
correlationHeaderExcludedDomains | 相関ヘッダーを送らないドメインを明示できているか |
| サーバー側監視との連携 | バックエンド側でもトレースを受け取れる設定になっているか |
| 本番前テスト | ログイン、決済、外部API連携でリクエスト失敗が増えないか |
特に認証、決済、外部SaaS APIでは、不要なヘッダー追加がトラブルになることがあります。相関を強化する設定は便利ですが、全ドメインへ一律に適用するのではなく、対象APIを見極めて段階的に展開するのが安全です。
Cookie、ストレージ、個人情報の扱い
ブラウザーRUMでは、Cookieやストレージの扱いが重要です。ユーザーやセッションの識別に関係するため、プライバシーポリシー、社内規程、地域ごとの法令対応と合わせて確認します。
Application Insights JavaScript SDKでは、Cookie使用の無効化、Cookieドメインやパスの設定、インスタンスベースのCookie管理などが用意されています。公式情報では、バージョン2.6.0以降、初期化後に無効化・再有効化できるインスタンスベースのCookie管理が提供され、従来のグローバル関数を置き換える形になっていると説明されています。(Microsoft Learn)
実務では、次のような方針を決めておくと導入後の手戻りを減らせます。
| 項目 | 推奨される確認 |
|---|---|
| Cookie利用 | 同意管理ツールとの整合性を確認する |
| ユーザーID | 個人を直接特定できる値を送らない |
| カスタムイベント | メールアドレス、氏名、電話番号、住所などを含めない |
| URL | クエリ文字列に個人情報やトークンが含まれていないか確認する |
| リクエスト/レスポンスヘッダー | 認証情報やAPIキーが収集されないようにする |
| テレメトリ初期化子 | 不要な情報を送信前に除外・加工する |
構成情報では、リクエストヘッダーやレスポンスヘッダーの追跡、無視するヘッダー、テレメトリ初期化子、サンプリングなどの設定が用意されています。既定ではAuthorization、X-API-Key、WWW-Authenticateといったヘッダーが無視対象に含まれる説明がありますが、独自ヘッダーを使っている場合は別途確認が必要です。(Microsoft Learn)
個人情報対策では、「送ってからLog Analyticsで見ないようにする」では不十分です。ブラウザーから送信する前に、SDK設定やテレメトリ初期化子で不要な情報を落とす設計にします。
テレメトリ量とコストを制御する
Application Insights JavaScript SDKを入れると、ページビューだけでなく、Ajax/Fetch、例外、クリックイベントなどが増える可能性があります。アクセス数の多いサイトでは、想定以上にテレメトリ量が増えることがあります。
構成情報では、送信されるイベント割合を制御するsamplingPercentage、ページビューあたりのAjax呼び出し数を制御するmaxAjaxCallsPerView、Ajax/Fetchの自動追跡除外パターンなどが説明されています。(Microsoft Learn)
最初に決めるべきなのは、何を必ず残し、何を削減してよいかです。
| データ | 優先度 | 削減の考え方 |
|---|---|---|
| JavaScript例外 | 高 | 原則として残す。特定の既知エラーだけ除外を検討 |
| 主要ページのページビュー | 高 | サービス品質や利用状況の基礎データとして残す |
| 重要APIの依存関係 | 高 | 障害調査に必要。外部APIも含めて確認 |
| クリックイベント | 中 | 重要CTAや分析対象に絞る |
| 大量発生する静的リソース呼び出し | 低〜中 | 除外パターンや上限設定を検討 |
公式構成情報では、明示的にテレメトリをフィルター処理するとポータルの統計が歪む可能性があり、単にボリューム削減が目的ならサンプリングを優先する考え方が示されています。(Microsoft Learn)
つまり、障害調査に不要なイベントを落とす場合はフィルター、全体傾向を保ちながら量を減らす場合はサンプリング、という使い分けが基本です。
移行・見直しで確認すべきポイント
既にApplication Insights JavaScript SDKを使っている場合は、今回の情報をもとに次の点を見直します。
Instrumentation Key中心の古い設定を見直す
古い実装では、instrumentationKeyだけで初期化しているケースがあります。現在は接続文字列を使う構成を基本に考えるのが安全です。
接続文字列にはInstrumentation Keyに加え、エンドポイント指定などの構成を含められます。リージョンエンドポイントやカスタムエンドポイント、ソブリンクラウドなどを考慮する場合も、接続文字列を使う方が管理しやすくなります。(Microsoft Learn)
複数バージョンのSDKが同じページにないか確認する
公式手順では、同じページで異なるバージョンのApplication Insightsが複数実行されている場合、初期化中にエラーが発生することがあると説明されています。この場合は、name設定で名前空間を変更する対応が示されています。(Microsoft Learn)
ただし、実務では名前空間を分ける前に、まず重複読み込みをなくすことを優先します。
よくある重複パターンは次のとおりです。
- HTMLテンプレートにLoader Scriptがあり、Reactアプリ側でもnpm SDKを初期化している
- タグマネージャー経由とアプリコード内の両方でSDKを入れている
- マイクロフロントエンドごとにApplication Insightsを初期化している
- 旧スニペットが一部ページだけ残っている
複数のSDKを意図して使う場合は、名前空間、接続先、送信イベント、初期化順序を明確にします。意図していない重複は、データの二重計上や初期化エラーの原因になります。
Cookie管理の古い書き方を見直す
古いコードでCoreUtilsやグローバルなCookie関数を使っている場合は、インスタンスベースのCookie管理へ寄せることを検討します。公式構成情報では、ツリーシェイク改善の観点から、グローバル関数を使わないことが推奨されています。(Microsoft Learn)
特にnpmパッケージでバンドルサイズを気にする場合、不要なコードを含めないために、古いヘルパークラスへの依存を減らすことが重要です。
ソースマップの運用を整える
JavaScriptエラーを本格的に調査するなら、ソースマップの扱いも確認します。
公式構成情報では、ソースマップにより、ミニファイされたJavaScriptコードの例外スタックをアンミニファイしてデバッグしやすくできると説明されています。また、Azure Blob Storageコンテナーへソースマップをアップロードし、Application Insightsリソースと関連付ける運用が示されています。(Microsoft Learn)
本番運用では、次の点を決めておきます。
| 項目 | 実務上の注意 |
|---|---|
| ソースマップの公開範囲 | 公開アクセスにしない。必要な権限で管理する |
| バージョン管理 | デプロイバージョンとソースマップのパスを一致させる |
| CI/CD連携 | ビルド後にBlob Storageへ自動アップロードする |
| 障害調査手順 | 例外発生時に誰がどの画面で確認するか決めておく |
ソースマップがないと、エラーの場所が圧縮後のファイル名や行番号で表示され、調査に時間がかかります。リリース頻度が高いSPAでは、SDK導入と同じタイミングでソースマップ運用を整える価値があります。
展開前チェックリスト
Application Insights JavaScript SDKを本番展開する前に、次のチェックリストを確認してください。
| チェック項目 | 確認内容 | 担当 |
|---|---|---|
| Application Insightsリソース | 本番・検証・開発で分離されている | Azure管理者 |
| 接続文字列 | 環境ごとに正しく差し替わる | 開発者 |
| SDK導入方法 | Loader Scriptかnpmかを明確にしている | 開発者 |
| CSP/ネットワーク | SDK読み込み元と送信先を許可している | インフラ担当 |
| OpenTelemetryとの役割分担 | ブラウザー側とサーバー側を混同していない | アーキテクト |
| SPAルート追跡 | 画面遷移ごとにページビューが適切に記録される | フロントエンド開発者 |
| クリック分析 | 収集対象と命名ルールが決まっている | 開発者、分析担当 |
| CORS相関ヘッダー | 外部ドメインや認証サービスで失敗しない | 開発者 |
| Cookie/個人情報 | 不要な個人情報を送信していない | セキュリティ担当 |
| テレメトリ量 | サンプリングや除外条件を検討している | 運用担当 |
| データ確認 | Search、Logs、KQLで受信を確認した | 運用担当 |
| 障害調査 | SDKロード失敗時の確認手順がある | 運用担当 |
特に本番前には、ローカル環境だけでなく、実際のCSP、プロキシ、WAF、認証基盤、CDNを通したステージング環境で確認することが重要です。ブラウザーRUMは、ネットワークやセキュリティ設定の影響を受けやすいためです。
最小構成で始める実践手順
これから導入する場合は、最初からすべての機能を有効にするのではなく、段階的に進めるのがおすすめです。
まずページビューと例外を取る
最初の段階では、Application Insightsリソースを作成し、接続文字列を取得します。そのうえで、Loader ScriptまたはnpmパッケージでSDKを組み込み、ページビューとJavaScript例外が送信されることを確認します。
この段階のゴールは、細かな分析ではなく「本当にデータが流れているか」を確認することです。
次にAPI呼び出しとSPA画面遷移を確認する
次に、Ajax/Fetchの依存関係、SPAのルート変更、バックエンド側のリクエストとの関連付けを確認します。
APIサーバーもApplication InsightsやOpenTelemetryで監視している場合は、ページビューからAPI呼び出し、サーバー処理まで追えるかを見ます。ここで相関が取れない場合は、CORS、相関ヘッダー、サーバー側のトレース設定を見直します。
最後にクリック分析やカスタムイベントを追加する
ページビュー、例外、API呼び出しが安定してから、Click Analyticsプラグインやカスタムイベントを追加します。
クリック分析は便利ですが、無計画に有効化すると「ボタンA」「not_specified」「div」など、分析しにくいイベントが増えます。重要なUI要素にdata-*属性を設定し、イベント名や親要素IDのルールを決めてから展開しましょう。
よくあるトラブルと対処法
データがApplication Insightsに表示されない
まず接続文字列の形式を確認します。InstrumentationKey=...を含む接続文字列として正しく設定されていない場合、SDKロードや送信が失敗する可能性があります。次に、ブラウザーの開発者ツールでSDKの読み込み、ネットワーク送信、CSPエラーを確認します。
Azureポータルでは、SearchペインでPage ViewやCustom Eventを選び、数分待ってから確認します。データ反映には少し時間がかかることがあります。(Microsoft Learn)
ページビューが二重に記録される
SPAで手動のtrackPageView()と自動ルート追跡を同時に使っている場合、ページビューが重複することがあります。ルート変更時の追跡を自動にするのか、アプリ側で手動送信するのかを決め、どちらかに寄せます。
また、Loader Scriptとnpm SDKの両方が読み込まれていないかも確認します。
APIリクエストが急に失敗する
CORS相関ヘッダーを有効にしたあとにAPIリクエストが失敗する場合、呼び出し先がtraceparentなどのヘッダーを許可していない可能性があります。特に外部IDプロバイダー、決済サービス、SaaS APIでは注意が必要です。
この場合は、CORS設定を見直すか、correlationHeaderExcludedDomainsで対象ドメインを除外します。(Microsoft Learn)
クリックイベントが分析しにくい
Click Analyticsプラグインでnot_specifiedのようなイベントが増える場合、HTML要素のidやdata-*属性が不足している可能性があります。重要なボタンやリンクには、分析で意味が分かる名前を付けます。
例として、資料請求ボタンなら次のように、用途が分かる属性を設計します。
<button data-id="request-document-primary" data-parentid="pricing-page-cta">
資料を請求する
</button>イベント名は、画面名、機能名、行動が分かる形にすると後から分析しやすくなります。
管理者・開発者が次にやるべきこと
Azure MonitorのApplication Insights JavaScript SDK Setupで最も重要なのは、ブラウザー側の監視はApplication Insights JavaScript SDKで行い、サーバー側のOpenTelemetryとは役割を分けて設計することです。
これから導入する場合は、次の順序で進めると失敗しにくくなります。
- Application Insightsリソースを環境ごとに用意する
- 接続文字列を取得し、Loader ScriptまたはnpmでSDKを組み込む
- SearchとLogsでPage View、例外、依存関係が流れているか確認する
- SPAのルート変更、CORS相関ヘッダー、Cookie、個人情報の扱いを確認する
- 必要に応じてClick Analytics、カスタムイベント、ソースマップ、サンプリングを追加する
最初から高度な分析を作り込むより、まず「主要ページが見えている」「JavaScriptエラーが追える」「API失敗と関連付けられる」という状態を作ることが重要です。そのうえで、クリック分析やカスタムイベントを追加すれば、Azure Monitorを単なる障害監視ではなく、ユーザー体験改善のための実用的な観測基盤として活用できます。
コメント