Intune デバイス登録の失敗と Autopilot ESP ハングを、2026 年のヘルプデスク実務目線で徹底解説。0x80180024 / 8018000a / 0x8007064c などエラーコード別の対処、dsregcmd と mdmdiagnosticstool を使ったログ採取、ハイブリッド Azure AD Join の落とし穴、条件付きアクセスとの絡み、そして問い合わせ受付時に上から潰せる 10 項目チェックリストまで、現場ですぐ使えるランブックとしてまとめました。
更新日: 2026年7月31日
Microsoft Intune のデバイス登録エラーは、ほとんどの場合「ライセンス未割り当て」「MDM スコープの誤設定」「古い登録アーティファクトの残存」のいずれかが原因で発生します。エラーコードごとに対処ルートは概ね決まっているので、まず dsregcmd /status と mdmdiagnosticstool.exe で情報を採取してから、本記事のエラーコード表に沿って手を動かすのが最短です。正直、ここを飛ばして勘で触ると余計に時間を溶かします（過去の自分がそうでした）。ヘルプデスクとして 2026 年に最も問い合わせを受ける 0x80180024・8018000a・0x8007064c・DeviceCapReached、そして Windows Autopilot の Enrollment Status Page（ESP）ハング まで、現場のランブックとして通しで解説します。
0x80180024・8018000a・0x8007064c は「既に登録済み」系のエラーで、登録アーティファクトのクリーンアップが必須。InstallationState = 4、LOB と Win32 の混在、Teams Machine-Wide Installer の同時実行が三大要因。dsregcmd /status（AzureAdJoined と MdmUrl の確認）と mdmdiagnosticstool.exe -area DeviceProvisioning -cab のログ採取で固定化する。Microsoft Intune のデバイス登録は「単一のアクション」ではなく、以下の段階を順に踏むフローです。まず Microsoft Entra ID による認証、次に MDM サービスによるディスカバリー、続いてデバイスの登録またはジョイン、最後にポリシー・アプリ・コンプライアンスの割り当てが実行されます。どの段階で失敗するかで発生するエラーコードは大きく変わるため、切り分けの最初の一歩は「どのフェーズで止まったか」を明確にすることです。
実際にヘルプデスクとして数百件を捌いてきた経験から言うと、根本原因のパターンは驚くほど狭いです。ざっくり頻度順に並べると、こんな感じ。
enrollment.manage.microsoft.com や portal.manage.microsoft.com がプロキシでブロックされている。この 8 パターンで大半が説明できます。エラーコードを見た瞬間にこの中のどれかを疑えるようになると、平均対応時間（MTTR）は劇的に短縮できます。
現場でよく遭遇する Intune / MDM 登録エラーを、原因と処置をセットで表にしました。エラーメッセージそのままで検索すると英語の Microsoft Q&A に飛ばされることが多いので、まずこの表で当たりをつけてから深堀りするのが効率的です。
| エラーコード | 意味 | 主な原因 | 推奨対処 |
|---|---|---|---|
0x80180024 | MDM 登録の競合 | 既に別 MDM に登録済み／登録アーティファクトが残存 | 「職場または学校アカウント」を削除→再登録 |
8018000a | デバイスが既に登録済み | 別ユーザーが同一デバイスを Entra Join 済み | 先行ユーザーでサインイン→職場アカウント削除→自ユーザーで再登録 |
0x8007064c | マシンが既に登録済み | クローンイメージ／前アカウントの証明書残存 | HKLM\SOFTWARE\Microsoft\Enrollments のクリーンアップ後再試行 |
0x80180026 | MDM 登録エラー（汎用） | MDM Discovery URL 到達不可・証明書失効 | ネットワーク疎通確認・システム時刻同期・SCEP 証明書再発行 |
0x80070774 | DC 探索不可 | Hybrid Join 環境で DC への LDAP/Kerberos 失敗 | VPN 接続確認・DNS 設定・サイト＆サービス構成の見直し |
0x801c0003 | Entra 登録拒否 | デバイス登録がブロックされている | Entra ID の「デバイス設定」で登録を「すべて」に変更 |
0x80090016 | TPM キーコンテナ問題 | TPM 初期化不良／プラットフォームキーの破損 | TPM クリア＋再起動、tpm.msc で状態確認 |
DeviceCapReached | デバイス上限超過 | ユーザーあたりの登録上限（既定 15）に到達 | 不要デバイスを Intune から削除／上限を管理センターで引き上げ |
| 「アカウントは許可されていません」 | Intune ライセンス未割り当て | ユーザーに Intune ライセンスが未付与 | 管理センターで Microsoft 365 E3/E5・Intune Plan を割り当て |
| 「IT 管理者が MDM 権限を設定していません」 | MDM Authority 未設定 | テナントの MDM 権限が未定義 | Intune 管理センターで MDM 権限を Intune に設定 |
この 2 つは症状が似ていますが、切り分け自体は単純です。dsregcmd /status で AzureAdJoined が YES かつ MdmUrl が空欄なら 0x80180024（MDM 側のみの競合）。AzureAdJoined が YES で別ユーザーの UPN が入っていれば 8018000a（Entra 側から別ユーザーが握っている）です。前者はレジストリだけ触れば済みますが、後者は先に別ユーザーでサインインしてアカウントを外す必要があります。個人的にはここで一度、対象デバイスの現ユーザーと登録済みユーザーが本当に一致しているかを声に出して確認するのを癖にしています（意外とここで詰まる）。
Enrollment Status Page（ESP）は、初回サインイン時にアプリ・ポリシー・証明書・ネットワーク構成の進捗を表示する画面です。ESP が固まる原因は Microsoft の Windows Autopilot トラブルシューティング FAQ に整理されていますが、実務でよく踏むのは次の 8 パターン。私の直近案件でも、8 割はこの中のどれかでした。
レジストリ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\Setup\Apps\Tracking\Sidecar\Win32App_{AppID} の InstallationState が 4（失敗）になっていると、ESP はそこで後続アプリのインストールを止めます。Intune 管理拡張機能（IME）ログ（C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log）で該当 App ID の失敗理由を確認してください。
ESP は LOB（Line-of-Business）アプリと Win32 アプリの同時追跡をサポートしていません。どちらも TrustedInstaller 経由でインストールされ、同時実行できないためです。混在させる必要がある場合は、ESP を使わない Windows Autopilot デバイス準備（Device Preparation）への移行を検討します。
Teams Machine-Wide Installer の MSI は ESP に追跡されないため、他の MSI ベース Win32 アプリと同時にインストールされると TrustedInstaller の排他制御に引っかかります。Teams の展開は ESP 対象外にするか、Win32 アプリとして再パッケージするのが安全です。
この配布形式は ESP と相性が悪く、他の Win32 アプリと同時に走ると ESP がハングします。ESP で追跡させたい場合は、Microsoft 365 Apps を Win32 アプリ型としてパッケージし直すのがベストプラクティスです。
MSI や EXE インストーラー側で再起動を発火させると、ESP はセッションを失いハング状態になります。再起動は必ず Intune の「アプリの割り当て」→「再起動の動作」で制御してください。
Autopilot で使うユーザーに Intune ライセンスがないと、ESP は「Identifying」フェーズで長時間停止するか、そのまま完了しません。Autopilot 展開の 前に ライセンスグループへの割り当てを確認しておくのが鉄則です。
言語・地域・キーボードの変更禁止、AppLocker、パスワード複雑度、最小長など、初期セットアップの動作を制限する GPO や設定プロファイルが ESP を阻害します。Autopilot 対象デバイス向けには「ESP 完了までは適用しない」フィルターを設定しましょう。
Pre-Provisioning フェーズで実行される PowerShell スクリプトは ESP のトラッキング対象ではありませんが、失敗すると 30 分規模の遅延を引き起こすことがあります。-ExecutionPolicy Bypass の設定漏れ、SYSTEM コンテキストでは使えない資格情報参照などが典型パターンです。
Intune 登録・Autopilot ESP のトラブルシューティングは、ログなしで進めると必ず遠回りします。以下のコマンドを「最初にまとめて実行して結果を保存する」だけで、8 割の問い合わせは切り分け可能です。
# 管理者権限の PowerShell またはコマンドプロンプトで実行
dsregcmd /status > C:\Temp\dsregcmd_status.txt
# 特に重要な行
# AzureAdJoined : YES ← Entra ID 参加済みか
# DomainJoined : NO/YES ← オンプレ AD 参加済みか（Hybrid の判定）
# MdmUrl : https://... ← 空欄なら MDM 未登録
# MdmTouUrl : https://...
# MdmComplianceUrl : https://...
# TenantName / TenantId ← 想定テナントと一致するか期待される動作は「AzureAdJoined = YES」かつ「MdmUrl に Intune の URL が入っている」状態です。AzureAdJoined = YES なのに MdmUrl が空欄なら、自動 MDM 登録の GPO か Entra の MDM スコープがユーザー／デバイスに当たっていません。
# Windows 10 1809 以降で使用可能
mdmdiagnosticstool.exe -area DeviceProvisioning;DeviceEnrollment;Autopilot -cab C:\Temp\MDMDiag.cab
# CAB を展開すると、以下が採取される
# MDMDiagReport.html : サマリレポート（まずはこれを開く）
# MDMDiagReport_RegistryDump.Reg: 登録関連の全レジストリ
# *.evtx : 各種イベントログ
# MDMDiagHtmlReport.html : HTML ビュー
# 期待される出力: MDMDiagReport.html 内の「Enrollment State」が EnrolledGUI でイベントビューアーを開き、以下のパスを確認します。エラー・重大レベルでフィルターすると原因が絞りやすいです。
アプリケーションとサービス ログ > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Adminアプリケーションとサービス ログ > Microsoft > Windows > Provisioning-Diagnostics-Provider > Adminアプリケーションとサービス ログ > Microsoft > Windows > AAD > OperationalPowerShell 診断のノウハウはActive Directory アカウントロックアウト調査ガイドで扱った手法とほぼ同じで、Get-WinEvent で条件を絞ってから Format-List * で全プロパティを見るのが確実です。
ESP がハングしている画面で Ctrl+Shift+D を押すと、診断ページが開き CAB ファイルとしてログを収集できます。ネットワーク経由でエスカレーション先に送るときはこれが最も情報密度の高いパッケージです。
Hybrid Join 環境で Autopilot を回すと、Entra ID Join がバックグラウンドで先行し、その後にオンプレ AD Join を試みます。この順序は Hybrid シナリオにとって致命的で、Entra 側の登録が完了する前に MDM 登録が走ってしまい、GPO や証明書関連のポリシーが未適用のまま次工程に進むため、後段のポリシー適用で連鎖的に失敗します。
典型的な症状は次のとおりです。
0x80070774（DC 探索不可）で ESP が失敗2026 年時点で Microsoft は Hybrid Join からの脱却を強く推奨しており、新規デバイスは Entra Join + Windows Hello for Business + Cloud Kerberos Trust の組み合わせに移行するのがベストプラクティスです。既存の Hybrid 環境で当面回す必要がある場合は、以下の順序で緩和策を入れます。
「既に登録済み」系のエラー（0x80180024・8018000a・0x8007064c）が消えないときは、デバイスをクリーンな状態に戻すのが最短です。以下は破壊的操作を含むため、必ず順序を守って実行してください。
# 「設定 > アカウント > 職場または学校にアクセス」から
# 該当アカウントを選択 → 「切断」をクリック
# コマンドラインで同等操作を行う場合
# 現在の登録 ID を確認
dsregcmd /status | findstr /i "TenantName TenantId"
# 職場アカウントとしての切断（AzureAd 参加を解除）
dsregcmd /leave
# 期待される出力: "The device left AzureAd successfully"# 残存する Enrollment GUID を列挙
Get-ChildItem -Path "HKLM:\SOFTWARE\Microsoft\Enrollments" |
Where-Object { $_.PSChildName -match "^[0-9A-F\-]{36}$" } |
ForEach-Object {
$props = Get-ItemProperty $_.PSPath
[PSCustomObject]@{
GUID = $_.PSChildName
UPN = $props.UPN
EnrollmentType = $props.EnrollmentType
ProviderID = $props.ProviderID
}
} | Format-Table -AutoSize
# 期待される出力: Intune 由来のエントリのみ表示（複数残っているなら要クリーンアップ）# MDM 関連のスケジュールタスクを一時停止
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
Disable-ScheduledTask
# Intune 管理拡張機能（IME）サービスの停止
Stop-Service -Name IntuneManagementExtension -Force -ErrorAction SilentlyContinueユーザー切断で消えない場合、対応する GUID フォルダを以下のパスから削除します。必ずレジストリのバックアップを取ってから実施してください。
# 削除対象のパス
# HKLM\SOFTWARE\Microsoft\Enrollments\{GUID}
# HKLM\SOFTWARE\Microsoft\Enrollments\Status\{GUID}
# HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\{GUID}
# HKLM\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\{GUID}
# HKLM\SOFTWARE\Microsoft\PolicyManager\Providers\{GUID}
# HKLM\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\{GUID}
# HKLM\SOFTWARE\Microsoft\Provisioning\OMADM\Logger\{GUID}
# HKLM\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions\{GUID}
# PowerShell で一括削除する場合の例
$targetGuid = "<対象 GUID>"
$paths = @(
"HKLM:\SOFTWARE\Microsoft\Enrollments\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\Enrollments\Status\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\PolicyManager\Providers\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Logger\$targetGuid",
"HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions\$targetGuid"
)
foreach ($p in $paths) {
if (Test-Path $p) { Remove-Item -Path $p -Recurse -Force }
}デバイス側の掃除が終わったら、Intune 管理センターの「デバイス」→「すべてのデバイス」と、Microsoft Entra 管理センターの「デバイス」で古いオブジェクトを削除します。BitLocker 回復キーが Entra に保管されている場合はWindows 11 BitLocker 回復キー対処ガイドの手順で先にキーを回収してから削除してください。
2026 年時点で最も見落とされがちなのが、条件付きアクセス（Conditional Access, CA）による登録ブロックです。CA ポリシーで「準拠デバイスを要求」を有効にしていると、Intune 登録用のクライアント（Enrollment Web App）自体もブロック対象になり、ニワトリと卵の状態が発生します。
登録関連の CA トラブルの典型パターンは以下の 3 つです。
問い合わせを受けたときに、上から順に潰していけば 8 割の登録問題は切り分けられるチェックリストです。ドキュメント好きの自分は、これを部内 Wiki に貼って「上から順に埋めてから起票」というルールにしました。運用してみたら一次切り分けの時間がざっくり半分になったので、面倒でもテンプレ化する価値はあると思います。
dsregcmd /status で AzureAdJoined / MdmUrl の値*.manage.microsoft.com、ztd.dds.microsoft.com、login.microsoftonline.com）tpm.msc）この 10 項目のうち 8 つ以上に「OK」がついた状態でエラーが再現するなら、初めて Microsoft サポートにエスカレーションする価値のあるレベルです。それ以前に上げると、まずこの 10 項目を潰すよう戻されます。
設定 > アカウント > 職場または学校にアクセスから既存アカウントを切断し、再サインインすれば 8 割は解消します。それでも残る場合は HKLM\SOFTWARE\Microsoft\Enrollments 配下の残留 GUID を削除してください。0x80180024 は「既に別 MDM に登録済み」を意味するため、レジストリのクリーンアップが必須です。
頻度順に、Win32 アプリのインストール失敗（InstallationState = 4）、LOB アプリと Win32 アプリの混在、Teams Machine-Wide Installer との同時実行、Intune ライセンス未割り当ての 4 つです。ESP 画面で Ctrl+Shift+D を押して診断ログを収集し、Intune 管理拡張機能ログ（IntuneManagementExtension.log）で失敗アプリを特定してください。
MDM 自動登録の GPO（Enable automatic MDM enrollment using default Azure AD credentials）が対象ユーザー／デバイスに適用されていないか、Entra ID の MDM スコープが「なし」になっているのが主因です。GPO は「コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > MDM」以下にあり、Hybrid Join 環境では必須の設定です。
変更できます。Intune 管理センターの「デバイス > 登録 > デバイス登録制限」から、既定ポリシーまたはカスタムポリシーで 1〜15 の範囲で設定可能です。BYOD で 15 台では不足する場合は、Autopilot 対象デバイスを「企業所有」として事前登録することでこの上限を回避できます。
初回同期直後は正常な挙動です。ポリシー評価とレポートには最大 8 時間かかるため、ESP 完了直後に Company Portal でサインインしても即座には準拠になりません。ユーザーには「サインアウトして 10 分待ってから再サインイン」と案内するか、Company Portal から「デバイスを同期」を手動実行してもらってください。
2026 年時点で Microsoft は Cloud Native（Entra Join + Cloud Kerberos Trust + Windows Hello for Business）への移行を推奨しています。既存デバイスは Autopilot Reset や Fresh Start を使って再展開する方式が現実的で、オンプレファイルサーバー・プリンターへのアクセスは Kerberos Cloud Trust でシングルサインオンを維持できます。段階的移行としては、まず新規展開分だけ Entra Join に切り替え、既存デバイスは端末更改のタイミングで置き換えるのがトラブルが少ないアプローチです。
Windows 11 24H2/25H2で頻発するBitLocker回復キー要求トラブルを、ヘルプデスク現場の視点で完全網羅。発生原因の切り分け、回復キーの5つの取得経路、自動修復ループの脱出手順、Intuneでの組織的なエスクロー管理、そして意図的な無効化手順までを2026年最新仕様で解説します。