ウイルス対策ソフトを入れていても、EDRが必要になる場面があります。両者は役割が違うためです。EDRが何を、どう守るのかを解説します（攻撃手順は載せません）。
従来型ウイルス対策との違い
| 観点 | 従来型アンチウイルス | EDR |
|---|---|---|
| 検知の軸 | 既知シグネチャ／IOC（ハッシュ等） | 振る舞い／IOA（一連の動き） |
| すり抜け耐性 | ファイルレス・正規ツール悪用に弱い | 振る舞いで捉えやすい |
| 事後調査 | 限定的 | タイムラインで経緯を追える |
| 対応 | 駆除が中心 | 隔離・調査・復旧まで支援 |
EDR・XDR・MDR・SIEMの違い
製品の説明でよく並ぶ用語を、何をするかと、どこを見るかで分けます。
| 用語 | 何をするか | 見る範囲 |
|---|---|---|
| ウイルス対策（EPP） | 既知の悪いファイルを照合して、実行前に止める | 端末 |
| EDR | 端末の動きを記録し、不審な流れを検知して、隔離・調査を助ける | 端末 |
| XDR | EDRの考え方を、メール・クラウド・ネットワーク・アカウントにも広げてつなげる | 端末を含む複数の領域 |
| MDR | 検知と対応を、外部の専門チームが代わりに行うサービス | 契約で決めた範囲 |
| SIEM | さまざまな機器やサービスのログを集め、検索・相関・保存する | 組織全体のログ |
EDRとXDRは製品の種類、MDRは運用の形、SIEMはログの置き場所と考えると整理しやすくなります。
どう守るか（仕組み）
① 端末の振る舞いを継続記録（プロセス・通信・ファイル操作）
↓
② 怪しい“一連の流れ”を検知（IOAベース）
↓
③ 端末を隔離・タイムラインで調査・復旧
シグネチャ照合（既知の悪を弾く）と振る舞い検知（IOAで気づく）は対立しません。両方を持つのが現実的で、EDRは後者を厚くする位置づけです。
小規模での現実的な向き合い方
1
まず基本の対策を固める
OS/アプリの自動更新・最小権限・CVE監視・MFA。高価なEDRより先に、攻撃を入れない・広げないための基本の対策が効く。
2
OS標準の保護を活かす
Windowsの Microsoft Defender には簡易な振る舞い検知が含まれる。まずこれを有効・最新に保つ。
3
ログを残し、IOAの目を持つ
認証ログ・通信量・プロセスを残し、「普段と違う流れ」に気づける状態にする（→ IOA）。
4
必要に応じてEDRを検討
守るべきデータや端末数が増えたら、管理型のEDR（例：Microsoft Defender for Endpoint 等）を検討する。導入＝運用なので、対応できる体制とセットで。
具体例：公開された事案と公的な方針
- 大阪急性期・総合医療センター（2022年）：調査委員会報告書は、被害が電子カルテ全体に広がった要因の1つとして、電子カルテ系の重要なサーバーにアンチウイルスが入っていなかったことを挙げています。検知の仕組みは、入っていない端末では働きません。EDRでもウイルス対策でも、まず対象から漏れた機器がないかが問題になります
- 米国の連邦政府：行政管理予算局（OMB）は2021年10月8日の通達 M-22-01 で、大統領令14028にもとづき、連邦機関にEDRの導入を進めるよう指示しました。通達はEDRを、端末のデータをリアルタイムに継続して監視・収集し、ルールにもとづく自動の対応と分析を組み合わせるもの、と説明しています
自分の環境で確認する方法
個人や小さな事業所なら、まず手元のPCで次を確かめます。
- 「Windowsセキュリティ」の「ウイルスと脅威の防止」で、リアルタイム保護がオンになっているかを見る
- PowerShellを管理者として開き、
Get-MpComputerStatus | Select-Object AMRunningMode,RealTimeProtectionEnabled,BehaviorMonitorEnabled,AntivirusSignatureLastUpdatedを実行する。RealTimeProtectionEnabledとBehaviorMonitorEnabled（振る舞いの監視）がTrueか、定義ファイルの更新日が古くないかを確かめる AMRunningModeがNormalならDefenderが主のウイルス対策として動いている。Passiveなら他社製の製品が主になっているので、その製品が有効で最新かを確かめる
なお、PCに標準で入るMicrosoft Defenderウイルス対策は、その1台を守る仕組みです。複数の端末の動きを1か所に記録し、離れた場所から隔離できる管理型のEDRとは別のものです。
組織でEDRを使っているなら、次の3点を確かめます。
- 資産の台帳とEDRの管理画面の登録台数を突き合わせ、入っていない端末を探す。サーバーや委託先が使う接続機器が漏れやすい
- アラートを誰がいつ見るか、夜間・休日に端末を隔離する判断を誰がするかを決めておく
- 端末からEDRを止める操作が、一般の利用者権限ではできないことを確かめる
当サイトの視点：製品名より『記録・検知・対応できる状態』
EDRは強力ですが、当サイトは「EDRを入れたから安全」とは考えません。検知は事故が起きてからの話で、まず必要なのはそもそも起こさない・広げない設計（最小権限・パッチ・MFA・秘密を平文で置かない）です。そのうえで、すり抜けは必ずあるので、振る舞いを記録・検知・対応できる状態を、規模に見合った形で持つ。個人なら「Defender＋ログ＋IOAの意識」で十分なことも多く、組織なら管理型EDRが選択肢になります。大事なのは製品名ではなく、予防（起こさない）と検知（気づく）の両方ができているかです。
出典（一次情報）
- 米国行政管理予算局（OMB）「M-22-01: Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Systems through Endpoint Detection and Response」（2021年10月8日） — whitehouse.gov（EDRの説明と連邦機関への導入指示）
- Microsoft Learn「Get-MpComputerStatus」 — learn.microsoft.com（Defenderの状態を確かめるコマンド）
- Microsoft Learn「Endpoint detection and response in block mode」 — learn.microsoft.com（Defenderの active／passive の動作）
- 大阪急性期・総合医療センター「情報セキュリティインシデント調査委員会報告書」（2023年3月28日公表） — gh.opho.jp