【MDE運用】オンボーディング済みかをレジストリで即座に判定する手順

はじめに

PCのキッティング作業やIntune・GPOでの一括展開において、Microsoft Defender for Endpoint（以下、MDE）のオンボーディングスクリプトを実行したものの、Microsoft Defenderポータル（security.microsoft.com）のデバイス一覧に端末が表示されるまで数十分から数時間も待たされ、作業が完了したか判断できず困った経験はないでしょうか。

私も過去に、数百台の端末へMDEを展開するプロジェクトで、ポータル画面への反映ラグが原因で「キッティング完了判定」が出せず、現場の作業員を1台あたり30分以上待機させてしまった苦い経験があります。しかし、クライアント端末側のレジストリ値とローカルのイベントログを組み合わせた判定手法を確立したことで、スクリプト実行直後の数秒間で確実にオンボーディング成否を判定できるようになりました。

この記事では、ポータル側の反映を待たずにクライアントPC側でMDEのオンボーディング状態（OnboardingState）を即座に確認するコマンドと、キッティング現場でそのまま使えるPowerShell自動判定スクリプトを解説します。

読み終えるころには、ローカル端末上で5秒以内にオンボーディング完了を裏付けられるようになり、キッティングや障害切り分けの待機時間をゼロにできます。

この記事の要点

• クライアント側のレジストリ HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status にある OnboardingState が 1 であればオンボーディング済みと判定できる
• レジストリ値だけでなく、EDRセンサーサービス（Sense）が Running であること、およびイベントID 1（初回通信成功）の記録をセットで確認するのが確実
• PowerShellスクリプトやIntune検出規則に組み込むことで、全端末のMDE登録ステータスを自動収集・監査できる

項目	動作確認・検証環境
検証年月	2026年9月
対象OS	Windows 11 Pro / Enterprise 23H2・24H2
対象製品	Microsoft Defender for Endpoint (Plan 1 / Plan 2)
必要権限	ローカル管理者権限（サービスおよびイベントログ照会時）

---

結論：MDEオンボーディング状態はレジストリ「OnboardingState」で即決できる

結論からお伝えすると、クライアント端末がMDEにオンボーディングされているかどうかは、レジストリの OnboardingState の値が 1 になっているか を確認するのが最も速く確実な方法です。

Microsoft Defenderポータルにデバイス情報が反映されるまでには、クラウド側の集計処理により通常15分〜最大数時間のタイムラグが発生します。しかし、端末ローカルのレジストリとサービス状態は、オンボーディング処理が完了した瞬間に書き換わります。

確認すべきレジストリパスと設定値の意味

MDEのステータス情報は、以下のレジストリキー配下に格納されています。

キー: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status
名前: OnboardingState
種類: REG_DWORD

OnboardingState の値によって、現在の端末状態は以下の通り明確に区別されます。

OnboardingState の値	状態の意味	クライアント端末の挙動
1	オンボーディング済み	MDEセンサー（Sense）が稼働し、クラウドへテレメトリを送信中
0	未オンボーディング（またはオフボード済み）	MDE未構成、またはオフボーディングスクリプトにより登録解除済み
値が存在しない	初期状態（未構成）	OSインストール直後など、一度もMDEオンボーディングが実行されていない

このように、値が 1 であることを確認できれば、クライアント側のオンボーディング構成は正常に完了していると判断できます。

コマンドプロンプト（reg query）で1秒確認するワンライナー

キッティング作業中などにコマンドプロンプトから即座に確認したい場合は、以下の reg query コマンドを実行します。

reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" /v OnboardingState

正常にオンボーディングされている端末では、以下のように 0x1 が返ってきます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status
    OnboardingState    REG_DWORD    0x1

同時に、どのMDEテナント（組織ID）に紐づいているかを確認したい場合は、OrgId の値もあわせて参照してください。

reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" /v OrgId

ここに自社のGUID文字列が表示されていれば、正しいテナントへ登録されている証拠になります。

---

PowerShellでMDE稼働状態を多角的にチェックする実践手順

実運用では、レジストリ値が 1 であっても、プロキシ遮断などでセンサー通信が止まっているケースがあります。そのため、「レジストリ」「サービス稼働」「イベントログ」の3点セット をPowerShellで確認するのがプロの現場における鉄則です。

1. レジストリ値（OnboardingState・OrgId）の取得

PowerShellでレジストリからオンボーディング状態と組織IDを取得するコマンドは以下の通りです。

# MDEステータスのレジストリプロパティを取得
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" -ErrorAction SilentlyContinue |
    Select-Object OnboardingState, OrgId, LastConnected

OnboardingState が 1 であり、OrgId にテナント固有のGUIDが入っていることを確認します。

2. EDRセンサーサービス（Sense）の稼働確認

MDEのコアプロセスは MsSense.exe（サービス名：Sense、表示名：Windows Defender Advanced Threat Protection Service）です。このサービスが起動しているかを確認します。

# Senseサービスの稼働ステータスを確認
Get-Service -Name "Sense" -ErrorAction SilentlyContinue | Select-Object Name, Status, StartType

Status が Running になっていれば、EDRセンサーがメモリ上で正常に動作しています。もし Stopped のまま起動しない場合は、オンボーディングパッケージの破損や必要なOS更新プログラムの不足が疑われます。

3. キッティング・展開検証用の自動判定スクリプト

キッティングの最終チェック工程や、SCCM・Intuneの検出スクリプトとしてそのまま組み込める総合判定スクリプトを作成しました。管理者権限のPowerShellで実行してください。

# MDEオンボーディング総合診断スクリプト
$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"
$RegData = Get-ItemProperty -Path $RegPath -ErrorAction SilentlyContinue
$SenseSvc = Get-Service -Name "Sense" -ErrorAction SilentlyContinue

$OnboardingState = if ($null -ne $RegData) { $RegData.OnboardingState } else { "未存在" }
$OrgId           = if ($null -ne $RegData) { $RegData.OrgId } else { "なし" }
$ServiceStatus   = if ($null -ne $SenseSvc) { $SenseSvc.Status.ToString() } else { "サービス未検出" }

# SENSEイベントログから直近の正常接続（イベントID 1）を確認
$LastSuccessEvent = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-SENSE/Operational'
    Id      = 1
} -MaxEvents 1 -ErrorAction SilentlyContinue

$Result = [PSCustomObject]@{
    ComputerName    = $env:COMPUTERNAME
    OnboardingState = $OnboardingState
    OrgId           = $OrgId
    SenseService    = $ServiceStatus
    CloudConnected  = ($null -ne $LastSuccessEvent)
    LastEventTime   = if ($LastSuccessEvent) { $LastSuccessEvent.TimeCreated } else { "記録なし" }
}

$Result | Format-List

if ($OnboardingState -eq 1 -and $ServiceStatus -eq "Running") {
    Write-Host "[OK] MDEオンボーディングは正常に完了しています。" -ForegroundColor Green
    exit 0
} else {
    Write-Host "[NG] MDEオンボーディングが未完了、またはサービスが停止しています。" -ForegroundColor Red
    exit 1
}

このスクリプトは、終了コード（exit 0 / exit 1）を返すように設計しているため、バッチ処理やMDMツールのコンプライアンス判定にもそのまま流用できます。

---

現場でハマる「OnboardingStateは1なのにポータルに出ない」3つの落とし穴

レジストリの OnboardingState が 1 になっているにもかかわらず、丸一日経ってもDefenderポータルに端末が現れない場合、以下の3つの落とし穴に該当しているケースが大半です。

落とし穴1：プロキシやFWでMDEクラウドURLへの通信が遮断されている

最も多い原因は、オンボーディングスクリプト自体はローカルで成功したものの、MDEクラウドエンドポイント（*.atp.azure.com や *.events.data.microsoft.com 等）へのHTTPS通信が社内プロキシやファイアウォールでブロックされているケースです。

この場合、OnboardingState は 1 になり Sense サービスも Running になりますが、クラウドへ初回ハートビートが届かないためポータルには永遠に表示されません。

落とし穴2：イベントログ「Microsoft-Windows-SENSE/Operational」のエラー見落とし

通信障害が起きているかどうかは、イベントビューアーの以下のパスを確認することで即座に判別できます。

アプリケーションとサービス ログ > Microsoft > Windows > SENSE > Operational

主なイベントIDと意味は以下の通りです。

イベントID	レベル	メッセージ内容と現場での判断基準
ID 1	情報	正常: MDEクラウドサービスへの接続・登録が正常に完了した
ID 4 / 5	エラー	通信失敗: クラウドエンドポイントへの接続に失敗（プロキシ・SSLインスペクション要確認）
ID 14	警告	構成不備: オンボーディング情報の読み込みや初期化で問題が発生

特に社内環境で「SSLインスペクション（HTTPS復号）」を行っている場合、MsSense.exe は証明書ピンニング（Certificate Pinning）により中間者攻撃とみなして通信を切断し、イベントID 4 または 5 を出力します。必ずプロキシ側でMDE関連URLをSSL復号の除外対象に設定してください。

落とし穴3：公式ツール「MDE Client Analyzer」を使わずに手探り調査してしまう

イベントログを見ても原因が特定しきれない場合、手作業でネットワーク設定を追い続けるのは非効率です。Microsoft公式の診断ツール MDE Client Analyzer（MDEClientAnalyzer.cmd）を実行すれば、OS構成・レジストリ・全エンドポイントへの疎通結果を数分でHTMLレポートとして出力してくれます。

異常がある項目は赤字で表示されるため、プロキシ担当者やネットワーク部門へエスカレーションする際のエビデンスとしても非常に有効です。

---

よくある質問（FAQ）

Q: レジストリの OnboardingState を手動で 1 に書き換えたらオンボーディングされますか？

A: いいえ、手動で 1 に書き換えてもオンボーディングはされません。そもそも HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status キーはシステム保護（ACLおよび改ざん防止）により管理者であっても直接編集が拒否されます。必ずポータルからダウンロードした正規のオンボーディングスクリプトやIntune構成プロファイルを使用してください。

Q: オフボーディングを実行した端末では OnboardingState の値はどうなりますか？

A: 正規のオフボーディングスクリプトを実行すると、即座に OnboardingState の値が 0 に書き換わり、Sense サービスが停止します。キッティングやり直しやPC退役時の「オフボーディング完了確認」としても、この値が 0 になったかをチェックする方法が有効です。

Q: IntuneでMDEを展開している場合、クライアント側のどこを見ればポリシー適用を確認できますか？

A: 上記の OnboardingState レジストリに加えて、HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection 配下に OnboardingInfo という値が存在するかを確認してください。ここにテナントのオンボーディングペイロードが書き込まれていれば、Intuneから端末へのポリシー配布自体は成功しています。

---

まとめ

MDEのオンボーディング確認をクライアント側で完結させるポイントは以下の通りです。

• ポータル反映を待たず、レジストリ OnboardingState の値が 1 であるかを最優先で確認する
• あわせて Sense サービスが Running であること、および OrgId に正しいテナントGUIDが入っているかをチェックする
• ポータルに表示されない場合は、イベントログ Microsoft-Windows-SENSE/Operational の イベントID 1（成功） と ID 4 / 5（通信エラー） を切り分ける
• キッティング手順書には本記事のPowerShell判定スクリプトを組み込み、作業員による目視確認のバラつきをなくす

ローカルでの即時判定を取り入れることで、キッティングのリードタイム短縮と確実なエンドポイント保護を両立できます。

関連記事

• 【検証】SYSTEM権限でも弾かれる！？Defenderフォルダアクセス制御とhosts書き込みの罠
• 【Intune】クライアント側サービス名とIMEログ調査・即時同期の完全手順
• 【社内情シス必携】依頼スクリプトの管理者実行代行「権限昇格」チェックリスト