Windows Autopilot requirementsで最初に押さえるべき結論は、Autopilotの成否は「端末がWindowsかどうか」だけでは決まらないという点です。対応するWindowsのエディションとサポート状態、OOBE中に必要なネットワーク到達性、Microsoft Entra IDとIntuneの構成、ユーザーへのライセンス割り当てがそろって初めて、ゼロタッチ展開が安定します。
特に2026年5月21日時点で確認すべきポイントは、Windows 10を前提にした展開計画の見直し、認証付きプロキシや厳格なファイアウォール環境での通信許可、Microsoft Entra参加権限とIntune自動登録、そしてWindows AutopilotとWindows Autopilot device preparationの要件差です。この記事では、公式情報を基に、管理者や展開担当者が実際に確認すべき設定・移行・展開上の注意点を整理します。
Windows Autopilot requirementsで押さえるべき全体像
Windows Autopilot requirementsでは、要件が大きく「Software」「Networking」「Licensing」「Configuration」の4カテゴリに整理されています。つまり、Autopilotは単なる初期セットアップ機能ではなく、Windows、Microsoft Entra ID、Microsoft IntuneなどのMDM、ライセンス、インターネット上の複数サービスが連携して動作する展開基盤です。(Microsoft Learn)
実務上の見直しポイントは、次の4つです。
| 分類 | 管理者が確認すべきこと | 確認漏れで起きやすい問題 |
|---|---|---|
| Software | 対応するWindowsエディション、OSバージョン、サポートライフサイクル | OOBEでAutopilotプロファイルが適用されない、サポート対象外構成になる |
| Networking | DNS、HTTP/HTTPS、NTP、Autopilot関連URL、Intune・Entra ID・Windows Updateへの到達性 | サインイン不可、登録停止、アプリ配信失敗、更新未適用 |
| Licensing | Microsoft Entra IDとMDM機能を含むサブスクリプション、ユーザーへのライセンス割り当て | Intune登録が始まらない、ユーザーがデバイスを登録できない |
| Configuration | Intune自動登録、Entra参加権限、デバイス登録、Autopilotプロファイル割り当て | デバイスが既定プロファイルになる、登録エラー、意図しない参加方式になる |
重要なのは、どれか1つを満たせばよいわけではないことです。たとえば、正しいライセンスがあっても、OOBE中のネットワークが認証付きプロキシで遮断されていれば失敗します。逆に、ネットワークが正常でも、ユーザーにIntune登録に必要なライセンスが割り当てられていなければ展開は止まります。
影響を受ける対象者
Windows Autopilot requirementsの見直しは、Intune管理者だけの作業ではありません。調達、ネットワーク、ID管理、ヘルプデスク、社内自動化の担当者まで影響します。
| 対象者 | 影響範囲 | すぐ確認すべきこと |
|---|---|---|
| Intune・エンドポイント管理者 | Autopilotプロファイル、登録状態ページ、アプリ配信、Windows Update | プロファイル割り当て、ESP設定、ブロックアプリ、更新ポリシー |
| Microsoft Entra ID管理者 | Entra参加、ユーザー権限、会社ブランド、デバイスオブジェクト | 自動MDM登録、参加権限、不要な手動削除の有無 |
| ネットワーク・セキュリティ担当者 | OOBE中の外部通信、プロキシ、DNS、NTP、TLS検査 | Autopilot関連URL、80/443/123番ポート、認証なし通信の可否 |
| 調達・資産管理担当者 | OEM登録、ハードウェアハッシュ、対応エディション | OEM・リセラーによるAutopilot登録、購入時のテナント紐付け |
| ヘルプデスク | リセット、再展開、端末返却、修理後対応 | 登録解除手順、マザーボード交換時の再登録、回収端末の扱い |
| 開発者・自動化担当者 | CSV/API連携、デバイス登録・削除の自動化 | 登録順序、削除順序、ログ、例外処理、ハードウェア変更時の再取得 |
特に注意したいのは、AutopilotデバイスとIntune上のWindowsデバイスは同じ一覧ではない点です。公式ドキュメントでは、Autopilot登録が成功し、ライセンスを持つユーザーがサインインした後に、Windowsデバイス一覧へ追加されると説明されています。(Microsoft Learn)
Software requirements：対応OSとエディションの確認
Windows Autopilotを使うには、サポートされているWindowsクライアント、Microsoft Entra ID、Microsoft IntuneなどのMDMサービスが前提になります。Windows 11ではPro、Pro Education、Pro for Workstations、Enterprise、Education、Enterprise LTSCなどが対象です。Windows 10も対象エディションは示されていますが、サポートライフサイクルの範囲内であることが前提です。(Microsoft Learn)
Windows 10前提の展開計画は見直しが必要
Windows 10は2025年10月14日にサポート終了に到達しており、Microsoftはサポートを維持するにはWindows 11への移行、または対応する選択肢の確認を案内しています。Windows Autopilotの要件でも、サポートライフサイクルを超えた製品はサポートされないとされています。(Microsoft Learn)
そのため、2026年時点で新規展開やPC更新を計画する場合は、原則としてWindows 11を前提に設計するのが安全です。Windows 10 LTSC、IoT、ESUなど例外的な運用を続ける場合でも、「Windows 10が動くからAutopilotも問題ない」と判断せず、対象エディション、ライフサイクル、ライセンス、業務要件を個別に確認してください。
古いインストールメディアや再イメージングにも注意
Autopilotは「追加の専用ハードウェア」を要求するものではありませんが、Windowsを実行するためのハードウェア要件は満たす必要があります。また、自己展開モードや事前プロビジョニングではTPM構成証明に関する通信要件も関係します。(Microsoft Learn)
展開現場で失敗しやすいのは、古いメディアで再イメージングした端末です。購入時は問題なくても、キッティング工程で古いISOや古いベースイメージを適用すると、更新不足やサポート外構成になることがあります。検証時は、次の項目を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| OSエディション | Pro、Enterprise、Educationなど対象エディションか |
| OSバージョン | サポート中のWindows 11、または明確にサポートされるWindows構成か |
| インストールメディア | 最新の累積更新を含むメディアか |
| OEM登録 | 購入時にAutopilot登録される契約・手順になっているか |
| ハードウェア変更 | マザーボード交換後にハードウェアハッシュを再取得しているか |
Networking requirements：OOBE中に必要な通信を遮断しない
Windows Autopilotは、OOBEの段階でインターネット上の複数サービスへ接続します。公式要件では、インターネットDNS名の名前解決、HTTPの80番、HTTPSの443番、NTPのUDP 123番ポートへのアクセスが基本条件として示されています。制限の強いネットワークや、インターネット接続前に認証が必要な環境では追加構成が必要です。(Microsoft Learn)
最初に許可すべき通信の考え方
Autopilot用のネットワーク設計では、「ユーザーがサインインした後にIntuneポリシーで何とかする」という考え方は危険です。Autopilotはユーザーがデスクトップに到達する前、つまりIntuneポリシーが十分に適用される前に外部サービスへ接続します。
特に確認すべき通信は次のとおりです。
| サービス・通信 | 確認ポイント | ブロック時の影響 |
|---|---|---|
| Windows Autopilot Deployment Service | https://ztd.dds.microsoft.com、https://login.live.com への到達性 | Autopilotプロファイル取得やサインイン前後の処理に影響 |
| Microsoft Entra ID | ユーザー認証、Entra参加または登録 | 資格情報検証やデバイス参加が失敗 |
| Microsoft Intune | MDM登録、ポリシー・アプリ配信 | デバイス登録、構成配布、ESP処理が停止 |
| Windows Update | OOBE中・構成後の更新取得 | Autopilot自体は継続しても重要な更新が取得されない |
| Delivery Optimization | Windows Update、Storeアプリ、Office更新、Intune Win32アプリ配信 | ピアツーピア配信が使えず、クラウドからの取得に偏る |
| NTP | time.windows.com へのUDP 123番通信 | 時刻ずれにより認証や証明書検証で問題が起きる |
| NCSI | *.msftconnecttest.com のDNS解決とHTTPアクセス | Windowsがインターネット接続を正しく判定できない |
| Microsoft Store | Storeアプリや更新の取得 | Autopilotは継続してもStoreアプリ配信に影響 |
| 診断データ | lgmsapeweu.blob.core.windows.net のブロック確認 | 診断アップロードができず、トラブルシュートが難しくなる |
Windows Update、Delivery Optimization、NCSI、Microsoft Store、診断データなどは、ブロックされてもAutopilotプロセス自体が継続する場合があります。しかし「継続する」と「望ましい状態で完了する」は別です。更新が入らない、アプリが届かない、診断が残らないといった問題は、展開後のサポートコストに直結します。(Microsoft Learn)
プロキシ環境ではIntuneポリシーに頼りすぎない
公式情報では、Windows Autopilotのプロキシ設定はプロキシサーバー側で構成するべきであり、Intuneポリシーでプロキシ設定を展開する方法は完全にはサポートされず、予期しない動作の原因になり得るとされています。(Microsoft Learn)
実務では、次のような環境で失敗が起きやすくなります。
- OOBE中に認証付きプロキシを通らないと外部へ出られない
- TLS検査により証明書チェーンやCRL確認が失敗する
- ゲストWi-Fiや検証用VLANでは通るが、本番キッティング用VLANでは通らない
- Windows UpdateやMicrosoft Storeを一律ブロックしている
- NTP通信を社内NTPだけに限定しているが、OOBE時の経路が整っていない
Autopilotの検証は、管理者の社内PCではなく、実際に初期展開で使うネットワーク、プロキシ、VLAN、無線LANで行う必要があります。検証用に一時的に緩いネットワークを使うと、本番展開時にだけ失敗する典型的なパターンになります。
Licensing requirements：購入だけでなくユーザー割り当てまで確認する
Windows Autopilotでは、Microsoft Entra IDとMDM機能が必要です。公式要件では、Microsoft 365 Business Premium、Microsoft 365 F1/F3、Microsoft 365 Enterprise E3/E5、Enterprise Mobility + Security E3/E5、Intune for Education、Microsoft Entra ID P1/P2とMicrosoft Intuneなどの組み合わせが示されています。(Microsoft Learn)
ここで見落としやすいのは、サブスクリプションを契約しているだけでは不十分な点です。Microsoft 365サブスクリプションを使う場合でも、ユーザーがIntuneへデバイス登録できるようにライセンスを割り当てる必要があります。(Microsoft Learn)
ライセンス確認の実務チェック
| 確認項目 | 見るべきポイント |
|---|---|
| テナントの契約 | Intune、Entra ID、MDM自動登録に必要な機能を含むか |
| ユーザー割り当て | Autopilotで最初にサインインするユーザーにライセンスが付与されているか |
| グループベースライセンス | 対象ユーザーが正しいグループに入り、割り当てが完了しているか |
| 試験ユーザー | 本番ユーザーと同じライセンス・権限条件で検証しているか |
| Microsoft 365 Apps | 必須ではないが、Intuneで展開する場合は配信設計と帯域を確認しているか |
| Windows Subscription Activation | Windows ProからEnterpriseへのステップアップを使う場合、条件を満たしているか |
よくある失敗は、管理者アカウントでは展開できるのに一般ユーザーでは失敗するケースです。これは、管理者にだけライセンスやEntra参加権限があり、実際の利用者に必要な条件が付いていない場合に起きます。検証では、必ず本番と同じユーザー種別でOOBEからサインインしてください。
Configuration requirements：Entra ID、Intune、自動登録を事前に整える
Windows Autopilotを使う前に、Microsoft Entraの自動登録、最初にサインインするユーザーのEntra参加権限、デバイス登録、Autopilotプロファイル割り当てを準備する必要があります。自己展開モードはユーザーレスで動作するため例外がありますが、通常のユーザー主導展開では最初のユーザー権限が重要です。(Microsoft Learn)
新規端末はクラウドネイティブを基本に考える
公式情報では、新しいデバイスはMicrosoft Entra参加を使ったクラウドネイティブ展開が推奨されており、Windows Autopilotを含め、新しいデバイスをMicrosoft Entraハイブリッド参加として展開することは推奨されていません。ハイブリッド参加を使う場合は、コンピューターが内部ネットワーク上にある必要があります。(Microsoft Learn)
これは、既存のActive Directory運用をすぐ廃止すべきという意味ではありません。しかし、新規PC更新やWindows 11移行のタイミングでは、次のように判断すると失敗しにくくなります。
| 展開方針 | 向いているケース | 注意点 |
|---|---|---|
| Microsoft Entra参加 | 新規Windows 11端末、クラウド中心の運用、リモートワーク | アプリ、証明書、ファイルサーバー、認証方式の棚卸しが必要 |
| Microsoft Entraハイブリッド参加 | オンプレAD依存が強く、移行期間中の端末 | 内部ネットワーク到達性、Intune Connector、AD DS連携が必要 |
| 自己展開モード | 共有端末、キオスク、ユーザー操作を減らしたい端末 | TPM構成証明、端末対象ポリシー、ネットワーク要件を厳密に確認 |
| 事前プロビジョニング | ユーザー受け渡し前にアプリ・ポリシーを適用したい端末 | 技術者フロー、TPM、アプリ配信、ESP設定の検証が必要 |
デバイス登録とプロファイル割り当ては別作業
Windows Autopilotでは、デバイスの一意のハードウェアIDをAutopilotサービスにアップロードし、テナントIDに関連付ける必要があります。理想的にはOEM、リセラー、ディストリビューターが購入時に登録しますが、組織内で手動登録することもできます。(Microsoft Learn)
ただし、デバイスを登録しただけでは十分ではありません。登録後にAutopilotプロファイルを対象デバイスへ割り当てる必要があります。割り当て漏れがあると、意図したOOBE動作や参加方式にならない可能性があります。
登録まわりで失敗しやすいポイント
- Microsoft Entra登録済み、またはMDM専用登録デバイスをそのままAutopilot登録しようとする
- 修理やマザーボード交換後に古いハードウェアハッシュのまま再展開する
- デバイスをIntune、Autopilot、Microsoft Entra IDから順不同で削除する
- リセラー登録と社内手動登録の責任分界が曖昧
- プロファイルが未割り当てのまま検証する
公式情報では、デバイスが組織から完全に離れる場合はWindows Autopilotから登録解除する必要があり、Intuneから削除した後にAutopilot登録を解除する流れが示されています。また、Microsoft Entra IDから手動で削除すると予期しない問題が起きる可能性があるため、登録解除手順を守ることが重要です。(Microsoft Learn)
2026年時点で特に確認したい展開上の変更点
OOBE中のWindows品質更新プログラム
Windows Autopilotの新機能では、Intuneの登録状態ページで、OOBE中にWindowsの月次セキュリティ更新プログラムをインストールする設定が追加されています。2026年1月13日時点で、この機能はWindowsの2026-01 B品質更新プログラムに含まれるとされています。新しく作成されるESPプロファイルでは既定で有効、既存プロファイルでは編集・変更されるまで無効のままと説明されています。(Microsoft Learn)
管理者は、次の観点で確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 既存ESPプロファイル | OOBE中の品質更新インストールが意図した設定になっているか |
| 展開時間 | 更新適用により初期セットアップ時間が長くならないか |
| 再起動 | ユーザー受け渡し前の再起動を許容できるか |
| 更新検証 | 月次更新を本番展開前に検証する運用があるか |
| ネットワーク帯域 | 多数台展開時にWindows Update通信を処理できるか |
セキュリティ面では初日から最新化できるメリットがあります。一方で、短時間で大量展開する現場では、更新取得による所要時間増加や帯域集中が課題になります。単に有効・無効を選ぶのではなく、更新検証の運用、展開台数、ネットワーク帯域、Delivery Optimizationの設計とセットで判断してください。
Windows Autopilot device preparationとの違い
「Windows Autopilot requirements」と「Windows Autopilot device preparation requirements」は別の要件として確認する必要があります。Windows Autopilot device preparationの要件は5カテゴリで、Software、Networking、Licensing、Configurationに加えて、管理者に必要なRBAC権限が含まれます。また、対象はWindows 11です。(Microsoft Learn)
混同すると、次のような判断ミスが起きます。
| 混同しやすい点 | 注意点 |
|---|---|
| 通常のAutopilot要件 | Windows 10、Windows 11、Windows Holographicが対象として示される |
| device preparation要件 | Windows 11を対象とし、RBAC権限の確認が必要 |
| ネットワーク要件 | 似ているが、必要URLや対応する認証方式の差を個別確認する |
| 管理者権限 | device preparationではIntuneのカスタムロール権限まで確認する |
| 認証方式 | OOBE中のスマートカード・証明書ベース認証の扱いが異なるため注意する |
社内で「Autopilot」と一括りに呼んでいる場合は、どの展開方式を使っているのかを先に明確にしてください。手順書、Intuneの画面、検証結果、トラブルシュートの前提がずれると、原因調査に時間がかかります。
管理者が展開前に行うべきチェックリスト
Autopilot展開を安定させるには、検証を「端末」「ネットワーク」「ID・ライセンス」「プロファイル」「運用」の順に進めると抜け漏れが減ります。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 端末棚卸し | OS、エディション、サポート状態、ハードウェア変更履歴を確認 | 対象外OSや古いメディアが混在していない |
| 展開方式の決定 | Entra参加、ハイブリッド参加、自己展開、事前プロビジョニングを選ぶ | 業務要件とネットワーク要件が一致している |
| ネットワーク検証 | 本番と同じVLAN・プロキシ・Wi-FiでOOBE検証 | DNS、80/443/123、Autopilot関連URL、Intune、Entra IDへ到達できる |
| ライセンス確認 | 対象ユーザーへ必要ライセンスを割り当てる | 一般ユーザーでIntune登録まで完了する |
| Entra・Intune構成 | 自動MDM登録、参加権限、会社ブランド、ESPを確認 | OOBEで意図したサインイン・登録・表示になる |
| デバイス登録 | OEM登録または手動登録、テナント紐付けを確認 | Intune管理センターでAutopilotデバイスとして確認できる |
| プロファイル割り当て | Autopilotプロファイル、アプリ、構成プロファイルを対象化 | 対象デバイスに正しいプロファイルが割り当たる |
| 本番前パイロット | 部署、拠点、ネットワーク条件を変えて小規模展開 | 失敗パターンと復旧手順を文書化できている |
| 返却・再展開設計 | Intune削除、Autopilot登録解除、Entra IDの扱いを定義 | 孤立レコードや回復不能デバイスを防げる |
よくある失敗と原因の切り分け
Autopilotのトラブルは、画面上では同じように見えても原因が異なります。まずは、どの段階で止まっているかを切り分けてください。
| 症状 | 主な原因候補 | 確認ポイント |
|---|---|---|
| 組織のサインイン画面にならない | デバイス未登録、プロファイル未割り当て、Autopilotサービス到達不可 | Autopilotデバイス一覧、プロファイル状態、ztd.dds.microsoft.com への通信 |
| サインイン後に登録が進まない | ライセンス未割り当て、MDM自動登録未設定、Entra参加権限不足 | ユーザーライセンス、MDM user scope、参加権限 |
| ESPで止まる | 必須アプリ、Win32アプリ、Store、Windows Update、ネットワーク遅延 | ブロックアプリ、アプリ割り当て、配信元、ログ |
| 自己展開・事前プロビジョニングが失敗 | TPM構成証明、TPMプロバイダーURL、ネットワーク制限 | *.microsoftaik.azure.net、Intel/AMD/Qualcommの証明書取得先 |
| 端末再利用時に失敗 | 古いAutopilot登録、Entra IDオブジェクト削除、Intune削除漏れ | 登録解除手順、シリアル番号、デバイスオブジェクト |
| 検証環境では成功し本番で失敗 | 本番VLAN、プロキシ、DNS、NTP、TLS検査の差 | 実際の展開場所でOOBE検証 |
トラブルシュートでは、最初からアプリやIntuneポリシーを疑うのではなく、OOBE中のネットワーク到達性、ライセンス、Entra参加権限、デバイス登録状態を順に確認する方が早く原因にたどり着けます。
開発者・自動化担当者が確認すべき点
Autopilot関連の作業をCSV、スクリプト、API、チケットシステム、資産管理システムと連携している場合は、登録と削除の順序を厳密に扱う必要があります。
特に注意すべき点は次のとおりです。
- ハードウェアハッシュは端末識別に使われるため、マザーボード交換など大きな変更後は再取得を前提にする
- Intune、Autopilot、Microsoft Entra IDのレコードを順不同で削除しない
- 端末返却、修理、廃棄、再販売のワークフローにAutopilot登録解除を組み込む
- OEMまたはCSP登録と社内登録が重複しないよう、責任範囲を記録する
- 登録失敗時に、シリアル番号、テナントID、登録元、プロファイル割り当て状態を追跡できるようにする
- Microsoft LearnのRSS更新を監視し、ネットワーク要件や手順変更を検知する
公式ドキュメントでも、要件追加や更新の通知にRSSを使えることが案内されています。許可リストや手順書を固定化している組織では、更新監視の仕組みを作っておくと、ある日突然Autopilotだけ失敗するリスクを減らせます。(Microsoft Learn)
まず着手すべき3つのアクション
Windows Autopilot requirementsを確認したら、最初に行うべきことは明確です。
まず、Autopilot対象端末のOSとエディションを棚卸しし、Windows 10前提の新規展開が残っていないか確認してください。次に、本番と同じネットワークでOOBEからAutopilotを検証し、DNS、80/443/123番ポート、Autopilot関連URL、Intune、Microsoft Entra ID、Windows Updateへ到達できるかを確認します。最後に、Microsoft Entraの自動MDM登録、ユーザーライセンス、Entra参加権限、Autopilotプロファイル割り当てを一般ユーザー条件で検証します。
Autopilotの失敗は、端末側の問題に見えても、実際にはネットワーク、ライセンス、ID構成、登録手順のどこかに原因があることが少なくありません。2026年時点の展開では、Windows 11を中心に、クラウドネイティブなMicrosoft Entra参加を基本線として設計し、例外的なハイブリッド構成やWindows 10運用は要件を個別に確認することが重要です。
コメント