Application Insightsを有効にして、要求や例外のグラフがそれっぽく出るところまで来た——でも本当に困るのはここからです。「なんか遅い」と言われたのに、どこが遅いのか分からない。エラーが出ているらしいのに、どのリクエストで起きたのか追えない。データは集まっているのに、そこから「犯人」を特定できないと、監視ツールはただのきれいなダッシュボードで終わってしまいます。
この記事は、その一歩先——集めたテレメトリを使って、実際に問題を見つけて対処する「分析・運用」に振り切った内容です。分散トレースで遅さの犯人を探し、可用性テストとスマート検出で壊れる前に気づき、サンプリングでコストを抑え、最後はKQLで自分の手で深掘りする。App Insightsを「見るだけ」から「使いこなす」に引き上げるのがゴールです。
「グラフは出せるようになったけど、そこから何をどう見れば原因にたどり着けるの？」
なお、そもそもApplication Insightsが何を集めているのか（要求・依存関係・例外・トレースといったテレメトリの中身）があやふやな方は、先に Azure Application Insightsとは？APMの仕組み・テレメトリ・分散トレースを実務目線で解説 に目を通しておくと、この記事の位置づけがはっきりします。本記事はその親記事の「入門」に対する実践・応用編です。
分散トレースとアプリケーションマップで「遅さの犯人」を探す
実務でいちばん多く、いちばん厄介なのが「なんか遅い」です。そしてこの「遅い」の正体を突き止めるための、App Insights最強の武器が分散トレースと、それを絵にしたアプリケーションマップです。
いまどきのアプリは、一枚岩で動いていることのほうが少ないですよね。フロントのWeb APIがあって、その裏で認証サービスを呼び、さらに別のマイクロサービスやデータベース、外部APIを叩く。1回のユーザー操作が、裏ではいくつものコンポーネントをリレーのように渡り歩いて結果を返しています。この「1回の処理が通り抜けた経路ぜんぶ」を、1本の線としてつなげて記録するのが分散トレースです。
たとえるなら、荷物の配送追跡です。ネット通販で買った荷物が「発送→○○センター経由→△△営業所→配達中」と各拠点の通過時刻つきで追えますよね。分散トレースはこれのアプリ版で、リクエストという荷物が「APIを出発→認証サービスを通過→DBに立ち寄って→戻る」という各区間を、それぞれ何ミリ秒で通ったかまで記録します。だから「どの区間で荷物が長く止まっていたか」＝どこが遅かったかが一目で分かるわけです。
なぜ経路がつながるのか：相関ID
「別々のサービスが出したログが、なぜ1本の処理としてつながるのか？」——ここが分散トレースの肝です。カギは相関ID（Operation ID / Trace ID）という、リクエストごとに振られる通し番号です。
最初にリクエストを受けたサービスが1つのIDを発行し、それを次のサービスを呼ぶときのHTTPヘッダーにこっそり忍ばせて渡します。受け取った側も同じIDを使ってログを残す。これを全区間で繰り返すことで、バラバラのサービスが出したテレメトリを、後から同じIDで1本の処理として縫い合わせられるのです。宅配便でいう「送り状番号」がずっと荷物に付いて回るのと同じ発想ですね。ありがたいことに、App InsightsのSDKや自動計装を使っていれば、このID付与とヘッダー伝搬は基本的に自動でやってくれます。自分で番号を採番して回す必要はありません。
この仕組みは、業界標準の W3C Trace Context（traceparent という共通ヘッダー）に沿っています。だからApp Insights同士だけでなく、OpenTelemetry対応の他システムとも経路をつなげられる、という広がりも覚えておくと後で効いてきます。
アプリケーションマップの読み方
集まった分散トレースを、コンポーネント同士の関係図として自動で描いてくれるのがアプリケーションマップです。App Insightsの左メニュー「アプリケーション マップ」を開くと、丸（ノード）が線（依存関係）でつながった路線図のような絵が出てきます。丸ひとつがサービスやDBといったコンポーネント、線が「AがBを呼んでいる」という呼び出し関係です。
この絵を読むときに見るべきは、ざっくり3つだけです。
- 依存（どこが誰を呼んでいるか）：線をたどれば処理の流れが分かる。想定外の呼び出しが混じっていないかも見える。
- 遅延（各区間の平均応答時間）：線やノードに時間が表示される。ここが「遅さの犯人」を指す指標。
- 失敗率（赤く色づく箇所）：エラーが多いノードは赤い縁取りで警告される。エラーの発生源が絵で一目で分かる。
実務の流れはこうです。ユーザーから「遅い」と報告が来たら、まずアプリケーションマップを開く。すると、たとえば「Web API → SQL Database」の線に 1.8秒 と出ていて、そこだけやたら時間を食っている、といった具合に犯人の当たりがつきます。次にそのノードをクリックして、遅い実サンプル（実際のトレース1件）を開くと、タイムラインのガントチャートが現れます。処理の各区間が横棒で並び、どの棒が長く伸びているかで「アプリ本体は速いが、SQLの1クエリだけで1.6秒食っている」といったところまで一気に降りていけます。
「マップで犯人の区間に当たりをつけて、実サンプルのガントチャートで一番長い棒を探す」。この二段構えが遅延調査の王道です。
私が現場でありがたみを感じたのは、この「絵で当たりがつく」点でした。テキストログを延々grepしていた頃は、遅い1件を見つけるだけで消耗していました。マップなら赤いノード・太い線を目で探すだけなので、調査の入り口が段違いに速くなります。
カスタムイベント・カスタムメトリックでビジネスの数字も測る
ここまでは「アプリが速いか・壊れていないか」という技術寄りの話でした。でもApp Insightsは、ビジネス上の出来事や数字も測れます。それがカスタムイベントとカスタムメトリックです。
要求や例外は「自動で集まる」ものですが、こちらは自分でコードから明示的に送るテレメトリです。使い分けはシンプルで、カスタムイベント（TrackEvent）は「起きた出来事」、カスタムメトリック（TrackMetric）は「測った数値」と覚えてください。
- TrackEvent：「ユーザーが購入完了した」「クーポンが適用された」といった、回数を数えたい出来事。「今日カートに追加は何回起きたか」を知りたいときに使う。
- TrackMetric：「カートの合計金額」「同時接続数」「バッチの処理件数」といった、値そのものを集計したい数値。平均や最大を見たいときに使う。
コードのイメージはこんな具合です（.NET / C#の例）。TelemetryClient のメソッドを呼ぶだけで、あとはApp Insightsが集計してくれます。
// 「購入完了」という出来事を、付随情報つきで記録
telemetryClient.TrackEvent("PurchaseCompleted",
new Dictionary<string, string> { { "plan", "premium" } });
// 「カート金額」という数値を記録
telemetryClient.TrackMetric("CartTotal", 4980);ポイントは、イベントにプロパティ（付随情報）を添えられること。上の例では plan に premium を付けています。こうしておくと、後で「premiumプランの購入だけを集計する」といった切り口で分析できます。技術指標とビジネス指標が同じ場所・同じ時間軸に並ぶのが強みで、「応答時間が悪化した時間帯に、購入完了が落ち込んでいた」といった、性能とビジネスをまたいだ相関を1画面で追えるようになります。
ひとつ注意。カスタムメトリックを送りすぎると取り込み量（＝課金）が増えます。また、既定では「事前集計」されて個々の値の細かい絞り込みができない場合があるので、細かい軸で分析したいメトリックは設計時に意識しておくと後悔しません。まずは「本当に見たい数字」を数個だけ送るところから始めるのがおすすめです。
可用性テストで「壊れたこと」に先に気づく
ここまでは「ユーザーがアクセスした結果」を見る話でした。でも本当に怖いのは、そもそもユーザーがアクセスできない状態——サイトが落ちている、証明書が切れている、といった障害です。この「ユーザーより先に気づく」ための仕組みが可用性テストです。
やっていることは意外と素朴で、Azureが世界中の拠点から、定期的にあなたのURLを叩きに行くだけです。会社の外から、定期巡回の見回りさんがドアをノックして「ちゃんと開くか」を確認してくれるイメージですね。設定はApp Insightsの左メニュー「可用性」から「標準テストの追加」で行います。
構成で押さえるべきポイントは次のとおりです。
- URLと成功条件：監視したいURLを指定。ステータスコードが200であること、さらに「応答本文に特定の文字列が含まれること」まで成功条件にできる。トップページが200を返しても中身がエラー画面、という事故を防げる。
- 複数リージョンから実行：最低でも複数拠点から叩くのが鉄則。1拠点だけだと「テスト元のネットワーク障害」を「サイトダウン」と誤判定しかねない。複数拠点の多くで失敗して初めてアラート、という設定で誤検知を減らせる。
- テスト頻度：5分間隔などで定期実行。頻度を上げるほど早く気づけるが、その分テスト自体のコストも意識する。
- 失敗アラート：条件を満たさなかったときにメールやTeams、アクショングループへ通知。ここまで設定して初めて「気づける」状態になる。
可用性テストの結果は応答時間つきで蓄積されるので、「どのリージョンからのアクセスが遅いか」「いつから落ちていたか」も後から追えます。SSL証明書の有効期限チェックなども設定できるので、「証明書が切れて全ユーザーが繋がらなくなる」という定番事故を、期限前に検知して防げるのも実務的にうれしいところです。
スマート検出で「異常の兆候」を自動で見つける
可用性テストは「完全に落ちた」を捉えるものですが、実際の障害はもっと曖昧に始まります。じわじわ応答が遅くなる、失敗率がいつもより少し高い——こういう「なんとなく調子が悪い」を、人間がグラフを睨んで気づくのは限界があります。そこを肩代わりしてくれるのがスマート検出です。
スマート検出の賢いところは、「しきい値を自分で決めなくていい」点です。ふつうのアラートは「応答時間が1秒を超えたら通知」のように基準値を人が決めますよね。でもアプリごとに”普通”は違うし、時間帯でも変わります。スマート検出は、あなたのアプリのいつものパターンを自動で学習しておき、そこから統計的に外れた振る舞い——応答時間の急な悪化や、失敗率の異常な上昇——を見つけて自動で通知します。健康診断でいう「あなたの平常値から外れています」を機械が判断してくれる感覚です。
ありがたいのは、多くのスマート検出ルールが既定で有効になっていること。App Insightsを有効にした時点で、失敗率の異常上昇などはすでに見張ってくれています。まずやることは「オンにする」ではなく「通知先を確認・設定する」ことです。App Insightsの左メニュー「スマート検出」→「設定」から各ルールを開き、検出時にメールを送る宛先や、アクショングループ（Teams・Webhookなど）を指定しておきます。ここを設定しないと、検出はしていても誰にも届かない、という宝の持ち腐れになります。
可用性テストとの役割分担で整理すると、可用性テスト＝「外から見て繋がるか」を能動的にノックする、スマート検出＝「集まったテレメトリの中の異常な変化」を自動で見張る。前者が”壊れた瞬間”、後者が”壊れる兆候”に強い、と覚えておくと使い分けに迷いません。
サンプリングでコスト（取り込み課金）を最適化する
ここでいったん、地味だけど実務では絶対に避けて通れない話——お金の話をします。App Insightsの課金は、ざっくり言うと取り込んだテレメトリのデータ量（GB）に対して発生します。つまりアクセスが多いアプリほど、送るデータが増え、請求が膨らみます。「監視を厚くしたら月末の請求にびっくりした」というのは、あるあるの失敗です。
そこで登場するのがサンプリングです。発想はシンプルで、すべてのテレメトリを保存するのではなく、一部を「代表」として残し、残りは間引く。選挙の出口調査で、全有権者に聞かなくても一部への調査で全体の傾向がつかめるのと同じ理屈です。うまく間引けば、統計的な精度はほぼ保ったまま、取り込み量とコストだけを大きく減らせます。
適応型サンプリングと固定率サンプリング
サンプリングには主に2つの方式があります。
- 適応型サンプリング：トラフィック量に応じて間引く割合を自動調整する方式。アクセスが少ない時間帯はほぼ全部残し、急増したら自動で間引く。.NETのSDKでは既定で有効なことが多く、まずはこれに任せておけば大きな失敗はない。「1秒あたり何件まで送る」という目標だけ決めればよい。
- 固定率サンプリング：「常に10%だけ残す」のように割合を固定する方式。挙動が予測しやすく、複数コンポーネントで同じ率をそろえたいとき（分散トレースを途切れさせたくないとき）に向く。
間引くと聞くと「トレースが途切れるのでは？」と不安になりますが、App Insightsのサンプリングは賢くできていて、同じ処理（同じ相関ID）に属するテレメトリは「残すなら丸ごと残す・間引くなら丸ごと間引く」という単位で判断します。だから、残ったトレースについては要求から依存関係まで一連が揃っており、分散トレースの調査が成り立ちます。さらに、残した1件が全体の何件分を代表しているか（サンプリング率）も記録されるので、件数を復元して正しい合計を表示してくれます。「10%しか残してないのに要求数のグラフが実数で出る」のはこのためです。
実務のさじ加減としては、まずは既定の適応型サンプリングに任せるのが正解です。そのうえでコストが問題になってきたら、間引く目標を調整する。逆に、監査などで「1件も落としたくない」種類のテレメトリ（重大な例外など）は、サンプリングの対象外にする設定もできます。「コストは抑えたいが、大事なイベントだけは確実に残す」の両立ができる、と押さえておきましょう。
Log AnalyticsとKQLで自分の手で深掘りする
最後は、App Insights使いこなしの本丸です。ここまで紹介したマップやグラフは「用意された切り口」ですが、実務では必ず「その切り口では見られない、自分だけの疑問」が出てきます。それに答えるのがLog Analyticsと、そこで使うクエリ言語 KQL（Kusto Query Language）です。
App Insightsが集めたテレメトリは、裏側ではテーブルとして保存されています。左メニューの「ログ」を開くと、KQLでこのテーブルを自由に検索・集計できます。データベースのSQLに近い感覚ですが、KQLはログ分析に特化していて、上から下へ「絞る→整える→まとめる」と読めるのが特徴です。まず触るべき主なテーブルはこれです。
- requests：要求（アプリが受けたリクエスト1件ずつ）。応答時間・成否・URLなど。
- exceptions：例外（発生したエラー）。種類・メッセージ・スタックトレース。
- dependencies：依存関係（アプリが外部＝DBやAPIを呼んだ記録）。呼び先・所要時間・成否。
まずは基本の1本。「直近1時間で、失敗した要求を、失敗数の多いURL順に並べる」クエリです。
requests
| where timestamp > ago(1h)
| where success == false
| summarize failures = count() by name
| order by failures desc読み方はこうです。requests テーブルを起点に、パイプ | で処理を数珠つなぎにしていきます。where timestamp > ago(1h) で直近1時間に絞り、where success == false で失敗だけに絞り込む。summarize ... by name でURL（name）ごとに件数を数え上げ、order by ... desc で多い順に並べる。SQLと違って「絞ってから集計する」という思考の順番どおりに上から書けるので、慣れると読み書きが速いです。
テーブルを結合して「要求と例外」をつなぐ
KQLの真価は、複数テーブルを結合して1つのテーブルでは見えない関係を炙り出すところにあります。よくあるのが「失敗した要求に、実際どんな例外がひもづいていたか」を知りたいケース。相関ID（operation_Id）で requests と exceptions を結合すれば、「どのURLの失敗で、どんな例外が飛んでいたか」を一覧にできます。
requests
| where timestamp > ago(1h) and success == false
| join kind=inner (exceptions) on operation_Id
| summarize count() by name, typejoin kind=inner (exceptions) on operation_Id が結合の部分です。同じ処理を指す通し番号 operation_Id をカギにして、失敗した要求（requests側の name）と、そこで起きた例外の種類（exceptions側の type）を結びつけています。これで「/checkout の失敗は SqlException が原因、/login の失敗は TimeoutException」といった、症状と原因のひもづけが一発で出せます。アプリケーションマップで当たりをつけ、最後はKQLで裏を取る——これが定番の調査コンボです。
KQLは「テーブルから始めて、パイプで絞る→まとめる」と読むだけ。まずは where と summarize の2つを覚えれば、実務の8割は書けます。
なお、KQLはApp Insightsのテーブルだけでなく、Azure Monitor全体・仮想マシンのログ・セキュリティログなどAzureのあらゆるログ分析で共通して使う言語です。ここではApp Insightsの3テーブル（requests / exceptions / dependencies）に触れる範囲に絞りましたが、KQL言語そのものの演算子や集計関数の掘り下げは、別途Log Analyticsの記事で扱う予定です。まずは「App Insightsのデータは、最終的にKQLで自由に問い合わせられる」という到達点を体で覚えてください。
まとめ
この記事では、Application Insightsを「見るだけ」から「使って問題を解決する」に引き上げる、分析・運用の勘所を実務の順に見てきました。要点を振り返ります。
- 分散トレース／アプリケーションマップ：相関IDで縫い合わされた経路を絵で追い、遅延・失敗の「犯人の区間」に当たりをつける。遅延調査の主役。
- カスタムイベント／メトリック：TrackEvent＝出来事、TrackMetric＝数値。技術とビジネスの指標を同じ時間軸で並べられる。
- 可用性テスト：外から複数リージョンでURLをノックし、”壊れた瞬間”にユーザーより先に気づく。証明書切れ対策にも。
- スマート検出：平常パターンを自動学習し、応答悪化・失敗率異常という”兆候”を通知。しきい値設定不要。既定で有効、通知先だけ設定する。
- サンプリング：一部を代表として残し、統計精度を保ったまま取り込みコストを削減。まずは既定の適応型に任せる。
- Log Analytics／KQL：requests・exceptions・dependenciesを
where／summarize／joinで深掘り。用意された画面では答えられない疑問はここで解く。
ここまでできれば、「なんか遅い」「エラーが出ているらしい」と言われたときに、マップで当たりをつけ、KQLで裏を取り、次からは可用性テストとスマート検出で先に気づく——という、監視を”運用”に変える一連の流れが自分の手で回せるようになります。App Insightsは、有効にした瞬間より、ここから先で本当の価値が出るツールです。
あわせて読みたい：
