Microsoft Entra と Microsoft Intune のデバイス登録で最初に確認すべき結論は、「Step 5 – Enroll devices in Microsoft Intune」が単なる登録手順ではなく、デバイス ID、MDM 登録、コンプライアンス確認までをつなぐ展開の最終工程だという点です。管理者は、登録方法を OS ごとに選ぶだけでなく、Microsoft Entra ID への登録または参加、Intune 登録制限、MFA、既存 MDM からの移行、登録後のレポート確認までを一体で見直す必要があります。Microsoft Learn の該当ページでは、ページ上の最終更新日は 2026年4月29日と表示されているため、本稿では 2026年7月1日時点で確認すべき公式情報として、実務上の影響範囲と管理者の確認ポイントを整理します。(GitHub)
Microsoft Entra の Step 5 は「Intune 登録」だけで終わらない
Microsoft Entra の観点で見ると、Step 5 の中心は「デバイスを Microsoft Entra ID に登録または参加させ、その後 Microsoft Intune に登録し、コンプライアンスを確認する」流れです。Intune 登録中にはデバイスへ MDM 証明書がインストールされ、管理者が事前に作成した登録ポリシー、登録制限、構成ポリシーなどを適用できる状態になります。(Microsoft Learn)
ここで重要なのは、Intune にデバイスを登録する前に、Microsoft Entra ID 上でデバイス ID が確立されることです。公式情報では、Intune 管理の前提として Microsoft Entra ID での登録が必要とされており、どの ID オプションを使うかによって、利用できる登録方法やユーザーのサインイン体験が変わると説明されています。(Microsoft Learn)
実務では、次のように考えると判断しやすくなります。
| 観点 | 主な選択肢 | 実務上の判断ポイント |
|---|---|---|
| 個人所有デバイス | Microsoft Entra registered | BYOD、モバイル、個人 PC で業務リソースへアクセスさせる場合に検討 |
| 会社所有 Windows | Microsoft Entra joined | Windows Autopilot、自動登録、フル管理を行う場合に検討 |
| 既存 Configuration Manager 環境 | 共同管理 | すぐに Intune へ全面移行せず、ワークロード単位で段階移行する場合に検討 |
| モバイル・Mac | OS 別の登録方式 | Android Enterprise、Apple ADE、Company Portal など、所有形態と管理範囲で選択 |
「登録できるか」だけで判断すると、後から「コンプライアンスが取れない」「条件付きアクセスでブロックされる」「BYOD のはずが会社所有扱いになる」といった問題が起きやすくなります。Step 5 は、デバイス展開の最後に見えて、実際には ID 設計とポリシー設計の答え合わせをする工程です。
今回の確認ポイント：管理者が見るべき変更・影響範囲
今回の公式情報で管理者が注目すべき点は、新しいボタンや単独機能の追加ではなく、Intune 登録を始める前の前提条件がより実務的に整理されていることです。特に、既存 MDM からの移行、登録制限、デバイス登録マネージャー、MFA、OS 別の登録方法、登録後のレポート確認は、グローバル環境ほど影響が大きくなります。(Microsoft Learn)
| 確認項目 | 影響を受ける環境 | 管理者が行うべきこと |
|---|---|---|
| Microsoft Entra ID のデバイス状態 | 全テナント | registered / joined / hybrid joined の使い分けを確認 |
| Intune 登録制限 | BYOD、複数 OS 管理環境 | OS、バージョン、所有形態、登録台数の制限を整理 |
| 既存 MDM からの移行 | Jamf、他社 MDM、旧 MDM 利用環境 | 登録解除、リセット要否、再登録手順を事前に決める |
| MFA・条件付きアクセス | セキュリティ要件が高い組織 | 登録時 MFA の適用範囲とライセンスを確認 |
| Windows 自動登録 | Windows 10/11、Autopilot 利用環境 | MDM ユーザー スコープと MAM ユーザー スコープを確認 |
| Android 管理方式 | Android 端末を管理する組織 | Android Enterprise または AOSP 方式への移行状況を確認 |
| 登録後レポート | 全テナント | 不完全な登録、放棄された登録、コンプライアンス状態を確認 |
既存デバイスは「リセットが必要か」を先に判断する
既存デバイスを Intune へ登録する場合、最初に確認すべきなのは「現在どの MDM に登録されているか」と「Intune 登録前に初期化が必要か」です。公式情報では、別の MDM プロバイダーに登録されているデバイスは、Intune 登録前に既存 MDM から登録解除する必要があるとされています。さらに、Android Enterprise の会社所有プロファイル、フル マネージド、専用デバイス、Apple ADE の iOS/iPadOS、tvOS、visionOS、macOS などは、Intune 登録前に工場出荷時リセットが必要なケースとして整理されています。(GitHub)
一方で、Windows、Linux、BYOD の iOS/iPadOS、BYOD の macOS、個人所有 Android Enterprise 仕事用プロファイルなどは、表上はリセット不要とされています。ただし、リセット不要のデバイスでも、登録後すぐに Intune ポリシーのインストールが始まり、過去に構成された設定が残る場合があります。(GitHub)
実務では、次の順で棚卸しすると安全です。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 端末一覧を作る | OS、所有者、利用部門、現 MDM、Entra 状態を整理 | 「Windows は全部同じ」と扱い、BYOD と会社所有を混在させる |
| リセット要否を分類 | ADE、COPE、COBO、COSU などを確認 | 初期化が必要な方式を、業務中端末へそのまま適用する |
| 登録手順を分ける | 新規配布、既存端末、リモート端末で手順を分ける | すべて Company Portal 登録に寄せてユーザー負担が増える |
| パイロットを実施 | 小規模グループで登録、ポリシー、アプリ配布を検証 | 全社展開後にサインインやアプリ配布の問題が発覚する |
登録前の構成で確認すべき設定
Step 5 では、登録ポリシーを作成する前に、登録制限、デバイス分類、デバイス登録マネージャーなどを準備することが推奨されています。これらは登録作業そのものを簡単にするだけでなく、管理センター上でデバイスを整理し、意図しないデバイス登録を防ぐための重要な設定です。(Microsoft Learn)
デバイス登録制限
Intune のデバイス登録制限では、プラットフォーム、バージョン、製造元、所有形態、ユーザーごとの登録台数などを制限できます。たとえば、個人所有 Android の登録は許可するが、サポート対象外 OS の登録は拒否する、といった運用が可能です。公式情報では、Linux や一部の Windows 登録シナリオでは登録制限が利用できないことも示されています。(Microsoft Learn)
登録制限は、セキュリティ部門だけで決めると現場運用とずれやすい設定です。情シス、ヘルプデスク、端末調達、グローバル拠点の担当者で「許可する端末」「例外承認する端末」「拒否する端末」をあらかじめ合意しておくことが重要です。
デバイス登録マネージャー
大量の会社所有デバイスをキッティングして配布する場合は、デバイス登録マネージャーの利用を検討します。公式情報では、通常の非管理者アカウントでは 15 台までの登録に対し、デバイス登録マネージャーは最大 1,000 台の会社所有デバイスを登録・管理できるとされています。ただし、Apple Automated Device Enrollment など一部の登録方法では互換性がないため、選択した登録方式で使えるかを事前確認する必要があります。(Microsoft Learn)
登録時 MFA と条件付きアクセス
登録時に MFA を要求すると、デバイス登録を行うユーザーが本人であることを確認しやすくなります。公式情報では、Linux を除くプラットフォームで条件付きアクセス ポリシーと MFA ポリシーを使って有効化でき、Microsoft Entra ID P1 または P2 が必要とされています。(Microsoft Learn)
注意したいのは、MFA を強めるほどセキュリティは上がる一方で、初回登録の失敗率も上がりやすいことです。特に海外拠点、共有端末、夜間シフト、委託先ユーザーでは、MFA 手段を持っていない、スマートフォンを業務端末として使えない、登録時に本人確認が完了できないといった問題が起こります。全社展開前に、対象ユーザーが実際に登録を完了できるかをテストしてください。
OS 別に選ぶべき Intune 登録方法
Step 5 の重要な点は、OS ごとに推奨される登録方法が異なることです。Windows、Android、Apple、Linux を同じ「Intune 登録」として扱うと、所有形態や管理範囲に合わない構成になりやすくなります。
Windows：自動登録と Autopilot の設計が中心
Windows では、自動登録、BYOD 登録、プロビジョニング パッケージによる一括登録、Windows Autopilot、共同管理、グループポリシーによる登録などが整理されています。特に Windows Autopilot は会社所有のデスクトップ、ノート PC、キオスクで利用でき、Microsoft Entra join と組み合わせることで、リモートワーク環境でもデバイス配布と登録を標準化しやすくなります。(GitHub)
一方で、Windows 登録でよく起きる失敗が、MDM ユーザー スコープと MAM ユーザー スコープの設定ミスです。公式情報では、MDM ユーザー スコープを Some または All にすると、対象デバイスは Microsoft Entra ID に参加し、Intune で管理されます。一方、MAM ユーザー スコープは組織アカウントを管理するためのもので、BYOD や個人所有デバイス向けに設計されています。(Microsoft Learn)
さらに、BYOD シナリオで MDM と MAM の両方のユーザー スコープが有効な場合、MAM ユーザー スコープが優先され、デバイスは Intune に登録・管理されないと説明されています。Windows 端末が「登録されるはずなのに管理対象にならない」場合は、まずこの設定を確認してください。(GitHub)
Android：Android Enterprise を前提に考える
Android では、個人所有、会社所有、仕事用プロファイル、フル マネージド、専用デバイス、AOSP デバイス、ゼロタッチ登録など、所有形態と用途によって登録方式を選びます。Google Mobile Services を使用する個人所有・会社所有デバイスでは Android Enterprise 登録ソリューションが推奨され、GMS を持たない AOSP デバイスでは AOSP 登録方法を使用します。(GitHub)
特に注意すべきなのは Android device administrator 管理です。公式ページでは、Google Mobile Services にアクセスできるデバイスでは Android device administrator 管理が非推奨で、利用できなくなっていると説明されています。また Microsoft の Intune Customer Success ブログでは、GMS デバイスに対する Android device administrator 管理のサポート終了が 2024年12月31日から始まると案内されています。(Microsoft Learn)
既存の Android device administrator 端末が残っている場合は、単に「登録できているか」ではなく、今後の OS 更新、サポート、セキュリティ修正、ヘルプデスク対応の観点でリスクを評価し、Android Enterprise 方式への移行計画を作るべきです。
Apple：ADE と BYOD を混ぜない
Apple デバイスでは、iOS/iPadOS と macOS の登録方式として、Apple Automated Device Enrollment、Apple Configurator、Mac の BYOD 登録、Apple User Enrollment、Apple Device Enrollment などが整理されています。Apple デバイスを管理する前提として、Apple MDM プッシュ証明書のアップロードや、ADE を使う場合の Apple enrollment program token の取得が必要です。(GitHub)
会社所有デバイスなら ADE を基本にすると、監督モードや初期セットアップ時の自動登録を活用しやすくなります。BYOD の iPhone や iPad では、個人データと業務データの分離を意識し、Apple User Enrollment か Apple Device Enrollment のどちらが適切かを確認します。管理を強めたいからといって BYOD に会社所有向けの考え方を持ち込むと、プライバシー説明や利用規約の面でトラブルになりやすくなります。
Linux：有効化作業よりも対応範囲の説明が重要
Linux 登録は、BYOD シナリオの従業員や学生が個人 Linux デバイスを Microsoft Intune に登録し、Microsoft Edge から業務リソースへアクセスする用途として説明されています。公式情報では、Intune 管理者が管理センターで Linux 登録を有効化する必要はなく、自動的に有効で、登録された Linux デバイスは管理センターに表示されるとされています。(Microsoft Learn)
Linux は自動的に有効だからこそ、利用部門への説明が重要です。Windows と同じレベルのデバイス構成管理を期待するのではなく、どの業務リソースにアクセスできるのか、どの条件付きアクセス要件を満たす必要があるのかを明確にしておくと、運用時の誤解を減らせます。
グローバル環境での影響範囲
グローバル企業では、Step 5 の影響は本社の Intune 管理者だけにとどまりません。国や地域ごとに端末調達方法、BYOD 可否、通信環境、MFA 手段、Apple Business Manager や Android Enterprise の運用体制が異なるためです。
| 影響範囲 | 具体例 | 対応のポイント |
|---|---|---|
| 海外拠点 | 現地購入 PC、現地 SIM の Android、拠点独自 MDM | 登録方式を本社標準へ寄せる前に、現地の既存管理を棚卸しする |
| リモートワーカー | 端末に物理アクセスできない | Windows Autopilot、自動登録、ゼロタッチ登録を優先検討する |
| BYOD 利用者 | 個人スマートフォン、個人 PC | MAM と MDM の境界、プライバシー説明、利用条件を明確にする |
| ヘルプデスク | 登録失敗、MFA 失敗、Company Portal で停止 | 画面単位の手順書と失敗時の切り分けフローを用意する |
| セキュリティ部門 | 条件付きアクセス、コンプライアンス、暗号化 | 登録後の準拠状態をレポートで確認し、例外を放置しない |
特にリモートワーク環境では、Microsoft Entra join と Intune 自動登録の設計が重要です。公式情報では、Windows の Microsoft Entra join と自動登録は、リモートワークなど管理者がデバイスにアクセスできない場合のソリューションとして説明されています。(GitHub)
移行期限と注意すべき廃止・非推奨事項
Step 5 の公式ページ自体は、全テナントに対して「この日までに設定変更が必須」とする新しい一律の移行期限を示す内容ではありません。ただし、関連して注意すべき期限・非推奨事項はあります。
最も重要なのは Android device administrator 管理です。GMS デバイスに対する Android device administrator 管理は、Microsoft 側でサポート終了が案内されており、現在もこの方式を前提にしている環境では、Android Enterprise または AOSP など別の管理方式への移行確認が必要です。(TECHCOMMUNITY.MICROSOFT.COM)
また、Apple ADE や Android Enterprise の会社所有デバイスでは、登録前のリセットが必要になるケースがあります。これは「期限」ではありませんが、移行計画に大きく影響します。利用中端末を初期化する場合、業務停止、データ退避、ユーザー再セットアップ、アプリ再配布の工数を見込まなければなりません。(GitHub)
管理者が今すぐ確認すべきチェックリスト
Step 5 を実務に落とし込むなら、次の順で確認するのが効率的です。
| 優先度 | 確認項目 | 確認する場所・観点 |
|---|---|---|
| 高 | Microsoft Entra ID のデバイス状態 | registered、joined、hybrid joined の混在状況 |
| 高 | Windows の MDM/MAM ユーザー スコープ | 意図どおり MDM 登録される設定か |
| 高 | Android device administrator の残存 | GMS デバイスで旧方式が残っていないか |
| 高 | 既存 MDM からの移行対象 | Intune 登録前に解除・リセットが必要か |
| 中 | 登録制限 | OS、バージョン、所有形態、台数制限が現行運用と合うか |
| 中 | Apple 証明書・トークン | Apple MDM プッシュ証明書、ADE トークンの期限と管理者を確認 |
| 中 | 登録時 MFA | 対象ユーザー、例外、ライセンス、初回登録手順を確認 |
| 中 | デバイスカテゴリ | 部門別・用途別の自動グループ化が必要か |
| 中 | 登録後レポート | 不完全な登録、放棄された登録、コンプライアンス状態を確認 |
登録後の確認も忘れてはいけません。公式情報では、不完全なユーザー登録や放棄されたユーザー登録を追跡する Intune レポートが案内されており、Company Portal でユーザーがどこで登録を完了できなかったかを確認できます。トラブルシューティング用のドキュメントも用意されています。(Microsoft Learn)
よくある失敗と回避策
MDM と MAM のスコープを同時に有効化して意図しない挙動になる
Windows BYOD で「デバイスを Intune 管理したい」のか、「組織アカウントやアプリだけを保護したい」のかが曖昧なまま設定すると、MDM と MAM のスコープ設定で想定外の挙動になります。特に、両方が有効な場合に MAM が優先されるシナリオは、登録トラブルの原因になりやすいポイントです。(GitHub)
回避策は、ユーザー種別ごとに「会社所有 Windows」「個人所有 Windows」「モバイル BYOD」「共有端末」を分け、MDM と MAM の目的を明文化することです。
BYOD ユーザーに誤った登録手順を案内する
Windows の個人所有デバイスでは、ユーザーがどの選択肢を選ぶかによって、Microsoft Entra registered になるか、Microsoft Entra joined になるかが変わります。公式情報では、組織所有デバイスで職場アカウントを使って OOBE を進めると Microsoft Entra ID に参加し、会社所有として扱われること、BYOD ではユーザーに選ぶべき操作を明確に伝える必要があることが説明されています。(Microsoft Learn)
回避策は、ユーザー向け手順書に「この画面ではこの選択肢を選ぶ」とスクリーンショット付きで明記することです。ヘルプデスク向けには、誤って joined になった場合の切り戻し手順も用意しておくと安全です。
パイロットなしで全社展開する
公式情報では、Intune の登録ポリシーを初めて展開する場合や新しい構成を試す場合、小規模から開始し、パイロットまたはテストグループへ割り当てる段階的アプローチが推奨されています。(Microsoft Learn)
回避策は、最低でも「IT 部門」「一般ユーザー部門」「海外拠点またはリモートユーザー」「例外端末を持つ部門」の複数グループで検証することです。1つのテスト端末だけで成功しても、全社展開の検証としては不十分です。
まず実行すべき次のアクション
Microsoft Entra の Step 5 を確認した管理者は、まず Intune 管理センターと Microsoft Entra 管理センターで、現在のデバイス状態を棚卸ししてください。次に、Windows の MDM/MAM ユーザー スコープ、Android の管理方式、Apple の ADE 準備状況、既存 MDM からの移行対象を確認します。
そのうえで、小規模なパイロットグループに対して登録ポリシーを割り当て、登録成功率、コンプライアンス状態、アプリ配布、条件付きアクセスの動作を確認します。Step 5 は展開の最終工程ですが、失敗するとユーザーが業務リソースにアクセスできなくなるため、単なる登録手順ではなく「ID、管理、セキュリティを接続する本番移行チェック」として扱うことが重要です。
コメント