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つは、利用が少ないことなどを理由にアラートへ変換されず、移行後はそのリソースで使えなくなります。これらの検出に頼っている場合は、移行前に代わりの監視を用意してください。
（2026年10月更新）
補足：2026年10月時点でも、アラートルールへの移行はプレビューのままです。移行ダイアログで「サブスクリプション内のすべてのリソースを移行」を選んでも対象は既存のリソースだけで、プレビュー期間中に新しく作る Application Insights は従来型の Smart Detection で作成されます。新しいリソースは、作るたびに移行が必要です。
この記事では、以降、アプリの障害にいちばん直結する 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のご相談まで、お気軽にどうぞ。
