Microsoft Defender の「Configure automated investigation and response capabilities in Microsoft Defender XDR」でまず確認すべきポイントは、自動調査と対応（AIR）の有効化そのものではなく、デバイスグループごとの自動修復レベル、Office 365 側のアラートポリシー、Action center の承認運用です。設定を入れて終わりではなく、「どの資産は自動修復させるか」「メール削除などの対応を誰が承認するか」「2026年9月1日以降の手動 AIR 廃止にどう備えるか」まで見直す必要があります。
Microsoft Learn では、対象の設定ページは 2026年6月15日更新、関連する Action center の管理ページは 2026年6月25日更新として表示されています。本記事では、これらの公式情報をもとに、Microsoft Defender XDR の自動調査と対応を運用に落とし込むための確認ポイントを整理します。(Microsoft Learn)
Microsoft Defender XDR の自動調査と対応で何が変わるのか
Microsoft Defender XDR の自動調査と対応、いわゆる AIR は、アラート発生後にセキュリティ担当者が行う調査・判定・修復の一部を自動化する機能です。アラートからインシデントが作成されると、関連する証拠を調査し、悪意あり、疑わしい、脅威なしといった判定を行い、必要に応じてファイルの隔離、プロセス停止、デバイス隔離、URL ブロックなどの修復アクションを提示または実行します。(Microsoft Learn)
重要なのは、AIR が単体の便利機能ではなく、Microsoft Defender for Endpoint、Microsoft Defender for Office 365、Microsoft Defender for Identity などの信号を横断して扱う XDR 運用の一部である点です。端末、メール、ID のいずれかだけを見ていると、設定ミスや承認漏れに気づきにくくなります。
特に今回の公式情報で管理者が見るべきポイントは、次の4つです。
| 確認項目 | 重要な理由 | 管理者が取るべき対応 |
|---|---|---|
| デバイスグループの自動化レベル | 端末に対する修復が自動実行されるか、承認待ちになるかを左右する | 重要端末・一般端末・開発端末などに分け、Remediation level を確認する |
| Office 365 のセキュリティ・アラートポリシー | 一部のアラートが AIR を開始するため、無効化やカスタム置換が影響する | Threat management カテゴリの既定アラート、Standard/Strict ポリシー、構成アナライザーを確認する |
| Action center の承認運用 | メールや一部修復アクションは承認待ちになり、放置すると調査完了が遅れる | Pending と History を定期確認し、承認・拒否・取り消しの担当者を決める |
| 2026年9月1日の変更 | AIR の独立した調査エクスペリエンスや手動トリガーが使えなくなる | 手順書、SOC運用、スクリプト、教育資料を見直す |
AIR は「有効化」よりも「自動化レベルの設計」が重要
Microsoft Defender XDR の設定ページでは、AIR を構成する流れとして、前提条件の確認、デバイスグループの自動化レベルの確認または変更、Office 365 のセキュリティおよびアラートポリシーの確認が示されています。(Microsoft Learn)
ここで最も実務に影響するのが、デバイスグループごとの自動化レベルです。Microsoft は「Full – remediate threats automatically」、つまり脅威を自動的に修復するフル自動化を推奨しています。(Microsoft Learn)
ただし、すべての環境で何も考えずにフル自動化へ寄せればよいわけではありません。標準的な業務用 PC ではフル自動化が有効でも、業務停止の影響が大きいサーバー、開発用ビルド端末、特殊な業務アプリが動作する端末では、誤検知時の影響も含めて段階的に判断する必要があります。
自動化レベルの考え方
Microsoft Defender for Endpoint の自動化レベルには、フル自動化、複数段階の半自動化、自動応答なしがあります。フル自動化では悪意ありと判断されたエンティティに対する修復が自動的に実行され、半自動化ではフォルダーの種類などに応じて承認が必要になります。なお、「No automated response」は自動調査が実行されないため、Microsoft は推奨していません。(Microsoft Learn)
| 自動化レベル | 使いどころの目安 | 注意点 |
|---|---|---|
| Full – remediate threats automatically | 一般的なクライアント端末、標準化された業務端末 | 最も推奨されるが、誤検知時の復旧手順は事前に確認する |
| Semi – require approval for core folders remediation | OS 領域や基幹アプリへの影響を慎重に見たい端末 | 承認待ちが増えるため、Action center の監視体制が必要 |
| Semi – require approval for non-temp folders remediation | 一時フォルダーの脅威は迅速に処理しつつ、通常領域は確認したい場合 | 承認遅れが対応遅延につながる |
| Semi – require approval for all folders | 本番サーバーや影響評価中の端末 | SOC の負荷が大きくなりやすい |
| No automated response | 一時的な例外検証など、限定的な用途 | セキュリティ姿勢を下げるため、恒久設定には不向き |
実務では、まず全端末を一律に扱わず、デバイスグループを次のように分けて考えると判断しやすくなります。
| デバイス種別 | 推奨される設計例 | 理由 |
|---|---|---|
| 一般社員の Windows 11 / Windows 10 端末 | フル自動化を基本にする | 感染拡大防止と SOC 負荷削減の効果が大きい |
| 経営層・機密部門の端末 | フル自動化＋アラート監視強化 | 放置リスクが高く、初動の速さが重要 |
| 開発・ビルド端末 | 専用タグでグループ化し、段階的に自動化レベルを上げる | 独自 EXE や DLL が誤検知される可能性がある |
| 本番サーバー | 対象 OS、エージェント、復旧手順を確認してから適用 | 隔離やプロセス停止が業務影響を生む可能性がある |
| レガシー端末・検証端末 | 期限付きの例外グループを作る | 例外が放置されると保護レベルが下がる |
デバイスグループで確認すべき設定変更
Microsoft Defender portal では、System > Settings > Endpoints > Device groups からデバイスグループを確認し、Remediation level を見直します。公式ドキュメントでは、デバイスグループのポリシー、とくに Remediation level 列を確認し、必要に応じてグループの作成・編集を行う流れが示されています。(Microsoft Learn)
デバイスグループは、単に端末を分類するだけの機能ではありません。Microsoft Defender for Endpoint では、デバイスグループを使って、関連するアラートやデータへのアクセス制御、グループごとの自動修復設定、調査時のフィルタリングなどを行えます。端末が複数のグループ条件に一致する場合は、最も高いランクのグループに追加される点にも注意が必要です。(Microsoft Learn)
設定確認の実務手順
| 手順 | 確認内容 | 見落としやすいポイント |
|---|---|---|
| Microsoft Defender portal にアクセス | Security Administrator 以上の権限でサインインする | 閲覧権限だけでは設定変更や承認ができない |
| Device groups を開く | 既存グループと Remediation level を確認する | 旧テナントでは半自動化のまま残っている可能性がある |
| グループ条件を確認 | デバイス名、ドメイン、タグ、OS などの条件を確認する | 条件が広すぎると意図しない端末が入る |
| ランクを確認 | 複数グループに該当する端末の優先順位を確認する | 重要端末が一般端末グループに入ると危険 |
| Entra ユーザーグループを確認 | 誰が対象デバイスを閲覧・操作できるか確認する | Entra グループ未割り当ての場合、全ユーザーからアクセス可能になる可能性がある |
| 変更後に検証 | テスト端末でアラート、調査、修復、Action center 表示を確認する | 設定変更だけで実運用確認を省くと、承認漏れに気づけない |
特にグローバル企業では、国・地域別に運用部門が分かれていることがあります。この場合、「日本拠点の端末は日本 SOC が見る」「欧州拠点は現地チームが一次確認する」といった分担に合わせて、デバイスグループと RBAC をそろえることが重要です。
Office 365 側のアラートポリシーも AIR に影響する
AIR の設定というと Endpoint 側だけを見がちですが、Microsoft Defender XDR では Office 365 のアラートやメール保護設定も重要です。Microsoft は、Exchange 管理者権限の悪用、マルウェア活動、外部・内部の脅威、データライフサイクル管理リスクなどを検出する組み込みアラートポリシーを提供しており、一部のアラートは Office 365 の自動調査と対応をトリガーできます。(Microsoft Learn)
ただし、メールとコンテンツに対する修復アクションは、端末のフル自動化と同じ感覚で扱ってはいけません。公式ドキュメントでは、メールおよびメールコンテンツに対する修復アクションは自動的には実行されず、セキュリティ運用チームによる Action center での承認を待つと説明されています。(Microsoft Learn)
Office 365 側で確認する項目
| 確認項目 | 確認すべき理由 | 実務での見直しポイント |
|---|---|---|
| Threat management カテゴリの既定アラート | 一部のアラートが AIR を開始する | 既定アラートを無効化していないか確認する |
| カスタムアラート | 既定アラートを置き換えると AIR が起動しない場合がある | カスタム化の目的と影響を棚卸しする |
| Standard / Strict プリセットセキュリティポリシー | Microsoft が推奨する保護設定の基準になる | 対象ユーザーに割り当てられているか確認する |
| Configuration analyzer | カスタムポリシーを標準・厳格設定と比較できる | 例外設定が増えすぎていないか確認する |
| ユーザー報告・ZAP・クリックアラート | AIR の開始要因になる可能性がある | 報告フローと SOC の確認手順を整える |
よくある失敗は、「Defender for Endpoint の自動化レベルを上げたから、メールもすべて自動処理される」と誤解することです。端末側の自動修復と、メール・コンテンツ側の承認待ちは分けて設計してください。
Action center は承認待ちをさばく運用の中心になる
2026年6月25日更新の公式ページでは、Action center で修復アクションを確認・管理する流れが整理されています。Action center では、保留中の修復アクションの承認、承認済みアクションの監査ログ、完了済みアクションの確認を一元的に行えます。(Microsoft Learn)
Action center には、デバイス、メールとコラボレーションコンテンツ、ID に関する保留中および完了済みの修復アクションが集約されます。Pending タブでは承認や拒否が必要なアクションを確認でき、History タブでは自動調査、手動対応、Live Response、ウイルス対策などによって実行されたアクションを監査できます。(Microsoft Learn)
Action center の運用ルール例
| 運用項目 | 推奨ルール | 理由 |
|---|---|---|
| Pending の確認頻度 | SOC の勤務シフトごとに確認する | 承認待ちを放置すると調査完了が遅れる |
| 承認基準 | 悪意あり判定、影響範囲、対象資産の重要度で判断する | 反射的な承認・拒否を防ぐ |
| 拒否基準 | 業務アプリ、開発成果物、誤検知疑いは追加調査する | 必要な業務ファイルの隔離を防ぐ |
| 取り消し手順 | History から Undo 可能なアクションを確認する | 誤検知時の復旧時間を短縮する |
| 証跡管理 | CSV エクスポートや監査ログを定期保存する | インシデントレビューや監査対応に使える |
Microsoft Learn では、保留中のアクションはできるだけ早く承認または拒否することが重要だと説明されています。また、Action center では一部の完了済みアクションを取り消すこともできますが、ファイル隔離などの取り消し操作には Security Administrator 以上の権限が必要です。(Microsoft Learn)
権限設計で失敗すると「見えるが対応できない」状態になる
AIR の運用では、設定権限、承認権限、メール修復権限を分けて確認する必要があります。公式ドキュメントでは、AIR 機能を構成するには Security Administrator 以上のロールが必要とされています。Action center での承認や拒否には、対象が Endpoint か Office 365 かによって追加の権限が必要です。(Microsoft Learn)
特に注意したいのが、メールの修復です。Office 365 のメールやコンテンツを修復するには、Security Administrator に加えて、Search and Purge ロールを持つ Email & collaboration のロールグループが必要になる場合があります。Microsoft Learn では、Email & collaboration permissions の Security Administrator ロールグループに所属しているだけでは、Action center や Microsoft Defender XDR 機能へのアクセスは付与されない点も明記されています。(Microsoft Learn)
権限確認のチェックリスト
| 担当者 | 必要な操作 | 確認すべき権限 |
|---|---|---|
| セキュリティ管理者 | AIR 設定、デバイスグループ、自動化レベルの変更 | Microsoft Entra の Security Administrator 以上 |
| SOC アナリスト | Pending アクションの確認、調査ページの閲覧 | Defender XDR / Unified RBAC の適切な閲覧・対応権限 |
| メール対応担当 | 悪意あるメールの削除、隔離、承認 | Security Administrator に加え、Search and Purge を含むロール |
| 監査担当 | History の確認、CSV エクスポート、証跡確認 | 読み取り権限と監査プロセス上のアクセス許可 |
| インシデント責任者 | 誤検知時の Undo 判断 | 取り消し可能なアクションを実行できる管理権限 |
「誰かが見ているはず」という状態は危険です。Action center の Pending を確認する担当者、承認判断を行う責任者、誤検知時に Undo できる管理者を明確にしておきましょう。
2026年9月1日までに見直すべき移行ポイント
関連する Microsoft Defender for Endpoint の公式情報では、2026年9月1日以降、Automated Investigation and Response は Microsoft Defender で独立した調査エクスペリエンスとして実行されなくなり、手動トリガーも利用できなくなると説明されています。AIR の検出と対応機能は Microsoft Defender の既定のウイルス対策保護スタックに含まれて自動的に実行され、オンデマンド調査が必要な場合はフルウイルス対策スキャンを実行する流れになります。(Microsoft Learn)
ここで誤解してはいけないのは、「AIR がなくなる」という意味ではないことです。変わるのは、独立した AIR の調査体験や手動開始に依存した運用です。したがって、影響を受けるのは次のような組織です。
| 影響を受ける運用 | 変更後に見直すこと |
|---|---|
| SOC 手順書に「Initiate Automated Investigation」を明記している | フルウイルス対策スキャン、インシデント調査、Action center 確認へ手順を更新する |
| 手動 AIR 開始を前提に教育している | 2026年9月1日以降の画面・操作に合わせてトレーニングを更新する |
| スクリプトや SOAR 連携で手動 AIR を起動している | 代替アクション、API、フルスキャン、インシデント管理フローを確認する |
| AIR の結果画面を監査証跡として使っている | Action center、インシデント、調査ページ、エクスポート運用へ切り替える |
| 例外端末だけ手動調査している | デバイスグループと自動化レベルで継続的に制御する |
移行対応は、2026年9月直前に画面変更だけを確認するのでは遅くなります。SOC の手順、管理者権限、エスカレーション基準、監査証跡の保存方法までまとめて見直す必要があります。
管理者が今すぐ確認すべきポイント
Microsoft Defender XDR の AIR 設定は、セキュリティ機能のオン・オフではなく、インシデント対応プロセスそのものに影響します。管理者は、次の順番で確認すると抜け漏れを減らせます。
ライセンスと対象範囲を確認する
公式ドキュメントでは、Microsoft 365 E5、Microsoft 365 A5、Microsoft 365 E3 と Microsoft Defender Suite アドオン、Microsoft 365 A3 と Microsoft 365 A5 Security アドオン、Office 365 E5 と Enterprise Mobility + Security E5 と Windows E5 の組み合わせなどが要件として示されています。(Microsoft Learn)
まず、自社テナントが対象ライセンスを満たしているか、Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps の構成が期待通りかを確認します。ライセンスが不足していると、画面上は一部機能が見えても、期待した自動調査や修復まで動かない場合があります。
Microsoft Defender Antivirus の状態を確認する
Endpoint 側の AIR は、Microsoft Defender Antivirus がアクティブモードまたはパッシブモードで動作している必要があります。無効化またはアンインストールされている場合、AIR は正しく機能しません。また、Windows Server 2012 R2 と Windows Server 2016 では Unified Agent が必要です。(Microsoft Learn)
サードパーティ製 EDR やウイルス対策製品と併用している環境では、Defender Antivirus のモード確認を必ず行ってください。導入済みと思っていても、実際には保護スタックが期待通りに動作していないケースがあります。
デバイスグループとタグを棚卸しする
デバイスグループは、ドメイン、デバイス名、タグ、OS プラットフォームなどで分類できます。特にグローバル環境では、地域名や部門名だけでなく、「production-server」「developer-device」「executive-device」のような運用上の意味を持つタグを使うと、自動化レベルの判断がしやすくなります。
注意点は、例外グループを作ったまま放置しないことです。検証目的で半自動化や自動応答なしにした端末は、期限、理由、承認者を記録し、定期的に見直してください。
Office 365 の既定アラートを無効化していないか確認する
Office 365 側では、ユーザー報告、ZAP、ユーザークリックアラート、疑わしいメールボックス動作などが AIR の開始に関係する場合があります。Microsoft Defender for Office 365 の公式情報では、AIR を開始する既定アラートが無効化されている場合や、カスタムアラートに置き換えられている場合、AIR がトリガーされない可能性があると説明されています。(Microsoft Learn)
カスタムポリシーが多い組織では、Configuration analyzer を使い、Standard または Strict のプリセットセキュリティポリシーとの差分を確認するのが現実的です。
Action center の承認 SLA を決める
半自動化やメール修復の承認待ちを放置すると、AIR の効果が下がります。Pending アクションは、重大度や対象資産に応じて「即時確認」「1時間以内」「当日中」などの目安を決めておくと、SOC の対応が安定します。
また、Action center の History は監査ログとしても重要です。四半期ごとのレビューで、どのアクションが自動実行され、どのアクションが承認待ちになり、どれだけ拒否・Undo されたかを振り返ると、自動化レベルの調整に使えます。
よくある設定ミスと回避策
| よくあるミス | 起きる問題 | 回避策 |
|---|---|---|
| フル自動化を怖がって全端末を半自動化にする | Pending が増え、SOC が処理しきれなくなる | 一般端末からフル自動化を適用し、例外端末だけ分ける |
| メール修復も自動実行されると思い込む | Action center の承認待ちが放置される | メール・コンテンツは承認運用を明確にする |
| 旧テナントの既定値を確認していない | 半自動化のまま期待した自動修復が動かない | デバイスグループの Remediation level を全件確認する |
| 例外デバイスグループを作りっぱなしにする | 重要端末が低い保護レベルで残る | 例外に期限、理由、責任者を設定する |
| Email & collaboration 権限だけを見ている | Action center や XDR 側で承認できない | Microsoft Entra ロールと Defender XDR 権限をセットで確認する |
| 2026年9月1日の変更を手順書に反映しない | 手動 AIR 前提の対応が使えなくなる | フルスキャン、インシデント調査、Action center 確認へ運用を更新する |
実務でのおすすめ構成例
中堅以上の企業で Microsoft Defender XDR を運用する場合、最初から完璧な自動化を狙うより、次のような段階的な構成が現実的です。
| フェーズ | 対象 | 設定・運用 |
|---|---|---|
| 初期確認 | IT 部門の検証端末、標準業務端末の一部 | フル自動化を適用し、Action center の履歴と Undo 手順を確認する |
| 展開開始 | 一般社員端末 | フル自動化を基本にし、誤検知があれば除外ではなく検出内容を分析する |
| 重要端末対応 | 経営層、財務、人事、管理者端末 | フル自動化＋アラート監視強化で初動を速くする |
| サーバー対応 | 本番サーバー、業務アプリサーバー | 影響評価後に半自動化またはフル自動化を選択する |
| 定着運用 | 全社 | 月次で Pending、History、拒否、Undo、例外グループをレビューする |
ポイントは、「自動化を弱める」よりも「分類して制御する」ことです。自動修復のリスクを恐れて全体を半自動化にすると、結果的に承認待ちが増え、対応速度が落ちます。業務影響が大きい資産だけを明確に分け、それ以外はフル自動化を基本にするほうが、セキュリティ運用としては安定しやすくなります。
まとめ：Microsoft Defender の AIR は設定確認と承認運用をセットで見直す
Microsoft Defender XDR の「Configure automated investigation and response capabilities」で確認すべき本質は、AIR を使うかどうかではなく、自動化レベル、アラートポリシー、Action center、権限、2026年9月1日以降の運用変更をまとめて整えることです。
まずは、Microsoft Defender portal でデバイスグループの Remediation level を確認し、一般端末はフル自動化を基本に、サーバーや開発端末はタグとグループで分離します。次に、Office 365 の既定アラートとプリセットセキュリティポリシーを確認し、メール修復の承認フローを Action center に集約します。最後に、手動 AIR に依存している手順書や SOAR 連携を棚卸しし、2026年9月1日までにフルウイルス対策スキャンやインシデント調査中心の運用へ更新してください。
AIR は、設定した瞬間に運用が楽になる機能ではありません。正しく設計すれば SOC の負荷を下げ、初動対応を速められますが、承認待ちや例外グループを放置すると逆にリスクになります。今日確認すべき最初の一歩は、Device groups の Remediation level と Action center の Pendingです。
コメント