公開2026.07.09更新2026.10.01 セキュリティ

XDRとは？EDRとの違いと相関分析の仕組み・導入判断を実装者向けに解説【2026年時点】

XDR（Extended Detection and Response）は、エンドポイントだけを見るEDRの検知を、ネットワークやメール、クラウド、アイデンティティといった複数のレイヤーへ広げ、それぞれのログを相互に関連付けて脅威を追う統合基盤です。攻撃が端末単体で完結せず、メールの添付から端末侵入、権限昇格、クラウドへの横展開と連鎖する現実に対し、点在するアラートを1つのインシデントへ束ねて全体像を見せる側を担います。この記事では、XDRが集めるテレメトリの範囲、個別アラートを攻撃チェーンへ相関する分析の仕組み、EDR・SIEM・MDRとの役割分担、ネイティブ型とオープン型の選び方、そして受託開発で自社システムのログをXDRへ連携させるときの設計指針までを、実装する側の視点で整理します。手元で試せる相関クエリと認証ログのJSON例も載せました。

まとめ：XDRはEDRの検知を複数レイヤーへ広げて相関する統合基盤

XDRは、EDRが端末で捉えた振る舞いを起点に、メール・ネットワーク・クラウド・IDのログまで横断して突き合わせ、バラバラに上がるアラートを1本の攻撃シナリオへつなぎ直す層だと捉えると位置づけを掴みやすくなります。EDRが「端末という点」を見張るのに対し、XDRは点と点を結んで「攻撃の線」を再構成する側で、どのメールから侵入が始まり、どの端末を踏み台にして、どのクラウド資産へ到達しようとしたかを一連の流れで示します。攻撃が単一レイヤーで完結しなくなった流れのなかで、レイヤーごとに分断された検知を横につなぐ役割として広がりました。

導入の判断は、製品カタログの機能数やSERPの順位ではなく、守るべきレイヤーの広がりと、相関で上がった高確度アラートを裁く運用体制の有無で決めます。端末に加えてメール・クラウド・IDまで攻撃面が分散し、各製品のアラートを人が突き合わせきれずに取りこぼしている組織ほど、相関の費用対効果が見合う構造です。逆に、守る対象がまだ端末中心で、EDRのアラートすら裁ききれていない段階でXDRへ広げると、相関で束ねる元データが薄いまま運用負荷だけが増えます。まずEDRで端末の検知と運用を固め、レイヤーをまたぐ攻撃の取りこぼしが実際に見えてから広げる順序が、投資を生かす線引きです。相関の精度はIDの名寄せで決まるため、導入前に自社データで突き合わせを一度試しておくと判断を誤りにくくなります。

XDRの定義と対象範囲＝複数レイヤーのテレメトリを相関する仕組み

XDRという略語は Extended Detection and Response の頭文字で、Extended（拡張された）が示すとおり、EDRの検知対象をエンドポイントの外へ広げた点が名前の核です。守る単位は端末に限らず、端末・ネットワーク・メール・クラウド・アイデンティティにまたがるテレメトリで、それらを一つの基盤へ集約して相関させます。

XDRが提唱された背景とEPP・EDRだけでは追えない攻撃チェーン

XDRという言葉は、Palo Alto Networks が2018年に打ち出したのが広がりの起点とされ、その後 Gartner なども定義を整理してきました。背景にあるのは、EPPで入口を予防し、EDRで端末の侵入後を検知しても、攻撃全体は端末の外にまたがるという課題です。フィッシングメールで認証情報を奪い、正規のクラウドサービスへ正規アカウントでログインする攻撃は、端末上に不審な挙動をほとんど残さず、EDR単体の視野からはこぼれます。レイヤーごとに別々の製品がアラートを上げても、それらを人が手作業で突き合わせるまで攻撃チェーンは見えません。この分断を、検知の段階で機械的につなぐために生まれたのがXDRの発想です。エンドポイント側の詳しい検知ロジックは、XDRが内包するEDRの検知の仕組みと導入判断を実装者向けに解説した記事と合わせて読むと、XDRが「端末の検知を土台に他レイヤーへ拡張した発展形」だという関係が掴めます。

XDRが束ねるテレメトリ（端末・ネットワーク・メール・クラウド・ID）

XDRの中身を実装の目線で分解すると、まず各レイヤーの検知製品やログソースからテレメトリを取り込む収集層があります。取り込む対象は、EDRが出す端末のプロセス・通信のイベント、ネットワークの通信フロー、メールゲートウェイの添付やURLの判定、クラウドサービスの監査ログ、そして認証基盤のサインインイベントです。これらを共通のスキーマへ正規化してから相関にかける点が、単に各製品のアラートを一画面に並べる統合ダッシュボードとの違いです。アイデンティティ層の異常検知は、XDRが束ねる一レイヤーとして独立した検知でもあり、ITDRによる認証・ID基盤の異常検知を実装目線で整理した記事を押さえると、XDRがIDの信号もチェーンの一部として取り込む構造が具体化します。

Defender XDRの公式定義で確かめる対象レイヤーと製品の範囲

ネイティブ型の代表例で中身を確かめます。Microsoft Defender XDRの公式ドキュメントは、同製品をエンドポイント・ID・メール・アプリケーションにまたがって検出から対応までを連携させる防御スイートと定義し、信号の出どころに Defender for Endpoint（端末）、Defender for Office 365（メール）、Defender for Identity（ID基盤）、Defender for Cloud Apps（SaaS）などを並べています。見落としやすいのは、相関の対象がライセンスを持ちプロビジョニング済みの製品の信号に限られるという但し書きです。メール側の製品を契約していなければ、メール起点の攻撃チェーンは相関されないため、効果は実際に流れ込むレイヤーの信号で見積もります。

XDRの相関分析の仕組みと攻撃チェーンを1件に束ねる検知クエリ

集めたテレメトリを、どう一本の攻撃として束ねるか。ここがXDRの心臓部で、EDRの振る舞い検知を「レイヤーをまたいで連結する」方向へ拡張した設計になっています。

個別アラートを1インシデントへ相関するデータ基盤と分析エンジン

相関の土台は、各レイヤーから正規化して集めたテレメトリを蓄えるデータ基盤です。メールの添付が開かれ、続いて端末で見慣れない子プロセスが起動し、同じ端末から普段と違うクラウドへ通信が走る——こうした別レイヤーの単発イベントを、時間軸と共通の識別子（端末・ユーザー・IPなど）でつなぎ、1つのインシデントとしてまとめ上げます。個々のアラートを独立して裁くと数十件の警告になるところを、XDRは一連の攻撃として1件に集約するため、担当者が突き合わせに費やす時間を圧縮できます。設計の勘所は、相関のキーをどれだけ揃えられるか。端末IDやユーザーIDがレイヤー間で名寄せできないと、同じ攻撃が別インシデントに割れて相関が効きません。

Defenderポータルのインシデントとアラートの解説も、相関エンジンが関連アラートを自動で集約してインシデントを作り、開いているインシデントへ後から証拠を足し続けると説明しています。調査の起点がアラート単位からインシデント単位へ移るのが運用上の変化です。

高度な追及のKQLでメール添付から端末のスクリプト起動をつなぐ

同じ突き合わせを手で書くと仕組みが見えます。高度な追及（Advanced hunting）の概要によると、クエリで遡れるのはDefender XDRの生データで最大30日分、時刻はUTCで扱う仕様です。次は、メール添付と端末上のファイルを名前と受信者で突き合わせ、30分以内に同じ端末でスクリプトエンジンが起動した流れだけを抜き出す例です。

let lookback = 1d;
let attachments = EmailAttachmentInfo
| where Timestamp > ago(lookback)
| where FileName matches regex @"(?i)\.(docm|xlsm|iso|lnk|zip)$"
| project MailTime = Timestamp, NetworkMessageId,
          Upn = tolower(RecipientEmailAddress), FileName;
attachments
| join kind=inner (
    DeviceFileEvents
    | where Timestamp > ago(lookback)
    | project FileTime = Timestamp, DeviceId, DeviceName, FileName,
              Upn = tolower(InitiatingProcessAccountUpn)
  ) on FileName, Upn
| where FileTime between (MailTime .. (MailTime + 30m))
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(lookback)
    | where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "mshta.exe")
    | project ProcTime = Timestamp, DeviceId, Script = FileName, ProcessCommandLine
  ) on DeviceId
| where ProcTime between (FileTime .. (FileTime + 30m))
| project MailTime, FileTime, ProcTime, DeviceName, Upn, FileName, Script, ProcessCommandLine
| order by MailTime desc

相関キーにハッシュでなくファイル名と受信者を選んだのは、EmailAttachmentInfoテーブルのスキーマでSHA256列が「通常は値が入らない」と注記され、SHA1列も無いためです。相手のDeviceFileEventsテーブルもSHA256は通常空で、ハッシュで結ぶと結合がほぼ当たりません。同じ値を持つ列を先にスキーマで確かめるのが相関設計の最初の作業で、UPNを小文字へそろえるのも表記ゆれで攻撃チェーンが割れるのを防ぐためです。

1日で数件なら検知ルールへ昇格させ、数十件以上なら拡張子や送信元ドメインの除外条件を足すのが目安です。この件数はXDRのインシデント件数を測る物差しにもなります。

MITRE ATT&CK v19系の戦術で攻撃段階を可視化する仕組み

束ねたイベントを、どの攻撃段階に相当するかで意味づけするのが次の層です。多くのXDRは、相関したイベント列を攻撃手法の分類体系である MITRE ATT&CK の戦術・技術へマッピングし、初期侵入から権限昇格、横展開、持ち出しまでのどこにいるかを一連の流れで見せます。単発では弱いシグナルでも、初期侵入・実行・C2通信が同じ攻撃シナリオ上で連鎖したときにリスクを引き上げる、という束ね方は、EDRの振る舞い検知をレイヤー横断へ広げたものです。誤検知の抑え方も同じ思想で、業務で常用するツールの単発イベントは除外しつつ、除外がチェーンの穴にならないよう、相関後の攻撃段階のスコアで最終判定する構成にすると精度を保ちやすくなります。

参照する版は固定ではない点に注意が要ります。ATT&CKのバージョン履歴では2026年4月28日から19系が現行で、2026年10月時点の表示はv19.2です。Enterpriseの戦術一覧は15戦術で、従来 Defense Evasion だったTA0005が Stealth という名前になり、Defense Impairment（TA0112）が別の戦術として並んでいます。戦術IDで検知を集計している場合、版をまたぐとこの改称と分割で集計がずれるため、使う版を明記してから差分を当てます。

EDR・SIEMとの違いとネイティブ型・オープン型XDRの選択軸

XDRは似た略語や隣接領域の製品と守備範囲が重なるため、まず違いを一枚の表で押さえ、そのうえで製品タイプの選び方に進みます。

EDR・XDR・SIEM・MDRの守備範囲の違いを一枚の表で整理

それぞれが担う層と、検知・運用の起点で並べると役割分担が見えます。

分類	主な役割	対象・起点
EDR	端末の検知・対応	エンドポイントの振る舞い
XDR	複数レイヤーの相関検知	端末＋通信＋メール＋クラウド＋ID
SIEM	ログの集約・分析	全ログを横断（要チューニング）
MDR	監視運用の外部委託	人による監視・一次対応

XDRとSIEMは対象が重なりますが、性格が違います。SIEMはあらゆるログを集めて自由に相関ルールを書ける汎用基盤で、検知の設計と維持を自社が担う前提です。XDRは検知製品側があらかじめ相関ロジックを用意し、セキュリティ用途に寄せて出荷される点で、導入から検知が立ち上がるまでの手間が軽い代わりに、対応レイヤーは製品が想定した範囲に収まります。SIEM側の取り込み設計はSIEMとは？仕組みとEDR・XDR・SOARとの違いを解説した記事で整理しました。MDRは製品分類ではなく、EDRやXDRの監視と初動対応を外部の専門チームへ委託する運用サービスです。

ネイティブ型XDRとオープン型XDRの違いと環境に応じた選び方

XDRは大きく二タイプに分かれます。ネイティブ型（シングルベンダー型）は、同一ベンダーのEDR・メール・ネットワーク・クラウド製品でレイヤーを揃える形で、相関の精度と導入の手軽さが出やすい反面、既存資産をそのベンダーへ寄せる前提になります。オープン型（ハイブリッド型）は、既存の他社製EDRやファイアウォール、クラウドのログを取り込んで相関する形で、いま入っている製品を残せる代わりに、コネクタの整備とデータ正規化の作り込みが自社側に残るのが特徴です。選ぶ軸は、既存のセキュリティ製品をどれだけ残したいか、そして正規化やコネクタ維持の工数を自社で持てるか、の二点です。ゼロから揃えるならネイティブ型、既存資産が多様でロックインを避けたいならオープン型が向きます。

この境界は製品の世代で動いています。Microsoft系では、SIEMのMicrosoft SentinelをDefenderポータルへオンボードすると相関エンジンがSentinelの生データにも届くと上記のインシデント解説にあり、ネイティブ型にオープン型の取り込み口が付いた形です。課金の見積もり方はMicrosoft Sentinelの料金モデルとDefenderポータル統合の解説にまとめました。

XDRの導入を判断する条件と受託開発で相関基盤を組み込む設計指針

ここからは判断の章です。機能の横並び比較ではなく、「自組織に要るのか」「作り込むなら何に気をつけるのか」を条件付きで言い切ります。

XDRを導入すべき組織の条件と運用体制が伴わず過剰投資になる場面

XDRの費用対効果が出やすいのは、守る攻撃面が端末の外まで分散し、EDR・メール・クラウド・ID基盤のアラートを人が突き合わせきれずに取りこぼしが起きている組織です。レイヤーをまたぐ攻撃が実際に来ていて、点在するアラートの相関に人手がかかっている状態なら、束ねる価値が見合います。一方で過剰投資になりやすいのは、守る対象がまだ端末中心で、EDRのアラートすら裁ける体制がない段階でXDRへ広げる場合です。相関の材料になるレイヤーが揃っていないと、XDRを入れても束ねる元データが薄く、運用負荷だけが増えます。守るかどうかは、攻撃面が複数レイヤーへ広がっているか、相関で束ねる元データが揃うか、そして高確度アラートを裁く体制があるかの三点で決めます。人手が確保できないなら、XDRの監視を外部に委託するMDRを含めた構成で見積もるのが現実的な線引きです。内製と委託の分岐はSOCとは？監視運用の仕組みと内製・アウトソースの判断を解説した記事で扱っています。

SIEM・SOARとの役割整理とXDRへ寄せるか併存させるかの判断

XDRとSIEM・SOARは対象が重なるため、どちらへ寄せるかを設計時に決めておかないと二重投資になります。既にSIEMで全ログの集約とコンプライアンス用途の保管まで回しているなら、XDRは検知と相関の即応レイヤーに絞り、長期保管や独自ルールはSIEMへ残す併存が現実的です。逆にセキュリティ検知が主目的で、SIEMのルール維持に人手を割けないなら、XDRへ検知を寄せて構成を単純にするほうが破綻を避けられます。対応の自動化はSOARが担う領域で、XDRが相関で確度を上げたインシデントを起点に、端末隔離やアカウント一時停止のプレイブックを走らせる連携にすると初動が速くなります。設計時は、XDR単体の相関だけで自動遮断まで踏み込むと誤検知の影響が広範囲に及ぶため、複数レイヤーで裏の取れた高確度インシデントに自動アクションを絞り、それ以外は担当者の確認を挟む二段構えが安全です。

NIST SP 800-61r3の対応工程にXDRの自動対応を割り当てる手順

米国NISTはSP 800-61 Rev.3（インシデント対応の推奨事項）を2025年4月に公開し、2012年のRev.2を置き換えました。Rev.3は対応活動をサイバーセキュリティフレームワーク2.0の機能に対応づける構成です。

XDRに当てはめると、相関とインシデント化は検知、隔離やアカウント停止は対応の機能にあたります。手順は三段で、自動実行してよいアクション（端末隔離・セッション失効・メール削除など）ごとに求める裏付けのレイヤー数を決め、識別の機能として資産台帳とIDの棚卸しを先に整え、復旧の機能として隔離解除の判断者を明文化します。台帳が薄いと、止めてよい端末かを誰も判断できません。

受託開発で自社システムのログをXDRへ連携させる設計の注意点

自社サービスや業務システムをXDRの視野に入れる場合、いきなり独自の相関エンジンを書くより、アプリケーションの認証・操作ログを共通スキーマへ整えてXDRやSIEMのコネクタへ流すところから始めるのが堅実です。相関の効きはキーの名寄せで決まるため、ユーザーIDや端末ID、セッションIDをレイヤー間で突き合わせられる形で出力できるよう、ログ設計の段階で識別子を揃えておくのが要点になります。私たちが受託開発で扱う際も、まず何を相関のキーにするか、どのイベントを検知トリガーにするかを業務側と握ってからログ出力の実装に入る手順を取ります。侵入を前提に複数レイヤーで検知と対応を重ねる考え方は、境界の内外で信頼を分けないゼロトラストの防御思想（境界型防御との違いとNIST7原則）とも地続きです。こうした複数レイヤーのログ連携や検知基盤の設計・実装は、AIセキュリティ対策の受託開発として相談を受けています。入口の弱点を先に実測したい場合は、脆弱性診断・セキュリティ診断で攻撃面を洗い出してから検知設計に入る順序をおすすめしています。

OCSF 1.9系のAuthenticationクラスで認証ログを出力する例

共通スキーマの候補がベンダー横断のOCSF（Open Cybersecurity Schema Framework）です。OCSFスキーマブラウザのAuthenticationクラスは2026年10月時点で安定版v1.9.0、認証イベントはクラスID 3002です。必須属性はactivity_id・class_uid・type_uid・severity_id・time・userなどで、type_uidはクラスIDの100倍にactivity_idを足した値（ログオンなら300201）になります。ログイン失敗の最小に近い例です。

{
  "category_uid": 3,
  "class_uid": 3002,
  "activity_id": 1,
  "type_uid": 300201,
  "severity_id": 3,
  "time": 1790845200000,
  "status_id": 2,
  "is_mfa": false,
  "auth_protocol_id": 4,
  "user": { "uid": "u-10482", "name": "[email protected]" },
  "src_endpoint": { "ip": "203.0.113.24" },
  "session": { "uid": "s-7f3a9c" },
  "metadata": {
    "version": "1.9.0",
    "product": { "name": "order-portal", "vendor_name": "example" }
  }
}

status_idの2は失敗、auth_protocol_idの4はOpenIDを表す列挙値です。勘所はuser.nameにXDR側のID基盤（Entra IDのUPNなど）と同じ値を入れることで、ずれていると失敗ログインと端末やメールのイベントが同じ人物として結ばれません。定義はOCSFのスキーマリポジトリで版ごとに管理されるため、metadata.versionに準拠版を書いておきます。

よくある質問

XDRの導入や隣接ソリューションとの違いについて、実装や選定の現場で挙がりやすい質問に答えます。

XDRとEDRはどちらを選べばよいですか？

守る範囲で選びます。守りたい対象がエンドポイント中心ならEDR、端末に加えてメールやクラウド、IDまで横断して攻撃チェーンを追いたいならXDRが向きます。XDRはEDRの端末検知を内包して他レイヤーへ広げた発展形にあたるため、まずEDRで端末の検知と運用を固め、レイヤーをまたぐ取りこぼしが見えてからXDRへ広げる順序が現実的です。

XDRを導入すればSIEMは不要になりますか？

用途が重なる部分はありますが、置き換えを前提にはできません。XDRはセキュリティ検知に寄せて相関ロジックが用意された基盤で、検知と即応に強みがあります。SIEMは全ログを集約して長期保管やコンプライアンス用途、独自の相関ルールまで担う汎用基盤です。Defender XDRの高度な追及も遡れるのは30日分に限られます。検知はXDRへ寄せ、保管や監査用途はSIEMに残す併存構成が現実的な落とし所です。

XDRとMDRは何が違うのですか？

層が違います。XDRは複数レイヤーのテレメトリを相関して検知する製品・基盤で、MDRはその監視と一次対応を外部の専門チームへ委託する運用サービスです。XDRを導入しても、上がったインシデントを判断して初動を打つ人手は要ります。SOC人材を確保しづらい場合に、XDRの見張りと初動をMDRへ委託する組み合わせが取られます。

オープン型XDRとネイティブ型XDRはどちらがよいですか？

既存資産と工数で選びます。セキュリティ製品をゼロから揃えるなら、同一ベンダーで相関精度と導入の手軽さが出やすいネイティブ型が有力な候補です。すでに他社製のEDRやファイアウォールが多様に入っていて残したいなら、それらを取り込めるオープン型が向きますが、コネクタ整備とログ正規化の工数が自社側に残る点を見込んでおく必要があります。

中小規模の組織にもXDRは必要ですか？

攻撃面と体制しだいです。守る対象がまだ端末中心で、EDRのアラートを裁くだけで手一杯なら、先にEDRとログ監視を固めるほうが投資が生きます。メールやクラウド、SaaS利用が広がり、レイヤーをまたぐ攻撃の取りこぼしが実際に見え始め、かつ相関後のアラートを運用できる体制か監視委託を用意できるなら、XDRへ広げる価値が高まります。