はじめに
最近よくITイベントで「オブザーバビリティ（可観測性）」という言葉を聞きませんか？
今年（2025年）のMicrosoftのビッグイベント、Igniteでも Agentic AI（自律型AIエージェント） の監視手法として「オブザーバビリティ」が強く印象付けられました。
オブザーバビリティというと、外形監視やRUM（Real User Monitoring）など様々な機能が各ITベンダーから提供されていますが、その中で最も導入ハードルが高いと感じられるのがAPM（Application Performance Management） です。(個人的な主観です)
実際に多くの現場において、外形監視までは実現できていても「APMはまだ取り組めていない」というケースは少なくありません。その大きな原因は、「Agent導入の手間」と「学習コスト」にあると考えられます。
しかし、私は APMこそがMTTR（平均復旧時間）向上に最も重要な要素である と確信しています。外形監視やRUMの監視ではユーザー体験を直接的に監視はできていても、根本原因の解析に大きな時間を要してしまうのです。つまり、MTTRの向上と運用効率化というオブザーバビリティとしての真価を発揮できていないのです。
現代において、その導入は想像よりも難しくありません。特にAzureユーザーであれば、DatadogやDynatraceの様なオブザーバビリティツールを購入しなくても、非常に短時間で導入できAzurePortalの画面に標準で分析用の画面まで用意されています。
本記事では、AzureのAPMサービスであるApplication Insightsについて、導入の勘所から現場で使えるKQL（Kusto Query Language）、ユースケースまで、スモールスタートで始める方法を解説します。
1章 アプリケーション監視はなぜ重要か
本章ではAPMの重要性を考えるために順を追って従来の監視の抱える課題から、昨今のトレンド、APMのメリットについて考えていきます。この説明はじっくり始めるととても長くて退屈です。それでも知りたいという方が以下の著書を購読することをお勧めします。実際の運用現場での経験から、いかにオブザーバビリティやAPMが重要なのかについて言及しています。
O`REILLY | オブザーバビリティ・エンジニアリング
運用チームの課題
私は現行の監視における課題として次の様な相談を受けたことがありました。もし読者の方がシステム運用の担当者であれば、同じ境遇にないでしょうか。
- 社内システムの独自知識に特化したメンバーしか障害対応ができない
- ユーザーから見えないという報告がきたり外形監視で障害報告が上がっても、アプリチームへ丸投げ
- 丸投げした先のアプリチーム側の対応が遅すぎてMTTRが下がる
なぜ、このようなことが起こるのでしょうか。多くの場合（特に日本企業において）監視設計や運用チーム、アプリチームが怠惰なわけではなく、従来の監視の限界があるのだと思います。
従来の監視の限界
これまでの監視といえば、VMやApp Serviceプランの「CPU使用率」などのインフラメトリックに加え、catalina.out などの アプリケーションログ（テキストログ） を収集・監視するのが一般的でした。
しかし、現代の複雑なアプリケーションにおいては、「サーバーのリソースは余裕があり、ログにも明確なエラーが出ていないのに、システムは不調」 という事態が頻発します。
従来のインフラメトリックやテキストログの検索（Grep）だけでは、以下の「アプリケーション内部の課題」を特定するのは困難です。
- 外部依存の遅延（I/O Wait）: CPUは使っていないが、DBのロック待ちや外部APIの応答待ちで処理が止まっている（テキストログには処理時間は出ても「待機時間」は可視化されにくい）。
- マイクロサービスの迷宮: エラーが発生しているが、複数のサーバーを跨ぐ呼び出し連鎖（A→B→C）の「どこ」が震源地なのか、ログが分断されていて追えない。
- サイレントキラー: クラッシュはしていないが、特定の条件下でのみ例外が発生し、リトライを繰り返してシステム全体を圧迫している。
これらは外形監視やRUMで「遅い・繋がらない」という現象までは検知できても、「なぜ（原因）」 までは即座に特定できません。そこを埋めるのがAPMです。
AI開発における課題とオブザーバビリティ
特にIgnite 2025でも話題となった Agentic AI の開発において、この課題は顕著です。
従来のプログラムと異なり、AIエージェントは「ユーザーの指示を受けて、自律的に思考し、複数のツールを実行する」という複雑で非決定的な動きをします。
- 「なぜAIがその回答に至ったのか？」
- 「どの検索ツール（RAG）の呼び出しで時間がかかっているのか？」
- 「トークン消費量が急増した原因はどこか？」
これらは、CPU監視だけでは絶対に分かりません。アプリケーション内部の「思考のプロセス」や「外部サービスへの依存関係」を透視する APM（トレーシング）の技術 が、AI開発においても注目されています。
「推測」から「事実」へ
アプリケーション監視（APM）を導入する最大のメリットは、パフォーマンスチューニングや障害対応を「推測」ではなく 「データ（事実）」 に基づいて行える点です。
「なんとなく重い気がする」ではなく、「このSQLクエリが平均2秒かかっている」と特定することで、MTTR（平均復旧時間） を劇的に短縮できます。
2章 APM（Application Performance Management）とは
前章でAPMの利用価値について理解いただけてるかと思いますが、では具体的にAPMの定義について触れておきましょう。
APMとは、アプリケーションの性能と可用性をエンドツーエンドで可視化・管理する手法のことです。
特に近年、マイクロサービスアーキテクチャやサーバーレスの普及により、1つのリクエストが複数のサービス（Webサーバー → API → DB → ストレージ）を横断することが当たり前になりました。
こうした環境では、リクエストの一連の流れを追跡する 「分散トレーシング」 という技術が不可欠です。これをAzure上で手軽に実現するのがApplication Insightsです。
3章 Azure Application Insightsとは
Application Insights は、Azure Monitorの一部であり、開発者やDevOpsエンジニア向けのAPM機能です。
Azure App ServiceやAzure Functionsはもちろん、オンプレミスのサーバーや他社クラウド上のアプリケーション（Java, .NET, Node.js, Python等）も監視対象にできます。
収集されたデータは Log Analytics ワークスペース に保存され、強力なクエリ言語である KQL を使って分析できるのが特徴です。
これから導入するにあたり、「ベンダーロックイン」を懸念される方もいるかもしれません。Application Insightsは、可観測性の業界標準規格である OpenTelemetry をサポートしています。
OpenTelemetry について
Microsoftは現在、独自のSDKよりもOpenTelemetryベースのデータ収集（Distro）を推奨する傾向にあります。これにより、将来的に監視ツールを変更する場合でも、アプリケーションコードへの変更を最小限に抑えられます。
4章 導入と最初の監視
4-1. 環境構築の手順
具体的な導入手順は、使用している言語（.NET, Java, Node.jsなど）や環境によって異なります。
本記事では活用方法にフォーカスをしたいので、細かいセットアップ手順は割愛します。
以下の公式ドキュメントを参照し、環境に合わせてセットアップを行ってください。
公式ドキュメント
最初はコード修正が不要な「自動インストルメンテーション」から始めるのがおすすめです。AppServiceなどのPaaSのサービスはAzure Portalのスイッチ一つで有効化できるケースが多いです。まずは、取り掛かりやすいサービスからデータを収集するところから始めましょう。
4-2. 【活用シーン別】まずチェックすべき3つの視点とKQL
APMはこれまでの監視指標と少し視点が違っているのもあり、とっかかりにくいです。そのため、導入後データが溜まり始めたけどどうやって使うんだと悩むユーザーも多いかと思います。まずは以下の3つの視点でデータを見る癖をつけてみてはどうでしょうか。
①応答時間 (Response Time)
エンドユーザーから言われる「重い」や「遅い」といったユーザー体験を可視化する指標です。ここでは特に 「サーバー内部での処理にかかった時間」 を確認します。
- この値が高い場合: アプリケーションコードやDBクエリなど、サーバー側にボトルネックがあります。
- この値が低いのに「遅い」と言われる場合: ネットワークやクライアント（ブラウザのレンダリング等）に原因がある可能性が高く、RUM（Real User Monitoring）での解析が必要という切り分けができます。
▼ [ここに「概要」ブレードの「サーバー応答時間」グラフのキャプチャを挿入]
使えるKQL：平均応答時間の推移（1時間ごと）
requests
| summarize AvgDuration = avg(duration) by bin(timestamp, 1h)
| render timechart
②失敗した要求 (Failed Requests)
ユーザーの画面操作で表示される「エラー」を可視化する指標です。
Application Insightsでは、主にHTTPステータスコードが 400以上 のものを「失敗」として扱います。
- 500番台（Server Error）: プログラムのバグやDB接続エラーなど、早急に対応が必要なシステム障害です。
- 400番台（Client Error）: 入力間違いや権限不足などです。これ自体は正常な動作の場合もありますが、急増している場合はUIの不備や攻撃の可能性があります。
▼ [ここに「概要」ブレードの「失敗した要求」グラフのキャプチャを挿入]
使えるKQL：直近24時間の失敗リクエスト一覧
requests
| where success == false
| project timestamp, url, resultCode, duration
| order by timestamp desc
③要求数 (Server Requests)
「利用状況」を可視化するには要求数が最も分かりやすい指標です。
システムの負荷（スケーリングの必要性）を判断する材料になるだけでなく、ビジネス指標（キャンペーン効果）としても活用できます。
ただし、意図しない急増（スパイク）はDDoS攻撃やBotによる大量アクセスの可能性もあるため、単に「アクセスが増えて良かった」と判断せず、リファラーやIPアドレスの傾向と合わせて冷静に分析する必要があります。
使えるKQL：アクセス頻度の高いURLランキング（トップ10）
requests
| summarize Count = count() by url
| top 10 by Count desc
| render piechart
4-3. 最初のゴール
まずは難しい分析をしようとせず、Azure Portalのリソーストップにある 「概要ブレード」 を毎日1回見ることを習慣にすることから始めると良いです。「普段のグラフの形」を覚えることが、異常検知への第一歩になってきます。（Dynatraceではこの辺りもAIがしてくれますが。）
5章 障害調査とボトルネックの特定
ここからは、Application Insightsの強力な可視化機能を使って、具体的な問題を特定する方法を紹介していきます。ここまでできれば、あなたもApplicationInsightを使いこなしていると言えるでしょう。なお、各説明に参考URLを載せておりますので、より詳しく各機能を知りたい方は公式のドキュメントをご確認ください。
アプリケーションマップ (Application Map)
システム全体の依存関係を地図のように俯瞰できる機能です。ここでは「各コンポーネント間の応答時間」と「WebサーバーからSQL Databaseへの呼び出しでエラーが多発している」といった状況が一目でわかります。未知の遅延やエラーを検知したら真っ先に参照することで、エラー箇所の特定をサポートします。
参考：https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-map#explore-application-map
トランザクションの調査
「特定の処理がなぜ遅いのか」をさらに深掘りする際は、エンドツーエンドのトランザクション詳細を確認します。
失敗 (Failures) の分析
エラーが発生している場合、それが「どの例外（Exception）」によるものかを特定します。
ここでは、NullReferenceException や SqlException など、具体的なエラー原因の件数が分かります。
ワークロードにデプロイ後、この画面をひたすら見てエラーや例外処理を消込していました。ここで例外処理になっているが正常な動作の場合は例外処理にならないようにコードを書き換えたりもしていました。
参考：https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-map#investigate-failures
Live Metrics
リリース直後など、「今まさにこの瞬間」のサーバー負荷を見たい場合は Live Metrics を使用します。数秒の遅延もなく、リアルタイムに心電図のようなグラフが流れます。しかし、メトリクスのように長期保存はされないので注意です。
6章 アラート通知とダッシュボード
ここまでで、傷害調査方法を見てきましたが、実施の運用フェーズでは画面をずっと見ているわけにはいきません。ここからは運用チーム向けに異常時に通知が来るように設定します。
スマート検出 (Smart Detection)
Application Insightsには、設定不要でAIが異常を検知する「スマート検出」機能が標準で備わっています。「平時に比べてエラー率が異常に上昇した」などを検知すると自動でメールが飛ばすことができます。
私は個人的にはこの機能がもっともApplicationInsightの価値を感じる機能であると思っています。（2025年12月現在はまだプレビューなのが非常に残念ですが。）
参考：https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/proactive-diagnostics
カスタムアラート（ログアラート）
通常のログと同じように、AzureMonitorでKQLを使ったログアラートを作成も可能です。Requestの失敗率などSLOと合わせて設定しておくと良いかと思います。
例：特定のエラー（500エラー）が5分間に10回以上発生したら発報
アラートの条件に以下のKQLを設定します。
requests
| where timestamp > ago(5m)
| where resultCode == "500"
（※実際のアラート設定では、このクエリ結果の「行数」が「10より大きい」場合などの条件を指定します）
7章 注意点：データ量とコスト管理
Application Insightsは非常に強力ですが、何も考えずにログを出し続けるとコストがエグイことになっていきます。そして、そんなエピソードを聞いたことがあるメンバーにとってはそれが足枷になって導入が進まない・・・なんてこともないでしょうか。
そのために料金形態を理解し、以下のサンプリングと日時キャップの設定を入れるようにしておきましょう。
課金モデル
基本的には 「取り込んだデータ量（GB単位）」 による従量課金です。
詳細な単価については、以下の公式情報を必ず確認してください。
公式情報
サンプリング (Sampling) の重要性
コストを抑えるための最も重要な機能が「サンプリング」です。
これは、全アクセスのログを記録するのではなく、「全体の10%だけを記録する」といった間引き設定です。
サンプリングを行っても、統計的な数値（平均応答時間など）は補正されて表示されるため、全体の傾向把握には問題ありません。
私の経験上は常時25%程度に抑えておき、障害時やデプロイ前後のみサンプリングレートを引き上げるといったことをしています。
日次キャップ (Daily Cap)
予期せぬログの暴走（無限ループでのエラーログ出力など）による高額請求を防ぐため、「1日あたり〇GBまで」 という上限（日次キャップ）を設定しておく必要があります。最初は、予算をベースに単価から逆残して設定をしておくと良いです。
APMとしてはERROR率やリクエスト成功率等が重要な指標となるので、この構成方法はあまりお勧めできません。ですが、どうしてもという方のために以下に手順書を載せておきます。
https://learn.microsoft.com/ja-jp/azure/azure-functions/configure-monitoring?tabs=v2#configure-log-levels
8章 まとめ
Application Insightsを導入することで、アプリケーションの「現在の状態」がとてもよくわかるようになります。導入も決して難しくありません。ここで説明した重要なポイントは以下です。
- まずは導入してみる
- 毎日「概要ブレード」を眺める
- 慣れてきたらKQLで深掘りする
- サンプリングと日次キャップでコストを守る
もっとAIを活用して根本原因等の解析を進めたいなどであれば是非、DynatraceやDatadog等のSaaSの導入も検討してみて下さい。これからもAzureの監視やオブザーバビリティに関する記事を載せていきますので、是非フォロー、いいねをお願いします。