@comty(こむてぃ)Team Tea & Waterin

アディクシィ株式会社

NDR・EDR・XDRを整理する──「どこで見るか」ではなく「どうつなげて止めるか」で考える

Last updated at 2026-06-22Posted at 2026-06-22

はじめに

セキュリティ製品を調べていると、EDR、NDR、XDRという言葉がよく出てきます。

なんとなく見ると、どれも「攻撃を検知して対応する製品」に見えます。
しかし、現場で考えるべき論点は少し違います。

「どの製品が強いか」ではなく、まず見るべきは次の3点です。

どこからテレメトリを取るのか
どの攻撃行動を見つけたいのか
見つけたあと、誰が、どの手順で止めるのか

NIST CSF 2.0では、サイバーセキュリティの機能を Govern / Identify / Protect / Detect / Respond / Recover の6つに整理しています。EDR、NDR、XDRは、この中でも特に Detect と Respond を支える仕組みとして理解すると整理しやすくなります。¹

本稿では、NDR、EDR、XDRを「製品ジャンル」ではなく、検知・調査・対応の設計要素として整理します。

1. まず、EDR・NDR・XDRの違いを一枚で整理する

最初に結論です。

項目	主な観測対象	得意なこと	苦手なこと	代表的な対応
EDR	PC、サーバー、エンドポイント	プロセス実行、ファイル作成、レジストリ変更、端末隔離	エージェント未導入端末、OT機器、BYOD、通信全体の俯瞰	端末隔離、プロセス停止、ファイル隔離、調査
NDR	ネットワーク通信	横展開、C2通信、異常な通信、未知端末の発見	暗号化通信の中身、端末内部の詳細挙動	通信遮断、セグメント分離、感染範囲の把握
XDR	エンドポイント、ネットワーク、ID、メール、クラウドなど	複数領域の相関分析、インシデント統合、対応自動化	データ品質が低い環境、製品間連携が弱い環境	インシデント単位の調査、複数面での封じ込め

ざっくり言うと、EDRは「端末の中で何が起きたか」を見る仕組みです。
NDRは「ネットワーク上で何が流れたか」を見る仕組みです。
XDRは「端末・通信・ID・メール・クラウドの情報をつなげて、攻撃の流れとして見る」仕組みです。

ここで重要なのは、XDRがEDRやNDRを単純に置き換えるものではない、という点です。XDRは、複数のセンサーやログを束ねて相関分析する考え方です。つまり、EDRやNDRのテレメトリ品質が低ければ、XDRも強くなりません。

2. EDRは「端末内の行動」を見る

EDRは Endpoint Detection and Response の略です。対象は、PC、サーバー、仮想マシンなどのエンドポイントです。

従来のアンチウイルスやEPPが「侵入前・実行前の防御」に寄っていたのに対し、EDRは「侵入された後の検知・調査・対応」に重心があります。CISAのランサムウェア対策ガイドでも、アプリケーション許可リストやEDRの活用が推奨されています。²

EDRが見る代表的なイベントは、次のようなものです。

プロセスの起動
PowerShellやcmdの実行
不審な親子プロセス関係
ファイルの作成、変更、削除
レジストリ変更
認証情報へのアクセス
外部通信の発生
権限昇格の痕跡

たとえば、メール添付ファイルからマクロが動き、PowerShellが起動し、外部からペイロードを取得し、永続化のためにレジストリを書き換える。こうした一連の動きは、端末内部の挙動を追えるEDRが得意とする領域です。

JPCERT/CCも、インシデント調査ではWindowsイベントログ、Sysmon、ETWなどのログが重要になることを複数の資料で説明しています。特にETWは、EDR製品やウイルス対策ソフトの検知ロジックにも活用されていると説明されています。³

一方で、EDRには明確な限界があります。

エージェントが入っていない端末は見えない
ネットワーク機器、プリンター、IoT、OT機器は対象外になりやすい
攻撃者にEDRを停止・回避される可能性がある
アラートを誰も見ていなければ意味がない

最後の点は特に重要です。CISAのインシデント対応事例では、EDRアラートが継続的にレビューされず、一部の公開システムにエンドポイント保護がなかったことで、攻撃活動が長期間検知されなかった事例が紹介されています。⁴

EDRは「入れれば安心」ではありません。
端末に入れて、ログを取り、アラートを見て、初動対応できる体制まで含めてEDRです。

3. NDRは「通信の流れ」を見る

NDRは Network Detection and Response の略です。対象はネットワーク通信です。

EDRが端末の内側を見るのに対し、NDRはネットワーク上の通信を見ます。代表的には、次のようなデータを扱います。

NetFlow、IPFIXなどのフローデータ
DNSログ
プロキシログ
ファイアウォールログ
IDS/IPSログ
パケットメタデータ
クラウドのVPC Flow Logs
TLSメタデータ
東西通信のミラートラフィック

MITRE ATT&CKでは、検知に使う情報源として Network Traffic、Process、File、User Account など多数のデータ種別が整理されています。ATT&CKのData Sourcesページ自体は2025年10月のv18で非推奨化されていますが、センサーやログから得られる情報を攻撃行動と結びつけるという考え方は、検知設計の基礎として有用です。⁵

また、MITRE ATT&CKの Network Traffic Flow では、送信元・宛先IP、ポート、プロトコル、タイムスタンプ、データ量などのセッションレベル情報が、トラフィック分析や異常検知に使われると説明されています。⁶

NDRが特に効くのは、次のような場面です。

端末にEDRエージェントを入れられない
IoT機器やOT機器が多い
攻撃者の横展開を見たい
C2通信やビーコン通信を見たい
データ持ち出しの兆候を見たい
社内ネットワークの見えない端末を把握したい

たとえば、侵害された端末が社内の複数サーバーにSMBやRDPで接続し始める。あるいは、普段通信しない海外IPへ一定間隔で通信する。こうした「端末単体ではなく、通信のパターンとして怪しい」動きはNDRの得意領域です。

ただし、NDRにも限界があります。

暗号化通信の中身は基本的に見えない
通信量が多い環境ではノイズが増える
クラウドやSaaSの通信は経路次第で見えない
端末内で何が実行されたかまでは分からない
通信遮断の権限設計がないと、検知だけで止まる

つまり、NDRは「ネットワーク上の異常」を見つける仕組みです。
しかし、なぜその通信が発生したのか、端末内でどのプロセスが動いたのか、どのユーザーが関与したのかを調べるには、EDRやIDログとの突合が必要になります。

4. XDRは「点のアラート」を「線のインシデント」に変える

XDRは Extended Detection and Response の略です。

GartnerはXDRを、複数のセキュリティ基盤から脅威インテリジェンスやテレメトリを統合し、相関分析によってアラートに文脈を与え、自動対応能力を提供するものとして説明しています。⁷

ここで大事なのは、XDRの価値が「ログを1画面に集めること」ではないという点です。

XDRの本質は、次の3つです。

複数領域のデータを集める
攻撃の流れとして相関する
対応アクションにつなげる

たとえば、次のようなイベントが別々に発生したとします。

メールセキュリティ製品が不審な添付ファイルを検知
EDRがPowerShellの不審な起動を検知
ID基盤が普段と違う場所からのログインを検知
NDRが外部C2らしき通信を検知
クラウド監査ログが大量ダウンロードを検知

これらを別々のアラートとして扱うと、SOC担当者は大量の通知に埋もれます。
しかし、XDRがこれらを1つの攻撃シナリオとして束ねられれば、調査の優先順位が明確になります。

この考え方は、CISAのゼロトラスト成熟度モデルに出てくる Visibility and Analytics、Automation and Orchestration、Governance という横断的な能力とも近いです。ゼロトラストでは、単一の境界防御ではなく、複数の柱を横断して可視化・分析・自動化・統制を進めることが重視されています。⁸

ただし、XDRにも落とし穴があります。

落とし穴	内容	対策
データ不足	EDR、NDR、ID、メール、クラウドのログが不足している	先にログ取得範囲を棚卸しする
名寄せ不備	端末名、ユーザーID、IP、クラウドIDがつながらない	CMDB、ID管理、資産管理を整備する
自動対応の暴発	誤検知で端末隔離やアカウント停止が起きる	対応アクションに段階を設ける
ベンダーロックイン	特定製品群の中だけで相関が閉じる	API連携、SIEM連携、エクスポート性を確認する
運用不在	高機能でも見る人・判断する人がいない	SOC、MDR、CSIRTの役割を決める

XDRは「全部入りの魔法の箱」ではありません。
むしろ、EDR、NDR、ID、メール、クラウドログをどれだけきれいにつなげられるかが勝負です。

5. 導入順序は「EDRかNDRか」ではなく、守りたい対象から決める

EDR、NDR、XDRのどれから入れるべきか。
これはよくある問いですが、答えは環境によって変わります。

目安としては、次のように考えると現実的です。

環境	優先しやすい対策	理由
一般的なオフィスIT中心	EDR	PC・サーバーが主な侵入口になりやすい
工場、医療、OT、IoTが多い	NDR	エージェント導入が難しい機器が多い
Microsoft 365やSaaS中心	EDR + ID + メール保護	端末、ID、メールが攻撃経路になりやすい
SOC運用を強化したい	XDR / SIEM / SOAR	アラートを統合し、対応を標準化したい
小規模で専任者が少ない	MDR付きEDR/XDR	製品より監視・対応体制が不足しやすい

個人的には、多くの企業では次の順序が現実的だと考えます。

1. 資産とログの棚卸し
        ↓
2. 重要端末・サーバーへのEDR展開
        ↓
3. ネットワーク可視化、NDRまたはNTAの導入
        ↓
4. ID、メール、クラウドログとの相関
        ↓
5. XDRまたはSIEM/SOARでインシデント運用を統合

いきなりXDRから入ると、見た目は統合されます。
しかし、元データが不足していると、相関分析も弱くなります。

逆に、EDRだけに寄せすぎると、エージェント未導入端末やネットワーク全体の異常を見落とします。

大事なのは、次の問いに答えることです。

重要資産はどこにあるか
攻撃者はどこから入る可能性が高いか
侵入後、どこを通って横展開するか
どのログがあれば調査できるか
検知後、誰が何分以内に何を止めるか

JPCERT/CCは、高度サイバー攻撃でも複数機器に特徴的な痕跡がログとして残る場合があり、適切にログを採取・分析することで攻撃に気づき、全体像を捉えられる可能性があると述べています。一方で、ログを採取していても実際に分析調査している組織は多くない、という課題も指摘しています。⁹

これは、EDR、NDR、XDRすべてに共通する教訓です。
ログは集めるだけでは足りません。
分析し、判断し、止めるところまで設計する必要があります。

おわりに

EDR、NDR、XDRは、名前だけを見ると似ています。
しかし、役割はかなり違います。

EDRは、端末の中で起きたことを見ます。
NDRは、ネットワーク上で流れたことを見ます。
XDRは、それらを含む複数の情報をつなげ、攻撃の流れとして扱います。

本稿の結論は、次の通りです。

EDRは、端末内の実行・変更・侵害後対応に強い
NDRは、通信の異常・横展開・未管理端末の把握に強い
XDRは、複数領域のアラートをインシデントとして統合する
XDRはEDRやNDRの代替ではなく、相関・運用の上位レイヤーとして考える
導入順序は、製品カテゴリではなく、守りたい資産と調査したい攻撃経路から決める

次にやるべきことは、製品比較表を眺めることではありません。

まず、自社の環境で次の表を埋めることです。

確認項目	現状	不足	次アクション
重要端末にEDRが入っているか
サーバーにEDRが入っているか
EDR未導入端末を把握しているか
DNSログを取得しているか
東西通信を見られるか
IDログと端末ログを突合できるか
メール起点の攻撃を追跡できるか
クラウド監査ログを取得しているか
アラート対応手順があるか
自動隔離・アカウント停止の条件が決まっているか

セキュリティ運用は、道具を入れた瞬間に完成するものではありません。
「見える化」から始まり、「相関」し、「判断」し、「止める」ことで、ようやく実効性が出ます。

EDR、NDR、XDRは、そのための部品です。
主役は製品ではなく、攻撃を見つけて止める運用設計です。

参考

NIST Cybersecurity Framework 2.0 / The NIST Cybersecurity Framework (CSF) 2.0 PDF — CSF 2.0の6機能 GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER の根拠。(NIST技術シリーズ出版物) ↩
CISA StopRansomware Guide — ランサムウェア対策として、アプリケーション許可リストやEDRの活用が推奨されている。(CISA) ↩
JPCERT/CC Blog: ETW Forensics — ETW、イベントログ、Sysmon、EDR検知ロジックの関係を理解するための参考。(JPCERT/CC Eyes) ↩
CISA: Lessons Learned from an Incident Response Engagement — EDRアラートの継続的レビュー不足やエンドポイント保護不足が検知遅延につながった事例。(CISA) ↩
MITRE ATT&CK: Data Sources — センサーやログから収集できる情報種別と攻撃行動を結びつける考え方の参考。なお、Data SourcesページはATT&CK v18で非推奨化されている。(MITRE ATT&CK) ↩
MITRE ATT&CK: Network Traffic Flow — 送信元・宛先IP、ポート、プロトコル、時刻、データ量などの通信フロー情報が、トラフィック分析や異常検知に使われることの根拠。(MITRE ATT&CK) ↩
Gartner: Extended Detection and Response Reviews and Ratings — XDRの市場定義として、複数ソースのテレメトリ、脅威インテリジェンス、相関分析、自動対応を説明している。(ガートナー) ↩
CISA Zero Trust Maturity Model Version 2.0 — ゼロトラストにおける Visibility and Analytics、Automation and Orchestration、Governance の横断能力の参考。(CISA) ↩
JPCERT/CC: 高度サイバー攻撃への対処におけるログの活用と分析方法 — 適切なログ採取・分析によって攻撃の全体像を捉えられる可能性と、ログが十分に活用されていない課題の根拠。(jpcert.or.jp) ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up