変更要約: AZ-400 第5章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
5.2APM・アラート・自動対応
アプリ監視と通知——Application Insights、アラートルール/アクショングループ、自動スケール、ヘルスチェック/可用性テスト、自動修復——を理解します。問題を即座に検知し対応します。
計測したら検知と対応につなげます。Application Insights でアプリを監視し、アラートと自動アクションで素早く対処します。
5.2.1APM とアラート
- Application Insights：アプリの応答時間/依存関係/例外/利用状況を追跡（APM）。
- 可用性テスト：エンドポイントを外形監視し、ダウンを即検知。
- アラート＋アクショングループ：閾値超過で通知や自動アクションを起動。
- 自動対応：オートスケールや Runbook/Functions で自動修復につなげる。
「アプリの APM＝Application Insights」「外形監視＝可用性テスト」「閾値超過の通知/自動対応＝アラート＋アクショングループ」「自動修復＝Runbook/Functions/オートスケール」 は AZ-400 で頻出です。検知だけでなく、アクショングループで通知と自動対応に確実につなげます。
AZ-400 の APM/アラート設計は「計測を検知と対応に確実につなぐ」ことを問います。Application Insights はアプリの応答時間・依存関係（外部 DB/API 呼び出し）・例外・要求レート・ユーザー利用状況を追跡し、アプリケーションマップで依存の健全性を可視化、ライブメトリクスでリアルタイム監視、可用性テストでエンドポイントを外部から定期テスト（アウトサイドイン）します。※現行で新規作成するのは標準テスト（Standard test）だけです——URL ping テストは 2026 年 9 月 30 日に廃止（既存のテストも削除される）、TrackAvailability() によるカスタムテストは Classic API 扱いの旧ガイダンスに移っています。アラートルールは、メトリック（静的閾値/動的＝異常検知）、ログ（KQL クエリ）、可用性に対して発報し、アクショングループで通知（メール/SMS/プッシュ/音声）と自動アクション（Webhook/Logic Apps/Automation Runbook/Azure Functions/ITSM）を起動します。アラート処理ルールでメンテナンス時の抑制やルーティングを制御し、誤報を減らすためにM of N 評価・動的閾値を使います。自動対応は、負荷にはオートスケール、構成逸脱や定型復旧には Runbook/Functions、重大インシデントは Teams 連携やインシデント管理へ。重要なのは「検知して終わり」にせず、各アラートを Runbook（誰が・何を・どう直すか）に結びつけることで MTTR を下げる点です。設計の要は、Application Insights で APM＋可用性を計測し、アラート＋アクショングループで通知と自動修復まで確実につなぐことです。
| 機能 | 役割 | 要点 |
|---|---|---|
| Application Insights | アプリの APM | 応答/依存/例外・アプリマップ・ライブメトリクス |
| 可用性テスト | 外形監視 | エンドポイントを定期テスト |
| アラートルール | 閾値/ログ/可用性で発報 | 静的/動的閾値・M of N で誤報減 |
| アクショングループ | 通知＋自動対応 | メール/SMS・Runbook/Functions/Logic Apps |
シナリオ：本番 Web アプリの 5xx エラー率が急増したら、即座に当番へ通知し、可能なら自動で復旧を試みたい。→ Application Insights でエラー率/例外を計測し、動的閾値のアラートルール（誤報を抑制）を設定。発報時はアクショングループで当番に通知（Teams/SMS）しつつ、Automation Runbook/Functions で定型復旧（インスタンス再起動やキャッシュクリア）を自動実行。負荷起因ならオートスケールで対応。可用性は可用性テストで外形監視します。
FAQ：可用性テストと Application Insights の APM はどう違う？ 可用性テストは外部からエンドポイントへ定期的にリクエストを送るアウトサイドイン監視で、実ユーザーがいなくてもダウンや遅延を検知します（SLA 監視向き）。APM（Application Insights 本体）はアプリ内部の応答/依存/例外を計測するインサイドアウトで、実体験や内部のボトルネックを把握します。両者は補完関係です。
ひっかけ：アラートを作ってもアクショングループを紐づけていないと、通知も自動対応も起きません（検知だけで終わる）。アラート＝条件、アクショングループ＝通知/自動対応、をセットで設計します。また誤報を減らすには固定閾値より動的閾値や M of N 評価が有効です。アプリ内部の性能問題に可用性テストだけで対処するのも不十分（APM が必要）です。
5.2.2この節のまとめ
- APM＝Application Insights＋可用性テスト
- 対応＝アラート＋アクショングループ→自動修復
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Web アプリの応答時間・依存関係・例外を追跡し、パフォーマンス問題を特定したい。何を使いますか？
Q2. 重要なエンドポイントが外部から正常に応答しているかを定期的に監視したい。何を使いますか？
Q3. アラートが発報したら、メール通知に加えて自動修復の Runbook を起動したい。何を使いますか？