オンプレミスでSymantec Endpoint Protection（SEP）を運用していると、更新コストや運用負荷からMicrosoft Defenderへの置き換えを検討するケースが増えています。特にインターネット非接続でSCCM（Configuration Manager）運用の環境では、対応OS・定義更新の配布・監視の作り方を押さえないと移行が詰まります。
結論：置き換え可否は「OS世代」と「管理・更新の仕組み」で決まる
最初に結論を整理します。SEPからMicrosoft Defenderへ置き換える場合、Windows 10／Windows Server 2016以降はOS標準のMicrosoft Defender Antivirus（旧称Windows Defender）を活かしやすく、SCCM（Microsoft Configuration Manager/Endpoint Configuration Manager）でポリシー配布と状態監視まで完結させやすい領域です。一方で、Windows Server 2003やWindows 7、Windows Server 2008 R2／2012 R2は「Defenderに一括置換」というより、更改（OSアップグレード）を含む段階移行で考えるのが安全です。
また、ネット非接続のオンプレ環境では、Microsoft 365のポータルで見るDefender for Endpoint（EDR）の強みをそのまま得るのは難しく、目的を「AV（ウイルス対策）の置き換え」と「SCCMで回る運用」に絞ると設計がブレません。Defender for Endpointはオンボードやクラウドサービスとの通信が前提で、デバイス側のインターネット接続が必要であることが示されています。
まず整理：ここで言う「Microsoft Defender」は3つに分かれる
「Defenderに置き換える」と言ったとき、現場では名称の混同が起きがちです。オンプレ・インターネット非接続でSCCM運用という条件では、どこまでをDefenderで賄うのかを先に定義しておくと、移行計画のズレを防げます。
| 名称 | 役割 | インターネット前提 | この構成で現実的に使える範囲 | ポイント |
|---|---|---|---|---|
| Microsoft Defender Antivirus | アンチウイルス（リアルタイム保護、スキャン、検知/隔離） | 不要（ただしクラウド連携機能は別） | Windows 10/11、Windows Server 2016以降を中心に運用可能 | 定義（Security intelligence）とプラットフォーム更新を社内配布できれば、オフライン運用の中核になる |
| Microsoft Defender for Endpoint（MDE） | EDR（侵害調査、可視化、対応、脆弱性管理など） | 基本は必要 | ネット非接続ではメリットを活かしにくい（例外的に中継・プロキシ設計ができるなら検討余地） | Windows 7/Server 2012 R2など「古いOSを守る」文脈で話題に上がるが、クラウド接続がボトルネックになりやすい |
| SCCMの「Endpoint Protection」機能 | DefenderまたはSCEP（System Center Endpoint Protection）向けのポリシー配布、状態監視、アラート、定義更新の配布 | 不要（ただし更新取得はサーバー側が必要） | オンプレでの“管理・監視の土台”として活用 | Endpoint Protection pointロール、アンチマルウェアポリシー、定義更新ソースの設定などを整える |
SCCMのEndpoint Protectionは、クライアントを一括管理するための機能で、アンチマルウェアポリシーやWindows Defender Firewallの基本管理も行えます。クラウド前提のEDRとは役割が違うため、要件を分けて考えるのがコツです。
対応OSの現実：一律にDefenderへ寄せるのが難しい理由
ご相談の前提では、サーバーとクライアントに複数世代のOSが混在しています。このとき重要なのは「Defenderが入るか」だけでなく、サポートされる形で運用できるか（管理手段・更新手段・更改計画と矛盾しないか）です。
OS別の目安（置き換え判断の早見表）
| OS | Defender Antivirusの位置づけ | オフライン＋SCCM運用での現実解 | 推奨アクション |
|---|---|---|---|
| Windows 10 Enterprise/Pro | OS標準のAVとして利用可能 | SEPをアンインストールしてDefenderへ寄せやすい | Defenderを有効化し、SCCMでポリシー/定義更新/監視を整備 |
| Windows Server 2016 / 2019 | サーバー向けDefender Antivirusが利用可能（2016以降は標準で利用可能） | サーバー台数が多いほど「除外設計」と「更新の安定化」が重要 | 役割別に除外テンプレを作り、段階的にSEPを撤去 |
| Windows Server 2012 R2 | 条件付き（Defender for Endpointの“modern unified solution”でのオンボードなど） | ネット非接続だと条件を満たしにくい。Defenderへ“単純置換”はしにくい | 可能ならOS更改（2016+へ）。更改までSEP継続や分離運用を検討 |
| Windows Server 2008 R2 / Windows 7 | MDE文脈ではMMA（Microsoft Monitoring Agent）＋SCEP（System Center Endpoint Protection）などが前提になりやすい | Defender Antivirus単体での統一運用は現実的ではない | 更改を最優先。残す場合はネット分離・権限最小化・持ち込み制御を強化 |
| Windows Server 2003 | 対象外（現代的なDefender運用の前提を満たせない） | “AVを何にするか”以前に延命リスクが大きい | 更改計画（仮想化移行/アプリ更改）を最優先。暫定は隔離と監視を強化 |
Microsoftの公開情報でも、Microsoft Defender Antivirusをサーバーで利用できるOSは「Windows Server 2016以降」などが中心で、2012 R2は特定条件が必要とされています。またDefender for Endpointの最小要件にはWindows 7 SP1やWindows Server 2008 R2 SP1が含まれますが、これはEDR側（MMAなど）を前提にした話であり、オフライン環境では設計上の制約が出やすい点に注意が必要です。
加えて、Windows 7の「Windows Defender」はWindows 10のDefender Antivirusとは別物で、当時はスパイウェア対策中心として扱われていました。OSのサポート終了も踏まえると、AVの製品置換だけで解決する課題ではありません。
見落としがち：SCCM（ConfigMgr）の“サポートOS”が移行設計を縛る
オンプレで管理を完結させるなら「SCCMで管理できるか」がもう一つの制約条件になります。Configuration Manager（current branch）のサポート対象は、クライアントOSとしてWindows 10/11、サーバーOSとしてWindows Server 2012/2012 R2以降が中心です。Windows 7やWindows Server 2008/2008 R2は、ESUの更新配布など限定シナリオを除き、一般機能としてのサポート対象外である点が明記されています。
もし現在「Windows 7やServer 2003もSCCMで管理している」のであれば、実体としては旧版SCCM（または別ツール）を併用している可能性が高く、Defender移行と同時に“管理基盤の世代差”も顕在化します。移行計画では、端末側だけでなくSCCM側のバージョン、SUP/WSUSの構成、配布ポイントの帯域なども含めて棚卸ししましょう。
インターネット非接続での定義配布：SCCMで“社内WSUS化”するのが基本
オフライン環境で一番詰まりやすいのが「ウイルス定義（Security intelligence）をどう配布するか」です。結論から言うと、SCCM（Software Updates / WSUS連携）で更新を取得し、社内へ配布する設計が最も運用に乗りやすいです。SCCMにはEndpoint Protection向けの定義更新を配布する手順が用意されています。
Defenderの更新は“定義だけ”ではない
Defenderは「定義（Security intelligence）」だけ更新していれば良い、という設計になりがちですが、実務ではプラットフォーム更新も重要です。Microsoftの資料では、Defender Antivirusには月次のプラットフォーム更新（KB4052623）が必要で、配布方法としてWSUSやMicrosoft Configuration Manager、UNC共有が挙げられています。
| 更新の種類 | 主な内容 | 推奨頻度の目安 | オフライン環境での配布方法 |
|---|---|---|---|
| Security intelligence updates（定義） | マルウェア検知用のシグネチャ/知能情報 | できれば毎日（複数回が理想） | SCCMのSoftware Updates（ADR）で自動配布／代替でUNC共有 |
| Engine updates（エンジン） | 検知エンジンの改善 | 月次 | 定義更新に含まれる形で配布されるケースが多い |
| Platform updates（プラットフォーム） | Defender本体（プラットフォーム）の更新 | 月次 | WSUS/Configuration Managerで配布、またはUNC共有 |
なお、Defenderにはクラウド連携（cloud-delivered protection/MAPS）もありますが、これはインターネット接続が必要とされています。ネット非接続環境では、このクラウド側の恩恵は期待しにくいため、定義更新の新鮮さとASRなどの抑止策でカバーする発想が現実的です。
「定義は更新しているのに検知が弱い／管理画面に整合しない」といった事象は、プラットフォーム更新の欠落が原因になることもあります。SEPから移行するタイミングで、定義＋プラットフォーム更新を“同じ配布レーン”で回すことを最初から設計に入れておくと失敗しにくいです。
更新ソース（Fallback order）を決める：オフラインは「社内→社内」の順で逃げ道を作る
Defenderの更新は、どこからダウンロードするか（ソース）と、いつ適用するか（スケジュール）を分けて設計できます。Microsoftの資料では、更新ソースとしてMicrosoft Update、WSUS、Microsoft Endpoint Configuration Manager、ネットワークファイル共有など複数の選択肢があり、優先順位（fallback order）を決めて“古い場合は次のソースへ”と切り替える考え方が説明されています。
今回の前提（端末は原則インターネットへ出ない）なら、推奨の考え方は次のとおりです。
- 一次：SCCM（SUP/DP経由のSoftware Updates）
- 二次：UNC共有（ファイルサーバー上の定義/更新ファイル）
- （端末が外へ出ないなら）Microsoft Updateは入れない、または最下位にして事故を防ぐ
また、古いOSが混在する環境では「署名方式（SHA-2）に対応していないと定義更新が取れない」など、更新以前の前提条件で詰まることがあります。Microsoftの資料でも、セキュリティインテリジェンス更新とプラットフォーム更新がSHA-2署名で提供される点が示されており、レガシーOSは事前パッチが重要になります。
SCCMで定義更新を配布する具体手順（ADRの設定ポイント）
SCCMでは、Software UpdatesのAutomatic Deployment Rules（ADR）で定義更新を自動配布できます。Microsoftの手順では、分類（Definition Updates）と製品（Windows Defender for Windows 10 and later など）を条件にして更新を拾い、SUP同期のたびにADRを実行する構成が案内されています。
- Software Library > Software Updates > Automatic Deployment Rules からADRを作成
- 検索条件で Update Classification = Definition Updates を指定
- 製品は環境に合わせて選択（例：Windows Defender for Windows 10 and later、古いOSが残る場合は System Center Endpoint Protection for Windows 8.1 and earlier など）
- 評価スケジュールは「SUP同期後に実行」を基本にする
- 配布パッケージは、可能なら定義更新専用にして小さく保つ（DPへの複製が速くなる）
- ユーザー通知は非表示（サイレント）で回し、期限は「可能な限り早く」を基本にする
定義更新は頻度が高いため、手順内では「エラーのみ」を選んで状態メッセージの量を抑え、SCCMサーバー負荷を下げるといった工夫も示されています。100台規模でも、運用が長期化するとサーバー負荷やDB肥大が効いてくるため、最初から“運用を軽くする設定”を意識しておくと安心です。
サーバーでは「Windows Updateサービス」が止まっていると更新が詰まることがある
オフライン環境では「端末はインターネットに出ないからWindows Updateは不要」として、Windows Updateサービスを止めているケースがあります。しかし、Microsoftの手順でも、セキュリティインテリジェンス更新を得るためにWindows Updateサービスが必要であることや、WSUSを使う場合はDefenderのSecurity intelligence updatesを承認することが説明されています。SCCM/WSUSで配布する場合でも、更新適用の土台となるサービス状態は要確認です。
最終手段：UNC共有＋コマンドで“手動更新レーン”を用意する
SUP同期が止まった、DPが配布できない、といった事象は「非接続環境ほど復旧が遅れやすい」ため、運用設計として“最終手段”を準備しておくと事故が小さくなります。Microsoftの資料では、Defenderの定義更新をコマンドで実行し、UNC共有から取得する例も示されています（例：MpCmdRun.exeのSignatureUpdateで共有パスを指定）。
この手段は常用ではなく、あくまで障害時の復旧・暫定対応として位置付け、通常運用はSCCMで回すのがおすすめです。
SCCMでの管理・監視：クラウドなしでも“運用として回す”ための要点
インターネット非接続のオンプレ環境では、Microsoft 365のセキュリティポータルを使った可視化が難しいため、SCCMで状態監視・アラート・レポートを作り込むことが移行成功の鍵になります。Endpoint Protectionは、Configuration Manager階層でのアンチマルウェアポリシー管理やFirewall管理などを提供します。
まず必要になるSCCM側の構成要素
| 要素 | 目的 | メモ |
|---|---|---|
| Endpoint Protection point（サイト システム ロール） | Endpoint Protection機能を使う前提 | 階層の最上位（CASまたは単一プライマリ）に1台だけ配置が前提 |
| Software Update Point（SUP） | Defenderの定義/プラットフォーム更新を取得して配布 | オフライン配布の肝。同期スケジュールと監視を固める |
| Distribution Point（DP） | 社内の端末へ更新を配布 | 拠点がある場合はDP配置と帯域設計が効く |
| レポート/アラート（Reporting/Alerts） | 検知・未更新・ポリシー非準拠の可視化 | “毎朝見るダッシュボード”を決めると運用が安定する |
Endpoint Protection pointロールは、Endpoint Protectionを利用するために事前にインストールが必要で、階層内で1台のみ・最上位に配置することが求められます。
SCCMで見えるようになる代表的な監視項目
クラウドEDRのような高度な調査ビューはなくても、AV運用として重要なKPIはSCCMで押さえられます。特に「未更新」と「保護無効」は、インターネット非接続環境でも事故につながりやすいので、アラート条件を先に決めておくのがおすすめです。
| 監視項目 | 何が分かるか | アラート基準の例 |
|---|---|---|
| リアルタイム保護の有効/無効 | Defenderが実際に守れているか | 無効を検知したら即時通知 |
| 定義の更新日時/バージョン | “古い定義”で止まっていないか | 72時間以上更新なしで警告、7日で重大 |
| 検知履歴（脅威名、処置結果） | 感染や持ち込みの兆候 | 隔離失敗/再発を重大扱い |
| スキャン実行状況 | 定期スキャンが回っているか | フルスキャン未実施が一定期間続けば是正 |
| ポリシー適用状況 | 除外/スケジュールなどの統制 | “例外端末”を棚卸し対象にする |
オフライン環境で不足しがちな部分を補う：ログ設計と運用ルール
Defender for Endpointのような調査ポータルが使えない場合、「検知後に何を根拠に判断するか」が弱点になりがちです。そこで、オフライン環境でも回る形でログの集約と運用ルールを決めておくと、SEPから移行しても現場の不安が減ります。
- 検知イベントの一次情報：SCCMの検知情報＋端末のイベントログ
- 二次情報（感染範囲の推定）：端末のプロセス実行履歴、共有フォルダーアクセス、USB接続履歴など
- 対応フロー：隔離→ネットワーク隔離（可能なら）→端末調査→復旧→再発防止（持ち込み経路の対策）
オンプレのみの環境では“見えないから不安”になりやすいので、最初から「検知が出たらどこを見るか」を文書化し、運用に組み込みましょう。
ランサムウェア対策をオンプレで強化する：Controlled Folder AccessとASR
AVの置き換えだけでは、ランサムウェアや侵入後の横展開を止めきれないケースがあります。Windows 10/Server 2016以降が対象になるなら、Defenderの機能としてControlled folder access（コントロールされたフォルダー アクセス）やAttack Surface Reduction（ASR）ルールを検討する価値があります。
Controlled folder accessはSCCMから有効化できる
Controlled folder accessは、重要フォルダーへの不審なアプリの書き込みを抑止し、ランサムウェアによる暗号化被害を減らすための機能です。Microsoftの手順では、Configuration Managerの「Windows Defender Exploit Guard」からポリシーを作成し、Controlled folder accessを設定して配布できます。
ただし、いきなり“ブロック”で入れると業務アプリが止まることがあります。まずは監査（Audit）で影響を可視化し、許可リスト（許可するアプリ、保護するフォルダー）を固めてから段階的にブロックへ移行するのが現実的です。
ASRルールは「監査→ブロック」で段階導入する
ASRは攻撃の入口になりやすい挙動（Officeマクロ、資格情報の窃取、スクリプト悪用など）を抑止する仕組みです。Configuration ManagerからASRルールのポリシーを作成して配布できるため、オフライン環境でも統制が可能です。
| 導入ステップ | 狙い | 実務ポイント |
|---|---|---|
| 監査（Audit）で適用 | 業務影響と検知傾向を把握 | 監査ログの“多い端末/部署”を先に洗う |
| 限定コレクションでブロック | 影響範囲を小さくして本番テスト | IT部門端末→一部業務→全体の順に広げる |
| 全体にブロック展開 | 攻撃面の削減を本格化 | 例外申請フローと、例外の棚卸し周期を決める |
SEPからDefenderへ移行する実務手順（SCCM運用を前提にした型）
ここからは「作業として事故を起こしにくい」移行の型を、SCCM運用を前提にまとめます。ポイントは、SEPを外した瞬間にDefenderが確実に有効化され、定義更新が回り、監視が上がる状態を先に作ることです。
移行フェーズと成果物（チェックリスト）
| フェーズ | やること | 成果物 | 失敗しやすい点 |
|---|---|---|---|
| 現状把握 | OS/役割/SEP設定/ネット接続性を棚卸し | 台帳、分類（移行可/要更改/要分離） | “古いOSが想定より多い”が後から判明 |
| 基盤準備 | SCCM Endpoint Protection/SUP/DP/アラート整備 | ポリシー、ADR、監視ダッシュボード | 更新同期の失敗を見逃すと全体が古い定義で止まる |
| パイロット | 少数端末でSEP除去→Defender有効化→更新/監視確認 | 手順書、除外テンプレ、例外一覧 | SEPアンインストール後の再起動漏れ、競合（2重AV） |
| 段階展開 | リングで対象を拡大（部署/拠点/サーバー役割別） | 展開計画、障害時の切り戻し手順 | サーバーの業務アプリで除外不足が発生 |
| 運用定着 | 定義更新のSLA、アラート対応、例外棚卸し | 運用手順、月次レビュー項目 | “例外だらけ”になると守りが崩れる |
SEPアンインストール時の注意（Defenderの状態遷移を潰す）
- 同時に2つのAVを有効にしない：移行期間の共存は設計が必要（受動モード・切替タイミングを決める）。
- サーバーでは「自動で有効化/無効化されるはず」という思い込みを捨てる：非Microsoft製AVを外しても、バージョンによってはDefenderが想定通りアクティブに戻らないことがあるため、必ず状態確認を入れる。
- Defenderが無効化されるGPO/レジストリ設定が残っていないか確認する（過去に“不要だから無効化”している環境が多い）。
- アンインストール後は再起動を前提に計画し、パッチ適用と同じくメンテナンスウィンドウに乗せる。
Microsoftの資料でも、非Microsoft製AVをアンインストールした際にDefenderが自動でアクティブへ戻るはずだが、Windows Server 2016など特定のバージョンではそうならない場合があるため、状態確認と必要に応じた手動対応が案内されています。移行手順には必ず「状態確認」と「戻らない場合の手当て」を含めてください。
切り替え後の確認コマンド（代表例）
パイロットでは、SCCM上のステータスだけでなく端末側でも“効いている”ことを確認すると安心です。Windows 10/Server 2016以降なら、PowerShellで状態や設定を確認できます。
# 状態確認（例）
Get-MpComputerStatus
# 定義更新（社内更新源の設定に従って取得）
Update-MpSignature
# 除外やスケジュールなどの設定（例）
Set-MpPreference -ExclusionPath "D:\Data"Set-MpPreferenceはDefenderの設定（除外、スキャン、更新など）を変更するためのコマンドとして提供されています。SCCMポリシーの方針と矛盾しない範囲で、検証時の確認や一時的な調整に使うと便利です。
“古いOSを残す”場合の落としどころ：分離と更改ロードマップが必須
Server 2003やWindows 7など、サポート終了OSが残っている環境では「AVをDefenderにすれば安心」という状態にはなりません。Windows 7のサポートは終了しており、OSの脆弱性が修正されない状態でAVだけを最新化しても、リスクの根本は残ります。
どうしても残す場合は、次のような“守り方を変える”のが現実的です。
- ネットワーク分離（業務に必要な通信だけを許可。特に管理系・ファイル共有の経路を絞る）
- 特権の最小化（ローカル管理者の棚卸し、サービスアカウントの権限見直し）
- 持ち込み経路の制御（USB、持ち込みPC、共有フォルダー）
- 更改ロードマップ（いつ、どの順で、何に置き換えるか）
「Defenderへ移行する台数」と「更改が必要な台数」を分けて並走させると、SEP更改の投資判断もしやすくなります。例えば、Windows 10/Server 2016+はDefenderへ寄せ、古いOSは更改までSEP継続・隔離強化という二段構えが現実的です。
まとめ：SCCM＋Defenderで“オフラインでも回る”移行を成功させる
オンプレ・インターネット非接続・SCCM運用という条件でも、Windows 10/Windows Server 2016以降を中心に、SEPからMicrosoft Defender Antivirusへ寄せた運用は十分に実現可能です。鍵になるのは、次の3点です。
- OS世代で割り切り、Defenderへ寄せる範囲（Windows 10/Server 2016+）と更改が必要な範囲を分ける
- 定義更新＋プラットフォーム更新を、SCCM（SUP/DP）で社内配布し、障害時の逃げ道（UNC共有）も用意する
- SCCMのEndpoint Protectionで監視とアラートを作り込み、運用KPI（未更新/保護無効/検知）を回す
クラウド前提のEDR機能まで求める場合は別設計になりますが、まずは「社内で回るAV統制」を確立し、そこから更改やセキュリティ強化（Controlled folder access/ASRなど）へ段階的に広げるのが、現場で破綻しにくい進め方です。
コメント