Microsoft Intuneの公式ドキュメント更新「updated enrollment profile」で最初に確認すべき点は、既存の登録プロファイルが突然使えなくなるかどうかではなく、社内の運用手順が新しい enrollment policy（登録ポリシー） 表記と運用に追随できているかです。
2026年4月29日のMicrosoftDocs/memdocsのコミットでは、IntuneのAppleデバイス登録関連ドキュメントを中心に、enrollment profileからenrollment policyへの表記整理が広範囲に行われています。コミット上では24ファイルが変更され、89行の追加と89行の削除が確認できます。(GitHub)
実務上は、iOS/iPadOSやmacOSのApple Automated Device Enrollment（ADE）を使っている組織ほど影響を確認すべきです。特に、security admins、compliance teams、enterprise IT readersは、登録ポリシーの割り当て漏れ、既存プロファイルからの移行、Company Portalの扱い、Conditional Accessやコンプライアンス評価への影響を点検しておく必要があります。
Microsoft Intuneの公式ドキュメント更新「updated enrollment profile」で何が変わったか
今回の更新は、Intuneの管理機能そのものが一斉に変更されたというより、公式ドキュメント上の表記と運用説明が、新しい enrollment policy ベースの管理に寄せられた更新と見るのが適切です。
主な変更は次の3つです。
| 確認項目 | 公式更新で見える内容 | 実務での見方 |
|---|---|---|
| enrollment profileからenrollment policyへの表記変更 | 複数のApple登録関連ページで「profile」が「policy」に置き換えられている | 社内手順書、監査資料、ヘルプデスク回答で古い名称が残っていないか確認する |
| Apple Business ManagerからApple Businessへの表記整理 | Microsoft Learn上の一部説明で「Apple Business」という表記が使われている | Apple側のポータル名・契約名と、Microsoft Docs上の表記を混同しない |
| iOS/iPadOS・macOS ADE運用の整理 | 登録ポリシーの作成、割り当て、既定ポリシー設定が強調されている | 新規端末の出荷前にポリシー未割り当てを防ぐ運用が重要になる |
たとえば、iOS/iPadOS ADEの公式ドキュメントでは、Intune管理センターでApple mobileのEnrollment program tokensを開き、トークン配下のEnrollment policiesからポリシーを作成する流れが説明されています。さらに、デバイスが有効化される前に登録ポリシーを割り当てる必要があり、未割り当てのままユーザーが端末を起動すると登録に失敗すると明記されています。(Microsoft Learn)
これは「緊急対応が必要な仕様変更」なのか
結論から言うと、すべての環境で即日緊急対応が必要な更新とは限りません。ただし、ADEでAppleデバイスを大量展開している組織では、後回しにすると新規端末配布や移行時に混乱しやすい更新です。
背景として、Microsoftは以前からiOS/iPadOSおよびmacOSのADE enrollment policies experienceを案内しており、新しく作成される登録ポリシーは新しい体験に含まれること、既存のenrollment profilesは影響を受けないものの、今後の新機能は古いenrollment profilesには追加されない方針を示しています。(TECHCOMMUNITY.MICROSOFT.COM)
つまり、今回の「updated enrollment profile」は、次のように捉えると実務に落とし込みやすくなります。
- 既存プロファイルが直ちに消えるという意味ではない
- ただし、新規作成・新機能・公式手順はenrollment policy中心に移っている
- 端末登録の運用設計、監査証跡、ヘルプデスク手順は更新が必要
- ADEの新規展開や更新タイミングでは、旧profile前提の手順を使い続けないほうがよい
特にグローバル企業では、地域ごとのIT担当が古い「profile」という呼び方で手順を維持している場合があります。表記だけの問題に見えても、画面上のタブ名、手順書のスクリーンショット、監査時の説明がずれると、運用ミスにつながります。
まず確認すべきMicrosoft Intuneの設定箇所
今回の更新を受けて、最初に見るべき場所はApple ADE関連の登録設定です。
| 確認場所 | 確認内容 | 見落としやすいポイント |
|---|---|---|
| Enrollment program tokens | Apple BusinessまたはApple School Managerとのトークンが有効か | トークン期限切れやVPPライセンス不足が登録失敗の原因になる |
| Enrollment policies | 新しい登録ポリシーが作成済みか | 旧Profilesタブだけを見て、ポリシー未作成に気づかない |
| Devicesタブ | 対象デバイスに登録ポリシーが割り当てられているか | 端末をユーザーへ渡した後では、登録失敗の切り分けが面倒になる |
| Set Default Policy | 新規同期デバイス向けの既定ポリシーがあるか | デフォルト未設定だと、新規入荷端末で割り当て漏れが起きやすい |
| User Affinity | ユーザーあり・なしの設計が業務用途に合っているか | 共有端末、キオスク端末、個人割り当て端末を同じ設計にしない |
| Company Portal | 必要な配布方法と認証方式が整理されているか | App Store版を使う、または不要なアプリ構成を重複配布する |
Microsoft Learnでは、iOS/iPadOS ADEの登録ポリシーについて「1つの登録トークンあたり1,000個まで」という制限や、ポリシー未割り当てのデバイスを起動すると登録に失敗する点も説明されています。(Microsoft Learn)
既存のenrollment profileをどう扱うべきか
既存のenrollment profileを使っている場合、すぐに削除する必要はありません。むしろ、影響範囲を確認しないまま削除するほうが危険です。
MicrosoftのIntune Customer Successブログでは、既存のenrollment profilesは削除、編集、デバイスへの割り当て、表示が可能で、既存のデバイス割り当ては影響を受けないと説明されています。一方で、新しいenrollment policyを作成し、既定ポリシーとして設定することが推奨されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、次の順番で進めると安全です。
既存profileの棚卸しをする
まず、現在使っているenrollment profileを一覧化します。
確認する項目は、少なくとも次の通りです。
- 対象プラットフォーム：iOS/iPadOS、macOS
- 用途：個人割り当て端末、共有端末、キオスク、教育機関向け端末
- User Affinityの有無
- 認証方式：Setup Assistant with modern authentication、Company Portal、legacy Setup Assistantなど
- Company Portalの配布有無
- Setup Assistantで非表示にしている画面
- デバイス名テンプレート
- 対象トークンと対象デバイス数
- Conditional Accessやコンプライアンスポリシーとの関係
この棚卸しをせずに新しいポリシーを作ると、「登録はできたが準拠状態にならない」「Company Portalが想定通り入らない」「共有端末なのにユーザー前提の設定になっている」といった問題が起きやすくなります。
新しいenrollment policyを用途別に作る
新しい登録ポリシーは、1つですべてをまかなうより、用途ごとに分けるほうが管理しやすくなります。
| 用途 | ポリシー設計の例 | 注意点 |
|---|---|---|
| 役職者・一般社員向けiPhone | User Affinityあり、Setup Assistant with modern authentication | 初回サインイン、MFA、JIT登録、Company Portal要否を確認 |
| 共有iPad | User Affinityなし、Shared iPad向け設定 | ユーザー割り当てアプリや一部ポリシーが想定通り使えない場合がある |
| macOS標準端末 | User Affinityあり、macOS ADEポリシー | macOSではCompany Portalサインインが必要になる場面を確認 |
| 店舗・現場端末 | User Affinityなし、必要アプリを必須配布 | 利用者がサインインしない前提でアプリ、証明書、Wi-Fiを設計 |
| 検証用端末 | 本番と同じ構成を小規模に再現 | 本番既定ポリシーにする前の検証に使う |
macOS ADEの公式ドキュメントでは、登録ポリシーがMacデバイスの登録体験を定義し、割り当てられたデバイスへover-the-airで展開されると説明されています。(Microsoft Learn)
登録ポリシーの割り当て漏れを防ぐ
今回の更新で特に重視すべき運用ポイントは、登録ポリシーの割り当て漏れです。
Apple BusinessまたはApple School ManagerからIntuneへデバイスが同期されていても、対象デバイスに適切なenrollment policyが割り当てられていなければ、ユーザーが端末を起動した時点で登録に失敗する可能性があります。公式ドキュメントでも、デバイスが有効化される前に登録ポリシーを割り当てる必要があると説明されています。(Microsoft Learn)
実務では、次のチェックを出荷前プロセスに入れてください。
| タイミング | チェック内容 | 担当 |
|---|---|---|
| 端末購入後 | Apple BusinessまたはApple School ManagerでMDMサーバーへ端末を割り当てたか | 購買・IT資産管理 |
| Intune同期後 | 端末がEnrollment program tokens配下に表示されているか | Intune管理者 |
| 出荷前 | enrollment policyが割り当て済みか | キッティング担当 |
| 初回起動前 | 既定ポリシーが設定されているか | Intune管理者 |
| 初回登録後 | Entra登録、準拠状態、アプリ配布が完了しているか | セキュリティ運用・ヘルプデスク |
特に、海外拠点や外部ベンダーが端末を直接ユーザーへ発送する場合は、Intune上の割り当て確認を出荷条件に含めるべきです。端末がユーザーの手元に届いてから失敗すると、初期化、再同期、再割り当て、ユーザー対応が必要になり、ヘルプデスク負荷が増えます。
Apple Business表記の変更で注意すべきこと
今回のコミットでは、複数箇所で「Apple Business Manager」が「Apple Business」に置き換えられています。たとえば、ADEの説明やトークン、MDMサーバー、デバイス同期の説明で表記変更が確認できます。(GitHub)
ただし、これは少なくとも記事執筆時点では、自社のApple契約やポータル運用が自動的に変わったことを意味するとは限りません。Microsoft Learn上の表記ではApple Business portalやApple School Manager portalという案内が使われていますが、社内手順では実際のApple側画面、契約名、管理者ロール名と照合して更新する必要があります。(Microsoft Learn)
社内ドキュメントを直す場合は、次のように整理すると混乱を避けられます。
| 旧表記が残りやすい場所 | 修正方針 |
|---|---|
| 手順書の見出し | Microsoft Learnに合わせて「Apple Business」と書き換える。ただし必要に応じて「旧称・従来表記：Apple Business Manager」と補足する |
| 監査資料 | 実際の証跡画面名と公式ドキュメント表記を併記する |
| ヘルプデスクFAQ | ユーザー向けにはApple側名称より、端末登録の手順を優先して説明する |
| 管理者向けトレーニング資料 | Apple Business、Apple School Manager、Intuneのどの画面で作業するかを明確に分ける |
Company Portalの扱いは単純に「不要」と判断しない
今回の更新に関連して、Company Portalの扱いを見直す組織も多いはずです。ここで注意したいのは、Company Portalが不要になった環境と、まだ必要な環境を分けて考えることです。
Microsoftのブログでは、新しいADE enrollment policies experienceでは、登録ポリシー自体からCompany Portalアプリが自動展開されなくなること、Setup Assistant with modern authenticationが推奨されることが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
一方、iOS/iPadOS ADEの公式ドキュメントでは、Company Portalを使う場合はApp Store版ではなくIntune経由で展開するよう案内されています。App Store版はADEと互換性がなく、自動更新や可用性の面で適切ではないとされています。(Microsoft Learn)
また、macOS ADEでは、User AffinityありでSetup Assistant with modern authenticationを使う場合、Microsoft Entra IDへのデバイス登録を完了するために、ユーザーがCompany PortalアプリへMicrosoft Entra資格情報でサインインする必要があると説明されています。(Microsoft Learn)
判断基準は次の通りです。
| 判断ポイント | 推奨される確認 |
|---|---|
| iOS/iPadOS ADEでJIT登録を使う | Company Portalなしで登録・準拠評価が完了するか検証する |
| Company Portalをアプリ配布ポータルとして使う | 登録用ではなく、運用後のセルフサービス用として必要か判断する |
| ログ収集やデバイスアクションに使う | ヘルプデスク運用でCompany Portalが必要か確認する |
| macOS ADEを使う | Company Portalサインインが登録完了条件になっていないか確認する |
| 旧Company Portal認証方式を使っている | 新しい登録ポリシーへ移行する前に、認証方式とアプリ構成ポリシーを再設計する |
失敗しやすいのは、「Company Portalを入れれば安全」と考えて、ADE端末に不要なアプリ構成ポリシーを重複配布してしまうケースです。公式ドキュメントでは、初期登録時にIntuneが自動でCompany Portal向けの構成を送る条件があるため、手動で同じ構成を配布すると競合し、ユーザーに不要なサインインや管理ポリシーの再取得を求める可能性があると説明されています。(Microsoft Learn)
登録ポリシー変更後の反映タイミングに注意する
Intuneの登録ポリシーは、変更した瞬間に既存端末へすべて反映されるわけではありません。
iOS/iPadOS ADEの公式ドキュメントでは、既存の登録ポリシーを変更しても、割り当て済みデバイスには工場出荷時状態へリセットして再アクティブ化するまで新しい設定が反映されないと説明されています。例外として、デバイス名テンプレートの変更は次回チェックイン時に反映されます。(Microsoft Learn)
この点は、移行計画で非常に重要です。
たとえば、次のような誤解は避ける必要があります。
| 誤解 | 実際の注意点 |
|---|---|
| ポリシーを編集すれば既存端末のSetup Assistant画面も変わる | 多くの登録体験設定は再初期化・再アクティブ化が必要 |
| 既定ポリシーを変えれば全端末が新設定になる | 主に今後登録される端末への影響として考える |
| 端末名テンプレートと他の登録設定は同じ扱い | 端末名テンプレートは例外的に次回チェックインで反映される |
| パイロットなしで本番既定ポリシーを変更してよい | 新規登録フロー、MFA、準拠状態、アプリ配布を事前検証すべき |
セキュリティチームやコンプライアンスチームは、「ポリシーを更新した」という事実だけで完了扱いにせず、対象端末がいつ新しい登録体験を通過したのかを確認する必要があります。
セキュリティ管理者が確認すべき影響範囲
security adminsが見るべきポイントは、単なる名称変更ではありません。登録方式は、デバイス所有者、準拠状態、Microsoft Entra ID登録、Conditional Access、アプリ保護の評価に関係します。
企業所有端末として正しく扱われるか
Apple ADEで登録する端末は、企業所有端末として管理されることが前提です。社内で「個人所有端末をブロックする」登録制限やConditional Accessを使っている場合、登録ポリシー変更後も端末所有者が正しく反映されるか確認してください。
確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| Ownership | Corporateとして表示されるか |
| Microsoft Entra registration | 期待したユーザーまたはデバイスとして登録されているか |
| Compliance state | 準拠ポリシーが正常に評価されるか |
| Conditional Access | 想定通りアクセス許可・ブロックされるか |
| App deployment | 必須アプリ、VPPアプリ、構成プロファイルが配布されるか |
| Device actions | ワイプ、同期、リモートロックなどの操作が可能か |
User Affinityの設計が用途に合っているか
User Affinityありの端末は、特定ユーザーと端末を関連付ける用途に向いています。一方、店舗端末、受付端末、倉庫端末、共有iPadのようなデバイスでは、User Affinityなしの設計が適している場合があります。
判断を誤ると、次のような問題が起きます。
| 誤った設計 | 起こりやすい問題 |
|---|---|
| 共有端末にUser Affinityありを選ぶ | 最初に登録したユーザーの状態に依存し、後続ユーザーの運用が複雑になる |
| 個人割り当て端末にUser Affinityなしを選ぶ | ユーザー対象のアプリやポリシーが期待通り適用されない |
| Company Portal前提の手順を残す | 新しい登録体験と矛盾し、ユーザー操作が増える |
| macOSとiOSを同じ前提で設計する | Company Portal、Entra登録、認証方式の違いを見落とす |
コンプライアンスチームが見るべき監査上のポイント
compliance teamsにとって重要なのは、「古い名称の資料が残っているか」だけではありません。登録ポリシーの変更は、端末が管理対象になる入口に関わるため、監査証跡として次の情報を整理しておくべきです。
| 監査観点 | 残すべき情報 |
|---|---|
| 登録方式 | ADE、Apple User Enrollment、Company Portal、Web-based enrollmentなど |
| 対象範囲 | iOS/iPadOS、macOS、共有端末、個人割り当て端末 |
| 登録ポリシー名 | いつ作成し、どのトークンに紐づくか |
| 既定ポリシー | どのポリシーをデフォルトにしているか |
| 割り当て根拠 | デバイス、グループ、シリアル番号のどれで割り当てているか |
| 変更履歴 | 旧profileから新policyへ移行した日付、承認者、検証結果 |
| 例外管理 | 旧profileを残す理由、対象端末、廃止予定日 |
特に規制産業では、「Intuneで管理している」と説明するだけでは不十分です。どの登録ポリシーで、どの時点から、どの端末群に適用したのかを説明できる状態にしておく必要があります。
移行準備の実務手順
既存のenrollment profileから新しいenrollment policy中心の運用へ移る場合は、次の順番で進めると失敗しにくくなります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | 現在のprofileとpolicyを棚卸しする | 端末登録設定一覧 |
| 2 | 用途別に新しいenrollment policyを設計する | iOS、macOS、共有端末などの設計表 |
| 3 | 検証用デバイスへ割り当てる | パイロット対象端末リスト |
| 4 | 初期登録を実施する | 登録ログ、準拠状態、アプリ配布結果 |
| 5 | Conditional Accessと業務アプリを確認する | アクセス可否、MFA、業務アプリ動作結果 |
| 6 | 問題がなければ既定ポリシーを設定する | default policy設定記録 |
| 7 | 社内手順書とヘルプデスクFAQを更新する | 新しい運用手順書 |
Microsoft Learnのチュートリアルでも、Apple BusinessでMDMサーバーを作成し、端末を割り当て、Intuneへトークンをアップロードし、登録ポリシーを作成・割り当てる流れが示されています。同期後、デバイスが管理センターに表示されるまで最大12時間かかる場合があり、手動同期も可能です。(Microsoft Learn)
よくある失敗と対策
| 失敗 | 原因 | 対策 |
|---|---|---|
| 旧profileを消してしまい登録できない端末が出る | 移行前に割り当て状況を確認していない | 既存profileは棚卸し後、段階的に移行する |
| 新規端末がADE登録に失敗する | enrollment policy未割り当て、または既定ポリシー未設定 | 出荷前チェックにポリシー割り当て確認を入れる |
| Company Portalでサインインループが起きる | 認証方式とアプリ構成ポリシーが矛盾している | Setup Assistant、JIT登録、Company Portal配布条件を整理する |
| macOSで登録完了後に準拠にならない | Company PortalサインインやEntra登録が完了していない | macOS用の登録後タスクをユーザー手順に含める |
| 監査資料と画面名が一致しない | profileとpolicyの表記が混在している | 社内文書をenrollment policy中心に更新する |
| ポリシー変更が既存端末に反映されない | 再初期化が必要な設定を理解していない | 変更反映条件をリリース計画に明記する |
| Apple Business表記で混乱する | Microsoft DocsとApple側画面の表記差を説明していない | 手順書に「Microsoft Learn上の表記」と「実画面」を併記する |
どの組織ほど優先度が高いか
今回の更新は、次のような組織ほど優先度を上げて確認すべきです。
- Apple BusinessまたはApple School Manager経由でiPhone、iPad、Macを大量展開している
- ADEでゼロタッチ展開をしている
- 新入社員向け端末や店舗端末を定期的に出荷している
- Conditional Accessで準拠デバイスを必須にしている
- 旧Company Portal認証方式を使っている
- 監査や内部統制で端末登録プロセスの証跡が必要
- グローバル拠点ごとにIntune手順が分散している
- ヘルプデスクが古い「profile」前提のFAQを使っている
逆に、Apple ADEを使っておらず、Windows AutopilotやAndroid Enterprise中心の環境では、今回の更新の直接的な影響は限定的です。ただし、Intune全体で「profile」と「policy」の用語整理が進む可能性を考えると、デバイス登録関連の社内表記は一度見直しておく価値があります。
今日やるべき確認リスト
最後に、Microsoft Intune管理者が今日実施できる確認をまとめます。
| 優先度 | 確認項目 | 完了条件 |
|---|---|---|
| 高 | Apple ADEのEnrollment program tokensを確認する | 有効なトークン、対象デバイス、同期状況が把握できている |
| 高 | Enrollment policiesが作成されているか確認する | 用途別の登録ポリシーが存在する |
| 高 | 既定ポリシーを確認する | 新規同期デバイスに適用されるdefault policyが設定済み |
| 高 | 旧profileの割り当て状況を棚卸しする | 旧profileを残す理由と移行予定が明確 |
| 中 | Company Portalの配布方法を確認する | App Store版ではなく、必要に応じてIntune経由で配布している |
| 中 | Conditional Accessと準拠状態を検証する | 登録後に業務アプリへ想定通りアクセスできる |
| 中 | macOSとiOS/iPadOSの手順を分ける | プラットフォーム差が手順書に反映されている |
| 低 | 社内文書の表記を更新する | enrollment profileとenrollment policyの混在が解消されている |
今回の「updated enrollment profile」は、単なる用語変更として流すには少し重要な更新です。Microsoft IntuneのAppleデバイス登録は、今後ますますenrollment policy中心の説明に移っていきます。
まずは、既存profileを削除するのではなく、現在の割り当て、既定ポリシー、Company Portalの扱い、登録後の準拠状態を確認してください。そのうえで、新しいenrollment policyを検証用端末に割り当て、本番の既定ポリシーへ段階的に移行するのが安全です。
コメント