Microsoft Intuneの「Device enrollment guide for Microsoft Intune」は、デバイスをIntuneに登録する前に、Microsoft Entra ID、MDM証明書、デバイス所有形態、登録制限、既存MDMからの移行方法を整理するための公式ガイドです。結論から言うと、管理者が最初に確認すべきなのは「どの手順で登録するか」ではなく、どのデバイスを許可し、誰に割り当て、登録後にどのポリシーを適用するかです。
特に、Windows、macOS、iOS/iPadOS、Android、Linuxを混在管理している組織では、登録方式を誤ると「端末は登録できたが、条件付きアクセスで業務アプリに入れない」「既存MDMの設定が残ったままになる」「ADEやAutopilotの想定と違う所有区分になる」といった運用トラブルにつながります。2026年5月21日の更新情報としてこのガイドを確認する場合も、影響は“すでに登録済みの全端末が即座に変わる”というより、今後の登録・再登録・移行設計に関わる確認項目が整理されたものとして捉えるのが実務的です。
なお、確認時点のMicrosoft Learnでは、英語版の対象ページは2026年4月9日、日本語版は2026年4月10日が最終更新日として表示されています。更新通知の日付とページ上の更新日がずれる場合があるため、社内展開では対象ページ本文だけでなく、Windows、Apple、Androidなどのプラットフォーム別ガイドも併せて確認してください。(Microsoft Learn)
Microsoft Intuneのデバイス登録ガイドでまず理解すべきこと
Microsoft Intuneのデバイス登録は、単に端末を一覧に追加する作業ではありません。Microsoft Entra IDにユーザーやデバイスが登録され、そのうえでIntuneがMDM証明書をデバイスにインストールし、登録ポリシー、コンプライアンスポリシー、構成ポリシーなどを適用できる状態にするプロセスです。(Microsoft Learn)
この流れを理解していないと、登録後のトラブル原因を見誤ります。たとえば、ユーザーがCompany Portalアプリでサインインできても、デバイスが正しいMicrosoft Entra IDの状態になっていなければ、条件付きアクセスやコンプライアンスポリシーの評価で失敗することがあります。逆に、Intune側の登録制限が厳しすぎると、デバイスが業務利用前にブロックされます。
対象ガイドでは、登録できる主なプラットフォームとしてAndroid、iOS/iPadOS、Linux、macOS、Windowsが示されています。また、登録は既定ですべてのプラットフォームで有効ですが、Intuneの登録制限ポリシーを使って特定プラットフォームの登録を制限できます。(Microsoft Learn)
今回の更新で管理者が見るべき実務ポイント
「Device enrollment guide for Microsoft Intune」は、特定の1機能だけを変更する告知ではなく、Intune登録の前提条件と判断軸を整理するページです。実務上は、次の観点で自社テナントへの影響を確認します。
| 確認項目 | 何を意味するか | 管理者が取るべき対応 |
|---|---|---|
| Microsoft Entra IDとの関係 | Intune登録前に、デバイスIDとユーザー認証の設計が必要 | Microsoft Entra登録、Microsoft Entra参加、ハイブリッド参加のどれを使うか整理する |
| MDM証明書 | 登録中にMDM証明書が入り、Intuneとの通信とポリシー適用が始まる | 証明書、コンプライアンスポリシー、構成プロファイルの適用順をパイロットで確認する |
| 個人所有と会社所有 | BYODと組織所有では適用できる制御やパスワード要件が異なる | 所有区分の判定ルールを決め、誤って個人所有扱いにならないようにする |
| 登録制限 | プラットフォーム、OSバージョン、メーカー、所有形態、登録台数を制限できる | 既定の許可状態を放置せず、対象外OSや私物端末の扱いを明文化する |
| 既存MDMからの移行 | 移行元MDMの登録解除や、プラットフォーム別の初期化要否が関係する | 端末種別ごとに「ワイプあり」「ワイプなし」の移行パターンを分ける |
| パイロット展開 | いきなり全社適用せず、小規模グループから段階的に広げる | テストグループ、先行部門、全社展開の順に割り当て範囲を拡張する |
Intuneの登録制限には、デバイスプラットフォーム制限とデバイス制限制限があります。プラットフォーム制限ではOS、メーカー、所有形態などを使って登録を制御でき、デバイス制限制限ではユーザーが登録できる台数を制御できます。(Microsoft Learn)
影響範囲：管理者、セキュリティ担当、開発者が確認すべきこと
Microsoft Intuneのデバイス登録ガイドの影響は、Intune管理者だけにとどまりません。条件付きアクセス、業務アプリ、ヘルプデスク運用、端末キッティングにも関係します。
| 対象者 | 影響する業務 | 確認ポイント |
|---|---|---|
| Intune管理者 | 登録ポリシー、登録制限、構成プロファイルの設計 | MDM機関がIntuneに設定されているか、ライセンスが割り当て済みか、登録対象グループが整理されているか |
| ID・セキュリティ担当 | Microsoft Entra ID、条件付きアクセス、MFA | 登録済みデバイスや準拠デバイスを条件にしたアクセス制御が、登録方式と矛盾していないか |
| Windows管理者 | Autopilot、グループポリシー登録、共同管理 | Microsoft Entra参加、ハイブリッド参加、Configuration Manager共同管理のどれを使うか |
| Apple管理者 | ADE、Apple Configurator、Apple MDMプッシュ証明書 | Apple Business ManagerまたはApple School Manager、ADEトークン、MDMプッシュ証明書の有効期限 |
| Android管理者 | Android Enterprise、AOSP、仕事用プロファイル | GMSあり端末はAndroid Enterprise、GMSなし端末はAOSPなど、端末の用途に合う登録方式を選ぶ |
| アプリ開発者・アプリ担当 | 業務アプリのサインイン、デバイス準拠状態、アプリ保護 | アプリ側で「未登録」「非準拠」「MAMのみ」の状態を想定したエラーメッセージや案内を用意する |
| ヘルプデスク | 登録失敗、Company Portal案内、再登録対応 | OS別の登録手順、失敗時の確認画面、初期化が必要なケースをナレッジ化する |
特に開発者やアプリ担当者は、Intune登録そのものを設定しなくても影響を受けます。たとえば、WindowsのBYOD登録ではMicrosoft 365アプリへのサインイン時に「組織がデバイスを管理できるようにする」選択が出るケースがあります。また、MDMユーザースコープとMAMユーザースコープが同じユーザーに有効な場合、MAMユーザースコープが優先され、デバイスがIntuneにMDM登録されない場合があります。(Microsoft Learn)
登録前に確認すべき設定チェックリスト
Intuneの登録トラブルは、登録手順そのものよりも「事前設定の不足」で起きることが多くあります。次の項目は、全社展開前に必ず確認しておきたいポイントです。
| 確認項目 | 確認する内容 | 見落とした場合のリスク |
|---|---|---|
| MDM機関 | MDM AuthorityがIntuneに設定されているか | Configuration Manager共同管理時に、どちらが管理主体か分からなくなる |
| ライセンス | 対象ユーザーまたはデバイスにIntuneライセンスが割り当てられているか | 登録途中で失敗する、ポリシーが適用されない |
| 管理ロール | Policy and Profile Managerまたは必要に応じてIntune Administrator権限があるか | 登録制限やプロファイルを作成・変更できない |
| サポートOS | 対象OSがIntuneのサポート範囲内か | 登録できても機能が保証されない、将来の更新で問題化する |
| Apple要件 | Apple MDMプッシュ証明書、Apple ID、ADEトークンを準備しているか | iOS/iPadOSやmacOSの登録が止まる |
| Android要件 | Managed Google Playとの接続やAndroid Enterprise方式を確認しているか | 仕事用プロファイル、フルマネージド、専用デバイスの構成に失敗する |
| グループ設計 | ユーザーグループ、デバイスグループ、パイロットグループを用意しているか | 全社に誤配布する、想定外の端末が登録される |
| 登録制限 | OS、メーカー、所有形態、登録台数の制限を設定しているか | 私物端末や古いOSが業務環境に入る |
| 監視方法 | 登録失敗レポートやトラブルシューティング手順を用意しているか | 初回展開時に失敗原因を切り分けられない |
公式ガイドでは、Intuneのセットアップ、MDM機関、ライセンス、サポート対象デバイス、管理ロール、Apple MDMプッシュ証明書、グループ準備、Device Enrollment Managerの利用が前提条件として示されています。(Microsoft Learn)
既存MDMからIntuneへ移行する場合の注意点
既存のMDMからMicrosoft Intuneへ移行する場合は、移行元MDMの登録解除を先に計画します。ただし、登録解除をしても既存の機能や設定が必ず削除されるとは限りません。Intune側で同じ設定を明示的に構成しない場合、以前のMDMで構成された設定が端末に残る可能性があります。(Microsoft Learn)
移行計画では、OS単位ではなく「登録方式」単位で初期化要否を判断するのが安全です。たとえば、Android Enterpriseの会社所有ワークプロファイル、フルマネージド、専用デバイスでは初期化が必要とされています。一方、WindowsやLinuxでは初期化不要のケースがあります。Appleについては、全体ガイドではiOS/iPadOSやmacOSのリセット要否に注意が必要とされ、関連する展開ガイドではBYODとADEで扱いが分かれるため、登録方式ごとの公式ページを確認してください。(Microsoft Learn)
| 移行対象 | 判断の目安 | 実務上の注意点 |
|---|---|---|
| Android Enterprise BYOD仕事用プロファイル | 初期化不要のケースがある | 仕事用プロファイル削除、再登録、アプリデータの扱いを利用者に案内する |
| Android Enterprise COPE、COBO、COSU | 初期化が必要 | 端末回収、バックアップ、QRコードやZero-touch登録の準備を先に行う |
| iOS/iPadOS | BYODかADEかで判断 | ADEは新規またはワイプ済み端末前提のため、既存端末移行ではワイプ計画が重要 |
| macOS | BYODかADEかで判断 | FileVault、証明書、Wi-Fi/VPN設定の再配布タイミングを確認する |
| Windows | 初期化不要のケースがある | 既存MDM設定、ローカル管理者権限、Autopilot再登録の要否を確認する |
| Linux | 初期化不要のケースがある | 対象ブラウザーや業務リソースへのアクセス要件を確認する |
「初期化不要」は「何もしなくてよい」という意味ではありません。移行元MDMの制御が残ったままIntuneポリシーを受けると、Wi-Fi、VPN、証明書、パスコード、暗号化設定などが競合する可能性があります。移行前に、既存MDMの構成プロファイルを棚卸しし、Intune側で再作成するもの、廃止するもの、利用者に再設定してもらうものを分けてください。
登録制限を設計する時の失敗しやすいポイント
Intuneの登録制限は便利ですが、過信は禁物です。Microsoft Learnでは、登録制限はセキュリティ機能そのものではなく、侵害されたデバイスが属性を偽る可能性があるため、善意のユーザー向けのベストエフォートな障壁と説明されています。(Microsoft Learn)
そのため、登録制限だけで端末セキュリティを完結させるのではなく、条件付きアクセス、コンプライアンスポリシー、デバイス構成、Defender系の保護、監査ログを組み合わせる必要があります。
反映待ちを考慮せずに登録テストを始める
登録制限や割り当てフィルターを変更した直後に端末を登録すると、期待したポリシーがまだ反映されていない場合があります。Microsoft EntraとIntuneの間でユーザー、グループ、フィルター割り当てを処理する更新は即時ではなく、通常15分程度かかることがあります。(Microsoft Learn)
展開手順書には、「グループ追加後すぐに登録しない」「登録テストは反映待ち時間を置いて実施する」と明記しておくと、不要な切り分けを減らせます。
デバイス制限制限を既存端末にも即時適用されると思い込む
デバイス制限制限やプラットフォーム制限の変更は、新規登録に効く設計です。既に登録済みの端末を即座に削除したり、構成を巻き戻したりするものではありません。デバイス制限制限は、Intune管理済みであること、直近90日以内にIntuneと接触していることなど、複数の条件を満たすデバイスを対象にします。(Microsoft Learn)
「今後登録させない設定」と「既存端末を是正する設定」は分けて考える必要があります。既存端末には、コンプライアンスポリシー、構成プロファイル、デバイスアクション、必要に応じたワイプやリタイアを使います。
DEMアカウントを万能な一括登録手段として使う
Device Enrollment Manager、いわゆるDEMアカウントは、多数の端末を配布前に登録・準備する場合に便利です。DEMアカウントでは最大1,000台を登録・管理できますが、標準の非管理者アカウントは15台までです。(Microsoft Learn)
ただし、DEMはすべての登録方式で使えるわけではありません。Apple Automated Device Enrollmentには対応せず、AOSPもDEMをサポートしません。また、DEMで登録した端末はユーザー関連付けやアプリ配布、条件付きアクセス、VPNプロファイルなどに制約が出る場合があります。(Microsoft Learn)
大量展開では「DEMで登録する」のではなく、「Autopilot、ADE、Android Enterprise、プロビジョニングパッケージ、DEMのどれがその端末用途に合うか」を先に選ぶべきです。
プラットフォーム別の登録方式をどう選ぶか
登録方式の選び方は、端末の所有者、利用者の有無、初期化できるか、リモート配布か、既存の管理基盤を残すかで決まります。
| シナリオ | 向いている方式 | 判断基準 |
|---|---|---|
| 新規購入のWindows PCを会社所有として配布 | Windows Autopilot、Microsoft Entra参加、自動登録 | 初回起動時から会社管理にしたい、リモート配布したい |
| 既存のオンプレAD参加Windowsを段階的に管理 | グループポリシーによる自動登録、または共同管理 | ハイブリッド参加やConfiguration Manager環境を維持したい |
| Configuration Manager管理を残したいWindows | 共同管理 | ワークロードを段階的にIntuneへ移したい |
| iPhoneやiPadを会社所有で配布 | Apple Automated Device Enrollment | Apple Business ManagerまたはApple School Managerで管理し、監視モードを使いたい |
| 共有Macやキオスク端末 | Apple Configurator、Direct Enrollment | ユーザー関連付けなしで端末を準備したい |
| Androidスマートフォンを業務専用で配布 | Android Enterpriseフルマネージド | 端末全体を会社管理にしたい |
| Android端末を個人利用も許可して配布 | Android Enterprise会社所有ワークプロファイル | 仕事領域と個人領域を分けたい |
| 私物端末で業務アプリだけ使わせたい | BYOD登録、またはアプリ保護ポリシー中心の運用 | 端末全体の管理が必要か、業務データ保護だけで足りるかを判断する |
Windows登録では、自動登録、BYOD登録、プロビジョニングパッケージ、Autopilot、共同管理、グループポリシー登録など複数の方法があります。Microsoft Learnでは、クラウドネイティブな管理を目指す場合はMicrosoft Entra参加を推奨する説明もあり、ハイブリッド参加ではIntune Connector for Active Directoryやドメインコントローラーへの接続要件も関係します。(Microsoft Learn)
Appleの自動デバイス登録では、Apple Business ManagerまたはApple School Managerで購入・割り当てた新規またはワイプ済み端末が前提です。Intune側ではApple MDMプッシュ証明書や有効なAppleトークンが必要です。(Microsoft Learn)
Android管理で特に注意したい点
Androidは、Intune登録の中でも方式選定を誤りやすいプラットフォームです。Google Mobile Servicesを利用できる一般的なAndroid端末では、Android Enterpriseの登録方式を優先して検討します。個人所有の仕事用プロファイル、会社所有ワークプロファイル、フルマネージド、専用デバイスなど、用途別に管理範囲が変わります。(Microsoft Learn)
一方、Android Device Administrator、いわゆるDA管理は非推奨であり、Google Mobile Servicesにアクセスできるデバイスでは利用できなくなっています。現在DA管理を使っている組織は、Android Enterpriseなど別の管理方式への移行計画を立てる必要があります。(Microsoft Learn)
現場で多い失敗は、古い手順書のままCompany Portal登録を案内してしまい、利用者がDAフローに進んでからブロックされるケースです。Android展開では、登録制限でDAをブロックするだけでなく、利用者に「QRコード」「Zero-touch」「Samsung Knox Mobile Enrollment」「Company Portal」など、どの方法で始めるのかを明確に案内してください。
展開前に作るべき社内向け手順
Intuneのデバイス登録を安定して進めるには、公式ガイドの内容をそのまま社内に転記するのではなく、自社の端末構成に合わせて短い手順に落とし込むことが重要です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | 端末台数、OS、所有区分、既存MDM、業務アプリ、証明書利用を棚卸しする | 端末インベントリ、移行対象リスト |
| 方針決定 | BYOD、会社所有、共有端末、キオスク端末ごとに登録方式を決める | 登録方式マトリクス |
| 事前設定 | MDM機関、ライセンス、Apple証明書、Managed Google Play、登録制限を設定する | Intune初期設定チェックリスト |
| パイロット | IT部門、先行部門、代表ユーザーで小規模に登録テストする | 失敗事例、FAQ、修正版手順 |
| 本番展開 | グループ単位で段階展開し、登録状況を監視する | 展開スケジュール、利用者向け案内 |
| 運用改善 | 登録失敗レポート、問い合わせ、非準拠端末を定期確認する | 運用レポート、改善タスク |
Microsoft Learnでも、ポリシー割り当ては小さく始め、パイロットまたはテストグループに割り当ててから段階的に広げることが推奨されています。(Microsoft Learn)
登録後の監視とトラブルシューティング
登録は「完了したら終わり」ではありません。初回展開後は、登録失敗、ポリシー未適用、条件付きアクセス失敗、ユーザーの途中離脱を確認する必要があります。
Intune管理センターでは、Enrollment failures report、Troubleshooting + support、Device enrollment pageを使って、登録失敗の発生日、理由、OS、OSバージョン、ユーザー名、登録方式などを確認できます。Device enrollment pageでは、初回登録時に適用された登録制限やEnrollment Status Pageポリシー、優先度、ターゲット、フィルター評価も確認できます。(Microsoft Learn)
ヘルプデスク向けには、少なくとも次の情報を用意しておくと対応が速くなります。
- 端末のOSとバージョン
- 会社所有か個人所有か
- どの登録方式を使ったか
- 登録時に表示されたエラー画面
- ユーザーが所属するMicrosoft Entra IDグループ
- 登録制限やフィルターの対象になっていないか
- 既存MDMや古い構成プロファイルが残っていないか
問い合わせ対応では、「もう一度登録してください」と案内する前に、登録制限、ライセンス、グループ割り当て、MAM/MDMスコープ、証明書、既存MDMの残留設定を確認するのが近道です。
管理者と開発者が次に取るべき行動
Microsoft Intuneのデバイス登録ガイドを確認したら、最初に行うべきことは、Intune管理センターで登録設定を変更することではありません。まず、自社の登録対象を「会社所有」「個人所有」「共有端末」「キオスク端末」「既存MDM移行端末」に分け、各グループに対して登録方式、初期化要否、適用ポリシー、サポート窓口を決めることです。
そのうえで、Intune管理者は登録制限とパイロットグループを設定し、セキュリティ担当は条件付きアクセスとコンプライアンスポリシーの前提を確認します。アプリ開発者やアプリ担当者は、未登録・非準拠・MAMのみの状態でもユーザーが次の行動を理解できるよう、サインイン失敗時の案内や社内FAQを整備してください。
Microsoft Intuneのデバイス登録は、最初の設計を誤ると後から修正するコストが大きくなります。公式ガイドのポイントは、「登録方法を選ぶ前に、ID、所有区分、登録制限、移行方式、監視方法を決める」ことです。まずは小規模なパイロットで、登録成功率、ポリシー適用、業務アプリへのアクセス、ヘルプデスク対応時間を確認し、その結果をもとに全社展開へ進めるのが安全です。
コメント