EDR（Endpoint Detection and Response）は、PCやサーバーといったエンドポイントで起きる不審な振る舞いを継続的に監視し、侵入を検知して封じ込める仕組みです。侵入そのものを防ぐEPPと違い、EDRは「防ぎ切れなかった侵害を前提に、端末上の挙動から異常を見つけて対応する」側を担います。この記事では、EDRが集めるテレメトリの中身、振る舞いで攻撃を捉える検知ロジック、EPP・XDR・MDR・ITDRとの役割分担、SIEMやSOARと連携させた対応の自動化、そして受託開発で自社システムに監視を組み込むときの設計指針までを、実装する側の視点で整理します。加えて、収集イベントを絞るSysmonの設定ファイル、親子プロセスの連鎖を抜き出す追及クエリ、端末を隔離するAPIのリクエストという、手元で試せる形の記述例も添えました。
まとめ：EDRは侵入を前提に検知と対応を足すエンドポイント防御
EDRは、入口で止めるEPPを通り抜けた侵害を、端末の振る舞いから見つけて封じ込めるレイヤーだと捉えると位置づけを掴みやすくなります。ウイルス対策やEPPが「既知の脅威をブロックする予防」なのに対し、EDRは突破された後のプロセス起動やファイル操作、通信の異常を記録して検知し、感染端末の隔離やプロセス停止まで手を伸ばす側です。攻撃の起点がファイル型マルウェアから、正規ツールを悪用するファイルレス型へ移った流れのなかで、事前ブロックだけでは取りこぼす侵害を捕まえる役割として広がりました。
導入の判断は、製品の知名度やSERPの順位ではなく、自組織のエンドポイントの数と侵害時の影響範囲で決めます。端末台数が多く、機密情報を扱い、外部と通信する資産が広い組織ほど検知の費用対効果が見合う構造です。逆に、守るべき端末が少なく既存のEPPとログ監視で足りている段階では、専用EDRの検知アラートを裁く運用体制のほうが先に負荷になりがちで、まず運用を回せる構成から入るほうが投資が生きます。なお、Webアプリケーション側の認可制御の不備は端末の挙動監視では捉えられず、別の対策が要ります。実例と設計指針は生保協会の生命保険契約照会システムで情報漏えい｜認可制御不備の技術解説にまとめました。
EDRの定義と保護対象＝エンドポイントの振る舞いを監視する仕組み
EDRという略語は Endpoint Detection and Response の頭文字です。名前のとおり、守る対象はネットワーク境界でもクラウドでもなく「エンドポイント」、つまり従業員のPCやサーバー、仮想デスクトップといった端末そのものに絞られています。監視の単位は端末上で動くプロセスやファイル、通信であり、そこで起きる一連の挙動を記録して分析します。
EDRがGartnerで2013年に提唱された背景とEPPとの分業
EDRという言葉は、Gartnerのアナリストが2013年に提唱したのが始まりとされています。背景にあるのは、シグネチャで既知のマルウェアを弾くEPPだけでは、未知の攻撃や正規ツールを悪用する手口を止め切れないという課題でした。攻撃者が端末に侵入した後の横方向への移動や権限昇格は、単体のファイルを見るだけでは捉えにくく、時間軸に沿った挙動の記録が必要になります。EPPが入口で予防し、EDRが侵入後の検知と対応を担うという分業は、この課題認識から生まれた構図です。
EDRが集めるテレメトリ（プロセス・通信・レジストリ）の中身
EDRの中身を実装の目線で分解すると、まず端末に導入したエージェントが挙動のテレメトリを集める層があります。集める対象は、プロセスの生成と親子関係、実行されたコマンドライン引数、ファイルやレジストリの変更、外部への通信先、スクリプトの実行などです。エージェントはこれらを継続的に記録してサーバー側へ送り、正常時のベースラインからの逸脱を評価する構造になっています。PowerShellの難読化された実行や、正規プロセスからの見慣れない子プロセス生成といった、単体では判断しづらいイベントを文脈込みで残す点が、従来のウイルス対策との違いです。
収集項目の粒度は、Windowsに無償で追加できるSysinternals公式のSysmonドキュメントを読むと具体的に掴めます。同ドキュメントの版は2026年6月17日付で、イベントIDはプロセス生成が1、ネットワーク接続が3、ファイル作成が11、レジストリ値の設定が13、DNSクエリが22、プロセスの改ざん検出が25という定義です。商用EDRのエージェントも取得する情報の種類はこの並びと重なるため、自社でどのイベントを検知の材料にするかを設計する前段の教材として読み解く価値があります。
Sysmonの設定ファイルでプロセス生成と通信を絞り込む記述例
テレメトリはすべて集めると量が破綻するため、実装では収集段階でフィルターをかけます。Sysmonは設定XMLのEventFiltering配下にイベントごとのタグを置き、onmatch属性で包含と除外を切り替える方式です。公式ドキュメントの記述に沿うと、同じフィールド名の条件はOR、異なるフィールド名の条件はANDとして評価され、同一タグに包含と除外の両方を書いた場合は除外が優先されます。次は、文書アプリからのスクリプト起動を拾い、業務常用のブラウザーの通信を落とす最小構成です。
<Sysmon schemaversion="4.82">
<HashAlgorithms>SHA256</HashAlgorithms>
<EventFiltering>
<RuleGroup name="office-child" groupRelation="and">
<ProcessCreate onmatch="include">
<ParentImage condition="end with">winword.exe</ParentImage>
<Image condition="end with">powershell.exe</Image>
</ProcessCreate>
</RuleGroup>
<NetworkConnect onmatch="exclude">
<Image condition="end with">msedge.exe</Image>
</NetworkConnect>
<DnsQuery onmatch="include">
<QueryName condition="end with">.top</QueryName>
</DnsQuery>
</EventFiltering>
</Sysmon>導入と設定更新のコマンドは、インストールがsysmon64 -iに設定ファイルを続ける形、稼働中の設定差し替えがsysmon64 -cで、どちらも再起動を伴いません。記録先はApplications and Services Logs配下のSysmon運用ログで、タイムスタンプはUTCです。除外条件を広く取ると検知の穴になるため、業務常用の実行ファイル名で落とす場合は署名やパスまで条件に足して範囲を締めるのが安全側の書き方です。
IOAとIOCで振る舞いを検知するロジックと自動対応の実装手順
集めたテレメトリを、どう「異常」と判定するか。ここがEDRの心臓部で、製品ごとに検知エンジンは違っても、判定の考え方には共通の型があります。
既知の痕跡（IOC）と攻撃の振る舞い（IOA）を組み合わせた検知
検知の材料は大きく二種類に分かれます。ひとつは既知の侵害の痕跡を指すIOC（Indicator of Compromise）で、悪性のファイルハッシュや通信先ドメインなど「これが見つかったら侵害」という静的な指標です。もうひとつは攻撃の振る舞いを指すIOA（Indicator of Attack）で、たとえば正規の文書ファイルからスクリプトが起動し、続けて認証情報の読み出しと外部通信が連鎖する、といった一連の動きをシグナルにします。IOCは既知の脅威に強く、IOAは未知の手口でも攻撃の型で捉えられるため、両方を組み合わせて検知の網を張るのがEDRの基本設計です。IOCで捕まえる側の実例としては、正規プロセスに紛れて資源を食うマイニング型の挙動を追った暗号通貨マイニングマルウェアの検出方法と駆除手順の解説が、痕跡と振る舞いの両面を突き合わせる流れを具体化しています。
MITRE ATT&CKへのマッピングと誤検知を抑える除外設計
振る舞い検知は自由度が高いぶん、誤検知との折り合いが設計の勘所になります。多くのEDRは、検知した挙動を攻撃手法の分類体系であるMITRE ATT&CKのEnterpriseマトリクスの戦術・技術にマッピングし、どの段階の攻撃に相当するかを可視化するのが一般的です。単発のイベントで警告を上げるのではなく、複数の弱いシグナルが同じ攻撃シナリオ上で連鎖したときにリスクを引き上げる、という束ね方で誤検知を抑えます。管理者側は、業務で常用する管理ツールなどを除外リストに登録しつつ、除外が検知の穴にならないよう範囲を絞る運用で精度を保ちます。
参照する版は固定ではありません。ATT&CKの配布データのバージョン一覧によると、Enterprise版は19系まで進み、v19.0が2026年4月28日、v19.2が2026年8月5日付です。18系のリリースノートでは従来のDetectionsフィールドがDetection Strategies・Analytics・Data Componentsに分解され、Data Sourcesは廃止という構造変更が入りました。検知ルールをATT&CKの技術IDへ機械的に紐づけている実装では、版を上げるときにこの構造差でマッピングが崩れる箇所が出るため、版番号を固定してから差分を当てる運用が安全です。
高度な追及のKQLで親子プロセスの連鎖を抽出する検知クエリの書き方
ルールを作る前に、そのシグナルが自社環境で何件当たるのかを実データで数える工程が要ります。Microsoft Defender XDRの高度な追及では、DeviceProcessEventsテーブルのスキーマ定義にプロセス生成イベントが集まり、実行元プロセスを表すInitiatingProcessFileNameと生成されたプロセスのFileName、引数のProcessCommandLineを並べて連鎖を追えます。文書アプリからスクリプトエンジンが起動する型を7日分数える書き方は次のとおりです。
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName,
FileName, ProcessCommandLine
| order by Timestamp desc件数が一桁で、当たった端末も業務内容から説明できるなら、そのままルール化して通知に回せます。三桁で出るなら、その組み合わせは自社では正常系であり、除外条件か追加シグナルを重ねる側の設計に切り替えます。この「先に数えてから閾値を決める」順序を踏まないルールが、運用開始後にアラートを溢れさせる主因です。攻撃の入口となる手口を検知要件へ落とし込む材料としては、ClickFixのような偽CAPTCHAでコマンドを実行させる手口の実装者向け解説が、どの親子関係を数えるべきかを具体化してくれます。
検知後の端末隔離・プロセス停止・ロールバックという対応の自動化
EDRの名前の後半、Responseにあたる部分が検知と並ぶ価値です。侵害を疑う端末を検知した際、ネットワークから論理的に切り離すホスト隔離、悪性プロセスの強制停止、変更されたファイルを元に戻すロールバックといった対応を、管理コンソールから、あるいは条件付きで自動で実行できます。設計時は、誤検知で正規業務の端末を止めないよう、自動対応の発動条件を段階で分けるのが定石です。低リスクは通知と証跡保全のみ、確度の高い侵害は即時に隔離、という二段構えにすると、初動の速さと業務影響のバランスが取りやすくなります。
隔離APIをREST呼び出しで自動化するときの権限とレート制限
隔離を人の操作から切り離すなら、製品のAPIを叩く形になります。Microsoft Defender for Endpointの隔離APIのリファレンスは、対象デバイスIDを含むエンドポイントへのPOSTで、必須のCommentと隔離方式のIsolationTypeをJSONで渡す仕様です。方式はFull（完全隔離）、Selective（一部アプリの通信のみ制限）、UnManagedDevice（非管理端末向け）の三択で、成功時は201が返り、実行状況を追える識別子つきのアクション情報が本文に入ります。
POST https://api.security.microsoft.com/api/machines/{id}/isolate
Authorization: Bearer {token}
Content-Type: application/json
{
"Comment": "Isolate machine due to alert 1234",
"IsolationType": "Full"
}設計上の制約は三つあります。呼び出しに必要なアクセス許可はMachine.Isolateで、ユーザー資格情報で叩く場合はロール側に修復アクションの権限とデバイスグループの参照権が要ります。レート制限は同リファレンスの記載で1分あたり100回・1時間あたり1,500回のため、大量端末を一括で止める運用は制限を織り込んだ実装が前提です。加えて完全隔離はWindows 10のバージョン1703以降とWindows 11、選択的隔離は1709以降が条件で、隔離後の端末はスプリットトンネルVPNでない構成だとクラウド側と通信できなくなる点も、封じ込め後の調査手順に影響します。
EPP・XDR・MDR・ITDRとの違いとエンドポイント防御での役割分担
EDRは単独で完結する製品ではなく、周辺のセキュリティ層と組み合わせて効果を出します。似た略語が並ぶため、まず守備範囲を一枚の表で押さえます。
| 分類 | 主な役割 | 検知・対応の起点 |
|---|---|---|
| EPP | 侵入前の予防 | 既知シグネチャ・事前ブロック |
| EDR | 侵入後の検知・対応 | 端末の振る舞い・プロセス |
| XDR | 複数レイヤーの相関 | 端末＋通信＋クラウド＋ID |
| MDR | 監視運用の外部委託 | 人による監視・対応 |
| ITDR | アイデンティティ防御 | 認証・ID基盤の異常 |
EPPによる予防とEDRによる検知の役割分担と併用するときの判断
EPPは既知の脅威を入口でブロックする予防、EDRは通り抜けた侵害を端末の挙動で検知する側、という分業です。片方があればもう片方が要らないという関係ではなく、予防で母数を減らし、残った侵害を検知で捕まえる二層構造が守りとして堅くなります。現在は両者を一つのエージェントに統合し、予防と検知を同じ製品で提供する形が主流で、導入時はEPP単体か、検知と対応まで含めるかを、運用体制と守るべき資産の重さで選びます。
XDR・MDR・ITDRとの守備範囲の違いと製品を選ぶときの軸
XDRは、EDRのエンドポイント検知を軸に、メールやクラウド、ネットワーク、アイデンティティのログまで横断して相関するアプローチです。攻撃が端末単体で完結せず複数のレイヤーをまたぐ場合に、点ではなく線で攻撃チェーンを追えます。詳しい仕組みはアイデンティティ層の脅威を検知するITDRの解説と合わせて読むと、EDRが端末、ITDRがID、XDRがそれらを束ねる相関という役割分担が掴めます。一方でMDRは製品分類ではなく、EDRやXDRの監視と初動対応を専門チームへ委託する運用サービスで、自社にSOC人材を抱えられない組織が検知の見張り番を外部に持つ選択肢です。選ぶ軸は、守る対象がエンドポイント中心か複数レイヤーか、そして運用を内製できるか委託するか、の二点に集約されます。
EDRの導入を判断する条件と受託開発で監視機能を組み込む設計指針
ここからは判断の章です。カタログスペックの横並び比較ではなく、「自組織に要るのか」「作るなら何に気をつけるのか」を条件付きで言い切ります。
EDRを導入すべき組織の条件と運用負荷で過剰投資になりやすい場面
EDRの費用対効果が出やすいのは、エンドポイントの台数が多く、機密情報や個人情報を扱い、外部と通信する端末が広く分布する組織です。端末一台の侵害が横展開で全体に波及しうる構造ほど、検知と迅速な隔離の価値が見合います。一方で見落とされがちなのが運用負荷で、EDRは導入して終わりではなく、上がってくる検知アラートを人が判断して初動を打つ体制があって初めて機能します。裁く人手がないままアラートが放置されれば、検知していても被害は止まりません。SOC人材を抱えられない規模なら、製品単体より前にMDRのような監視委託を含めた構成で見積もるのが現実的な線引きです。守るかどうかは、端末の数と侵害時の影響、そして運用を回せる体制の三点で決めます。内製と委託の分岐点はSOCとは？監視運用の仕組みと内製・アウトソースの判断を解説した記事で工数の内訳から整理しています。
SIEM・SOARと連携させたインシデント対応の自動化の設計指針
EDRは、検知して終わりでは価値が半分にとどまります。検知したシグナルをSIEMとは？仕組み・機能とEDR/XDR/SOARの違いを実装視点で解説した記事のとおりログ基盤へ集約して他ソースと突き合わせ、SOARのプレイブックで「端末の隔離」「関連アカウントの一時停止」「証跡の保全」まで自動で走らせる設計にして初めて、対応の速度が攻撃者を上回ります。設計時は、EDR単体の検知だけで自動遮断まで踏み込むと誤検知の影響が大きいため、SIEMで複数ソースの相関が取れた高確度のケースに自動アクションを絞り、それ以外は担当者の確認を挟む二段構えが破綻を避けやすい構成です。EDRの隔離APIとSIEM側の相関ルールを同じ製品群で束ねる構成なら、Microsoft Sentinelの料金モデルとDefenderポータル統合の解説が取り込み経路と課金の見積もり方の参考になります。
NIST SP 800-61r3が示す対応工程とEDR運用への当てはめ方
対応フローの設計は、自社で一から起こすより公的な枠組みに載せたほうが抜けが減ります。米国NISTはSP 800-61 Rev.3（インシデント対応の推奨事項）を2025年4月に公開し、旧Rev.2の固定的な4段階ライフサイクルを外して、対応活動をサイバーセキュリティフレームワーク2.0の機能群へ対応づける構成に改めました。EDRの守備範囲は主に検知と対応・復旧にあたるため、識別と防御にあたる資産台帳や構成管理が薄いままEDRだけ入れても、アラートに出た端末の持ち主や用途が特定できず初動が止まります。導入計画では、端末台帳の整備と、隔離を実行してよい判断者の明文化を、検知ルールの設計と同じ工程に並べておくと運用が回ります。
受託開発で自社システムにエンドポイント監視機能を組み込む注意点
自社サービスや業務システムに監視を作り込む場合、いきなり独自の検知エンジンを書くより、EDR製品が出すアラートと端末テレメトリをイベント基盤へ流し、既存のログ分析と統合するところから始めるのが堅実です。私たちが受託開発で扱う際も、まずテレメトリの取得口と保持期間、検知後の対応フローを業務側と握ってから実装に入る手順を取ります。侵入を前提に検知と対応を重ねる考え方は、境界の内外で信頼を分けないゼロトラストの防御思想（境界型防御との違いとNIST7原則）とも地続きです。こうしたエンドポイント監視を含むセキュリティ機能の設計と実装は、AIセキュリティ対策の受託開発として相談を受けています。検知ルールを組む前に、守る対象のシステム側にどんな穴が空いているかを実測したい場合は、脆弱性診断・セキュリティ診断で入口の弱点を洗い出してから監視設計に入る順序をおすすめしています。
よくある質問
EDRの導入や他ソリューションとの違いについて、実装や選定の現場で挙がりやすい質問に答えます。
EDRとEPPは何が違うのですか？
担当するフェーズが違います。EPPは既知の脅威を入口でブロックする侵入前の予防、EDRは通り抜けた侵害を端末の振る舞いから見つける侵入後の検知と対応です。マルウェアのファイルを持たず正規ツールを悪用する攻撃はEPPの死角になりやすく、その領域をEDRが振る舞い検知で埋めます。両者は競合ではなく、予防と検知を二層で持つ補完関係です。
EDRを入れればウイルス対策ソフトは不要になりますか？
置き換えるものではありません。既知のマルウェアを事前に弾くEPPやウイルス対策は入口の予防として引き続き効き、EDRはそこを抜けた侵害を検知します。現在は両方を一つのエージェントに統合した製品が主流で、予防と検知を分けて考えつつ、実体としては同じ製品で両方を賄う構成が一般的です。
小規模な組織にもEDRは必要ですか？
台数と体制しだいです。守るべき端末が少なく既存のEPPとログ監視で足りている段階なら、検知アラートを裁く人手のほうが先に負荷になります。特権端末が多い、外部公開資産が多い、機密情報を扱うといった条件が揃い、かつアラートを運用できる体制か監視委託を用意できるなら、導入の価値が高まります。
EDRとXDRはどちらを選べばよいですか？
守る範囲で選びます。守りたい対象がエンドポイント中心ならEDR、端末に加えてメールやクラウド、IDまで横断して攻撃チェーンを追いたいならXDRが向きます。XDRはEDRを内包して他レイヤーへ広げた発展形にあたるため、まずEDRで端末の検知を固め、相関の必要性が見えてからXDRへ広げる順序が現実的です。XDRが複数レイヤーのログを相関する仕組みは、XDRとは？EDRとの違いと相関分析の仕組み・導入判断を実装者向けに解説した記事で詳しく整理しています。
EDRの運用は自社だけで回せますか？
体制があれば可能ですが、検知アラートを判断して初動を打つ人手が要ります。SOC人材を確保しづらい場合は、EDRやXDRの監視と一次対応を外部の専門チームへ委託するMDRを組み合わせると、検知の見張り番を持てます。導入時は製品費用だけでなく、この運用体制まで含めて見積もるのが失敗を避ける勘所です。
関連記事
- SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説：EDRの検知シグナルを他ログと突き合わせる集約基盤の側を、取り込み設計と製品選定から解説しています。
- XDRとは？EDRとの違いと相関分析の仕組み・導入判断を実装者向けに解説：端末の検知を軸に複数レイヤーへ広げた発展形を、相関分析の仕組みから整理した記事です。
- ITDRとは？EDRとの違いと検知の仕組み・導入判断を実装者向けに解説：EDRが端末を守るのに対し、認証情報やID基盤の異常を検知するアイデンティティ層の防御を実装目線で解説しています。
- ClickFixとは？偽CAPTCHAでコマンドを実行させる手口と実装者向けの検知・防御：EDRが検知対象とする、正規ツールを悪用してコマンドを実行させる攻撃手口を防御側の目線で整理しています。
- ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：侵入を前提に検知と対応を重ねるEDRの考え方の土台となる、ID中心の防御思想を設計原則から解説した記事です。
