【図解】XDRとは？EDRとの違い、生まれた経緯、企業ネットワークでの構成例を初心者向けに解説

EDRを入れたあとに、「次はXDRです」と言われて戸惑った方は多いと思います。名前はEDRに「X」が付いただけですが、何が増えたのか、なぜ増えたのかは、製品の説明を読んでもつかみにくい言葉です。

この記事では、XDRとは何か、どういう経緯で出てきた考え方なのかを整理します。そのうえで、公開されている各社の資料を調べ、メーカーによらない共通の構成として一般化し、企業のネットワークにありそうな構成例、メーカーの範囲外のログの集め方、攻撃の流れで説明します。上から順に読めば、XDRの全体像がつかめるようにしています。

ご利用にあたって

本記事は、Microsoft、Palo Alto Networks、Trend Micro、CrowdStrikeの公開資料を調べたうえで、特定の製品によらない形に一般化した一般例です。特定の製品の実装を説明するものではなく、構成図と構成例は筆者が作成した想定例です。各製品の内部構造や動作を保証しません。
実際の実装、必要なエージェントや中継サーバの有無、対応範囲は製品によって異なります。導入や設計の前に、必ずメーカーや販売元に確認してください。この記事の内容については、免責とさせてください。
製品の機能、名称、ライセンスは変更されることがあります。導入や設計の際は、必ず各社の公式ドキュメントで最新の情報を確認してください。
調べた情報の出典は、記事末尾の「参考URL」にまとめています。
本ブログの掲載内容は個人の見解によるものです。

EDRの基本は【図解】EDRとは？ウイルス対策ソフト（EPP）との違いと、不審な動きを見つける仕組みで解説しています。先に読んでおくと、この記事がわかりやすくなります。

この記事でわかること

XDRとは何か、EDRと何が違うのか
SIEM、EDR、XDRと続いてきた歴史と、XDRが生まれた理由
公開資料に共通する「4つの機能レイヤー」
企業ネットワークでの構成例
メーカーの範囲外のログの集め方（エージェント、API連携、中継サーバ）と、3つの構成パターン
攻撃の流れで見たXDRの動き
SIEM・SOARとの違いと、導入前に確認したいこと

XDRとは
なぜXDRという考え方が出てきたのか
XDRの基本構成：4つの機能レイヤー
企業ネットワークでの構成例
1. 構成例：クラウドのXDR基盤にログを集める
メーカーの範囲外のログは、どう集めるのか
攻撃の流れで見るXDRの動き
SIEM・SOARとの違い
導入前に確認したいこと
まとめ
参考URL

XDRとは

XDR（Extended Detection and Response）は、端末だけでなく、メール、ID、ネットワーク、クラウドなど複数の場所のデータを集めて、まとめて検知し、まとめて対応するための仕組みです。EDRが端末の中を詳しく見るのに対して、XDRは見る範囲を広げ、別々の場所で起きた出来事を一つの流れにつなげます。

Gartnerの説明も、複数のセキュリティ製品からデータを自動的に集めて相関させ、検知とインシデント対応を高めるもの、という趣旨です。「X」は「Extended（拡張された）」と説明されることが多く、層や製品をまたぐ意味で「cross-layer」と説明するメーカーもあります。

建物の警備でたとえると、EDRは各部屋に付けた高性能な防犯カメラです。部屋の中で起きたことは細かく映りますが、合鍵を盗まれたこと（ID）や、廊下を通って別の部屋へ移ったこと（ネットワーク）は映りません。XDRは、カメラに加えて鍵の利用履歴、郵便物の確認、廊下のセンサーも集め、同じ人物の一連の行動として並べて見せる統合監視にあたります。

図1　EDRとXDRが見る範囲の違い

項目	EDR	XDR
見る範囲	端末（PC・サーバ）	端末に加えて、メール、ID、ネットワーク、クラウドなど
主なデータ	プロセス、ファイル、レジストリの操作など	左に加えて、認証ログ、メールの配送情報、通信ログ、クラウドの操作ログなど
警告の扱い	端末ごとの警告が中心	複数の場所の警告を関連づけて、1件のインシデントにまとめる
対応	端末の隔離、プロセスの停止など	左に加えて、アカウントの無効化、メールの削除、通信の遮断など（製品や連携先により異なる）

なぜXDRという考え方が出てきたのか

見る場所ごとに製品が分かれていた

セキュリティ製品は、守る場所ごとに増えてきました。メールにはメールセキュリティ、端末にはEDR、ネットワークにはFWやNDR（ネットワークの通信を監視する製品）、クラウドにはCASB（クラウドサービスの利用を監視・制御する製品）といった具合です。それぞれ自分の担当範囲は詳しく見られますが、管理画面と警告は製品ごとに別々です。

一方、攻撃は場所をまたいで進みます。メールで入り、端末で実行し、IDを盗み、ネットワークを渡り、クラウドからデータを持ち出す、という流れです。担当者は各画面の警告を見比べて、「この警告とあの警告は同じ攻撃だ」と自分で結びつける必要がありました。警告が増えるほどこの作業が重くなり、いわゆるアラート疲れにつながります。

SIEMとEDRだけでは埋まらなかった部分

ログを集めて調べる仕組みとしては、すでにSIEM（Security Information and Event Management）がありました。この言葉は、2005年にGartnerのアナリストが提唱したものです。EDRは、2013年にGartnerのAnton Chuvakinが「endpoint threat detection and response」として名付けた分類で、端末上の不審な活動を検知し、調べるためのツールを指します。

SIEMは幅広いログを集められますが、何を怪しいとみなすかのルールは、運用する側で用意し、調整していくのが一般的です（製品が検知ルールを用意している場合もあります）。EDRは端末の中を深く見られますが、見えるのは端末の範囲です。XDRという言葉を作ったPalo Alto Networksは、当時のEDR製品は用途が狭く、セキュリティチームのニーズに応えきれていないという問題意識から、XDRというカテゴリを考えたと説明しています。

年表で見る流れ

図2　XDRに至るまでの流れ（年は等間隔ではありません）

XDRという言葉は、同社CTOのNir Zukが2018年に作ったとPalo Alto Networksが説明しています。同社は2019年2月にCortex XDRを発表し、3月4日からの提供を案内しました。Trend Microも、2019年にXDRのソリューションを始めたとしています。

2020年には、GartnerがXDRを同年のセキュリティトレンドの筆頭に挙げ、市場の注目が一気に集まりました。当初は、同じメーカーの製品を統合するクラウド型の提供として語られていましたが、同年9月のカンファレンスでは、他社製品を組み合わせる進め方も含めて説明されています。この違いが、次に説明する「ネイティブ型」と「オープン型」です。

ネイティブ型とオープン型

XDRは、どこまでを同じメーカーの製品でそろえるかによって、大きく2つの考え方に分けて説明されます。

型	考え方	一般的な傾向
ネイティブ型（単一ベンダー型）	同じメーカーの製品どうしを統合する	製品間の連携が深く、導入と運用をそろえやすい。他社製品のデータの取り込みは限られる場合がある。
オープン型（ハイブリッド型）	他社製品のログや警告も取り込む	既存の製品を置き換えずに使える。データ形式のそろえや連携設定が必要になる。

最近は、ネイティブ型のメーカーも他社データの取り込みに対応しており、両者の差は小さくなっています。この記事の4つの機能レイヤーは、どちらの型にも当てはまる形でまとめます。

XDRの基本構成：4つの機能レイヤー

公開されている各社の資料を読み比べると、XDRの機能はおおむね4つの層に分けて考えられます。次の図は、私が一般化して整理したモデルです。標準や公式の定義ではなく、製品によって層の区切りや名前は変わります。

図3　XDRの4つの機能レイヤー（筆者が一般化した例）

層	役割	具体的な内容
1 データ収集	各場所の活動データを常時集める	端末のプロセスやコマンドライン、認証ログ、メールの配送情報、DNSや通信のログ、クラウドの操作ログなど
2 正規化・蓄積	形式の違うデータを共通の形にそろえて保管する	ユーザー名、端末名、IPアドレスなどの項目をそろえる。ADやEntra IDの属性を付けて、誰の端末かが分かるようにする。
3 相関・検知	関連するデータをつなげ、怪しい動きを判定する	同じユーザー、端末、IPアドレス、ファイルのハッシュなどを手がかりに、時間の近い出来事を結びつける。ルール、機械学習、脅威インテリジェンスで判定する。
4 インシデント管理・対応	関連する警告を1件にまとめて見せ、対応を実行する	インシデントの一覧、攻撃の流れの表示、端末の隔離やアカウントの無効化の実行、他の仕組みへの連携

補足：OCSFとは

第2層で使われる共通形式の一つに、OCSF（Open Cybersecurity Schema Framework）があります。製品ごとにバラバラなセキュリティログの項目を、共通の形で表すためのオープンな仕様です。2022年8月にAWSとSplunkが中心となって発表され、2024年にLinux Foundationの下で運営されるようになりました。

企業ネットワークでの構成例

ここからは、メーカーを特定せずに、企業ネットワークにありそうな構成で見ていきます。想定は、本社と支社があり、メールやID基盤をクラウドで使っている企業です。

構成例：クラウドのXDR基盤にログを集める

図4　企業ネットワークでのXDR構成例（想定）。矢印は、ログの送信と、隔離などの対応指示の両方向を表します

本社と支社のPC、本社のサーバにはEDRのエージェントを入れます。FWのログも送りますが、FWなどの機器からの送り方は、次の章で説明します。
クラウド型の製品では、拠点にログ収集用のサーバを置かなくても、エージェントからクラウドへ直接送る構成が取れる場合があります。
メール、ID基盤、クラウドストレージは、APIなどで連携してログを取り込みます。
XDR基盤が相関と検知を行い、SOC（セキュリティ運用の担当チーム）や情報システム部門の担当者がインシデントを確認します。
必要に応じて、SIEMでの長期保管や、チケット管理への連携を行います。隔離などの対応指示は、エージェントやAPI連携を通じて各場所へ返します。

メーカーの範囲外のログは、どう集めるのか

XDRを入れるときに悩みやすいのが、「導入するメーカーの製品の中はつながるとして、それ以外のログはどうするのか」という点です。この章では、まずログの届け方を整理します。そのうえで、どこまで同じメーカーでそろえるかによる3つのパターン（A・B・C）を、端末にエージェントを入れる必要があるか、中継サーバが必要かに注目して説明します。

この章の注意

この章は、メーカーを特定しない一般例です。何が標準で取り込めるか、エージェントや中継サーバが必要か、どの機器に対応しているかは、製品、バージョン、ライセンスによって異なります。
導入や設計の前に、必ずメーカーや販売元に、自社の機器と構成で成り立つかを確認してください。

ログの届け方は大きく4種類

XDR基盤にログを届ける方法は、送り元によって決まります。大きく分けると、次の4種類です。

図5　ログの届け方（想定）。送り元によって、エージェント、API連携、中継サーバを使い分けます

届け方	仕組み	端末への導入	中継サーバ	主な送り元
エージェント	端末に常駐ソフトを入れ、クラウドへ直接送る	必要	通常は不要	PC、サーバ
クラウド間のAPI連携	クラウドサービスどうしを、管理画面の設定とアカウントの許可でつなぐ	不要	不要	メール、ID基盤、クラウドストレージ、他社EDRの管理基盤
syslogなど＋中継サーバ	機器が社内の中継サーバへログを送り、中継サーバがまとめてクラウドへ転送する	機器側は送信先の設定のみ	必要	FW、プロキシ、スイッチ、VPN装置など
サーバのログ収集	ADサーバなどのログを、エージェントで送る。またはサーバ間でログを集約して中継サーバから転送する	場合による	場合による	ADサーバ、ファイルサーバなど

クラウドサービスは、すでにインターネット上にあるため、クラウドどうしの連携で済むことが多くなります。端末は、端末の中の細かい動きを集める必要があるため、エージェントが基本です。問題になりやすいのは、社内にあって、エージェントを入れられない機器です。

ログ中継サーバとは

ログ中継サーバは、社内の機器からログを受け取り、まとめてXDR基盤へ転送するサーバです。ログコレクタ、フォワーダなどと呼ばれることもあります。

FWやスイッチなどの機器は、ログをsyslogという形式で決まった宛先へ送る機能を持っていても、クラウドのXDR基盤へ直接送る機能は持たないことが多いため、社内に受け口を用意します。製品によっては、メーカーが専用の中継機能を提供していることがあり、汎用のサーバにログ収集用のソフトを入れる形のものもあります。

機器側の設定は、ログの送り先を中継サーバのアドレスにするだけで済むのが一般的です。
中継サーバが、受け取ったログを一時的にためて送信の失敗に備えたり、不要なログを減らして取り込み量と費用を抑えたりする製品があります。
機器から中継サーバまでのログは、暗号化（TLS）に対応する製品もあります。対応する機器と製品の組み合わせかどうかを確認します。
その分、台数の確保、冗長化、パッチ適用、容量の監視など、運用する対象が増えます。

syslogの形式はRFC 5424で定められています。ログを集めて保管する際の考え方は、NIST SP 800-92に整理されています（出典は「参考URL」を参照）。

パターンA：すべて同じメーカーでそろえる

端末、ID、メール、クラウドアプリなどの主要な場所を、同じメーカーの製品でそろえるパターンです。ネイティブ型の典型にあたります。メーカーの範囲内は、あらかじめ連携が用意されているため、追加の仕組みをほとんど考えずに済みます。

図6　パターンA：すべて同じメーカーでそろえる（一般例）

送り元	届け方	端末への導入	中継サーバ
PC・サーバ	エージェントが直接送信	必要（EDRのエージェント）	不要
メール、ID基盤、クラウドアプリ	クラウド同士のAPI連携	不要	不要
FW、プロキシ、ADサーバなど（メーカーの外側）	syslogなどで中継サーバへ。メーカーによっては専用エージェントが用意されている	機器側は送信先の設定。サーバは専用エージェントの場合もある	必要になることが多い

メーカーの範囲内は、管理画面で連携を有効にし、アカウントの許可を与えるだけで取り込める、という進め方が多くなります。
外側にある機器のログは、標準では取り込めないことがあります。中継サーバで取り込むのか、取り込まずに別の運用にするのかを決めます。
向くのは、特定のメーカーの製品をすでに多く使っている環境です。他社の製品が多いほど、追加の作業が増えます。

パターンB：EDRメーカーを軸に、足りない部分をつなぐ

端末のEDRは軸にするメーカーのものを使い、そのメーカーのログ取り込みの仕組みへ、FWやID基盤など他社のログも集めるパターンです。端末のデータはエージェントで集まりますが、それ以外は取り込み設定が必要になります。

図7　パターンB：EDRメーカーを軸に、足りない部分をつなぐ（一般例）

送り元	届け方	端末への導入	中継サーバ
PC・サーバ	エージェントが直接送信	必要（EDRのエージェント）	不要
他社のメール、ID基盤、クラウドアプリ	クラウド同士のAPI連携。取り込み用の部品はコネクタ、統合などの名前で用意される	不要	不要
FW、プロキシ、ADサーバなど	syslogなどで中継サーバへ送り、クラウドへ転送	機器側は送信先の設定。サーバはエージェントや転送設定	必要になることが多い

「コネクタ」は、特定のサービスや機器のログを取り込むための連携部品です。用意されているサービスは設定で取り込め、用意されていない機器は、中継サーバでsyslogなどの汎用の形式で受けることになります。
中継サーバには、軸にするメーカーが用意する収集用のソフトを使う場合と、汎用のサーバにsyslogの受信を設定する場合があります。名称と提供の形はメーカーによって異なります。
他社のログは、項目の読み取り（パース）と形式のそろえが必要です。使いたい製品の形式に対応しているかを確認します。
FWのログは量が多く、取り込み量に応じて費用が変わる製品では、費用に影響します。
向くのは、複数のメーカーの製品が混在していて、EDRを軸に検知を広げたい環境です。

パターンC：SIEMメーカーを軸に、すべてを集めて検知する

すでにSIEMを運用している環境で、SIEMを全体のログの集約先にして、XDRのような検知と対応を実現するパターンです。端末の守りには、別のメーカーのEDRを使っていることが多く、SIEMから見ると、ほとんどが「他社製品から運んでくるログ」になります。

図8　パターンC：SIEMメーカーを軸に、すべてを集める（一般例）

送り元	届け方	端末への導入	中継サーバ
PC・サーバ（OSのログ）	SIEM側の収集エージェントで送信	必要（EDRとは別のエージェント）	不要
EDR製品の警告	EDRの管理基盤からAPIなどで取得	不要（EDRは導入済み）	不要
メール、ID基盤	クラウド同士のAPI連携	不要	不要
FW、プロキシ、ADサーバなど	syslogなどで中継サーバへ。ADサーバなどはエージェントの場合もある	機器側は送信先の設定	必要になることが多い

SIEMは幅広い機器の取り込みに対応していることが多く、すでに社内にログ収集用のサーバがある場合は、それを使い続けられることがあります。
端末の詳しいデータ（プロセスの動きなど）はEDR側に残り、SIEMには警告や要約が届く構成が一般的です。詳しい調査はEDRの画面で行うことになります。
端末の隔離などの対応は、SIEMからEDR製品のAPIを呼ぶか、SOARで手順を組んで実現します。あらかじめ用意された機能ではなく、作り込みが必要になることがあります。
向くのは、SIEMをすでに運用していて、長期保管などの要件がある環境です。警告がSIEMとEDRで二重に出ないよう、役割分担を決めておきます。

3つのパターンの比較

項目	A 同じメーカー	B EDR軸	C SIEM軸
端末のエージェント	EDRのエージェントのみ	EDRのエージェントのみ	EDRに加えて、OSログ用の収集エージェントが必要な場合がある
クラウドサービス	標準の連携	コネクタなどで連携	API連携を設定
中継サーバ	メーカーの外側の機器のみ	他社の機器やサーバ	ほぼすべての社内機器
対応の指示	標準機能	自社EDRは標準。他社製品は連携しだい	API連携やSOARで作り込む
設定と運用の量	少なめ	中くらい	多め

自社の環境に当てはめるときは、次の順に確認すると整理しやすくなります。

端末にエージェントを入れられるか、すでに入っているEDRはどれか。
メールやID基盤などのクラウドサービスが、API連携で取り込めるか。
残るFW、プロキシ、ADサーバなどの台数と、中継サーバを置く場所、運用する人。
隔離などの対応を、どの製品に、どの経路で指示するか。

攻撃の流れで見るXDRの動き

XDRが効く場面を、想定例で確認します。実際の事案ではありません。社員がメールの添付ファイルを開いてから、データが持ち出されるまでの流れを考えます。

図9　攻撃の流れと、XDRによる警告の集約（想定例）

場所	単体で見たとき	XDRで見たとき
① メール	「不審なメール」の警告が1件。受信者が開いたかどうかは分からない。	同じ受信者の端末で起きた動きとつながる。
② 端末	「OfficeからPowerShellが起動」の警告が1件。正規の管理作業に見えることもある。	直前に届いたメールの添付とつながり、攻撃の起点と判断しやすくなる。
③ ID	「普段と違う場所からのサインイン」の警告が1件。出張の可能性もある。	同じユーザーの端末で不審な動きがあった直後のサインインとして見える。
④ ネットワーク	内部の別の端末への接続が増えたという警告が1件。	同じ端末が起点であることが分かる。
⑤ クラウド	大量ダウンロードの警告が1件。	同じアカウントの操作とつながり、持ち出しの可能性が高いと判断できる。

担当者は、5件の警告を別々の画面で見比べる代わりに、1件のインシデントとして順に確認できます。影響を受けた端末とアカウントが一覧でき、製品によっては、端末の隔離とアカウントの停止を同じ画面から実行できます。

注意

警告がつながるのは、同じユーザーや端末など、共通の手がかりがデータに含まれているときです。データを取り込んでいない場所で起きたことは、XDRからも見えません。
端末の隔離やアカウントの無効化を自動で行うと、誤検知のときに業務へ影響します。どこまでを自動にするかは、運用の体制と合わせて決めておく必要があります。

SIEM・SOARとの違い

XDRと似た言葉に、SIEMとSOAR（対応手順を自動化する仕組み）があります。3つは競合するというより、担当する範囲が違います。次の表は、一般的な傾向で比べたものです。

名称	主な役割	主な入力	検知のしかた	対応
SIEM	さまざまなログを集めて保管し、検索や検知に使う。監査対応や長期保管にも使う。	幅広い機器・サービスのログ	相関ルールを用意し、調整して使うのが一般的（製品が検知ルールを用意している場合もある）	通知が中心。実行は他の仕組みと連携して行うことが多い
SOAR	対応の手順（プレイブック）をワークフローとして自動化する。	他の製品が出した警告やケース	検知は行わず、受け取った警告を起点に動く	調査・通知・隔離などの手順を自動実行する
XDR	複数の場所のデータを相関させ、検知から対応までをまとめて行う。	自社のセンサーや、連携した製品のデータ	製品側が用意した検知の仕組みで、関連する警告を1件にまとめる	端末の隔離など、よく使う対応は製品の機能として用意されている

使い分けの目安は次のとおりです。ログの長期保管や、機器を問わない幅広い集約が必要ならSIEM、複雑な手順や他システムを巻き込む自動化が必要ならSOAR、端末やIDなど主要な場所の検知と対応をまとめて始めたいならXDRです。実際には、XDRの警告をSIEMに集める構成や、XDRとSOAR・SIEMの機能が一つの製品にまとまっている例もあります。名前だけで判断せず、何を取り込み、どこまで自動化できるのかを確認することが大切です。

導入前に確認したいこと

確認すること	見ておく点
取り込みたいデータ	端末だけか、ID、メール、クラウドまで含めるか。取り込める範囲は、製品とライセンスで異なる。
メーカーの範囲外のつなぎ方	端末にエージェントが必要か。FWやADサーバなどに中継サーバが必要か。中継サーバの構築と運用を誰が行うか。
既存製品との連携	いま使っているEDR、FW、ID基盤と連携できるか。ログの取り込みだけか、対応の指示まで出せるか。
自動対応の範囲	端末の隔離やアカウントの無効化を、どこまで自動で行うか。誤検知のときの影響を踏まえて決める。
運用する人	誰がインシデントを確認するか。夜間や休日はどうするか。自社で難しければ、MDR（運用代行サービス）も選択肢になる。
データ量と費用	取り込み量で費用が変わる製品がある。ログの保管期間の要件も合わせて確認する。

まとめ

項目	ポイント
XDRとは	端末、メール、ID、ネットワーク、クラウドのデータをまとめて検知し、対応する仕組み
EDRとの違い	EDRは端末の中を詳しく見る。XDRは複数の場所の出来事をつなげて、1件のインシデントにする。
生まれた背景	製品ごとに別々の警告を、人が結びつける負担が大きかった。SIEMとEDRだけでは埋まらない部分があった。
基本構成	データ収集、正規化・蓄積、相関・検知、インシデント管理・対応の4層
範囲外のつなぎ方	端末はエージェント、クラウドはAPI連携、社内の機器は中継サーバ、という使い分けが基本
選ぶときの軸	取り込みたい範囲、既存製品との連携、自動対応の範囲、運用する体制

XDRは製品名ではなく、複数の場所のデータをつなげて検知と対応を行うという考え方です。メーカーごとに実装は違いますが、4つの機能レイヤーで見ると、どの製品も同じ流れで説明できます。製品を比べるときは、この4つの層のどこが強く、メーカーの範囲外をどうつなぐのか（エージェント、API連携、中継サーバ）を確認すると、違いが見えやすくなります。実際の実装は、必ずメーカーや販売元に確認してください。

参考URL

調べた時点（2026年10月）の公開情報です。最新の内容は各社の公式ドキュメントで確認してください。