Application Insights Smart Detectionのアラート設定勘所｜検知した異常が誰にも届かない状態を防ぐ
Smart Detection の既定の通知先は、メールアドレスではなく「サブスクリプションの範囲で監視系のロールを持つ人」です。
権限をリソースグループ単位で最小化した環境ほど、この宛先は空になります。検知は正常に動き続けるため、アラートの記録は残るのに誰にも届かないという状態に、気づく手がかりがありません。
アラートを設計するとき、アクショングループの宛先を点検するのは基本中の基本です。ところが Application Insights を作ると自動で用意される Smart Detection のアクショングループは、宛先が個々のメールアドレスではなくロールで書かれています。宛先の一覧を見ても、実際に誰が受け取るのかはロールの割り当てを別に調べるまで分かりません。点検したつもりでも、ここがすり抜けます。この記事では、Smart Detection が何をしてくれる機能なのかを整理したうえで、既定の宛先が空になる条件と、それを前提にした通知の設計、届くことの確かめ方を解説します。
目次
株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。
Application Insights Smart Detection とは
Smart Detection は、Application Insights に送られてくるアプリのテレメトリ（要求・依存関係の呼び出し・例外など）を自動で分析し、いつもと違う振る舞いを見つけて知らせる機能です。Microsoft Learn は「失敗率の急上昇や、クライアントまたはサーバーのパフォーマンスに異常なパターンがあると、アラートが届きます。この機能は構成を必要としません。アプリが十分なテレメトリを送信していれば動作します」と説明しています。
しきい値を自分で決める通常のアラートとの違いは、2点あります。
しきい値を決めなくてよい
「失敗率が何％を超えたら通知」という線を引く必要がありません。代表的な検出である Failure Anomalies（失敗の異常）は、機械学習でそのアプリの正常な失敗率を学習し、そこから大きく外れたときに知らせます。負荷が上がると失敗も増えやすい、特定の要求は失敗しやすい、といったアプリごとの癖も織り込んで判断します。
原因の手がかりまで分析して届ける
異常を見つけると、失敗した要求に共通する特徴（応答コード・要求名・アプリのバージョンなど）を分析し、関連する例外や依存関係の失敗、トレースログの例を添えて通知します。Learn は「通常のメトリックアラートは、問題があるかもしれないことを伝えます。Smart Detection は診断作業を代わりに始め、本来なら自分で行う分析の多くを実行します」としています。通知を開いた時点で、どこから調べ始めればよいかが分かるのが強みです。
検出の種類と、2つの系統
Smart Detection には複数の検出があり、通知の仕組みの上で2つの系統に分かれます。この違いを知らないと、設定を探す場所を間違えます。
| 検出 | 何を見つけるか | 通知の仕組み |
|---|---|---|
| Failure Anomalies（失敗の異常） | 要求や依存関係の呼び出しの失敗率が、学習した正常範囲を外れた | 最初から Azure Monitor のアラートルールとして作られる。アクショングループで通知する |
| 応答時間の劣化／依存関係の所要時間の劣化 | 処理時間が過去の基準より遅くなった | 従来型の Smart Detection の設定で通知する。アラートルールへ移行する仕組みがあり、移行すればアクショングループで通知できる（移行はプレビュー） |
| トレースの重大度の劣化／例外量の異常な増加／メモリリークの可能性 | ログの重大度の比率、例外の件数、メモリ消費のパターンの変化 |
移行について、Learn は「移行は Application Insights リソースごとに個別に適用する必要があります。明示的に移行していないリソースでは、Smart Detection はこれまでどおり動作します」としています。一方で、ページ読み込みの遅さ・サーバー応答の遅さ・依存関係の長い所要時間・セキュリティ上の問題・日次データ量の異常な増加の5つは、利用が少ないことなどを理由にアラートへ変換されず、移行後はそのリソースで使えなくなります。これらの検出に頼っている場合は、移行前に代わりの監視を用意してください。
この記事では、以降、アプリの障害にいちばん直結する Failure Anomalies を中心に扱います。
「設定不要なら放っておいてよいのでは？」への答え
構成が要らないのなら、何もしなくてよさそうに見えます。検知については、そのとおりです。Learn は「Application Insights リソースを作成すると、Failure Anomalies のアラートルールが自動で作成されます」と書いています。
問題は通知先です。このアラートルールは、「Application Insights Smart Detection」という名前のアクショングループとセットで作られます。Learn はその中身をこう説明しています。
「既定では、このアクショングループには Email Azure Resource Manager Role のアクションが含まれ、サブスクリプションで監視共同作成者（Monitoring Contributor）または監視閲覧者（Monitoring Reader）のロールを持つユーザーに通知を送信します」
つまり既定の宛先は、特定のメールアドレスではなく「そのロールを持っている人」です。そしてアクショングループ側の仕様として、ロール宛てのメールには条件があります。
割り当ては「サブスクリプション」の範囲でなければならない
Learn は、ロール宛てのメールを使う条件として「ロールにはユーザーまたはグループを割り当てる」「割り当てはサブスクリプションのレベルで行う」「ユーザーの Microsoft Entra のプロフィールにメールアドレスが設定されていることを確認する」の3つを挙げています。
お客様専用の環境では、権限を最小限にするために、リソースグループの範囲でだけロールを割り当てることがよくあります。この運用自体は正しいのですが、その場合、監視閲覧者を割り当てていても既定の通知は誰にも届きません。サブスクリプションの範囲では所有者しかいない、という構成でも同じです。既定の宛先は監視共同作成者と監視閲覧者だけで、所有者は含まれないからです。
届いていないことに、気づく手段がない
この状態でも、検知そのものは正常に行われます。ポータルのアラートの一覧には記録が残ります。しかし、誰もポータルを開かなければ、障害は気づかれないまま進みます。「検知はされていたのに、誰にも届いていなかった」という形の見落としは、障害が起きて初めて表に出ます。
弊社も、お客様専用環境の点検でこの状態を見つけ、宛先を明示する形に直したことがあります。自動で作られたものは、作られたこと自体に安心して中身を確認しない、という落とし穴になりがちです。
現在の割り当てを確認するには、サブスクリプションの範囲に絞ってロールの割り当てを一覧します。
az role assignment list \
--scope /subscriptions/<サブスクリプションID> \
--role "Monitoring Reader" \
--query "[].{name:principalName, type:principalType}" -o table 監視共同作成者（Monitoring Contributor）についても同じように確認します。--scope をサブスクリプションにしておくと、リソースグループの範囲の割り当ては結果に含まれません。ここで誰も出てこなければ、既定の通知はどこにも飛んでいません。
通知先を設計する
ロールの割り当てを通知のために広げるのは、筋がよくありません。権限の設計と通知の設計は、別々に決めるべきものです。弊社では、宛先を明示したアクショングループを用意して、アラートルールに付け替える形を採っています。
宛先は個人ではなく、共有の受け皿にする
担当者個人のメールアドレスを宛先にすると、異動や退職、休暇のたびに通知が途切れます。運用チームの共有メールボックスや配布グループのように、人が入れ替わっても受け皿として残る宛先を指定します。
既定のアクショングループを直接編集しない
「Application Insights Smart Detection」という名前のアクショングループは、同じサブスクリプションの複数の Application Insights で共有されることがあります。Learn は、移行の処理について「その名前の既存のアクショングループが見つかった場合は、新しいアラートルールをそのアクショングループにつなぎます」と説明しています。これを直接書き換えると、意図しない別のアプリの通知先まで変わります。自分のアプリ用のアクショングループを別に作り、アラートルールの側で付け替えるほうが、影響範囲をはっきりさせられます。
構成をコードで管理するなら、アラートルールも含める
Failure Anomalies のアラートルールは microsoft.alertsmanagement/smartdetectoralertrules という種類のリソースで、テンプレートで定義し直せます。自動で作られたものをポータルで直すだけだと、環境を作り直したときに既定の状態へ戻ります。構成をコードで管理している場合は、アクショングループとアラートルールの付け替えまでをコードに含めておくと、再現性が保てます。
（2026年9月更新）
補足：現在の Microsoft Learn には、アクショングループの宛先にメールアドレスを指定した場合、保存してから30分以内にワンタイムパスコード（OTP）で確認する必要があると記載されています。確認していない宛先は、強制が有効になった後はアラートもテスト通知も受け取れません。一度確認すれば、同じテナント内の過去と今後のすべてのアクショングループに引き継がれます。なお、ロール宛てのメールにはこの確認は不要です。宛先を追加したら、確認メールへの対応までを設定作業に含めてください。
届くかどうかを確かめる
通知先を設定したら、届くことを確かめます。ここで確認の範囲を取り違えやすいので、何が確認できて何が確認できないかを分けて考えます。
ポータルのテストで分かるのは「宛先に届くか」まで
アクショングループには、ポータルからテスト通知を送る機能があります。件名に「Test」と付いたメールが届けば、その宛先へ配信できることは確認できます。ただし Learn によると、テストメールの詳細やリンクは見本のデータです。また、一定時間あたりに実行できるテストの回数には上限があります。
テストで確認できるのは、あくまで「そのアクショングループから宛先へ届くか」です。Smart Detection のアラートルールが、そのアクショングループにつながっているかは、テストでは分かりません。付け替えを忘れていても、テストは成功します。
つながりは、アラートルールの側から確かめる
Application Insights の［アラート］から［アラートルール］を開き、シグナルの種類を「Smart Detector」に絞ると、Failure Anomalies のルールが表示されます。ルールを開いて、付いているアクショングループが自分で用意したものになっているかを確認します。
Failure Anomalies は、狙って発火させることが難しい検出です。そこで弊社では、同じアクショングループを付けた一時的なアラートルールを別に作って発火させ、実際のアラートとして宛先に届くことを確かめたうえで、一時的なルールを削除しています。テストの成功だけで完了とせず、「本物のアラートが、本物の経路で届く」ことまでを確認の範囲にしています。
閉域の環境では、通知の出口を先に決める
アプリを仮想ネットワークの中に閉じ込め、外向きの通信を絞った環境では、アプリ自身から外部へ通知を送る作りは使えません。通知はアプリの外、Azure Monitor の側で出す設計になります。
アクショングループの側にも制約があります。Learn は Webhook のアクションについて「Webhook のエンドポイントは、パブリックにアクセスできる必要があります」と書いています。Private Link に対応しているアクションの種類は Event Hubs だけです。閉じた環境の中に通知の受け口を置く、という作りは基本的にできません。
このため閉域の環境では、Azure Monitor のアラートからメールで通知する形を軸にし、Webhook を使うなら受け口は閉域の外に置く、と最初に決めておきます。閉域の構成そのものはAzure OpenAI・AI Searchを閉域で使うで解説しています。
通知を受けたら、どこを見るか
Failure Anomalies の通知には、通常時と比べた失敗率、影響を受けた利用者の数、失敗に共通する特徴、関連する例外・依存関係の失敗・トレースが含まれます。影響を受けた利用者の数は、どれだけ急ぐべきかを判断する材料になります。
さらに掘り下げるときは、ログを直接照会します。ワークスペースベースの Application Insights では、テレメトリは Log Analytics ワークスペースの AppRequests（要求）・AppExceptions（例外）・AppTraces（トレース）・AppDependencies（依存関係）といったテーブルに入っています。
AppRequests
| where TimeGenerated > ago(1h)
| where Success == false
| summarize failed = count() by Name, ResultCode
| order by failed desc 通知に添えられた「失敗に共通する特徴」と、この集計が一致すれば、原因の当たりはかなり絞れます。同じ時間帯の AppExceptions を見て、どの例外が出ているかを確かめるのが次の手順です。
運用で見落としやすい細部
最後に、仕様として知っておかないと誤解しやすい点をまとめます。
| 仕様 | 運用上の意味 |
|---|---|
| 使い始めて24時間は学習期間 | アプリが一定量のデータを送るようになってから、正常な振る舞いを学ぶのに24時間かかります。構築した直後の障害は検知されません。 |
| 判定は Application Insights 全体の失敗率 | API ごとやアプリごとには通知しません。1つの Application Insights に複数のアプリを送っていると、1つのアプリの失敗が全体の中に埋もれることがあります。 |
| 復旧しても通知は来ない | 問題が8〜24時間検出されなければ自動で解決扱いになりますが、その際の通知はありません。解決したかどうかはポータルで確認します。 |
| Application Insights を削除してもルールは残る | 対応するアラートルールは自動では削除されません。環境を片付けるときは、ルールも忘れずに削除します。 |
| ロールを追加してから届くまで最大24時間 | ロール宛てのメールを使う場合、新しいロールを追加してから通知が届き始めるまで最大24時間かかることがあります。追加した直後に届かなくても、慌てず時間を置きます。 |
設定の勘所のまとめ
- 既定の宛先は「サブスクリプションの範囲で監視系ロールを持つ人」だけと心得る
- 自分のアプリ用のアクショングループに、共有の宛先を明示する
- アラートルールの側で付け替え、つながりを確認する
- テストの成功で終わらせず、本物のアラートで届くことを確かめる
- 閉域の環境では、通知の出口を最初に決める
弊社の支援
弊社は、お客様専用のAI基盤やアプリをAzure上に構築する形で、AIの業務活用を支援しています。構築して終わりではなく、障害に気づける状態で運用を始められるよう、監視と通知の設計も構築の範囲に含めています。
監視は、何かが起きるまで効いているかどうかが分からない仕組みです。だからこそ、宛先を明示し、届くことを確かめる手順を、構築の段階で済ませておくことを重視しています。公開面の守り方はAzure Front Door の背後のアプリを守るもあわせてご覧ください。
よくあるご質問
こちらをクリックして「よくある質問」を表示
Smart Detection を使うのに、何か設定は必要ですか？
検知には設定は要りません。アプリが十分なテレメトリを送っていれば動作し、Failure Anomalies のアラートルールも Application Insights を作ると自動で作成されます。ただし通知先は既定のままだと届かないことがあるため、宛先の確認と設定は必要です。
監視閲覧者のロールを割り当てているのに、通知が届きません。なぜですか？
割り当ての範囲を確認してください。ロール宛てのメールは、サブスクリプションの範囲で割り当てたユーザーやグループにしか届きません。リソースグループの範囲の割り当ては対象外です。あわせて、ユーザーの Microsoft Entra のプロフィールにメールアドレスが入っているかも確認してください。
サブスクリプションの所有者には通知が届きますか？
既定のアクショングループのままでは届きません。既定の宛先は監視共同作成者と監視閲覧者のロールだけです。所有者に届けたい場合も、ロールに頼らず、宛先を明示したアクショングループを用意することをお勧めします。
アクショングループのテストが成功すれば、設定は完了と考えてよいですか？
完了とは言えません。テストで分かるのは、そのアクショングループから宛先へ届くかどうかまでです。Smart Detection のアラートルールがそのアクショングループにつながっているかは別に確認が必要です。実際のアラートとして届くことまで確かめてください。
アラートルールへの移行は、すぐに行うべきですか？
Failure Anomalies は最初からアラートルールなので、移行は不要です。他の検出を移行するとアクショングループで柔軟に通知できるようになりますが、移行はプレビューで、ページ読み込みの遅さなど5つの検出は移行後に使えなくなります。それらに頼っていないかを確認してから判断してください。
障害が解決したときにも通知を受け取れますか？
Failure Anomalies では受け取れません。問題が一定時間検出されなければ自動で解決扱いになりますが、その際の通知や処理は行われない設計です。解決したかどうかは、Azure ポータルのアラートの一覧で確認してください。
お客様専用の環境の監視をどこまで作り込むかは、業務への影響の大きさによって変わります。現在の構成や運用体制をお聞かせいただければ、監視と通知の設計案をご提案します。お問い合わせよりお気軽にご相談ください。
関連サービス・関連コラム
- クラウド導入支援（Azure）｜アセスメントから移行・運用まで一気通貫で伴走
- Azure OpenAI・AI Searchを閉域で使う｜Private Endpointと仮想ネットワークの設計
- Azure Front Door の背後のアプリを守る｜App Service 認証（Easy Auth）とオリジンロックの設計
- Azureのインフラ払い出しをセルフサービス化する｜IaCとDeployment Stacksで申請から変更管理まで統制する
- ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ
- Azure Functions Flex Consumption のデプロイと運用｜従来プランとの違いと利用の注意点
- Azure Container Apps の料金を抑える設定｜使わない間は止めるか、常時起動にするかの判断基準
- Azureの構成をBicepで管理するときの落とし穴｜手作業の設定が消える理由と、本番に適用する前の確認
- Azure DevOps で本番環境へのデプロイを管理する｜承認・自動確認・切り戻しの組み立て方
- 稼働中のシステムを別のAzureリージョンへ移す｜引き継がれない設定と、切り替えの順序設計
まずは無料トライアルで、効果をご確認ください
「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。
