Intune の Microsoft Defender Antivirus レポートでは端末が 1121 台なのに、Microsoft 365 Security（Defender）ポータルでは 2710 台と表示される――この差は設定ミスではなく、見ている“デバイスの範囲”が違うことが主因です。本記事では、両者の集計スコープと「Endpoint Security」と「Defender for Endpoint」の役割分担、数字を突き合わせる具体手順をまとめます。
結論：台数が違うのは「正常」。集計スコープ（対象範囲）が違うだけ
まず結論から言うと、Intune の Defender レポートと Microsoft 365 Security（Microsoft Defender ポータル）の表示は、似て見えても“同じ母集団を見ているダッシュボード”ではありません。そのため、台数が一致しないのはむしろ自然です。
代表的には、次の違いが効いてきます。
- Intune 側：Intune 管理（MDM 登録など）の文脈で「管理対象端末の Defender Antivirus 状態・検出情報」を集計しやすい
- Defender ポータル側：Defender for Endpoint（MDE）として「ネットワーク上で見えているデバイス」を広く棚卸しし、オンボード済み／未オンボード（検出のみ）も含めて表示しうる
まずは用語整理：この2つを混ぜると必ず迷う
| 項目 | Intune（Endpoint Security / Defender Antivirus レポート） | Microsoft Defender ポータル（Microsoft 365 Security / MDE） |
|---|---|---|
| 立ち位置 | 管理（ポリシー配布・状態監視）側の入口 | 検知・調査・対応（EDR/XDR）側の基盤 |
| 主なデータ源 | Intune の管理下で上がってくる Defender Antivirus の状態・検出情報 | MDE のセンサー/テレメトリ、およびデバイス検出（Device discovery） |
| 台数が増えやすい条件 | Intune に登録されている端末が増えるほど増える | オンボード済み端末に加え、未オンボードの“検出のみ”デバイスやネットワーク機器/IoT も含みうる |
| 現場での使い分け | 構成を正す・コンプライアンスと紐づける・端末運用を回す | 脅威の一次情報（アラート）を見て調査・封じ込め・復旧を回す |
なぜ「1121 台」と「2710 台」のような大きな差が出るのか
Intune 側（Defender Antivirus レポート）が数えやすい“端末”
Intune で Defender Antivirus の状況をレポートとして確認する導線は、たとえば以下のように「Intune のレポート（Endpoint security 配下）」として提供されています。
- Intune 管理センター → Reports →（Endpoint security）→ Microsoft Defender Antivirus →（Reports）→ Detected malware
このレポートは、基本的に「Intune の管理コンテキストで Defender Antivirus 情報を報告できている端末」を中心に集計されます。つまり、Intune に入っていない端末、あるいは Intune にいても必要なレポートが上がっていない端末は、台数に乗りにくくなります。
Defender ポータル側（デバイス インベントリ）が数えやすい“デバイス”
一方、Microsoft Defender ポータルの「デバイス インベントリ」は、そもそも発想が棚卸し寄りです。ドキュメント上も「アラートが生成されたネットワーク上のデバイス一覧」を表示し、既定では「直近 30 日に確認されたデバイス」を表示すると説明されています。
さらに重要なのが、デバイス インベントリがオンボード済みデバイスだけでなく、デバイス検出（device discovery）で“ネットワーク上で見つかったデバイス”によっても populated（充填）される点です。これが、Intune の数字より大きくなりやすい最大要因です。
Defender ポータルで台数が膨らむ「よくある内訳」
「2710 台」のように大きくなり得る代表例を、Defender ポータルの機能仕様と照らして整理すると、次のパターンがほぼ当てはまります。
| 増える原因 | Defender ポータル側で起きること | Intune 側に乗りにくい理由 | 確認のコツ |
|---|---|---|---|
| 未オンボード（検出のみ）の端末が混ざる | 「Onboarding status」が Can be onboarded のデバイスが表示される | Intune 管理ではない／MDE へのオンボードが未完了 | デバイス インベントリのフィルタで Onboarding status を確認 |
| ネットワーク機器や IoT/OT も含まれる | タブに Network devices、IoT/OT devices が存在し、合算で Total が大きくなる | Intune 管理対象外であることが多い | Computers & mobile タブに絞って比較する |
| “新規検出”や“未分類”が混ざる | 上部カウントに Newly discovered や Not onboarded が出る | 端末台帳が固まっていない段階のデバイスも入り得る | 「いつ見えたか（First seen / Last device update）」を合わせる |
| 管理元が Intune 以外（MDE/ConfigMgr/Unknown） | フィルタに Managed by があり、Intune / ConfigMgr / MDE / Unknown が混在 | そもそも Intune 管理ではない | Managed by = Intune に絞ると差が縮む |
| 同名デバイスが二重に見える | 「検出のみ（can be onboarded）」と「オンボード済み」が別 ID で併存することがある | Defender 側の在庫データが収束するまでタイムラグがある | MAC アドレスやデバイス ID の扱いを理解して整理する |
“Can be onboarded” が増える仕組み：Device discovery を知ると腑に落ちる
Defender for Endpoint には、オンボード済み端末を起点にネットワーク上の未管理デバイスを見つける Device discovery 機能があります。Discovery にはモードがあり、例えば Basic はオンボード済み端末がネットワークイベントから近隣デバイス情報を“受動的に”抽出し、ネットワークトラフィックを新たに起こさない形で一覧化します。Standard は観測したデバイスに対して追加の情報を得るために（影響を抑えつつ）よりリッチな分類に寄せていきます。
つまり、Defender ポータル側の在庫は「社内ネットワークに現れたデバイス」を取りこぼしにくく設計されており、Intune 管理台帳より多いのは自然な設計です。
二重計上っぽく見えるとき：デバイス ID の収束までの“ズレ”がある
「同じデバイス名が、オンボード済みと未オンボード（Can be onboarded）の両方に出る」ケースは、現場でもよく遭遇します。Defender 側では、デバイス検出が MAC アドレスやホスト名を軸に行われるため、最初に“検出のみ”で作られた ID と、後からオンボードしたときの ID が一時的に別扱いになることがあります。
この場合、次回のアクティブプローブ等で一致が取れると、古い “can be onboarded” 側のデバイスが削除される動きが期待される、と説明されています。台数差の追い込み時は「重複＝運用ミス」と即断せず、まずはこの仕様を前提に棚卸ししてください。
Endpoint Security と Defender for Endpoint は同じ？ → 同一ではない（ただし連携は深い）
Endpoint Security（Intune）は“管理レイヤー”。Defender for Endpoint は“検知・対応の基盤”
Intune の Endpoint Security は、アンチウイルス、ファイアウォール、ディスク暗号化などの「セキュリティ設定を、管理者が運用しやすい形で配り・監視するための入口」です。実際に、Endpoint security の Antivirus ポリシーは「管理対象デバイス向けに、アンチウイルス設定のまとまりを扱いやすくする」思想で提供されています。
一方の Microsoft Defender for Endpoint（MDE） は、端末からテレメトリを受け取り、アラート・調査・封じ込めなどを回すためのプラットフォームです。ここが“脅威の一次情報”の本丸になります。
例外的に「Intune に入っていない端末」も Intune ポリシーで管理できる：Security settings management
ここが見落とされやすいポイントです。Intune と MDE を統合すると、Intune に未登録（非 enroll）でも、MDE にオンボードしているデバイスに対して Intune の Endpoint security ポリシーを適用できるシナリオがあります。これは Defender for Endpoint security settings management と呼ばれます。
この方式では、デバイスは Microsoft Entra ID のデバイス オブジェクトを基にポリシー割り当てを受け、端末側の Defender コンポーネントがポリシーを強制・状態を報告します。Intune に MDM 登録されているデバイスは、この“security settings management 用”のポリシー処理ではなく、通常どおり Intune からの管理に従います。
脅威が「両方に載る／片方にしか載らない」は条件次第
Defender ポータル（Security ポータル）に出やすい条件
Defender ポータルに関してはシンプルで、MDE に正常にオンボードされ、センサーがテレメトリ送信できているデバイスなら、アラートやデバイスの状態が載りやすくなります。オンボードが成功し、初期テレメトリが送られると、比較的早くポータルに出てくる旨も示されています。
また、デバイス インベントリ自体は「オンボード済みのテレメトリ」だけでなく「デバイス検出による発見」でも増えるため、Defender ポータルに“存在する”＝“オンボード完了・保護完了”とは限りません（ここが誤解の温床です）。
Intune の Defender Antivirus レポートに出る条件（出ないときの典型理由）
Intune の Defender Antivirus レポートは、表示の前提条件がもう少し厳しめです。代表的には次の条件を満たして初めて「脅威（検出/状態）」が見える方向に寄ります。
- 端末が Intune 管理下（またはレポート対象として状態が上がる管理経路がある）
- Defender Antivirus がアクティブ（他社 AV が主・Defender が受動モード等だと期待通りにならないことがある）
- MDM 経由で Defender の状態/検出情報が正しくレポートされている
そのため、現場で一番多いのは「Defender ポータルにはアラートがあるのに、Intune のレポートには出ない」パターンです。この場合の原因は、だいたい “Intune 管理外”か、“Intune への状態報告が欠けている”のどちらかに収束します。
「片方だけに出る」パターン別の切り分け表
| 見え方 | 起きがちな原因 | まず見る場所 | 対処の方向性 |
|---|---|---|---|
| Defender ポータルに出る／Intune に出ない | Intune 未登録、または Intune への AV 状態報告が上がっていない | Defender の Device inventory → Managed by / Onboarding status | Intune 登録の有無を確認、必要なら管理方式を統一（MDM/SSM/ConfigMgr） |
| Intune に出る／Defender ポータルに出ない | MDE オンボードが未完了、通信不良、センサー状態不良 | Intune の EDR Onboarding Status、MDE のオンボード状況 | オンボード手順・ネットワーク/プロキシ/エンドポイント疎通を確認 |
| Defender ポータルの台数だけが増え続ける | Device discovery による検出が増えている（未オンボード含む） | Device inventory の Not onboarded / Newly discovered、Onboarding status フィルタ | 対象ネットワーク/タグ/除外の設計、オンボード計画の見直し |
数字を“合わせたい”ときの実務：両者を同じ土俵に乗せる手順
「どちらが正しいか」ではなく、「何を母集団として比較したいか」を先に決めると、一気に整理できます。おすすめは次の3段階です。
ステップ1：Defender ポータル側の母集団を“Intune に寄せる”
Defender ポータル（Assets > Devices / Device inventory）では、タブとフィルタで母集団をかなり絞れます。
- タブを Computers & mobile にする（ネットワーク機器や IoT/OT を混ぜない）
- Onboarding status = Onboarded に絞る（検出のみを除外）
- Managed by = Intune に絞る（Intune 管理端末に寄せる）
- 必要に応じて OS（Windows 10/11 など）を揃える
この段階で「2710 →（かなり縮む）」となるケースが多いです。Defender 側は既定で直近 30 日表示などの期間概念もあるため、比較する期間（いつ見た端末か）も揃えるとさらにブレが減ります。
ステップ2：Intune 側は「EDR Onboarding Status」で“Defender と接続できている端末”を把握する
Intune 側で Defender for Endpoint のオンボード状況を俯瞰するなら、Endpoint security → Endpoint detection and response → EDR Onboarding Status が非常に役立ちます。このレポートは、どの端末がオンボード済みか、センサーの健康状態（Active/Inactive/Impaired）や、管理経路（Intune / ConfigMgr tenant attach / MDE Security Settings Management）などの“橋渡し情報”を一度に確認できるのが強みです。
「Intune の Defender Antivirus レポートの台数」と「Defender ポータルの Onboarded 台数」を比べるより、まず EDR Onboarding Status を基準台帳にするほうが、差分の理由が追いやすくなります。
ステップ3：CSV で突合するなら “Device AAD id” を軸にする
台数差の根本原因を潰すには、最終的に「どの端末が片側にしかいないのか」を一覧で見る必要があります。Defender のデバイス インベントリでは、列として Device AAD id を含められるため、これを軸にすると突合が安定します（端末名だけで突合すると重複・改名で破綻しやすい）。
また、重複が疑われる端末は MAC アドレスや First seen/Last update を併せて見て、「検出のみの残骸」と「オンボード済みの実体」を分離すると整理が早いです。
「数字が合わない」を“問題”にしない運用のコツ
目的別に「正」とする台帳を決める
- 運用・配布・準拠（コンプライアンス）が目的：Intune（デバイス台帳＋Endpoint Security＋準拠）を主
- 検知・調査・対応（インシデント対応）が目的：Defender ポータル（アラート・デバイスリスク・調査）を主
- カバレッジ管理（未保護端末の炙り出し）が目的：Defender の Device discovery/Not onboarded を主
台数を一致させること自体をゴールにすると、Device discovery の“良さ”（未管理端末の炙り出し）を捨ててしまうことがあります。Defender 側の台数が多いのは、むしろカバレッジギャップを見つけるチャンスです。
Intune レポートは「更新タイミング」と「生成型レポート」を意識する
Intune の Defender Antivirus 系レポートには、画面上で Refresh / Generate report を伴うものがあります。例えば Antivirus agent status のように、レポートを生成して最新データを取りに行く導線が示されています。さらに、レポートのデータ反映に一定の更新サイクルがあることも前提にして、インシデント対応の“瞬間値”は Defender ポータルで確認し、Intune は運用・是正の器として使う、という切り分けが安定します。
MDE オンボードが疑わしいときは「1時間で見えない＝要調査」を目安にする
「オンボードしたはずなのに Defender の Devices list に出ない」というケースは、オンボードや接続性の問題が疑われます。トラブルシュート手順では、オンボード完了後に一定時間（例：1 時間）経ってもデバイスが見えない場合に、オンボード/接続の問題を疑い、イベントログ等で確認する流れが案内されています。Defender ポータルに出ない端末が Intune 側に存在する場合は、まずこの観点で確認すると切り分けが速いです。
まとめ：台数差の“正体”はスコープ差。追うべきは「差分の分類」
Intune の Defender レポートと Microsoft 365 Security（Defender）ポータルは、同じ“Defender”という単語が出てくるため混同しがちですが、設計思想が異なります。台数が違うこと自体は異常ではありません。
台数差を前向きに活かすなら、差分を次の3分類に分けるのがコツです。
- Intune 登録済み × MDE オンボード済み：両方の運用対象（最も理想に近い）
- Intune 登録なし × MDE オンボード済み/SSM 管理：セキュリティは見えているが管理統制が弱い（設計判断ポイント）
- MDE 未オンボード（検出のみ）：カバレッジギャップ（優先度を付けてオンボード計画へ）
この整理さえできれば、「1121 と 2710 のどっちが正しい？」ではなく、「2710 の内訳のうち、守れていないのはどれ？」という、本来のセキュリティ運用に繋がる問いへ変換できます。
コメント