Azure Monitorのアクション グループは、アラート発生時に「誰へ通知するか」「どの自動処理を実行するか」をまとめて管理する仕組みです。今回まず確認すべきポイントは、メール通知先に対するOTP検証の扱いです。新しいメールアドレスを通知先に追加する場合、アクション グループ保存後30分以内にOne-Time Passcodeで確認する必要があると明記されました。(GitHub)
既存の監視設計をすべて作り直す変更ではありません。ただし、Azure Monitorのアラート通知をメール、Webhook、Azure Functions、Logic Apps、Runbook、Event Hubsなどに連携している環境では、通知先の追加・IaC展開・テスト・認証方式の確認が重要になります。特に管理者は「メールが届く設定になっているか」だけでなく、「受信者が検証を完了しているか」「自動アクションが期待どおり実行されるか」まで確認する必要があります。
Azure Monitorのアクション グループとは
Azure Monitorのアクション グループは、アラートが発生したときの通知先と実行アクションをまとめた設定です。通知先にはメール、SMS、音声通話、Azureモバイルアプリのプッシュ通知などを指定でき、自動アクションとしてWebhookやAzure Functionsなども利用できます。Azure Monitorだけでなく、Azure Service HealthやAzure Advisorでも使われるため、障害通知の共通基盤として設計するのが実務では効果的です。(Microsoft Learn)
アクション グループは、単なる「通知先リスト」ではありません。アラート発生時に、担当者へ連絡し、チケットを作り、外部システムへ通知し、必要に応じて自動復旧処理を起動するための入口です。そのため、アラート ルールごとに場当たり的に作るより、チーム、重要度、通知経路、運用時間帯を意識して設計する必要があります。
何が変わるのか：メール通知先のOTP検証が重要ポイント
今回の更新で特に注目すべき点は、メール通知先の確認プロセスです。MicrosoftDocsの履歴では、メール通知プロセスにOTP検証を追加する変更が確認できます。具体的には、新しいメールアドレスをアクション グループに追加した場合、保存後30分以内にOTPで確認する必要があり、この検証は同一テナント内の過去および将来のアクション グループにわたって保持されるとされています。(GitHub)
| 確認項目 | 内容 | 実務上の影響 |
|---|---|---|
| 新しいメールアドレスの追加 | 保存後30分以内にOTP確認が必要 | 受信者が確認を完了しないと、通知設計が期待どおり機能しない可能性がある |
| 検証済みメールアドレス | 同一テナント内で検証状態が保持される | 同じメールアドレスを複数のアクション グループで使う場合の運用負荷を下げられる |
| IaCやCLIでの展開 | 設定投入だけで終わらせない | 展開後に受信者側の確認とテスト通知を運用手順に含める必要がある |
| 既存の運用 | すべての自動アクションが変更されるわけではない | まずメール通知先の追加・変更がある環境を優先して確認する |
注意したいのは、「アクション グループを作成できた」と「通知が確実に届く」は別だという点です。特に本番障害通知に個人メールや共有メールを使っている場合、OTPメールがスパム対策で隔離される、担当者が30分以内に確認できない、共有メールの確認担当が決まっていない、といった運用上の失敗が起こりやすくなります。
影響を受けやすい対象者
Azure管理者・監視担当者
Azure portalでアクション グループを作成・変更する管理者は、メール通知先の検証状況、通知のテスト結果、レート制限を確認する必要があります。Azure Monitorでは、SMS、音声、プッシュ、メール通知にレート制限が適用され、複数サブスクリプションから同じ通知先へ大量に送っても制限対象になります。(Microsoft Learn)
開発者・SRE・DevOps担当者
Webhook、Azure Functions、Logic Apps、Runbookを使ってアラート後の処理を自動化している場合は、通知ペイロード、認証方式、再試行時の動作を確認してください。Azure FunctionsアクションではHTTPトリガーのエンドポイントとアクセスキーがアクション定義に保存されるため、関数キーを変更した場合はアクション グループ内のFunctionsアクションを削除して再作成する必要があります。(Microsoft Learn)
セキュリティ・ID管理担当者
Secure webhookやManaged Identityを使う環境では、Microsoft Entra ID、サービス プリンシパル、ロール割り当ての確認が欠かせません。アクション グループのManaged Identity対応はプレビューであり、対応アクションはAutomation Runbook、Event Hub、Logic Appに限られます。Azure Function、ITSM、Secure Webhook、WebhookはManaged Identityの対象外です。(Microsoft Learn)
アクション グループ作成時に確認すべき設定
Azure portalで作成する場合は、MonitorからAlertsを開き、Action groupsを選択して作成します。基本設定ではサブスクリプション、リソース グループ、リージョン、アクション グループ名、表示名を指定し、その後に通知とアクションを設定します。(Microsoft Learn)
リージョンはGlobalとRegionalを使い分ける
Service Healthアラートに応答させるアクション グループは、リージョンをGlobalに設定する必要があります。一方、Regionalを選ぶと、選択したリージョン内にアクション グループが保存され、ゾーン冗長になります。特定の地理的境界内で処理したい場合はRegionalを検討しますが、公式ドキュメント上の対象リージョン一覧に日本リージョンは記載されていないため、データ処理要件がある環境では最新の選択肢を必ず確認してください。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Global | Service Healthアラート、広域障害時の通知継続性を重視する場合 | アクション処理は任意の地理的リージョンで行われる可能性がある |
| Regional | 特定の地理的境界内で処理したい場合 | 選択可能リージョンが限られるため、要件に合うか確認が必要 |
通知タイプは「人への連絡」と「運用負荷」で選ぶ
メールはもっとも使いやすい通知手段ですが、OTP検証、メールフィルタ、スパム対策、送信元許可リストの整備が必要です。公式ドキュメントでは、メール送信元として [email protected]、[email protected]、[email protected] が示されています。(Microsoft Learn)
SMSや音声通知は緊急度の高いアラートに向いていますが、国や地域によってサポート状況が異なります。日本はSMS通知のサポート国に含まれており、音声通知もサポート一覧に含まれますが、音声通知では国によって米国ベースの電話番号から発信される場合があります。(Microsoft Learn)
| 通知タイプ | 向いている用途 | 失敗しやすいポイント |
|---|---|---|
| 通常の障害通知、チーム共有 | OTP未確認、迷惑メール判定、共有メールの確認漏れ | |
| Email Azure Resource Manager role | サブスクリプションのロールに基づく通知 | 対応ロールが限定される、Entra IDのメール属性が未設定 |
| SMS | 重大障害、夜間対応 | レート制限、国・地域のサポート、担当者の購読解除 |
| Voice | 即時対応が必要な重大障害 | レート制限、発信元番号、オンコール設計不足 |
| Azure app push | Azure管理者向けの補助通知 | アプリ側の設定やアカウント利用状況に依存 |
Email Azure Resource Manager roleを使う場合、通知対象にできるのはOwner、Contributor、Reader、Monitoring Contributor、Monitoring Readerです。また、新しいAzure Resource Managerロールをサブスクリプションに追加した場合、通知を受け取り始めるまで最大24時間かかることがあります。(Microsoft Learn)
自動アクションを選ぶときの判断基準
アクション グループでは、通知だけでなく自動化も設定できます。どのアクションを選ぶべきかは、「何をしたいか」よりも「失敗時にどうリカバリーできるか」で判断すると運用しやすくなります。
| アクション | 主な用途 | 確認すべき点 |
|---|---|---|
| Azure Functions | 軽量な処理、独自API連携 | HTTP POST対応、アクセスキー変更時の再作成、ストレージ アカウントへのアクセス |
| Logic Apps | Teams通知、チケット作成、スキーマ変換 | Webhook先が特定スキーマを要求する場合の変換処理 |
| Webhook | 外部監視、チャット、運用基盤への連携 | 公開アクセス、JSONペイロード処理、基本認証の扱い |
| Secure webhook | Entra IDで保護されたAPI連携 | 基本認証は非対応、対象API側のアプリ登録とロール設定 |
| Event Hubs | SIEM、ログ基盤、イベントストリーム連携 | Private Linkやネットワーク セキュリティ境界を使う場合に有力 |
| Automation Runbook | 自動復旧、運用手順の実行 | Run Asアカウント廃止後のManaged Identity移行 |
Webhookを使う場合、ターゲットエンドポイントは複数のアラート ソースから出るJSONペイロードを処理でき、パブリックにアクセスできる必要があります。Webhookアクションはセキュリティ証明書を渡せず、基本認証を使う場合はURIに資格情報を含める必要があります。Microsoft Teamsのように特定スキーマを要求する連携先では、Logic Appsでスキーマを変換する設計が現実的です。(Microsoft Learn)
Webhookの再試行も運用上重要です。最初の呼び出しが失敗すると、一定間隔で最大5回再試行されます。再試行後も失敗した場合、そのエンドポイントは15分間呼び出されません。HTTP 408、429、503、504などは再試行対象として扱われます。(Microsoft Learn)
Common alert schemaは原則有効化を検討する
アクション グループでは、通知やアクションごとにCommon alert schemaを有効化できます。Common alert schemaは、Azure Monitorの各アラートサービスで利用できる統一されたアラートペイロードです。WebhookやFunctions、Logic Appsでアラート内容を処理する場合、スキーマを統一しておくと、後から別種類のアラートを追加したときに処理を再利用しやすくなります。(Microsoft Learn)
ただし、既存のWebhook受け口が独自スキーマを前提にしている場合、いきなりCommon alert schemaへ切り替えると解析処理が壊れる可能性があります。切り替え前に、テスト用のアクション グループでペイロードを受け取り、必須項目、重大度、リソースID、アラート名、発生時刻の取り出し処理を確認してください。
テスト機能は本番投入前に必ず使う
Azure portalでは、作成または更新したアクション グループをテストできます。ただし、テスト前にアクション グループを保存しておく必要があります。テスト完了後はSuccessまたはFailedが表示され、失敗した場合はエラー詳細を確認できます。テスト通知の件名には「Test」が含まれます。(Microsoft Learn)
本番投入前のテストでは、以下を確認してください。
- 新規メール通知先がOTP検証を完了しているか
- SMSや音声通知が想定した担当者に届くか
- WebhookやFunctionsがHTTP POSTを正常に受け付けるか
- Logic Appsでスキーマ変換や分岐が正しく動くか
- RunbookやManaged Identityのロール割り当てが不足していないか
- テスト通知のレート制限に引っかかっていないか
テスト機能にはロール要件があります。既存アクション グループならSubscription Contributor、Resource Group Contributor、Action Group Resource Contributor、Azure Monitor Contributor、条件を満たすカスタムロールなどでテストできます。カスタムロールでは Microsoft.Insights/ActionGroups/* 権限が必要で、テスト専用にしたい場合はwrite/deleteを除外する設計が示されています。(Microsoft Learn)
Managed Identity対応は便利だが、プレビューで対象が限定される
Azure Action Groupsでは、下流サービスを呼び出すときにManaged Identityを使う機能がプレビューとして提供されています。資格情報を直接扱わずに認証できる点は大きなメリットですが、すべてのアクションタイプで使えるわけではありません。Automation Runbook、Event Hub、Logic Appは対応していますが、Azure Function、ITSM、Secure Webhook、Webhookは対象外です。(Microsoft Learn)
Azure portalでManaged Identityを構成する場合、ロール割り当ては自動的に追加されます。一方、PowerShell、CLI、SDKで構成する場合は、必要なロールを手動で割り当てる必要があります。IaCで展開するチームは、アクション グループの定義だけでなく、ID、ロール、対象リソースへのアクセス権も同じ手順に含めてください。(Microsoft Learn)
RunbookアクションはRun Asアカウント廃止後の移行を確認する
Azure AutomationのRun Asアカウントは2023年9月30日に廃止されています。Automation Runbookをアクション グループから実行している環境では、古いRun Asアカウントに紐づくRunbookアクションが残っていないか確認が必要です。公式ドキュメントでは、同じRunbookを選択した新しいAutomation Runbookアクションを追加し、古いRunbookアクションを削除して保存する手順が示されています。(Microsoft Learn)
ここで失敗しやすいのは、「Runbook自体はまだ動いているから問題ない」と判断してしまうことです。証明書の有効期限や認証方式の変更で、障害時にだけ自動復旧が動かない事態になりかねません。Runbookアクションを使っている場合は、平常時にテスト実行し、Managed Identityで必要なロールが付与されているか確認してください。
レート制限と上限を前提に設計する
Azure Monitorのアクション グループには、通知数やアクション数の制限があります。たとえば、サブスクリプション単位ではリージョンごとに1分あたり300通知、アラート ルール単位ではリージョンごとに5分あたり100通知などの制限があります。アクション グループ数そのものに明示的な制限はありませんが、ARMリソース グループの制限は適用されます。(Microsoft Learn)
| 項目 | 主な制限 |
|---|---|
| Emailアクション | アクション グループあたり1,000個 |
| SMSアクション | アクション グループあたり10個、本番では5分あたり1件以下 |
| Voiceアクション | アクション グループあたり10個、本番では5分あたり1件以下 |
| Webhookアクション | アクション グループあたり10個、Webhook呼び出しはサブスクリプションごとに毎分1,500個まで |
| Event Hubsアクション | アクション グループあたり10個 |
| Logic Appsアクション | アクション グループあたり10個 |
| Runbookアクション | アクション グループあたり10個 |
| テスト通知 | アクション グループごとにリージョンあたり5分で2件、サブスクリプションごとに5分で5件 |
レート制限を避けるには、通知先を増やすだけでは不十分です。公式ドキュメントでは、複数リージョンへの分散、重複したアラート ルールの統合、ステートフル アラートの利用、評価頻度の調整、数百のアラート ルールで1つのアクション グループを共有しないことが回避策として示されています。(Microsoft Learn)
アクション グループの再利用は便利だが、使い回しすぎない
1つのアラート ルールには最大5つのアクション グループを追加できます。また、複数のアラート ルールで同じアクション グループを再利用でき、アクション グループは特定の順序ではなく同時に実行されます。(Microsoft Learn)
再利用は管理を簡単にしますが、使い回しすぎると通知集中や影響範囲の拡大につながります。たとえば、すべての本番アラートを1つの共有アクション グループに集約すると、メールやWebhookのレート制限、担当者の通知疲れ、誤った通知先変更の影響が広がるリスクがあります。
実務では、次のように分けると管理しやすくなります。
| 分け方 | 例 | メリット |
|---|---|---|
| 重要度別 | Critical、Warning、Info | SMSや音声通知を重大障害に限定できる |
| チーム別 | Platform、App、Security | 担当外通知を減らせる |
| 環境別 | Production、Staging、Development | 本番と検証環境の通知強度を変えられる |
| 自動化別 | Notify-only、Auto-remediation | 自動復旧の誤作動リスクを抑えられる |
管理者・開発者向けチェックリスト
アクション グループを新規作成、変更、移行する場合は、次の順で確認すると抜け漏れを減らせます。
| 確認タイミング | チェック内容 |
|---|---|
| 作成前 | 通知対象、重要度、チーム、環境、リージョン要件を整理する |
| メール追加時 | OTP検証を30分以内に完了できる担当者を決める |
| 通知設定時 | メール送信元の許可、SMS・音声のサポート国、ARMロールのメール属性を確認する |
| 自動アクション設定時 | Webhookの公開性、Functionsのキー、Logic Appsのスキーマ変換、Runbookの認証方式を確認する |
| IaC展開時 | アクション グループ本体だけでなく、Managed Identity、ロール割り当て、受信者確認を運用手順に含める |
| 本番投入前 | 保存後にテストし、Success/Failedとエラー詳細を確認する |
| 運用中 | レート制限、通知疲れ、アクション グループの使い回しすぎを定期的に見直す |
まず実施すべき対応
今回の更新で最初に見るべき場所は、メール通知を使っているアクション グループです。新しいメールアドレスを追加する運用がある場合は、OTP検証の担当者、確認期限、検証メールの受信可否を手順化してください。次に、WebhookやFunctionsなどの自動アクションを使っている環境では、テスト機能を使って実際の通知・実行経路を確認します。
特に本番環境では、アクション グループを「作って終わり」にしないことが重要です。通知先が検証済みか、レート制限に耐えられるか、自動アクションの認証が古くないか、RunbookがManaged Identityへ移行済みかを確認すれば、障害時に通知だけ届かない、復旧処理だけ動かないといったリスクを減らせます。
コメント