Microsoft Defender Antivirusの除外設定は、「検知されたくないものを広く外す」ための設定ではありません。結論から言うと、誤検知、パフォーマンス低下、アプリ互換性の問題が実際に確認できた場合に限り、対象をできるだけ狭く指定して管理するべき例外設定です。
2026年5月22日更新のMicrosoft Learn関連情報では、Microsoft Defender for Endpointにおける除外設定の考え方、代替策、影響範囲が整理されています。一方、IntuneでMicrosoft Defender Antivirusのカスタム除外を構成する個別手順ページは、Microsoft Defender for Endpoint Plan 1／Plan 2向けのWindows環境を対象とした情報として公開されています。管理者がまず行うべきことは、新しい除外を増やすことではなく、既存の除外が本当に必要かを棚卸しすることです。(Microsoft Learn)
Microsoft Defender Antivirusの除外設定は最小限にするのが原則
Microsoft Defender Antivirusでは、ファイル、フォルダー、拡張子、特定プロセスが開いたファイルをスキャン対象から除外できます。これらは「カスタム除外」と呼ばれ、スケジュールスキャン、オンデマンドスキャン、リアルタイム保護に影響します。ただし、プロセスが開いたファイルの除外はリアルタイム保護にのみ適用されます。(Microsoft Learn)
重要なのは、除外設定がセキュリティ上の保護ギャップになる点です。Microsoftの公式情報でも、除外は慎重に使うべきものとされています。除外されたファイルやフォルダーに関連するイベントは、Microsoft Defender Antivirusがブロック、修復、検査できる範囲に影響する可能性があります。特にプロセス除外は、Network Protectionや攻撃面の縮小ルール、いわゆるASRルールの検査・適用にも影響するため、安易に指定してはいけません。(Microsoft Learn)
管理者の判断基準はシンプルです。
「問題が起きるかもしれない」ではなく、「問題が再現し、原因調査の結果、除外が最小リスクの対策だと説明できる」場合だけ設定します。
2026年5月22日更新情報で押さえるべきポイント
2026年5月22日更新の除外設定概要では、除外はトラブル対応の最初の選択肢ではなく、根本原因を把握した後に検討する手段として位置付けられています。誤検知であればファイル提出やアラート抑制、パフォーマンス問題であれば診断データやパフォーマンスログの確認が先です。(Microsoft Learn)
| 確認ポイント | 管理者が取るべき対応 |
|---|---|
| 除外は原則不要 | 既存ポリシーを棚卸しし、理由が不明な除外を削除候補にする |
| 誤検知対応 | すぐ除外せず、Microsoftへのファイル提出やアラート抑制を検討する |
| パフォーマンス問題 | Performance Analyzerやログで影響箇所を特定してから除外する |
| アプリ互換性 | アプリ単位で原因を確認し、フォルダー全体やプロセス全体の除外を避ける |
| プロセス除外 | ASRルールやNetwork Protectionへの影響を評価してから適用する |
| 展開方法 | 可能であればIntuneで集中管理し、スコープタグと割り当て先を明確にする |
今回の実務上の変更点は、「除外設定を追加する手順」そのものよりも、「除外をどこまで許可するか」「誰が承認するか」「いつ見直すか」を明確にする点にあります。従来からのPowerShell、グループポリシー、Configuration Managerによる管理を続けている環境でも、Microsoft Defender for Endpointの運用では、除外を一元的に監査できる状態にすることが重要です。
影響範囲：どの除外が何に効くのか
Microsoft Defender Antivirusの除外設定は、種類によって影響範囲が異なります。特に「プロセス除外」は名前から誤解されやすく、プロセス自体を除外するのではなく、そのプロセスが開いたファイルをスキャン対象から外す設定です。プロセス自体を除外したい場合は、ファイルまたはパスの除外として実行ファイルを指定します。(Microsoft Learn)
| 除外タイプ | 除外される対象 | 主な用途 | 注意点 |
|---|---|---|---|
| 拡張子の除外 | 指定した拡張子を持つすべてのファイル | 特定形式の大量ファイルで検証済みの性能問題がある場合 | .exe、.dll、.ps1、.js、.zipなどを広く除外するのは危険 |
| パスの除外 | 指定したファイルまたはフォルダー配下 | アプリの作業フォルダー、キャッシュ、データ領域など | C:\やC:\Users\のような広すぎる指定は避ける |
| プロセスが開いたファイルの除外 | 指定プロセスが開いたファイル | 特定アプリのI/Oでリアルタイム保護の影響が確認された場合 | スケジュールスキャンやオンデマンドスキャンには適用されない |
| コンテキスト付き除外 | スキャン種別、トリガー、プロセスなどの条件付き除外 | 影響範囲をさらに狭めたい場合 | 条件指定の構文やバージョン要件を確認する |
| サーバーロールの自動除外 | Windows Serverの特定ロール関連ファイル | Windows Server 2016以降の標準ロール | サードパーティ製アプリや独自配置のワークロードは別途確認が必要 |
除外の範囲を広げるほど、攻撃者に悪用される余地も広がります。まずは「拡張子」より「フルパス」、「プロセス名のみ」より「フルパスのプロセス」、「常時除外」より「条件付き除外」を優先するのが安全です。
Intuneで確認すべきMicrosoft Defender Antivirus除外設定
Microsoft Intuneでカスタム除外ポリシーを作成する場合は、Intune管理センターの「Endpoint security」から「Antivirus」を開き、AV policiesでポリシーを作成します。プラットフォームはWindows、プロファイルは「Microsoft Defender Antivirus exclusions」を選択します。(Microsoft Learn)
設定画面では、主に次の3つを確認します。
| Intuneの設定項目 | 内容 | 設定時の判断基準 |
|---|---|---|
| Excluded extensions | 拡張子単位の除外 | 全端末・全パスに効くため、原則として最後の手段にする |
| Excluded paths | ファイルまたはフォルダーの除外 | 可能な限りフルパスで指定し、アプリ単位に分ける |
| Excluded processes | 指定プロセスが開いたファイルの除外 | プロセス自体は除外されない点を理解して使う |
既存ポリシーを変更する場合は、IntuneのAntivirusポリシー一覧から「Microsoft Defender Antivirus exclusions」タイプのポリシーを開き、Configuration settingsを編集します。CSVのインポートやエクスポートも利用できるため、既存除外の棚卸しや移行作業では、まず現在のリストをエクスポートしてレビューするのが実務的です。(Microsoft Learn)
ポリシー名と説明欄に残すべき情報
除外設定は、後から見たときに「なぜ必要なのか」が分からなくなりやすい設定です。ポリシー名や説明欄には、少なくとも次の情報を残しておきます。
| 項目 | 例 |
|---|---|
| 対象アプリ | 会計システム、CIビルドサーバー、業務DB連携ツール |
| 対象環境 | 本番、検証、開発、特定部署 |
| 除外理由 | 誤検知、パフォーマンス問題、ベンダー推奨、暫定対応 |
| 根拠 | チケット番号、ベンダー文書、検証ログ、承認者 |
| 見直し日 | 四半期ごと、次回バージョンアップ後、暫定期限 |
たとえば、AV-Exclusion-ContosoApp-Prod-Windowsのように、用途、アプリ名、環境、OSが分かる名前にしておくと、監査時に追跡しやすくなります。
PowerShellやローカル設定を使う場合の注意点
既存の除外設定を確認する代表的な方法は、管理者権限のPowerShellでGet-MpPreferenceを実行することです。Exchange Serverの除外設定を監査する場合も、Microsoftは昇格したPowerShellからGet-MpPreferenceを使う方法を案内しています。(Microsoft Learn)
$p = Get-MpPreference
$p.ExclusionPath
$p.ExclusionExtension
$p.ExclusionProcessただし、HideExclusionsFromLocalAdminsが有効な環境では、除外設定がGet-MpPreferenceやレジストリエディターから見えない場合があります。この機能は既存の除外を削除するものではなく、ローカル管理者から見えにくくするための保護設定です。(Microsoft Learn)
PowerShellで除外を追加する場合は、Add-MpPreferenceを使います。Set-MpPreferenceは既存リストを置き換える動作になるため、移行作業中に既存の除外を誤って上書きしないよう注意が必要です。(Microsoft Learn)
Add-MpPreference -ExclusionPath "C:\Program Files\ContosoApp\Data"
Add-MpPreference -ExclusionExtension ".sample"
Add-MpPreference -ExclusionProcess "C:\Program Files\ContosoApp\contoso-worker.exe"個別パスが除外対象か確認したい場合は、MpCmdRun.exe -CheckExclusion -Pathを使えます。検証環境でポリシー展開後に確認するコマンドとして有効です。(Microsoft Learn)
MpCmdRun.exe -CheckExclusion -Path C:\Data\TestグループポリシーやConfiguration ManagerからIntuneへ移行する際の注意点
オンプレミス中心の環境では、グループポリシーやConfiguration Managerで除外設定を配布しているケースがあります。Microsoft Defender Antivirusでは、既定ではローカル管理者によるPowerShellやWMIの変更が、グループポリシー、Configuration Manager、Intuneで配布された除外リストとマージされます。ただし、競合がある場合はグループポリシーが優先されます。(Microsoft Learn)
移行時は、次の順番で進めると失敗しにくくなります。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 既存設定の収集 | GPO、Intune、Configuration Manager、PowerShell、ローカル設定を確認 | ローカル管理者が追加した除外を見落とす |
| 重複と広すぎる除外の整理 | 同じパス、類似フォルダー、拡張子単位の除外を洗い出す | 互換性維持の名目で古い除外を残し続ける |
| アプリ・サーバー単位に分割 | IIS、SQL Server、Exchange、業務アプリなどでリストを分ける | 複数ワークロードを1つの除外リストにまとめる |
| Intuneポリシー化 | スコープタグ、割り当てグループ、除外対象を明確にする | All devicesへ即時展開して影響範囲が読めなくなる |
| パイロット展開 | 検証端末、代表ユーザー、対象サーバー群に段階展開 | ロールバック手順を決めずに本番展開する |
| 監査と削除 | 不要な除外を削除し、理由と期限を記録 | 一度作った除外を永久設定として扱う |
移行の目的は「管理ツールを変えること」ではなく、「除外が必要な理由と影響範囲を説明できる状態にすること」です。Intuneへ集約する場合も、既存のGPOが残っていると意図したポリシーが適用されないことがあるため、優先順位と競合を必ず確認してください。
避けるべき除外設定の具体例
Microsoftの「Common mistakes to avoid when defining exclusions」では、攻撃者に悪用されやすいフォルダー、拡張子、プロセスを除外しないよう注意喚起されています。代表例として、システムドライブ全体、C:\、C:\Temp、C:\Users\、Windowsの一時フォルダー、実行ファイルやスクリプト系の拡張子、cmd.exeやpowershell.exeなどの汎用プロセスが挙げられています。(Microsoft Learn)
| 避けたい設定 | なぜ危険か | 代替案 |
|---|---|---|
C:\や%systemdrive%を除外 | 端末全体に近い範囲が保護対象外になる | 対象アプリのデータフォルダーだけを指定 |
C:\Users\*を除外 | ユーザープロファイル配下は攻撃者が悪用しやすい | 特定アプリの固定パスへ移動し、範囲を限定 |
.exeや.dllを拡張子除外 | 実行ファイル全般が検査されにくくなる | ベンダー指定のファイルをフルパスで指定 |
powershell.exeやcmd.exeをプロセス除外 | 管理ツールや攻撃ツールとして広く使われる | 対象アプリの専用プロセスをフルパスで指定 |
Filename.exeのようなファイル名だけの除外 | 同名の悪意あるファイルも対象になり得る | C:\Program Files\Vendor\App\Filename.exeのように完全パスで指定 |
特に開発環境では、「ビルドが遅いからnode.exeやdotnet.exeを丸ごと除外する」「ワークスペース全体を除外する」といった設定をしがちです。しかし、ビルドツール、スクリプト実行環境、Officeアプリ、シェルは攻撃経路にもなります。除外するなら、ツールそのものではなく、検証済みの一時出力フォルダーやキャッシュフォルダーに限定するべきです。
環境変数とワイルドカードの落とし穴
Microsoft Defender AntivirusサービスはLocalSystemアカウントのシステムコンテキストで動作します。そのため、%USERPROFILE%のようなユーザー環境変数は、管理者や利用者が想定するユーザーフォルダーではなく、システムプロファイルとして解釈される可能性があります。公式情報でも、フォルダーやプロセス除外ではユーザー環境変数をワイルドカードとして使わず、システム環境変数またはNT AUTHORITY\SYSTEMで動作するプロセスに適用される環境変数を使うよう案内されています。(Microsoft Learn)
ワイルドカードにも注意が必要です。*は便利ですが、指定範囲が広がりやすく、複数階層のフォルダーを意図せず含めることがあります。また、ドライブレターの代わりにワイルドカードを使うことはできません。移行時には、既存のワイルドカード指定が現在のフォルダー構成に合っているかを必ず確認してください。(Microsoft Learn)
コンテキスト付き除外を使うべき場面
通常の除外では範囲が広すぎる場合、コンテキスト付きのファイル／フォルダー除外を検討できます。これは、スキャン種別、スキャントリガー、プロセス、ファイルかフォルダーかといった条件を加えて、除外が適用される場面を限定する仕組みです。Microsoftの公式情報では、Windows上のMicrosoft Defender Antivirusで、より具体的な条件下だけスキャンしないようにする機能として説明されています。(Microsoft Learn)
たとえば、特定のドキュメントを常に除外するのではなく、オンアクセススキャン時だけ除外する、といった指定ができます。
c:\documents\design.doc\:{PathType:file,ScanTrigger:OnAccess}また、特定プロセスがアクセスした場合だけ除外する指定も可能です。
c:\documents\design.doc\:{Process:"winword.exe"}コンテキスト付き除外は、パフォーマンス問題を緩和しつつ保護低下を最小化したい場面に向いています。ただし、誤検知そのものを恒久的に解決する手段としては適していません。誤検知の場合は、Microsoftへのファイル提出や、必要に応じたカスタム許可インジケーターの検討が先です。(Microsoft Learn)
Exchange Serverやサーバーワークロードでの確認ポイント
Exchange Server、SharePoint Server、SQL Serverなどのサーバーワークロードでは、パフォーマンスや互換性のためにウイルス対策の除外が必要になる場合があります。ただし、Windows Serverの自動除外は、Windows Serverの標準ロールや機能を対象とするものであり、後から導入したアプリケーションや独自配置のワークロードまで自動的に最適化してくれるわけではありません。(Microsoft Learn)
Exchange Serverについては、多くの組織がパフォーマンス上の理由でフォルダーを除外しているものの、Microsoftは除外を監査し、パフォーマンスに影響せず削除できるか評価することを推奨しています。除外を削除できない場合でも、Microsoft Defender AntivirusのクイックスキャンではExchangeのディレクトリとファイルが除外に関係なくスキャンされる点を理解しておく必要があります。(Microsoft Learn)
サーバー運用では、次の3点を確認してください。
- ベンダー公式ドキュメントに基づく除外か
- 既定のインストールパスから変更していないか
- アプリ単位で除外リストを分割しているか
複数ワークロードを1つの除外リストにまとめると、後から不要な除外を削除しにくくなります。IIS、SQL Server、Exchange、バックアップソフト、業務アプリは、できるだけ別ポリシーとして管理しましょう。
開発者が確認すべきビルド・CI環境の注意点
開発者やDevOps担当者にとって、Microsoft Defender Antivirusの除外設定はビルド速度に関係することがあります。大量の小さなファイルを生成するビルド、パッケージ復元、テスト実行、コンテナイメージ作成などでリアルタイム保護の影響が見えるケースがあるためです。
ただし、開発端末やCIサーバーはスクリプト、依存パッケージ、認証情報、ビルド成果物が集まる場所でもあります。除外の範囲を広げると、侵害時の検知機会を減らします。
| よくある要望 | 危険な設定例 | 現実的な代替案 |
|---|---|---|
| ビルドを速くしたい | C:\Users\dev\source\*を丸ごと除外 | 対象プロジェクトの一時出力フォルダーだけを除外 |
| npmやNuGetの復元が遅い | node.exeやdotnet.exeをプロセス名だけで除外 | 固定パスのキャッシュやビルド出力先を検証して限定 |
| CIエージェントが重い | エージェント実行フォルダー全体を除外 | ワークスペース、成果物、キャッシュを分けて必要箇所だけ指定 |
| 社内ツールが誤検知される | 実行ファイル名だけを除外 | Microsoftへ提出し、必要なら署名・ハッシュ・フルパスで制御 |
開発チーム側でできる最も効果的な対策は、ビルド出力、依存パッケージキャッシュ、ソースコード、シークレットを同じフォルダーに混在させないことです。フォルダー構成が整理されていれば、除外対象を最小化できます。
展開前に使える判断フロー
Microsoft Defender Antivirusの除外設定を追加する前に、次の流れで判断すると、不要な保護低下を避けやすくなります。
| ステップ | 確認すること | 次の判断 |
|---|---|---|
| 事象の確認 | 誤検知、性能低下、互換性問題のどれか | 再現条件が不明なら除外しない |
| 原因調査 | アラート、ログ、パフォーマンスデータ、対象ファイル | Defender以外が原因なら除外しない |
| 代替策の検討 | ファイル提出、アラート抑制、アプリ更新、ベンダー修正 | 代替策で解決するなら除外しない |
| 除外範囲の設計 | 拡張子、パス、プロセス、条件付き除外 | 最も狭い範囲を選ぶ |
| 検証展開 | 少数端末、検証サーバー、限定グループ | 問題がなければ段階展開 |
| 監査 | 所有者、理由、期限、影響範囲を記録 | 定期的に削除可否を確認 |
判断に迷う場合は、まず「その除外を攻撃者が悪用できるか」を考えるとよいでしょう。悪用できる範囲が広い設定ほど、承認レベルを上げ、期限付きにするべきです。
管理者が今すぐ確認すべきチェックリスト
最後に、既存環境で確認すべき項目を整理します。
- Intune、GPO、Configuration Manager、PowerShell、ローカル設定の除外をすべて棚卸しする
C:\、C:\Users\、一時フォルダー、実行ファイル拡張子など広すぎる除外を洗い出す- プロセス除外がASRルールやNetwork Protectionに与える影響を確認する
Set-MpPreferenceによる上書き事故を避け、既存リストをバックアップするHideExclusionsFromLocalAdminsや改ざん防止の有無を確認する- アプリ、サーバーロール、環境ごとにポリシーを分割する
- 除外理由、承認者、期限、検証結果をポリシー説明欄やチケットに残す
- 四半期ごと、またはアプリ更新後に削除できる除外がないか見直す
Microsoft Defender Antivirusの除外設定は、設定すれば問題が解決する便利なスイッチではありません。むしろ、設定後の監査、見直し、削除まで含めて運用するセキュリティ例外です。まずは現在の除外リストをエクスポートし、「理由が説明できない除外」「範囲が広すぎる除外」「期限がない暫定除外」を削除候補として整理するところから始めましょう。
コメント