Microsoft Defenderのアラート ポリシーは、マルウェア、フィッシング、管理者権限の付与、外部共有、メール送信異常などを検知するための監視ルールです。まず確認すべきことは、既定ポリシーが有効なままか、不要な旧ポリシーを使い続けていないか、通知先・重大度・RBAC権限が運用体制に合っているかです。
2026年6月時点の公式情報では、Microsoft Defender XDRのアラート ポリシーはMicrosoft Defenderポータルから作成・確認でき、ポリシー条件に一致したユーザー操作や管理者操作が発生すると、アラート画面に表示されます。なお、該当するMicrosoft Learnページは参照時点で「Last updated on 2026-04-29」と表示されています。本記事では、その公式情報をもとに、管理者が確認すべき変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
Microsoft Defenderのアラート ポリシーは、単なる通知設定ではありません。組織内のセキュリティイベントを「誰が見るか」「どの重大度で扱うか」「どのタイミングで通知するか」を決める、セキュリティ運用の入口です。
今回の確認ポイントは、大きく分けると次の4つです。
| 確認項目 | 管理者が見るべきポイント | 対応を怠った場合のリスク |
|---|---|---|
| 既定のアラート ポリシー | 有効状態、通知先、日次通知上限 | 重要アラートを見落とす、または通知過多になる |
| 置き換え・非推奨のポリシー | 旧ポリシーを使い続けていないか | 将来的にアラートが出なくなる可能性 |
| RBAC権限 | セキュリティ担当者が必要なカテゴリを閲覧できるか | アラートは発生しているのに担当者が見えない |
| しきい値・重大度・通知 | High/Medium/Lowの設計が実態に合うか | 優先順位を誤り、初動対応が遅れる |
特に重要なのは、「アラートが生成されること」と「担当者がそのアラートを見て対応できること」は別問題という点です。Microsoft Defender XDRではRBAC権限によって閲覧できるアラートカテゴリが変わるため、ポリシーを作っただけでは運用が成立しません。(Microsoft Learn)
Microsoft Defenderのアラート ポリシーとは
Microsoft Defenderのアラート ポリシーは、ユーザーや管理者の操作が指定条件に一致したときにアラートを生成する仕組みです。たとえば、Exchange Onlineで管理者権限が付与された、悪意のあるメールが配信後に検出された、大量の外部共有が発生した、といったイベントを監視できます。(Microsoft Learn)
管理画面では、以下のような設定を組み合わせてポリシーを作成します。
- 監視するアクティビティ
- 対象ユーザーまたは全ユーザー
- IPアドレス、ファイル名、URLなどの条件
- アラートを発生させるしきい値
- アラートのカテゴリ
- 重大度
- メール通知の有無
- 通知先と日次通知上限
ポリシーは、Microsoft Defenderポータルの Email & collaboration > Policies & rules > Alert policy から確認できます。直接アクセスする場合は、Defenderポータルのアラート ポリシーページを利用します。(Microsoft Learn)
影響を受ける組織とライセンス条件
アラート ポリシーは、Microsoft 365 Enterprise、Office 365 Enterprise、Office 365 Government系の一部プランで利用できます。一方で、しきい値ベースや異常アクティビティベースの高度な機能は、Microsoft 365 E5/G5、またはDefender for Office 365 Plan 2などの追加サブスクリプションが必要になる場合があります。(Microsoft Learn)
特に注意したいのは、同じMicrosoft Defenderポータルを使っていても、契約プランによって設定できるポリシー条件や検知方式が変わることです。
| 利用環境 | 確認すべきこと |
|---|---|
| Microsoft 365 E5/G5 | しきい値、異常検知、自動調査の活用範囲を確認する |
| Microsoft 365 E3/E1系 | 追加ライセンスなしで使える検知条件に制限がないか確認する |
| Defender for Office 365 Plan 1 | 利用できる既定アラートと集約間隔を確認する |
| Defender for Office 365 Plan 2 | AIR、自動調査、Safe Links関連アラートの連携を確認する |
| Government系テナント | 自社テナントで有効な機能差を管理センター上で確認する |
E1/E3系の環境では、アクティビティが発生するたびにアラートを出す設定はできても、異常値ベースの検知や高度なしきい値設定が使えない場合があります。ポリシー設計の前に、必ず現在の契約とアドオンを確認してください。(Microsoft Learn)
管理者が最初に確認すべき変更点
今回の公式情報で実務上見落としやすいのは、既定ポリシーの扱いと、置き換え対象になっているポリシーです。
既定ポリシーは有効だが、すべての設定を編集できるわけではない
Microsoftが提供する既定のアラート ポリシーは、Exchange管理者権限の悪用、マルウェア活動、外部・内部の脅威、情報ガバナンスリスクなどを検出するために用意されています。既定ポリシーはシステムポリシーとして有効化されていますが、編集できるのはオン・オフ、通知先、日次通知上限などに限られます。その他の設定は編集できません。(Microsoft Learn)
つまり、既定ポリシーの検知条件が自社の運用に合わない場合は、既定ポリシーを直接細かく修正するのではなく、カスタム アラート ポリシーを追加して補完するのが現実的です。
一部の情報ガバナンス系ポリシーは非推奨化の流れにある
公式情報では、Information governance alert policiesの一部について、誤検知に関する顧客フィードバックを踏まえ、非推奨化の過程にあると説明されています。機能を維持したい場合は、同じ設定を持つカスタム アラート ポリシーを作成する案内があります。(Microsoft Learn)
特に「Unusual volume of external file sharing」のように、SharePointやOneDriveの外部共有を監視している組織は、既定ポリシーだけに依存しない構成を検討してください。
実務では、次のように整理すると対応しやすくなります。
| 現在の状態 | 推奨対応 |
|---|---|
| 既定の情報ガバナンス系アラートだけで外部共有を監視している | 同等条件のカスタムポリシーを作成する |
| SharePoint/OneDriveの外部共有を監査ログで別途監視している | Defender側のアラートと重複・抜けを比較する |
| DLPやPurview側で共有制御をしている | Defenderのアラートを補助的な検知として位置づける |
| 誤検知が多く無効化している | 条件、対象ユーザー、重大度を見直して再設計する |
置き換え対象のアラート ポリシーは必ず棚卸しする
Microsoft Defenderの既定アラートには、今後利用終了が示唆されているものがあります。たとえば、Email messages containing malware removed after delivery は Email messages containing malicious file removed after delivery に、Email messages containing phish URLs removed after delivery は Email messages containing malicious URL removed after delivery に置き換えられたと説明されています。公式情報では、旧ポリシーはいずれなくなるため、新しいポリシーを使うことが推奨されています。(Microsoft Learn)
また、Remediation action taken by admin on emails or URL or sender は Administrative action submitted by an Administrator に置き換えられたとされています。旧ポリシーを有効にしたまま運用している場合は、通知や運用手順を新しいポリシー名に合わせて更新してください。(Microsoft Learn)
移行時に確認するチェックリスト
| 確認項目 | 具体的な確認内容 |
|---|---|
| 旧ポリシーの有効状態 | 置き換え対象の旧ポリシーがまだ有効になっていないか |
| 新ポリシーの有効状態 | 後継ポリシーが有効になっているか |
| 通知先 | SOC、IT管理者、メール管理者など適切な担当者に届くか |
| 日次通知上限 | 通知が途中で止まらない設定になっているか |
| 運用手順書 | 旧ポリシー名のまま記載されていないか |
| SIEM連携 | 旧ポリシー名や旧アラート名でフィルタしていないか |
| 自動化スクリプト | ポリシー名をハードコードしていないか |
ここで失敗しやすいのは、Defenderポータル上では新旧ポリシーを確認していても、運用手順書、Teams通知、チケット起票ルール、SIEMの検索条件が旧名のまま残るケースです。管理画面だけでなく、周辺運用まで確認してください。
RBAC権限の確認が最重要ポイント
Microsoft Defenderのアラート ポリシー運用で最も多い失敗は、「アラートは生成されているのに担当者が見えていない」状態です。
アラートの閲覧可否は、Microsoft DefenderポータルのRBAC権限に左右されます。たとえば、Records ManagementロールグループのメンバーはInformation governanceカテゴリのアラートだけを表示でき、Compliance AdministratorはThreat managementカテゴリのアラートを表示できない例が示されています。(Microsoft Learn)
Defender for Office 365のアラート ポリシーでは、統合RBACを使う場合、読み取りにはSecurity operations / Security data / Security data basicsの読み取り権限、管理にはAuthorization and settings / Security settings / Detection tuningの管理権限が必要です。Microsoftは最小権限の原則を推奨しており、Global Administratorの常用は避けるべきとしています。(Microsoft Learn)
権限設計の実務例
| 担当者 | 必要な権限の考え方 | 注意点 |
|---|---|---|
| SOC担当 | Threat management、Mail flow系アラートを閲覧・分類できる権限 | 閲覧だけでなくステータス変更が必要か確認する |
| メール管理者 | Exchange、送信制限、隔離、コネクタ関連のアラートを確認できる権限 | Security Readerだけで足りるか検証する |
| コンプライアンス担当 | Information governance、DLP系アラートを確認できる権限 | Threat系アラートが見えない前提で分担する |
| ヘルプデスク | ユーザー報告メールや隔離リリース要求の確認範囲を限定する | 過剰な権限付与を避ける |
| 開発・自動化担当 | PowerShellやAPI連携で必要な最小権限を確認する | 管理者権限の常設を避ける |
権限を確認するときは、「自分の管理者アカウントで見えるか」ではなく、実際に一次対応する担当者のアカウントで見えるかを確認することが重要です。
しきい値・異常検知・重大度の設計ポイント
アラート ポリシーでは、アクティビティが発生するたびにアラートを出すだけでなく、一定回数を超えた場合や、組織の通常状態から大きく外れた場合にアラートを出す設計もできます。ただし、異常アクティビティベースの検知では、Microsoftが通常頻度のベースラインを作るため、最大7日間はアラートが生成されない期間が発生します。(Microsoft Learn)
新しいポリシーを作成してすぐにテストしても、想定したアラートが出ない場合があります。これは設定ミスとは限りません。
重大度を決める判断基準
重大度は、Low、Medium、High、Informationalなどで設定します。公式情報では、マルウェアの配信後検出、機密データの閲覧、外部共有、データ損失やセキュリティ脅威につながる行為には高い重大度を割り当てることが推奨されています。(Microsoft Learn)
| 重大度 | 向いているケース | 対応目安 |
|---|---|---|
| High | アカウント侵害、悪意あるURLクリック、テナント送信制限、機密情報の大量流出につながる操作 | 即時確認、担当者アサイン、必要に応じて封じ込め |
| Medium | 疑わしい送信パターン、大量共有、ZAP失敗など | 当日中に調査し、再発条件を確認 |
| Low | ユーザー報告、軽微なポリシー通知、確認目的のアラート | 定期確認またはチケット化 |
| Informational | 管理操作の完了通知、許可/ブロックリストの期限通知など | 監査ログとして扱い、必要時のみ対応 |
重大度を高くしすぎると、すべてが緊急扱いになり、SOCやIT管理者が疲弊します。逆に低くしすぎると、初動が遅れます。おすすめは、事業影響・拡散可能性・ユーザー影響の3軸で判断することです。
メール通知は「送る相手」と「上限」をセットで設計する
アラート ポリシーでは、アラート発生時にメール通知を送信できます。通知を有効にするか、誰に送るか、1日あたりの通知上限をどうするかを設定できます。公式情報では、特定カテゴリや高い重大度のアラートで通知を有効にすることが案内されています。(Microsoft Learn)
通知設計で避けたいのは、次の2つです。
- 全アラートを全管理者に送って、誰も見なくなる
- 通知上限が低すぎて、重要な時間帯に通知が止まる
実務では、Highは即時通知、Mediumは担当チームの共有メールまたはチケット化、Low/Informationalはダッシュボード確認に寄せると運用しやすくなります。
通知設計の例
| アラート種別 | 通知先 | 補足 |
|---|---|---|
| 悪意あるURLクリック | SOC、メールセキュリティ担当 | Safe LinksやAIRの調査結果も確認 |
| ユーザー送信制限 | メール管理者、ID管理者 | アカウント侵害確認をセットで実施 |
| Exchange管理者権限の昇格 | ID管理者、セキュリティ管理者 | 変更申請と照合する |
| 外部共有の急増 | 情報管理担当、SharePoint管理者 | 業務上の正当な共有か確認 |
| Tenant Allow/Block List期限 | メールセキュリティ担当 | 期限延長の要否を確認 |
アラート集約により、件数の見え方が変わる
Microsoft Defenderでは、短時間に同じポリシー条件に一致するイベントが複数発生した場合、個別のアラートとして大量に出すのではなく、既存アラートに追加されることがあります。これをアラート集約と呼びます。目的は、アラート疲れを減らし、同じイベントに対する対応を集約することです。(Microsoft Learn)
集約間隔はライセンスによって異なり、Office 365またはMicrosoft 365 E5/G5、Defender for Office 365 Plan 2、E5 Complianceアドオンなどでは1分、E1/E3系やDefender for Office 365 Plan 1では15分とされています。(Microsoft Learn)
この仕様は、管理者だけでなく、SIEMやチケットシステムに連携している開発者にも影響します。
たとえば、あるアラートの件数だけを見て「1件しか発生していない」と判断すると、実際には複数イベントが同じアラートに集約されている可能性があります。正確に確認するには、アラート詳細のアクティビティリストやメッセージリストまで確認してください。
組み込みのアラート チューニング ルールも確認する
Microsoft Defender XDRには、一般的な正常アクティビティによるノイズを減らすための組み込みアラート チューニング ルールがあります。これらのルールはアラートを抑制しますが、AIR調査やメール通知などの機能には影響しないと説明されています。Microsoft Security Copilot Phishing Triage Agentを使う場合、抑制されたアラートは分類されないため、該当する組み込みルールやカスタムチューニングルールの確認が必要です。(Microsoft Learn)
確認場所は、Microsoft Defenderポータルの System > Settings > Microsoft Defender XDR > Rules > Alert tuning です。(Microsoft Learn)
特に次のケースでは、チューニングルールの影響を確認してください。
- ユーザー報告メールのアラートが想定より少ない
- Phishing Triage Agentの分類対象にならないアラートがある
- SOCの検知ルールとDefender側の表示件数が合わない
- カスタムチューニングルールを過去に作成したが、棚卸ししていない
- 退職者や旧部門向けの例外ルールが残っている
アラート ノイズを減らすことは重要ですが、抑制ルールを広げすぎると、本来調査すべき兆候まで見えなくなります。チューニングは「消す」ためではなく、対応すべきアラートを浮かび上がらせるために使うべきです。
展開時の注意点：作成・更新後すぐには検知されない
アラート ポリシーは、作成または更新してから検知エンジンに同期されるまで最大24時間かかる場合があります。この間、ポリシー条件に一致する操作が発生しても、アラートが生成されない可能性があります。(Microsoft Learn)
新しいポリシーを展開するときは、次のような手順にすると安全です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 事前確認 | 既存ポリシー、通知先、RBAC、ライセンスを棚卸し | 本番影響を確認する |
| 設計 | 監視アクティビティ、対象ユーザー、重大度、通知先を決める | 重大度を高くしすぎない |
| 作成 | DefenderポータルまたはPowerShellで作成 | 作成権限を確認する |
| 同期待ち | 最大24時間を見込む | すぐに失敗判定しない |
| テスト | 条件に合う操作を実施し、アラート画面と通知を確認 | 異常検知系はベースライン期間に注意 |
| 運用反映 | 手順書、SIEM、チケットルール、当番表を更新 | 旧ポリシー名を残さない |
開発者や自動化担当者がPowerShellでポリシー作成を行う場合も、同期待ちを前提にテスト設計を組む必要があります。即時検知を前提にした自動テストは、誤って失敗扱いになる可能性があります。
管理者・開発者が今日確認すべきチェックリスト
最後に、Microsoft Defenderのアラート ポリシー運用で確認すべき項目をまとめます。
| チェック項目 | 確認内容 |
|---|---|
| 既定ポリシー | 無効化されている重要ポリシーがないか |
| 旧ポリシー | 置き換え対象のポリシーを使い続けていないか |
| カスタムポリシー | 既定ポリシーだけで足りない検知を補えているか |
| 情報ガバナンス | 非推奨化の影響を受ける監視がないか |
| RBAC | 実際の担当者が必要なアラートを閲覧・管理できるか |
| 通知先 | 退職者、旧メーリングリスト、個人依存の通知先がないか |
| 通知上限 | 高重要度アラートの通知が途中で止まらないか |
| 重大度 | 事業影響に応じてHigh/Medium/Lowを使い分けているか |
| アラート集約 | SIEMやチケットの件数解釈が正しいか |
| チューニング | 抑制ルールで重要アラートを隠していないか |
| 手順書 | 旧ポリシー名、旧URL、旧担当者が残っていないか |
| 展開計画 | 24時間の同期遅延や異常検知のベースライン期間を考慮しているか |
Microsoft Defenderのアラート ポリシーは「作って終わり」ではない
Microsoft Defenderのアラート ポリシーは、潜在的な脅威を監視するための重要な仕組みです。ただし、効果を出すには、ポリシー作成だけでなく、ライセンス、RBAC、通知、重大度、チューニング、既定ポリシーの変更状況まで含めて運用設計する必要があります。
まずは、Defenderポータルで既定ポリシーとカスタムポリシーを一覧化し、置き換え対象の旧ポリシー、通知先、RBAC権限を確認してください。そのうえで、重要アラートが担当者に届き、調査・分類・解決まで進められる状態になっているかをテストします。
セキュリティ運用で重要なのは、アラートの数を増やすことではありません。対応すべきアラートを、対応できる担当者に、適切な優先度で届けることです。Microsoft Defenderのアラート ポリシーは、その設計を見直すための中核機能として活用できます。
コメント