Windows Autopilot（Intune＋Entra ID）で Windows 11 を展開中、「デバイスの準備（Device preparation）」→「ハードウェアの保護（Secure your hardware）」で 0x800705b4 が出て先に進まない…。本記事では、実際に解決した「クラウド側（Intune／Autopilot／Entra ID）に残った登録情報を完全に削除する」手順を中心に、原因の考え方と再発防止の運用ポイントまでまとめます。
症状：Autopilot の「デバイスの準備」中に 0x800705b4 でループする
今回の状況を整理すると、次のような「Autopilot 展開ではよくある“詰まり方”」に該当します。
- Windows 11 Pro の PC を Microsoft Intune（MDM）＋ Entra ID（旧 Azure AD）＋ Windows Autopilot で構成しようとしている
- 一度 Windows Update を適用してから「クラウドからのクリーンインストール」で初期化し、Autopilot へ手動登録（Get-WindowsAutopilotInfo）を実施
- 実利用ユーザーでサインインしてセットアップを進めると、「デバイスの準備」→「ハードウェアの保護」で エラー 0x800705b4
- クリーンインストール／更新ロールバック等を繰り返しても、すぐに「職場または学校用にこのデバイスを設定しています」に戻される（OOBE のループ）
- TPM 2.0 は有効、同様の手順で他の端末は問題なく完了している
この「戻される」現象のポイントは、PC 側をどれだけ初期化しても、クラウド側で “この端末は Autopilot で組織に所属する端末だ” と認識されている限り、OOBE（初回セットアップ）で再び組織セットアップへ誘導されるという点です。
まず押さえる：0x800705b4 は Autopilot/Intune では“タイムアウト系”として出やすい
0x800705b4 は Windows のエラーとしては「処理がタイムアウトした」ときに使われることが多く、Autopilot のセットアップ画面で出る場合も、根本原因は 1つに限りません。代表的には次のようなパターンが重なります。
| カテゴリ | よくある原因 | 現場での見え方 | 対処の方向性 |
|---|---|---|---|
| 登録情報の競合 | 古い Autopilot 登録／Intune デバイス／Entra デバイスが残り、プロファイルや所有者、MDM 状態が食い違う | 同じ端末なのに「別端末」のように扱われたり、ESP が途中で失敗してループ | クラウド側の関連オブジェクトを完全削除 |
| ポリシー・アプリ過多 | ESP（Enrollment Status Page）で大量のアプリ／セキュリティ基準が一気に降り、時間内に完了できない | 「Secure your hardware」などセキュリティ系フェーズで止まる | 割り当て最小化、段階展開、必須アプリ見直し |
| 通信・環境要因 | プロキシ、SSL インスペクション、証明書、回線品質、名前解決、時刻ずれなど | 特定ネットワークでのみ失敗、同型機でも場所で差が出る | 別回線で検証、プロキシ例外、証明書/時刻確認 |
| TPM/ファーム要因 | TPM の状態不整合、UEFI/BIOS 古い、デバイスセキュリティ機能の初期化が不安定 | 同じテナントでも「その1台だけ」発生しやすい | UEFI 更新、TPM クリア検討（運用注意） |
そして今回、質問者が最終的に解決できたのは、最も再現性が高く、まず疑うべき 「登録情報の競合」でした。
結論：Intune／Autopilot／Entra ID から “同じ端末” を完全削除すると直るケースがある
今回の解決策はシンプルですが、重要なのは「1か所だけ削除」では不十分になりやすい点です。Autopilot はハードウェア ハッシュ（Hardware Hash）を基準に紐づくため、PC を初期化してもクラウド側で紐づきが残っていると、再び組織セットアップへ誘導されます。
まずは、どこに何が残ると問題になるかを表で把握してから作業すると、削除漏れを防げます。
| 削除対象 | 残っていると起きやすいこと | 削除場所（画面の辿り方） | 補足 |
|---|---|---|---|
| Intune のデバイス | 管理状態（MDM）が中途半端に残り、ESP/ポリシー適用が競合しやすい | Intune 管理センター → 「デバイス」→「すべてのデバイス」 | 「削除」と「廃止/Retire」は別物。根治目的なら削除を使うことが多い |
| Autopilot のデバイス（ハードウェア ID） | 初期化しても OOBE で自動的に組織セットアップへ戻される | Intune 管理センター →「デバイス」→「Windows」→「Windows 登録」→「デバイス（Autopilot デバイス）」 | ここが残っていると“戻される”状態が継続しやすい |
| Entra ID のデバイス オブジェクト | 同名/同一端末のオブジェクトが複数になり、参加状態や所有者が混線 | Entra 管理センター →「デバイス」 | 必要に応じて削除。削除対象の取り違えに注意 |
手順：クラウド側から完全削除して、端末を再セットアップする
Intune からデバイスを削除する
- Intune 管理センターに管理者でサインインします。
- 「デバイス」→「すべてのデバイス」を開きます。
- 対象 PC を選択し、デバイスを削除します。
ここでのコツは、同名のデバイスが複数存在する場合があることです。端末名だけで判断せず、可能であればシリアル番号など、確実に一致する情報で特定してください。
Autopilot（ハードウェア ID）からもデバイスを削除する
- Intune 管理センターで「デバイス」→「Windows」へ進みます。
- 「Windows 登録」→「デバイス（Autopilot デバイス）」を開きます。
- 該当 PC の Autopilot デバイスを選択し、削除します。
この削除が効く理由は、Autopilot が「この端末は組織の Autopilot 対象」という判定をする基準が、PC 内の状態ではなくクラウド側のハードウェア ハッシュ紐づけだからです。PC を何度初期化しても、ここが残っている限り OOBE で組織セットアップへ引き戻されやすくなります。
必要に応じて Entra ID 側のデバイス オブジェクトを削除する
- Entra 管理センター（旧 Azure AD）で「デバイス」を開きます。
- 同じデバイスが残っていれば削除します。
必須ではないケースもありますが、過去の参加状態が残って競合していそう、同名オブジェクトが複数あって判断が難しいといった場合は整理が有効です。運用上は監査や資産管理にも影響するため、削除前に対象を厳密に特定してください。
PC を再起動（またはリセット）して、OOBE をやり直す
質問者の環境では、「Intune と Autopilot から完全に削除」→「PC 再起動」で、0x800705b4 が発生せず正常にセットアップを完了できた、と報告されています。
実務的には、次のいずれかの形でやり直すと成功率が上がります。
- 組織端末として再展開したい：クラウド側の削除後、改めて Autopilot 登録→プロファイル割り当て→OOBE
- いったん“組織セットアップに戻される”状態だけ解除したい：Autopilot デバイス削除を確実に行い、端末を初期化して通常のセットアップへ
なぜ「クラウド側の完全削除」で直りやすいのか
この手の 0x800705b4 は、ネットワークやアプリ配布など多要因に見えますが、“その1台だけ何をやっても戻る”という挙動がある場合、クラウド側のオブジェクト不整合が原因になっていることが少なくありません。特に手動で Autopilot 登録（Get-WindowsAutopilotInfo）を繰り返したり、端末の初期化を挟むと、管理面では次のような状態が起きえます。
- Intune には古い管理レコードが残り、新しい enroll と競合する
- Autopilot にはハードウェア ハッシュが残り、端末は毎回“組織の Autopilot 対象”として扱われる
- Entra ID には同名デバイスが複数になり、所有者や参加状態の整合が崩れる
結果として、OOBE の「デバイスの準備」中に、セキュリティ系の処理（TPM 関連、保護機能の構成、コンプライアンス判定、必須ポリシーの適用など）が想定通りに完了せず、タイムアウト扱いで 0x800705b4 が出てループする、という構図です。
「戻される状態」を解除したいだけなら：Autopilot 登録の有無が決定的
「エラーの根本原因はまだ追えないが、とにかく端末が勝手に Intune/Entra のセットアップへ戻る状態を解除したい」という場合、優先順位は次の通りです。
| 目的 | 最優先でやること | 理由 | 注意点 |
|---|---|---|---|
| 組織セットアップへの自動誘導を止める | Autopilot デバイス（ハードウェア ID）を削除 | 初期化しても Autopilot 対象として判定されるため | 削除後に再度組織端末化するなら、再登録の手順を用意する |
| MDM 管理の状態を整理する | Intune デバイスの削除 | 古い管理レコードがポリシー適用を不安定にすることがある | 資産管理・監査の都合がある場合は運用ルールに従う |
| デバイスオブジェクトの混線を解消 | Entra ID デバイスの整理 | 同名複数・所有者不整合などでサインイン/登録が不安定になることがある | 削除対象の取り違えに注意 |
追加チェック：完全削除でも解決しない場合に見るべきポイント
もし「完全削除＋再セットアップ」を行っても再発する場合は、次の順で切り分けるのが効率的です。ポイントは、“同じテナント・同じ手順で他端末は成功している”という事実を活かし、差分（端末固有／ネットワーク固有）に寄せて確認することです。
ネットワーク（特にプロキシ/SSL検査）の影響を疑う
- 別ネットワーク（別回線・テザリング等）で OOBE を実施して差が出るか確認する
- 社内プロキシや SSL インスペクションがある場合、Microsoft の管理・登録系通信が阻害されない設計になっているか見直す
- 社内 DNS や名前解決の遅延がないか、疎通の安定性（瞬断がないか）を確認する
Autopilot の ESP は「最終的に成功すればよい」ではなく、一定の流れでクラウドと往復し続けるため、瞬断や検査の影響が表面化しやすいのが特徴です。
UEFI/TPM/ファームウェアの状態を見直す
- UEFI/BIOS を最新化できる場合は更新を検討する（特に新しい機種や出荷直後の端末）
- TPM が有効でも、状態が不整合なケースがあるため、運用ルールに沿って TPM の再初期化（クリア）を検討する
- BitLocker やデバイス暗号化関連のポリシーを当てている場合、適用順序・要件（TPM、起動方式、回復キー保管先）を再確認する
「Secure your hardware」という表示から、セキュリティ系の構成が絡んでいる可能性は高く、端末固有のファーム状態が原因になることもあります。
ESP の負荷を下げて、どこで詰まるか可視化する
運用的に非常に効くのが、Autopilot プロファイル／割り当てを“最小構成”にして再テストすることです。例えば、次のように段階を分けると原因が見えやすくなります。
- まずは必須アプリを外し、ポリシーも必要最小限（参加・基本セキュリティのみ）で ESP を通せるか確認
- 通るようになったら、アプリを 1つずつ戻す（重いアプリ、VPN、証明書系、セキュリティエージェントから優先的に検証）
- 「デバイスコンテキスト必須」か「ユーザーコンテキストでも可」かを整理し、ESP に詰め込み過ぎない
| よく重くなる要素 | 具体例 | 詰まり方 | 改善のヒント |
|---|---|---|---|
| 大型アプリ配布 | Office 一式、開発ツール、巨大インストーラー | アプリ待ちでタイムアウト扱い | 必須から外し、サインイン後配布へ |
| セキュリティエージェント | EDR、DLP、暗号化制御 | Secure your hardware の段階で止まりやすい | 導入順序、依存関係、前提証明書を見直す |
| 証明書/プロキシ | デバイス証明書、VPN 証明書、SSL検査 | クラウド通信の一部だけ失敗 | 例外設定、配布タイミングの調整 |
状態確認：dsregcmd /status で “参加と登録のねじれ” を見る
セットアップ後（またはトラブル再現時にコマンドが開ける状況）なら、端末の参加状態・MDM 登録状態を確認することで、クラウド側の整合が取れていない兆候を掴めます。
dsregcmd /status確認したい観点の例：
- Entra ID 参加（AzureAdJoined）が意図通りか
- MDM URL や Tenant 情報が想定と一致しているか
- デバイスが二重登録されていそうな兆候がないか
また、トラブルシュート時はログ採取も有効です。Windows のイベントログでは、MDM・参加・Autopilot 関連が複数箇所に分散します。環境によってパスやログ名が異なることもありますが、代表例として以下を確認します。
- MDM 関連：DeviceManagement-Enterprise-Diagnostics-Provider（管理/運用ログ）
- 参加・認証関連：AAD（Entra ID）関連の運用ログ
- Autopilot：OOBE/プロビジョニングの診断（OS バージョンにより見え方が異なる）
再発防止：Autopilot 手動登録運用で “詰まり” を減らすコツ
最後に、同じ 0x800705b4 を繰り返さないための運用面のコツをまとめます。実機展開の現場で効くのは、「端末側の初期化手順」よりも、クラウド側のデバイスライフサイクル管理です。
「削除」「廃止」「ワイプ」の違いをチームで統一する
Intune には似たボタンが複数あり、チーム内で使い分けがブレると、オブジェクトが残って不整合の原因になります。用語と目的を揃えておくと、トラブル時の復旧も速くなります。
| 操作 | 主な目的 | 残りやすいもの | 向いているケース |
|---|---|---|---|
| 削除（Delete） | 管理対象としての記録を消して整理する | Autopilot（ハードウェア ID）は別枠で残ることがある | 不整合を疑う、ゼロからやり直す |
| 廃止/Retire | 管理を外す（利用終了） | 記録や関連付けが残りやすい | 利用終了の運用、返却端末の整理 |
| ワイプ/Wipe | 端末を初期化して再展開する | クラウド側の紐づけは別途残ることがある | 再配布、手戻り削減 |
Autopilot の割り当ては「最小→段階的」にする
- 最初から“全部入り”のプロファイルやセキュリティ基準を割り当てると、トラブル時に原因が見えなくなる
- まず ESP を通す（端末が使える状態にする）→その後にアプリと強化ポリシーを段階的に当てる
- 「必須アプリ」「必須ポリシー」を定義し直し、ESP に載せるものを厳選する
手動で Get-WindowsAutopilotInfo を回すときの注意
質問の手順でも使われているように、手動登録は現場で便利ですが、再展開・再登録を繰り返すと不整合が起きやすいのも事実です。次の観点を押さえると事故を減らせます。
- 登録前に、すでに Autopilot に同一端末が存在しないか（シリアル等で）確認する
- 端末の命名規則、グループタグ、割り当てグループの運用を決め、例外運用を減らす
- トラブル端末は「端末側を疑う」より先に「クラウド側のオブジェクト整理」をチェックリスト化する
よくある質問：削除したのに、まだ Autopilot が始まる／まだ Intune に残る
Intune の「すべてのデバイス」から消したのに、OOBE でまた組織セットアップになる
この現象は、Autopilot デバイス（ハードウェア ID）が残っているときに起きやすいです。端末初期化後にネットワークへ接続した段階で Autopilot 判定が走り、組織セットアップへ誘導されます。対処は、Intune ではなくAutopilot デバイスの削除が軸になります。
Autopilot から消したのに、Entra ID や Intune に同名が残る
クラウド側のオブジェクトは複数システムにまたがるため、表示上のタイミング差や、過去の参加履歴により複数が残って見えることがあります。端末名だけで判断せず、シリアルなど一致情報で照合し、不要なオブジェクトを整理してください。
10台以上は成功していて、この1台だけ失敗する
この条件は「テナント全体の設定ミス」よりも、端末固有（TPM/UEFI）またはネットワーク固有（場所/回線/プロキシ）の可能性を上げます。まずは本記事の解決策（完全削除）でクラウド競合を潰し、それでもダメなら「別回線」「UEFI 更新」「ESP 最小化」の順で差分を詰めるのが現実的です。
まとめ：まずは “クラウド側を一度まっさらにする” のが最短ルートになりやすい
Autopilot の 0x800705b4 は、画面上は「Secure your hardware（ハードウェアの保護）」に見えても、原因は端末側だけではありません。特に、初期化や手動登録を繰り返した端末で「組織セットアップに戻される」挙動があるなら、Intune／Autopilot／Entra ID の登録情報が競合している可能性を最優先で疑うのが合理的です。
今回のように、Intune と Autopilot から完全にデバイスを削除し、必要に応じて Entra ID のデバイスも整理したうえで再セットアップするだけで、詰まりが嘘のように解消することがあります。まずは「削除対象を漏らさない」ことを最重要ポイントとして、チェックリスト運用に落とし込んでみてください。
コメント