Microsoft Intuneの公式ドキュメント更新「PM edits」は、単なる表記ゆれの修正として流し読みしないほうがよい更新です。結論から言うと、確認すべき中心は「Apple ADEまわりの用語整理」「tvOS／visionOS対応条件」「登録ポリシー・トークン・動的グループ運用への影響」の3つです。
今回の更新は、Microsoft Intuneそのものの新機能発表というより、MicrosoftDocs系リポジトリで公開されたドキュメント差分です。ただし、エンタープライズ環境では、公式ドキュメントの文言変更が運用手順書、監査資料、ヘルプデスク回答、移行計画にそのまま影響します。特にApple Business Manager／Apple School Manager経由でiOS/iPadOS、tvOS、visionOSを自動登録している組織は、既存の「profile」前提の記述を見直すタイミングです。
Microsoft Intuneの公式ドキュメント更新「PM edits」で何が変わったか
2026年4月29日のGitHubコミット「PM edits」では、MicrosoftDocs/memdocsリポジトリ内のMicrosoft Intune関連ドキュメントが更新されました。差分は7ファイルで、対象は主にintune/device-enrollment/apple配下のApple自動デバイス登録、つまりADE関連ドキュメントです。コミット上では87行の追加、179行の削除が記録されています。(GitHub)
今回の更新で目立つのは、Apple ADEの登録設定を説明する文脈で、従来の「enrollment profile」寄りの表現が「enrollment policy」へ整理されている点です。たとえばApple School Manager向けの手順では、タイトルや本文が「create enrollment profile」から「create enrollment policy」に変更され、Intune管理センター上の操作も「Profiles」ではなく「Enrollment policies」、「Create profile」ではなく「Create policy」として説明されています。(Microsoft Learn)
つまり、今回の「PM edits」は、管理者がすぐに設定変更を強制される更新ではありません。一方で、現場の運用文書や監査証跡では、古い表現のままにしておくと「管理画面と手順書が一致しない」「トークン削除時の条件を誤解する」「tvOS／visionOSの制限を見落とす」といったミスにつながります。
まず確認すべきポイント
| 確認項目 | 変更・確認内容 | 実務上の影響 |
|---|---|---|
| 登録設定の名称 | profile中心の表現からpolicy中心の表現へ整理 | 手順書、教育資料、申請フォーム、ヘルプデスク回答の修正が必要 |
| Apple ADEの対象 | iOS/iPadOS、tvOS、visionOSのADE対応が整理 | プラットフォーム別の展開計画を見直す必要がある |
| tvOS／visionOSの制限 | ユーザーアフィニティなし、コンプライアンスポリシー非対応などを確認 | セキュリティ基準や監査チェック項目の設計に影響 |
| ACME証明書 | tvOS 26.0以降、visionOS 26.0以降がサポート対象として明記 | OSバージョン要件を満たさない端末の移行判断が必要 |
| ADEトークン削除 | 既定のポリシー、登録ポリシー、割り当て済みデバイスの条件を確認 | トークン整理やテナント統合時の作業ミスを防ぐ |
| 動的グループ | enrollmentProfileNameとenrollmentPolicyNameの扱いを検証 | 自動割り当て、アプリ配布、構成プロファイル配布に影響する可能性 |
「enrollment profile」から「enrollment policy」への表記整理を見落とさない
最も分かりやすい変更は、Apple ADE関連の用語が「プロファイル」から「ポリシー」へ寄せられている点です。
たとえばtvOS向けの公式手順では、登録ポリシーを作成する流れとして、Microsoft Intune管理センターで「Devices」から「Enrollment」に進み、Apple mobileタブ、Enrollment program tokens、Enrollment policies、Create policy > tvOSを選ぶ流れが説明されています。(Microsoft Learn)
visionOS向けの手順でも同様に、Enrollment program tokensからEnrollment policiesを選び、visionOS向けの登録ポリシーを作成する流れが示されています。(Microsoft Learn)
運用文書で置き換えるべき表現
| 古い表現として残りやすいもの | 新しい表現として合わせたいもの | 見直す場所 |
|---|---|---|
| Enrollment profile | Enrollment policy | 手順書、社内Wiki、教育資料 |
| Profiles | Enrollment policies | 画面遷移説明、スクリーンショット |
| Create profile | Create policy | 新規登録手順 |
| Assign profile | Assign policy | デバイス割り当て手順 |
| Set Default Profile | Set Default Policy | 既定設定の説明 |
| default profile | default policy | トークン削除条件、監査資料 |
ここで重要なのは、単純な言葉の置換だけで終わらせないことです。管理画面の名称が変わると、運用担当者が参照する手順、チケットの分類名、申請項目、作業完了チェックリストもずれます。
特に新人管理者や海外拠点のIT担当者が作業する環境では、「Profilesを選択」と書かれた手順書を見て、現在の管理画面上で該当項目を見つけられない可能性があります。画面名が変わっただけでも、夜間作業や大量展開時には十分なリスクになります。
動的グループの条件はすぐ置換せず、必ず検証する
今回の更新で注意したいのが、Microsoft Entra IDの動的グループ条件です。
Apple School Manager向けの更新後ドキュメントでは、登録ポリシー名を使ってデバイスをグループに割り当てる例として、enrollmentPolicyNameパラメーターに言及しています。(Microsoft Learn)
一方で、教育機関向けのIntune計画ドキュメントでは、Automated Device Enrollmentで登録されたデバイスにenrollmentProfileNameが付与される説明や、device.enrollmentProfileName -eq "use case"のような例が引き続き掲載されています。(Microsoft Learn)
そのため、既存環境でdevice.enrollmentProfileNameを使っている場合、ドキュメント更新だけを理由に即座にenrollmentPolicyNameへ置き換えるのは避けるべきです。まず、テスト用の登録ポリシー、テスト端末、検証用の動的グループを使って、実際にテナント内で評価される属性を確認してください。
動的グループで確認すべき実務ポイント
| 確認対象 | 判断基準 | 推奨対応 |
|---|---|---|
| 既存の動的グループ | device.enrollmentProfileNameで期待通りメンバー化されているか | 動作中なら即時変更せず、棚卸し対象にする |
| 新規ルール | 管理センターまたはGraphで属性が評価可能か | 検証グループで1台ずつ確認する |
| アプリ配布 | ADE登録後、グループ反映までの遅延を許容できるか | 重要アプリは割り当て方式やフィルター併用を検討する |
| 監査資料 | ルール名と公式ドキュメントの用語がずれていないか | 「画面上はpolicy、属性名は検証済み名称」と明記する |
実務では、次のような既存ルールが残っていることがあります。
device.enrollmentProfileName -eq "ASM-iPad-Student-2026"このようなルールを見つけたら、まずは削除や置換ではなく、対象デバイス数、割り当てられているアプリ、構成プロファイル、コンプライアンス関連の依存関係を確認します。動的グループを誤って変更すると、アプリ未配布、構成未適用、スコープタグの不整合が発生する可能性があります。
tvOS／visionOSは「登録できる」だけでなく「何ができないか」を確認する
今回の更新では、Apple ADEにおけるtvOSとvisionOSの扱いも重要です。
Microsoft Learnの概要ページでは、Microsoft IntuneがApple mobile devicesとしてiOS/iPadOS、tvOS、visionOSのADEをサポートし、tvOSとvisionOSはユーザーアフィニティなしの登録のみをサポートすると説明されています。これらのプラットフォームでは、デバイスセットアップはApple Setup Assistantで完了し、登録後にデバイスを対象とするポリシーが適用されます。(Microsoft Learn)
tvOS向けの制限としては、ユーザーアフィニティなしで登録されること、コンプライアンスポリシーがサポートされないこと、登録ポリシーでSetup Assistant画面を構成できないこと、設定カタログ経由でアップロードされたカスタム構成プロファイルのみがサポートされることが記載されています。(Microsoft Learn)
visionOS向けにも、ユーザーアフィニティなし、コンプライアンスポリシー非対応、Setup Assistant画面の構成不可といった制限が示されています。(Microsoft Learn)
セキュリティ管理者が確認すべきこと
tvOSやvisionOSをエンタープライズ利用する場合、iOS/iPadOSと同じ統制をそのまま当てはめるのは危険です。
たとえば、iOS/iPadOSではユーザー単位の認証、アプリ配布、コンプライアンスポリシーを前提に運用していても、tvOS／visionOSでは同じ設計にならない場合があります。会議室端末、展示端末、研修用デバイス、現場共有デバイスとして使うなら、「誰が使っているか」よりも「どの場所にあり、どの構成が適用され、どのネットワークに接続できるか」を重視した管理設計が必要です。
| 利用シーン | 確認すべき観点 |
|---|---|
| 会議室のApple TV | Wi-Fi、AirPlay、アプリ制御、物理設置場所の管理 |
| 店舗・受付の共有端末 | ユーザーアフィニティなしでの設定適用、不要機能の制限 |
| Apple Vision Proの業務利用 | デバイス単位の構成、配布対象、ストレージ情報の表示制限 |
| 教育機関の共有iPad | Apple School Manager、Shared iPad、Managed Apple IDの整合性 |
ACME証明書の対応OSを移行計画に入れる
Apple ADEの概要ドキュメントでは、ACMEがサポートされるプラットフォームとして、iOS 16.0以降、iPadOS 16.1以降、tvOS 26.0以降、visionOS 26.0以降が示されています。(Microsoft Learn)
ACMEは証明書発行の検証や自動化を強化する仕組みとして説明されており、SCEPよりも不正な証明書発行を防ぎやすく、証明書管理のエラー削減に役立つとされています。(Microsoft Learn)
ここで移行担当者が確認すべきなのは、「IntuneがACMEに対応したか」だけではありません。対象端末のOSバージョン、登録方式、証明書ベースのWi-Fi／VPN／認証設計、既存のSCEP依存を棚卸しする必要があります。
ACME対応で確認するチェック項目
| 確認項目 | 具体的な見方 |
|---|---|
| OSバージョン | iOS/iPadOS/tvOS/visionOSごとにACME対応バージョンを満たすか |
| 登録方式 | 対象端末がADEで新規登録または再登録されるか |
| 証明書用途 | Wi-Fi、VPN、デバイス認証、管理プロファイルのどこで使うか |
| 既存SCEP | 既存構成を残すのか、段階的に移行するのか |
| 失敗時対応 | 証明書取得失敗時のログ確認手順、再登録手順を用意しているか |
セキュリティチームは、ACME対応を「証明書の安全性向上」として評価できます。一方で、現場展開ではOS要件を満たさない端末が混在しやすいため、全台一括移行よりも、端末種別や拠点単位で段階的に進めるほうが安全です。
supervised modeとlocked enrollmentはリセット要件まで含めて説明する
iOS/iPadOSのsupervised modeに関する更新も、運用上は重要です。
公式ドキュメントでは、supervised modeは企業所有デバイスを大規模に管理する際に有用で、AirDropの制限やデバイス名変更の防止など、より多くの管理オプションを提供すると説明されています。(Microsoft Learn)
ただし、登録後にsupervised modeへ変更する場合、iOS/iPadOSデバイスをMacに接続してApple Configuratorを使う必要があり、その際にデバイスはリセットされます。Intuneから登録後のデバイスをsupervised modeへ直接変更することはできません。(Microsoft Learn)
この点は、セキュリティ管理者よりも、実際に端末を配布・回収するIT運用チームが見落としやすいポイントです。
たとえば、次のようなケースでは事前説明が必要です。
| ケース | 起きやすい問題 | 事前対応 |
|---|---|---|
| 既存iPadをADE管理へ移行 | 利用者データの消失、再設定負荷 | バックアップ方針とワイプ手順を通知する |
| locked enrollmentを有効化 | 管理プロファイル削除ができなくなる | 例外対応フローを用意する |
| 監査でsupervised modeが必要 | 後から変更できず再登録が必要 | 配布前の登録ポリシーで設定を確認する |
| 大量端末展開 | 1台だけ設定漏れが発生しやすい | 既定ポリシーと割り当て状況を事前確認する |
「登録後に直せばよい」という考え方は、ADEでは通用しない設定があります。ワイプや再登録が必要な設定は、配布前チェックリストに入れておくべきです。
ADEトークン削除と既定ポリシーの条件を確認する
Apple ADEトークンの整理やテナント移行を予定している場合、今回の更新は特に重要です。
Microsoft Learnでは、登録プログラムトークンを削除できる条件として、トークンにデバイスが割り当てられていないこと、デバイスが既定のポリシーに割り当てられていないこと、そのトークン配下に登録ポリシーがないことが示されています。削除手順でも、トークンのDevicesから割り当て済みデバイスを削除し、Enrollment policiesから既定のポリシーを含む登録ポリシーを削除してから、トークンを削除する流れになっています。(Microsoft Learn)
さらに、トークンからデバイスを削除すると、それらのデバイスはIntune管理から削除され、使用中のデバイスではIntune管理下の企業リソースやアプリにアクセスできなくなる可能性があると警告されています。(Microsoft Learn)
トークン削除前の実務チェックリスト
| チェック | 確認内容 |
|---|---|
| デバイス割り当て | 対象トークンに端末が残っていないか |
| 既定ポリシー | default policyに端末が紐づいていないか |
| 登録ポリシー | トークン配下の登録ポリシーを削除できる状態か |
| 稼働中端末 | 業務利用中の端末を誤って管理外にしないか |
| 再登録計画 | 新トークンでワイプ・再登録する手順があるか |
| 利用者通知 | アプリや企業リソースにアクセスできなくなる可能性を通知したか |
トークン削除は、画面上は単純な管理操作に見えます。しかし実際には、端末管理の継続性、企業リソースへのアクセス、監査証跡に関わります。変更管理チケットを起票し、影響範囲とロールバック方針を明記してから作業するのが安全です。
既定ポリシーの設定は大量展開前に確認する
tvOSやvisionOSの公式手順では、端末がアクティブになる前に登録ポリシーを割り当てる必要があり、Apple BusinessまたはApple School Managerから同期された端末が起動された時点で登録ポリシーが割り当てられていないと、登録が失敗する可能性があると説明されています。(Microsoft Learn)
これは大量展開時に非常に重要です。倉庫や拠点に端末を発送したあと、現地担当者が先に電源を入れてしまうと、ポリシー未割り当てのままADEが始まり、初期セットアップが失敗することがあります。
大量展開前に確認する順序
| 順序 | 作業 | 目的 |
|---|---|---|
| 1 | Apple Business Manager／Apple School Managerで端末をMDMサーバーに割り当てる | Intuneと紐づける |
| 2 | IntuneでADEトークンを同期する | 端末一覧に反映する |
| 3 | 登録ポリシーを作成する | 登録時の設定を定義する |
| 4 | 対象端末へポリシーを割り当てる | 起動時に正しい設定を適用する |
| 5 | 必要に応じて既定ポリシーを設定する | 未割り当て端末の登録失敗を防ぐ |
| 6 | テスト端末を1台起動する | 実際のSetup Assistant挙動を確認する |
| 7 | 拠点展開を開始する | 本番配布する |
現場では「Apple側で割り当てたから完了」と誤解されがちです。Intune側で登録ポリシーが作成・割り当て済みであることまで確認してから、端末を開封・起動するようにしてください。
security admins、compliance teams、enterprise ITが分担して見るべき点
今回の更新は、Intune管理者だけで閉じる話ではありません。企業利用では、セキュリティ、コンプライアンス、IT運用がそれぞれ違う観点で確認する必要があります。
| 役割 | 確認すべき点 | 具体的なアクション |
|---|---|---|
| security admins | supervised mode、locked enrollment、証明書、tvOS／visionOS制限 | 端末種別ごとのセキュリティ基準を更新する |
| compliance teams | 公式ドキュメントの用語、非対応機能、監査証跡 | 監査資料内の「profile」表記を見直す |
| enterprise IT | 登録ポリシー、トークン、動的グループ、手順書 | 管理画面のスクリーンショットと手順を更新する |
| helpdesk | 利用者問い合わせ、登録失敗時の一次対応 | 「Invalid Profile」や登録失敗時の切り分け手順を用意する |
| endpoint architects | 既存設計との整合性、移行ロードマップ | iOS/iPadOS、tvOS、visionOSを分けて設計する |
特にコンプライアンスチームは、公式ドキュメントの更新を「証跡の更新」として扱うべきです。監査で提示する設計書が古い用語のままだと、実際の管理画面や公式文書との不一致を指摘される可能性があります。
すぐ実施したい確認手順
今回の「PM edits」を受けて、実務では次の順序で確認すると効率的です。
| 手順 | 作業内容 | 完了基準 |
|---|---|---|
| 1 | 影響範囲の棚卸し | Apple ADE関連の手順書、社内Wiki、申請フォームを一覧化する |
| 2 | 用語の更新 | profile表記をpolicy表記へ見直す。ただし属性名は検証後に判断する |
| 3 | 管理画面の確認 | Enrollment policies、Create policy、Assign policyの画面を実環境で確認する |
| 4 | 動的グループ検証 | enrollmentProfileName依存のルールを抽出し、テスト端末で評価する |
| 5 | tvOS／visionOS設計確認 | ユーザーアフィニティなし、コンプライアンスポリシー非対応を設計書に反映する |
| 6 | ACME要件確認 | OSバージョン、証明書利用箇所、既存SCEP構成を棚卸しする |
| 7 | トークン運用確認 | 更新・削除・既定ポリシー・割り当て解除の手順を確認する |
| 8 | 展開前テスト | 1台のテスト端末でADE登録からポリシー適用まで確認する |
この順序なら、単なるドキュメント差分の確認で終わらず、実際の運用リスクまで洗い出せます。
今回の更新を移行準備に活かす
Microsoft Intuneの公式ドキュメント更新「PM edits」で最も重要なのは、Apple ADE運用が「profile」ではなく「policy」を軸に説明される流れが強まっている点です。管理画面、手順書、監査資料、ヘルプデスク対応をこの流れに合わせておくと、今後の変更にも追随しやすくなります。
一方で、動的グループの属性名や既存自動化は、見た目の用語変更だけで置換しないでください。特にenrollmentProfileNameに依存したルールは、現在も他の公式ドキュメントで利用例が残っています。既存環境で動いている設定は、テスト端末と検証グループで確認してから変更するのが安全です。
次に取るべき行動は明確です。まず、Apple ADE関連の社内手順を開き、「profile」「Profiles」「Create profile」「Assign profile」「Default Profile」という表記を洗い出してください。そのうえで、Intune管理センターの現在の画面名、登録ポリシーの割り当て状況、ADEトークン、動的グループ、tvOS／visionOSの制限を確認します。
公式ドキュメント更新は、製品変更そのものではなくても、運用の前提を変えることがあります。今回の「PM edits」は、Microsoft IntuneでAppleデバイスを管理する組織にとって、手順書と実環境のずれを修正し、移行準備を前倒しするよい機会です。
コメント