アプリを本番にデプロイしたあと、いちばん怖いのが「なんだか遅い」「たまにエラーが出ているらしい」という、ふわっとした不調です。ユーザーからは「重い」と言われるのに、自分の手元では再現しない。ログを漁っても、どのリクエストで、どこが引っかかっているのか掴めない。私も駆け出しのころ、この「見えない不調」に何度も夜を溶かしました。
そこで頼りになるのがAzure Application Insightsです。これはひとことで言うと、アプリの中身を丸ごと見える化してくれる監視サービス。どのリクエストが遅いのか、裏でどのデータベースが足を引っ張っているのか、いつ・どんな例外が飛んだのか——今まで想像するしかなかった部分を、実データで見せてくれます。
「監視ツールって名前は聞くけど、結局アプリの何が見えるの？ログとどう違うの？」
この記事はApplication Insights入門編です。App Insightsが集めるテレメトリ（要求・依存関係・例外・トレース）の中身から、自動計装とSDK計装の違い、アプリへのつなぎ方と基本メトリックの読み方、そしてライブメトリックとトランザクション検索まで、初心者がまず押さえるべき土台を実務目線で噛み砕いていきます。読み終わるころには「アプリが遅い・エラーが出た」と言われたときに、どこを見ればいいかの入口が自分で分かるようになります。
なお、分散トレース・アプリケーションマップ・カスタムイベント・可用性テスト・スマート検出・サンプリング・KQLといった分析と運用の応用テーマは、続編の Application Insights 分析・運用編 でじっくり扱います。まずはこの入門編で全体像を掴んでください。
Application Insightsとは？アプリに付ける「ドライブレコーダー」
Application Insights（略してApp Insights）は、Azure Monitorという大きな監視の仕組みの一部で、APM（Application Performance Monitoring＝アプリケーション性能監視）を担当するサービスです。役割をひとことで言えば、アプリの性能・例外・利用状況をずっと記録し続けてくれる存在です。
イメージとしては、アプリに付けるドライブレコーダーが近いです。車のドラレコは、事故が起きたあとに「あのとき何が起きていたか」を映像で見せてくれますよね。App Insightsも同じで、「なんか遅い」「エラーが出た」というときに、その瞬間の走行記録——どのリクエストが、どこで、どれくらい時間を食っていたか——をあとから再生できます。あるいは、人につける健康モニターと考えてもいい。ふだんの心拍（応答時間）や、たまに出る不整脈（例外）を常に測っておいてくれる、というイメージです。
ここで「サーバーのCPUやメモリを見るのと何が違うの？」と思うかもしれません。ポイントは、App Insightsが見るのはインフラの外側ではなくアプリの内側だということです。CPU使用率が高い・低いといった話ではなく、「/checkoutというリクエストが平均800ミリ秒かかっていて、そのうち600ミリ秒はSQLへの問い合わせで消えている」といった、アプリの振る舞いそのものが見えます。ここがApp Insightsの独自価値です。
App Insightsが集める4種類のテレメトリ
App Insightsがアプリから集めてくるデータのことをテレメトリ（telemetry＝遠隔測定データ）と呼びます。ドラレコが映像・音声・GPSといった複数の情報を同時に記録するように、App Insightsも何種類かのデータを並行して集めています。まずこの4つを押さえると、画面のどのグラフが何を意味しているのかが一気に読めるようになります。
① 要求（Request）— 誰が何を呼んで、どれくらいかかったか
要求は、アプリが外から受け取ったリクエスト1件1件の記録です。「GET /productsが来て、ステータス200で、応答に120ミリ秒かかった」といった情報が1件ずつ残ります。応答時間・要求数・失敗率といった、いわゆるアプリの成績表はここから作られます。「どのエンドポイントが遅いか」を知りたいときに最初に見る場所です。
② 依存関係（Dependency）— アプリが裏で呼んでいる相手
依存関係は、アプリが処理の途中で外部に問い合わせた記録です。データベースへのSQL、他のAPIへのHTTP呼び出し、ストレージやキャッシュへのアクセスなどがこれにあたります。これが取れると何が嬉しいかというと、「リクエスト全体が遅い」ときに遅さの犯人が自分のコードなのか、それとも呼び出し先のDBなのかを切り分けられるのです。「アプリは悪くない、SQLが毎回2秒かかってた」といった発見は、ほぼこの依存関係が教えてくれます。
③ 例外（Exception）— いつ、何が、どこで壊れたか
例外は、アプリの中で発生したエラー（未処理例外や、明示的に記録した例外）の記録です。例外の種類・メッセージ・スタックトレース（どのコードのどの行で起きたか）が残るので、「ユーザーからエラーの報告が来たけど再現しない」というときでも、その瞬間のスタックトレースを直接見て原因の当たりを付けられます。ドラレコの衝撃検知に近い機能ですね。
④ トレース（Trace）— アプリが吐いたログそのもの
トレースは、アプリケーションが出力したログメッセージです。logger.LogInformation("注文処理を開始") のように普段コードに書いているログを、App Insightsに集約して残せます。要求・依存関係・例外という構造化されたデータの「すき間」を埋める、自由記述のメモのような位置づけです。
「要求＝入口、依存関係＝裏で呼んだ相手、例外＝壊れた瞬間、トレース＝手書きログ」。この4つの役割だけ先に覚えておくと、画面がぐっと読みやすくなります。
自動計装とSDK計装、どっちで始める？
アプリからテレメトリを集めるには、アプリに「計測する仕掛け」を仕込む必要があります。これを計装（instrumentation、インストルメンテーション）と呼びます。ドラレコを車に「取り付ける」作業にあたる部分ですね。方法は大きく2つあります。
自動計装 — コードを触らず後付けする
自動計装は、その名のとおりアプリのコードを一切変えずにテレメトリ収集を有効にする方法です。たとえばAzure App ServiceにWebアプリを載せている場合、ポータルの「Application Insights」メニューでスイッチをオンにするだけで、要求・依存関係・例外の収集が始まります。コードのビルドもデプロイもやり直さなくていいので、まず最初はこれで始めるのがおすすめです。市販のドラレコを買ってきて配線するだけ、というイメージです。
SDK計装 — コードに組み込んで細かく測る
一方のSDK計装は、Application InsightsのSDK（ライブラリ）をアプリに組み込む方法です。手間は増えますが、「注文が確定した回数を数えたい」といったアプリ独自の情報（カスタムイベントやカスタムメトリック）まで細かく取れるようになります。純正のドラレコを内蔵する、というイメージですね。こうしたSDKならではの応用は、続編の分析・運用編で詳しく扱います。
実務での付き合い方はシンプルで、まず自動計装で全体像を掴み、足りない情報だけSDKで足す。この順番が失敗しにくいです。いきなりSDKを全部書き込もうとすると、それだけで消耗してしまいます。
まずはアプリにつないで基本メトリックを見る
ここからは手を動かす話です。とはいえ最初のハードルは低くて、大きく「リソースを作る」→「接続文字列でつなぐ」→「グラフを見る」の3ステップです。
まずAzureポータルで「Application Insights」を検索し、新しいリソースを作成します。作成時にワークスペース（Log Analyticsワークスペース）を選ぶよう求められますが、これは集めたデータの保存先になる箱です。深く考えず、既存のものか新規作成を選んでおけば大丈夫です（この保存先が、続編で扱うKQL深掘りの土台になります）。
リソースができると、接続文字列（Connection String）が発行されます。これはアプリとApp Insightsを結びつける「宛先ラベル」のようなもので、こんな形をしています。
InstrumentationKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;IngestionEndpoint=https://japaneast-0.in.applicationinsights.azure.com/この接続文字列を、アプリの環境変数 APPLICATIONINSIGHTS_CONNECTION_STRING に設定すれば、テレメトリの送り先が決まります。App Serviceなら、先ほどの自動計装をオンにした時点でこの設定は自動で入るので、自分で貼り付ける必要すらありません。
ちなみに、古い記事では接続文字列ではなくインストルメンテーションキーという36文字のキーだけを使う方法が紹介されていることがあります。現在は接続文字列の利用が推奨されているので、これから始めるなら接続文字列を使ってください。ここは地味に引っかかりやすいポイントです。
つないでしばらくアクセスが発生すると、App Insightsの「概要」画面に応答時間・要求数・失敗した要求・サーバー例外の4つのグラフが自動で並びます。まずはこの4枚が読めれば十分。「昨日の夜だけ失敗した要求が跳ねてるな」といった気づきは、この画面を眺めるだけで得られます。この4つのグラフが、さきほどの4種のテレメトリ（要求・依存関係・例外・トレース）とちょうど対応していることも意識しておくと、画面の理解が一段深まります。
ライブメトリックとトランザクション検索
基本メトリックの4枚に慣れたら、序盤からもう2つ使える便利な画面を覚えておきましょう。この2つは特別な設定もいらず、つないだ瞬間から使えます。
ライブメトリック — いまこの瞬間を映す
ライブメトリック（Live Metrics）は、いま現在のアプリの状態を、ほぼ遅延ゼロのリアルタイムで映すダッシュボードです。概要画面のグラフが数分遅れの「録画」だとすれば、こちらは「生中継」です。デプロイ直後に「ちゃんとリクエストをさばけているか」「エラー率が跳ねていないか」をその場で見張るのに最適で、リリース作業のときに開きっぱなしにしておくと安心感が違います。「デプロイした瞬間に画面が真っ赤になったので即ロールバックできた」というのは、まさにライブメトリックの見張りが効いた場面です。
トランザクション検索 — 気になる1件を巻き戻す
トランザクション検索（Transaction Search）は、集まったテレメトリを1件単位で検索・閲覧できる画面です。「さっき500エラーになったあのリクエストだけ見たい」というときに、その1件の要求・依存関係・例外・トレースをまとめて追えます。ドラレコの映像を、事故の瞬間まで巻き戻して再生する感覚に近いです。概要画面で「失敗が増えている」と気づいたら、この検索でその失敗した1件に飛び込み、スタックトレースまで一気にたどる——というのが、いちばん基本の調査の流れになります。
「概要でざっと成績を見る → ライブメトリックで今を見張る → トランザクション検索で気になる1件を巻き戻す」。まずはこの3画面の往復ができれば、入門としては十分すぎるほどです。
まとめ
この記事では、Application Insightsを「アプリに付けるドライブレコーダー」というイメージで、入門として押さえるべき土台を見てきました。要点を振り返っておきます。
- 正体：Azure Monitorの一部で、アプリの内側（性能・例外・利用状況）を見張るAPMサービス。CPUやメモリではなく「アプリの振る舞い」が見える。
- 4つのテレメトリ：要求＝入口、依存関係＝裏で呼んだ相手、例外＝壊れた瞬間、トレース＝手書きログ。
- 計装：まず自動計装で全体像を掴み、足りない情報だけSDK計装で足す。つなぎ方は接続文字列（旧来のキーではなく）。
- 基本メトリック：概要画面の応答時間・要求数・失敗した要求・サーバー例外の4枚が読めれば入門は十分。
- 2つの画面：ライブメトリックで今を生中継、トランザクション検索で気になる1件を巻き戻す。
ここまで掴めれば、「アプリが遅い・エラーが出た」と言われたときに、まず概要画面で成績を見て、トランザクション検索でその1件を再生する——という調査の型の入口が自分のものになります。見えない不調に夜を溶かす日々から、一歩抜け出せるはずです。
さらに深く学ぶ：Application Insights 分析・運用編
この入門編で土台ができたら、次は集めたデータをどう分析し、どう運用に組み込むかです。分散トレースで複数サービスをまたぐ遅さの犯人を追ったり、可用性テストで外からアプリの生死を見張ったり、KQLで自分の切り口に自由に掘ったり——App Insightsの真価は、この応用パートで一気に開けます。続編でまとめて扱います。
あわせて読みたい：
