Microsoft Defender for Endpointのオンボーディングで管理者がまず確認すべきことは、「どの端末を、どの管理ツールで、どの接続方式で展開するか」です。2026年5月21日時点で確認した公式情報では、Microsoft DefenderポータルからOS、接続方式、展開方法を選び、オンボーディングパッケージを取得して展開する流れが基本です。特に、Intuneを使う環境ではEDRポリシーによる展開、既存セキュリティ製品との併用環境では競合回避、サーバーではライセンスと統合エージェントの確認が重要になります。(Microsoft Learn)
今回のポイントは、単に「Defenderを入れる」ことではありません。オンボーディングは、端末をMicrosoft Defender for Endpointサービスに接続し、セキュリティテレメトリを送れる状態にする作業です。導入後にEDR、次世代保護、脆弱性管理、攻撃面の縮小などをどう有効化するかまで見据えて設計しないと、端末は登録されても運用で検知・対応しきれない状態になりやすいです。(Microsoft Learn)
Microsoft Defender for Endpointオンボーディングの更新で押さえるべき要点
Microsoft Learnの「Onboard devices to Microsoft Defender for Endpoint」は、Microsoft Defender for Endpoint Plan 1、Plan 2、Microsoft Defender Vulnerability Managementを対象にした、端末オンボーディングの中核ドキュメントです。ページ上の最終更新日は2026年5月20日と表示されており、GitHub上の履歴では同日に「MDE-Intune sync added onboarding link from MDE to Intune」という更新が行われています。(Microsoft Learn)
実務上の変更点として注目したいのは、サンプル展開ツールの案内で、Intune関連のリンクが「Onboarding using Microsoft Intune」から「Deploy endpoint detection and response policy with Intune」へ差し替えられている点です。GitHubの差分では、該当箇所が1行削除・1行追加として記録されています。つまり、Intune環境では単なるオンボーディング手順ではなく、EDRポリシーを使った展開・管理の流れを確認する重要性が高まっています。(GitHub)
| 確認項目 | 管理者が見るべきポイント | 放置した場合のリスク |
|---|---|---|
| 展開方法 | Intune、Configuration Manager、GPO、ローカルスクリプトなど、端末管理の実態に合う方法を選ぶ | 同じ端末に複数ポリシーが当たり、競合や未登録が起きる |
| 接続方式 | StreamlinedまたはStandardを選択し、必要なURL・IP・プロキシ条件を確認する | 端末がDefenderクラウドへ通信できず、ポータルに表示されない |
| 既存セキュリティ製品 | 他社EDR・AVとの併用、除外設定、Defender Antivirusのモードを確認する | パフォーマンス低下、二重検知、通信遮断、サポート切り分けの長期化 |
| サーバー | サーバーライセンス、OS、統合ソリューション、Defender for Cloud連携を確認する | サーバーだけオンボーディング対象から漏れる |
| 展開後の検証 | デバイスインベントリ、アラート、検知テスト、センサー状態を確認する | 登録したつもりでも実際にはテレメトリが送信されていない |
影響範囲はクライアント、サーバー、非Windows端末まで広い
Microsoft Defender for Endpointのオンボーディングは、Windows PCだけを対象にした作業ではありません。公式ドキュメントでは、Windowsクライアント、Windows Server、macOS、Linux、Android、iOSなど、端末種別ごとに展開方法を選ぶ前提になっています。展開戦略のドキュメントでも、クラウドネイティブ、共同管理、オンプレミス、評価・ローカルオンボーディングといった環境別の考え方が示されています。(Microsoft Learn)
特に企業環境では、「全端末を同じ手順でオンボーディングする」という発想は危険です。たとえば、Windows 11の社給PCはIntuneでEDRポリシーを配布し、オンプレミス管理のサーバーはConfiguration ManagerやDefender for Cloud連携を使い、LinuxサーバーはAnsibleやインストーラースクリプトで展開する、といった分け方が現実的です。
Windowsクライアントで確認すべきこと
Windows 10、Windows 11、Windows 365などのクライアント端末では、Microsoft Defenderポータルの「Settings > Endpoints > Device management > Onboarding」からOS、接続方式、展開方法を選択し、オンボーディングパッケージを取得する流れになります。展開方法としては、ローカルスクリプト、Intune / MDM、Configuration Manager、グループポリシー、VDIスクリプトなどが案内されています。(Microsoft Learn)
注意したいのは、ローカルスクリプトを本番展開の標準手段にしないことです。公式情報ではローカルスクリプトは小規模・評価用途に近い位置づけで示されており、端末数が多い場合はIntune、Configuration Manager、GPOなどの管理ツールを使う方が管理しやすくなります。
Windowsクライアントの判断基準
| 環境 | 推奨しやすい展開方法 | 判断理由 |
|---|---|---|
| Intuneで管理しているPC | IntuneのEDRポリシー | ポリシー配布、状態確認、再展開がしやすい |
| Configuration Manager管理端末 | Configuration Manager | 既存の配布基盤を活用できる |
| ドメイン参加済みでGPO管理中心 | グループポリシー | オンプレミス運用に合わせやすい |
| 10台以下の検証端末 | ローカルスクリプト | すばやく動作確認できる |
| 非永続VDI | VDI向けスクリプト | イメージ更新や再作成を前提に設計できる |
Intune環境ではEDRポリシーの確認が重要
今回の公式情報で管理者が特に確認すべきなのは、Intuneを使った展開です。IntuneとMicrosoft Defender for Endpointを統合すると、Endpoint detection and responseポリシーを使ってEDR設定を管理し、端末をMicrosoft Defender for Endpointへオンボーディングできます。EDRポリシーによるオンボーディングでは、端末がDefender for Endpointテナントへセキュリティテレメトリを送信できるようになります。(Microsoft Learn)
IntuneのEDRポリシーでは、自動取得と手動設定のどちらを使うかが実務上の分かれ目です。Microsoft Defender for Endpointとのサービス接続が有効な環境では「Auto from connector」を使いやすく、複数テナント、分離環境、厳格な変更管理がある環境では、Defenderポータルから取得したオンボーディングパッケージを手動で使う判断になります。(Microsoft Learn)
| シナリオ | 選ぶべき方法 | 確認ポイント |
|---|---|---|
| IntuneとDefender for Endpointの接続が有効 | Auto from connector | 接続状態がConnectedか、対象グループが正しいか |
| すばやくWindows端末へ展開したい | 事前構成済みEDRポリシー | 全対象端末に一括適用される範囲を確認 |
| 部署・拠点・端末種別ごとに段階展開したい | カスタムEDRポリシー | 割り当てグループ、除外グループ、サンプル共有設定 |
| 複数Defenderテナントや分離環境がある | 手動EDRポリシー | ダウンロードしたパッケージのテナントが正しいか |
| 厳格な変更管理がある | 手動EDRポリシー | パッケージ更新、承認、ロールバック手順 |
よくある失敗は、Intuneのデバイス構成ポリシーとEDRポリシーで同じオンボーディング設定を管理してしまうことです。MicrosoftのIntuneドキュメントでも、複数のポリシーやポリシー種別で同じ設定を管理すると、デバイス側で競合が発生する可能性があると説明されています。既存ポリシーを確認せずに新しいEDRポリシーを作るのではなく、まず「どのポリシーがオンボーディングを担当しているか」を棚卸ししてください。(Microsoft Learn)
Streamlined接続方式を選ぶ前に確認すべきネットワーク条件
Microsoft Defenderポータルでオンボーディングパッケージを取得する際は、接続方式としてStreamlinedまたはStandardを選びます。Streamlined接続では、商用環境向けに*.endpoint.security.microsoft.comという簡素化されたドメインが示されており、クラウド提供の保護、マルウェアサンプル送信、Auto-IRサンプル保存、Defender for Endpointのコマンド＆コントロール、サイバー・診断データなどの通信が集約されます。(Microsoft Learn)
ただし、Streamlinedを選べばすべてのネットワーク設定が不要になるわけではありません。公式情報では、証明書失効リスト、Windows Update、SmartScreenなど、環境やパッチ適用方式によって引き続き到達性が必要になるサービスがあると説明されています。また、サービス接続は証明書ピンニングとTLSを使用し、トラフィック検査はサポートされず、ユーザー認証を要求するプロキシは接続を壊す可能性があります。(Microsoft Learn)
プロキシ・ファイアウォールで失敗しやすいポイント
| 失敗例 | 原因 | 対応 |
|---|---|---|
| 端末がDefenderポータルに出てこない | 必要なURLまたはIPへの通信が遮断されている | オンボーディング前にClient Analyzerで接続確認する |
| 一部拠点だけ登録できない | 拠点プロキシの認証・SSL検査・除外設定が異なる | 拠点別にプロキシ設定を棚卸しする |
| Streamlinedを選んだのに通信エラーが出る | SmartScreen、CRL、Windows Updateなど残りの依存通信を許可していない | Streamlined対象外の必須通信も確認する |
| IP許可リストで運用している | URL単位の集約とIP単位の集約で対象サービスが異なる | Azure service tagsやOneDsCollectorの扱いを確認する |
Streamlined接続を使う場合は、事前に対象OSやセンサー、Microsoft Defender Antivirusのバージョン条件も確認が必要です。たとえば、MMAエージェントで動作する古いWindows 7、Windows 8.1、Windows Server 2008 R2などはStreamlined接続方式の対象外として説明されており、Windows Server 2012 R2 / 2016では新しい方式を使うために統合エージェントへの移行が必要になります。(Microsoft Learn)
サーバーのオンボーディングではライセンスと統合ソリューションを確認する
Windows ServerやLinuxサーバーをMicrosoft Defender for Endpointへオンボーディングする場合、クライアントPCとは別にサーバーライセンスの確認が必要です。公式ドキュメントでは、Microsoft Defender for Servers Plan 1またはPlan 2、Microsoft Defender for Endpoint for servers、Microsoft Defender for Business serversなどの選択肢が示されています。(Microsoft Learn)
Windows Server 2012 R2やWindows Server 2016を扱う環境では、特に注意が必要です。公式情報では、これらのOSについて最新のSSUやLCU、Microsoft Defender Antivirus機能、最新プラットフォームバージョンなどの前提条件が示されており、従来のMMAベース実装からモダン統合ソリューションへの考慮も必要になります。(Microsoft Learn)
サーバー展開でありがちな失敗は、「PCの展開が終わったからDefender導入は完了」と判断してしまうことです。実際には、ファイルサーバー、ドメインコントローラー、アプリケーションサーバー、Linuxサーバー、クラウド上のVM、オンプレミスの非Azureサーバーが残りやすく、攻撃者にとってはそれらの方が価値の高い標的になることがあります。
サーバー展開前のチェックリスト
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | サーバー向けプランが割り当てられているか |
| OS | サポート対象OSか、必要な更新プログラムが入っているか |
| 既存AV | Microsoft Defender Antivirusをアクティブにするか、パッシブモードにするか |
| 管理基盤 | Defender for Cloud、Configuration Manager、GPO、スクリプトのどれを使うか |
| 通信 | プロキシ、ファイアウォール、TLS検査、CRL、Windows Updateの到達性 |
| 検証 | sc.exe query senseなどでセンサー稼働を確認できるか |
既存セキュリティ製品との併用では競合回避が最優先
Microsoft Defender for Endpointを導入する企業の多くは、すでに他社EDR、アンチウイルス、Webフィルタリング、DLP、資産管理エージェントなどを運用しています。Microsoftの併用に関する公式情報では、同じ機能を持つ複数のセキュリティ製品を同時に動かすと、パフォーマンス問題や競合が起こりやすいと説明されています。(Microsoft Learn)
既存製品と並行運用する場合は、次の3点を必ず設計に入れてください。
| 設計項目 | 具体的に決めること | 注意点 |
|---|---|---|
| 機能の分担 | EDR、AV、PUA保護、ネットワーク検出、修復をどの製品が担当するか | 二重実行は性能劣化や誤検知につながる |
| 除外設定 | 相互除外するパス、プロセス、証明書、通信先 | 除外を広げすぎると防御範囲が下がる |
| 切り替え期間 | 並行稼働、パイロット、旧製品停止のタイミング | 一斉切り替えは障害時の切り戻しが難しい |
重要なのは、「競合を避けるために全部除外する」という発想をしないことです。除外設定は障害回避に有効ですが、設定範囲が広すぎると検知できない領域が増えます。最初は検証端末でイベント、CPU使用率、ディスクI/O、アラートの重複を確認し、必要最小限の除外に絞り込むべきです。
展開はリング方式で進めると失敗しにくい
公式ドキュメントでは、新規展開にリングベースのアプローチが推奨されています。例として、Evaluateリングで50台、Pilotリングで次の50〜100台、本番展開で残りの端末へ広げる流れが示されています。各リングでは、端末がデバイスインベントリに表示されること、ダッシュボードにアラートが出ること、検知テストや模擬攻撃テストが通ることなどを終了条件として確認します。(Microsoft Learn)
リング展開の目的は、単に台数を分けることではありません。端末種別、拠点、ネットワーク条件、業務アプリ、既存セキュリティ製品との相性を早い段階で見つけることです。特に、開発部門、経理部門、コールセンター、工場端末、VDI、サーバー管理端末など、端末の使われ方が違うグループを検証リングに含めると、本番展開後のトラブルを減らせます。
実務向けのリング設計例
| リング | 対象 | 確認すること | 次に進む条件 |
|---|---|---|---|
| 評価 | 情シス・SOC・開発者の少数端末 | 通信、ポリシー競合、業務影響、検知テスト | 重大な業務影響がない |
| パイロット | 拠点・部署をまたぐ50〜100台程度 | Intune配布状況、アラート量、ヘルプデスク問い合わせ | 未登録端末と失敗原因を説明できる |
| 初期本番 | 重要度が低めの一般端末群 | 展開速度、ネットワーク負荷、監視運用 | 問い合わせ対応手順が整っている |
| 全社展開 | 残りのPC・サーバー・VDI | 継続監視、例外端末、サーバー残件 | インベントリと資産台帳が一致する |
オンボーディング後に必ず確認すべき設定
オンボーディングはゴールではなく、Defender for Endpoint運用の入口です。Microsoftの構成手順では、オンボーディング後にEDR、Defender Vulnerability Management、次世代保護、攻撃面の縮小、Automated Investigation and Remediationなどの機能を構成する流れが示されています。(Microsoft Learn)
最低限、次の確認を行ってから「展開完了」と判断してください。
| 確認項目 | 見る場所・方法 | 判断基準 |
|---|---|---|
| デバイス登録 | Microsoft Defenderポータルのデバイスインベントリ | 対象端末が表示されている |
| テレメトリ送信 | 最終表示時刻、センサー状態 | 端末が継続的に通信している |
| Intune配布 | Endpoint security > Endpoint detection and response | ポリシー適用が成功している |
| センサー状態 | IntuneのEDR Onboarding Status、Defenderポータル | Activeまたは正常相当の状態 |
| 検知テスト | 公式の検知テスト手順 | アラートが生成され、SOCが確認できる |
| 既存製品との影響 | CPU、メモリ、業務アプリ、アラート重複 | 業務影響が許容範囲内 |
管理者・開発者が今すぐ取るべき対応
まず、Microsoft Defenderポータルで現在のオンボーディング方式を確認してください。次に、Intune、Configuration Manager、GPO、ローカルスクリプトなど、どの管理経路で端末がオンボーディングされているかを一覧化します。複数のポリシーが同じ端末に当たっている場合は、どれを正とするかを決め、不要な既存オンボーディングポリシーを除外・整理します。
開発者やアプリ運用担当者は、業務アプリのビルド、署名、配布、ログ出力、自己更新処理がDefender for Endpoint導入後も問題なく動くかを検証してください。特に、開発ツール、CI/CDエージェント、独自スクリプト、社内製エージェント、ファイル大量生成アプリは、EDRやリアルタイム保護の影響を受けやすい領域です。検知されたイベントを見てすぐ除外するのではなく、アプリの挙動が本当に安全か、署名や配布元を整備できるかも合わせて判断することが重要です。
最後に、展開計画は「対象端末リスト」「接続方式」「展開ツール」「検証方法」「切り戻し手順」の5点で文書化してください。Microsoft Defender for Endpointのオンボーディングは、正しく設計すればEDR運用の土台になります。一方で、ネットワーク、既存セキュリティ製品、サーバーライセンス、Intuneポリシー競合を軽視すると、登録漏れや検知不能が起きます。まずは少数リングで通信と検知を確認し、IntuneのEDRポリシーやDefenderポータルのデバイスインベントリで状態を見ながら、段階的に本番展開へ進めてください。
コメント