Apple MDM 移行：IT 管理者向けガイド

運用中のAppleデバイスが数百台、あるいは数千台ある環境でMDMプロバイダーを切り替えることは、ITチームが取り組むプロジェクトの中でも、運用面において最も複雑なもののひとつです。AppleのOS 26に搭載されたネイティブな移行機能により、状況は大きく変わりましたが、スムーズな移行を実現するには、依然として綿密な計画、設定の文書化、そして移行後の確実な検証ワークフローが不可欠です。

本ガイドでは、移行前の資産調査から移行後のコンプライアンス検証に至るまでを網羅し、特に多くのチームが躓きやすいシナリオ、すなわちアプリデータの保持、FileVault回復キーの同期、および新しいOS 26移行パスの対象外となるデバイスの管理に重点を置いています。

Apple OS 26におけるMDM移行の変更点

OS 26以前、管理対象のAppleデバイスをMDMソリューション間で移行するには、ほぼ例外なく、工場出荷時設定へのリセット、再登録、およびすべての管理対象アプリの再インストールが必要でした。500台のMacBookを運用している場合、これはすべてのユーザーに影響を及ぼす、数週間にわたるプロジェクトとなります。

AppleのOS 26では、Apple Business（旧Apple Business Manager/ASM）を通じて管理されるネイティブな移行フローが導入されました。その仕組みは以下の通りです：

1. 管理者が「Apple Business」内で直接、デバイスをあるMDMサーバーから別のMDMサーバーへ再割り当てします。

2. 元のMDMサーバーが、登録済みのデバイスに移行通知をプッシュします。

3. ユーザーには、移行を完了するための設定可能な期限が記載されたプロンプトが表示されます。

4. デバイスは、データを消去することなく、元のMDMから登録解除され、自動的に新しいMDMに登録されます。

ADEに登録されたデバイスを扱い、管理を完全にApple Businessに委ねているAppleデバイス管理チームにとって、これは画期的な機能です。主な制約条件として、元のMDMと移行先のMDMの両方がOS 26移行APIをサポートしている必要があり、デバイスはOS 26以降を実行している必要があります。

OS 26 移行の対象外となるデバイスとシナリオ：

• OS 26より前のiOS/iPadOS/macOSを実行しているデバイス（これらについては、引き続き登録解除と手動での再登録、またはデータ消去が必要です）
• 共有iPadの導入環境
• Apple Business Essentialsに登録されているデバイス
• Apple BusinessまたはApple School Managerに登録されていないデバイス
• 別途の手順に従うユーザー登録済み（BYOD）デバイス

管理対象のデバイス群に OS 26 未満のデバイスが相当な割合で含まれている場合は、並行した移行計画を策定してください。注目される機能に目を奪われず、OS が混在する環境には多様なアプローチが必要であるという現実を見失わないでください。企業所有のハードウェアと並行してBYOD デバイスを管理している場合は、それらのデバイスについては完全に独立した移行計画を立てる必要があります。

移行前の計画：作業に着手する前に記録すべき事項

MDM移行が困難になる最も一般的な原因は、移行そのものではありません。それは、元のMDMが実際に何を行っているかについての文書化が不十分であることです。Apple Businessまたは移行先のMDMで何かを開始する前に、以下の情報をエクスポートして文書化してください：

構成プロファイル

• ソースMDMから、ペイロードの種類、適用範囲、およびデバイス固有の例外を含め、すべての構成プロファイルをエクスポートしてください。
• セキュリティ上重要な設定（FileVault、画面ロック、ファイアウォール、証明書の信頼、コンテンツフィルタリング）を管理するプロファイルには目印を付けてください。
• MDMによって配信されたプロファイルと、手動でインストールされたプロファイルを区別して記録してください。手動でインストールされたプロファイルは自動的に移行されず、ユーザーの操作なしでは再配信できない場合があります。

アプリインベントリおよびVPP／「Apps and Books」の割り当て

• 「Apps and Books」を通じて割り当てられた App Store アプリや、MDM 経由でサイドロードされたカスタムアプリやエンタープライズアプリを含め、管理対象アプリの完全なリストを取得します。
• どのアプリがデバイスに割り当てられ、どのアプリがユーザーに割り当てられているかを記録してください。
• 「Apps and Books」トークンが、元のMDMベンダーにハードコードされているのではなく、Apple Businessアカウントに関連付けられていることを確認してください。移行先のMDMで、トークンを無効化してから再招待する必要があります。

登録および監督状態

各デバイスについて、以下を記録してください：

• 登録タイプ（ADE／ユーザー登録／手動）
• 管理状態
• OSのバージョン
• シリアル番号およびApple Business登録状況

また、この時点で、MDMのデバイス在庫とハードウェア在庫管理記録を照合しておくことも重要です。一方のシステムには表示されるが、もう一方には表示されないデバイスは、移行後ではなく、移行前に解決すべき問題です。

セキュリティベースライン

現在の構成プロファイルを、それらが適用するセキュリティ制御と照合してください。組織が macOS 向けの CIS ベンチマークや NIST SP 800-179 の推奨事項に準拠している場合は、どのプロファイルがどの制御に対応しているかを文書化してください。このマッピングは、移行後に移行先の MDM におけるセキュリティ態勢を検証するために必要となります。

移行日前の移行先MDMの設定

本番環境のデバイスを1台でも移行する前に、移行先のMDMは完全に設定され、テスト済みである必要があります。準備が整っていないMDMへの移行を実行すると、デバイスが登録されているものの管理されていない状態が生じるリスクがあります。

移行先のMDMに必要な設定

Apple Push Notification Service (APNs) 証明書：APNs 証明書はベンダー固有です。 元のMDMのAPNs証明書は移行できません。組織のApple IDを使用してApple Push Certificates Portalから新しい証明書を生成し、それを移行先のMDMにアップロードしてください。証明書は毎年更新する必要があるため、有効期限と使用したApple IDを記録しておいてください。

ADE（Automated Device Enrollment）の統合：Apple Business において、移行対象のデバイスに対して宛先 MDM をサーバーとして割り当てます。これが OS 26 移行フローを設定する手順です。新しい MDM サーバーに割り当てられたデバイスは、ソース MDM が移行を開始すると、移行のプロンプトを受け取ります。

PreStage登録の設定：移行先のMDMで、デバイスが到着する前にPreStage（または同等の登録プロファイル）を設定します。これには以下が含まれます：

• セットアップアシスタントペインの設定
• 初期プロファイルの割り当て
• MDMプロファイルのインストール設定

アプリおよび書籍のトークン：ソース MDM からトークンを失効させ、宛先 MDM に再招待してください。ソース MDM からトークンを失効させると、そのシステムからの新しい VPP アプリの割り当てをプッシュする機能が直ちに無効になるため、このタイミングを移行期間と調整してください。

設定プロファイル：必要なすべての設定プロファイルを、移行先のMDMで再作成してください。単に旧MDMのプロファイル構造を1対1で再現するだけではいけません。この移行を機に、ポリシー構造の合理化を図ってください。従来のMDM環境では、長年にわたり重複したり、矛盾したり、冗長なプロファイルが蓄積されていることがよくあります。 移行は、こうした問題を整理するための自然な契機となります。

移行の実行：OS 26 フローのステップバイステップ

移行先のMDMの設定が完了し、Apple Businessでデバイスが割り当てられたら、以下の手順に従ってください：

1.ソースMDMから移行を開始します。ソースMDMは、登録済みのデバイスに対して移行を通知するMDMコマンドを送信します。具体的な仕組みはベンダーによって異なりますが、結果は同じです。デバイスに通知が表示されます。

2.ユーザーに移行の案内が表示されます。AppleのOS 26移行には、設定可能な登録期限が含まれています。 猶予期間（管理対象の企業用デバイスでは通常24～72時間）を設定でき、その期間が経過するとデバイスは自動的に移行を実行します。プロンプトが表示される前にユーザーに通知してください。説明のないシステムダイアログでデバイス管理の変更を求めると、サポートチケットが発生する原因となります。

3.デバイスが元のMDMから登録解除されます。デバイスは、元のMDMの管理プロファイルおよびそのMDMによって配信されたすべての構成プロファイルを削除します。

4.デバイスが宛先MDMに登録されます。デバイスはAppleのサーバーに接続し、宛先MDM用に割り当てられた登録プロファイルを取得して、登録を完了します。

5.移行先のMDMが構成プロファイルとアプリを配信します。デバイスは割り当てられたプロファイルを受信し、管理対象アプリのインストールを開始します。デバイスは初期化されません。ユーザーデータ、ローカルにインストールされたアプリ、およびMDMから配信された構成とは無関係な設定は保持されます。

アプリの保持に関する注意：「Apps and Books」を通じて割り当てられた管理対象アプリは、宛先MDMがそれらのアプリの管理権限を主張するように設定されている場合、OS 26への移行中に保持されます。宛先MDMがアプリの管理権限を主張しない場合、アプリは管理対象から非管理対象の状態に移行する可能性があり、これにより管理対象アプリのデータや選択的ワイプの動作に影響が生じる可能性があります。 移行前に、移行先のMDMにおけるアプリ管理の主張設定を確認してください。

FileVault およびセキュリティ設定の継続性

FileVault の復元キーは、ソース MDM に保存されます。Mac が宛先 MDM へ移行すると、ソース MDM との管理接続が失われ、そこに保存されていた復元キーは孤立状態になります。

FileVault 復旧キーの継続性を維持するには：

• 移行後、移行先のMDMはFileVault復旧キーのローテーションコマンドを発行する必要があります。これにより新しい復旧キーが生成され、移行先のMDMに預託されます。
• そのローテーションが行われるまでは、ソースMDMに保存されている以前のキーは復旧用に有効ですが、管理対象ではなくなります。
• 移行検証チェックリストでは、FileVaultが有効になっているMacを優先的に確認してください。すべてのデバイスについて、新しい復旧キーが移行先のMDMにエスクローされていることを確認してください。

その他のセキュリティ設定については、移行後に移行先のMDMで以下を確認してください：

• 画面ロックおよびパスワードポリシーの適用
• ファイアウォールの状態
• Intel Mac におけるシステム整合性保護（SIP）の状態
• Gatekeeperの設定
• 証明書信頼プロファイル

組織でコンプライアンスの枠組みを遵守している場合は、今こそ各デバイスに対してコンプライアンスチェックを実行すべき時です。デバイス管理とセキュリティを、別々の業務プロセスではなく統合された分野として捉えることで、移行後の検証をより体系的に行うことができます。

OS 26未満のデバイスに対する移行戦略

OS 26より前のiOS/iPadOSまたはmacOSを実行しているデバイスについては、以下の3つの方法があります。

オプション 1：OS 26 にアップデートしてから移行する。デバイスが OS 26 に対応している場合は、移行を開始する前に、ソース MDM からアップデートを配信します。これは、対象となるハードウェアにとって最も簡単な方法です。

オプション 2：ソース MDM から登録解除し、宛先 MDM に再登録する。ADEに登録されているデバイスの場合、ソースMDMから登録解除を行うと、Apple Businessの割り当てに基づいて、デバイスは宛先MDMに再登録されます。この方法ではデータ消去は必要ありませんが、スキップするように設定していない場合は、ユーザーが「セットアップアシスタント」の手順を完了する必要があります。

オプション 3：工場出荷時設定へのリセットと再登録。「Apple Business」に登録されていないデバイスや、クリアする必要がある複雑なローカル設定が施されているデバイスについては、データ消去と再登録が最もクリーンな選択肢となります。このオプションは、エンドユーザーとの調整が最も多く必要となります。

計画の早い段階で、全端末のOSバージョンの分布状況を記録しておきましょう。Macの30％がmacOS Sequoiaを実行しており、OS 26へのアップグレード対象外である場合、それは別途計画を立てる必要がある重要な運用上の課題となります。

ロールバック計画と緊急時対応手順

多くの移行ガイドでは、このセクションが省略されています。そうしてはいけません。

本番環境への移行を開始する前に、ロールバックの閾値を定義してください。つまり、どの時点で移行を一時停止または元に戻すかを決める必要があります。一般的なトリガーには次のようなものがあります：

• 移行済みデバイスのX％以上が、Y時間以内に構成プロファイルを受信できなかった場合
• 管理対象アプリの損失が定義された閾値を超えた場合
• FileVaultの復元キーの欠落率が設定された割合を超えたという報告
• 移行済みデバイスへのセキュリティツール（EDR、エンドポイント保護）の展開に失敗した場合

OS 26 移行フローにおけるロールバックとは、Apple Business 内でデバイスを元の MDM サーバーに再割り当てし、逆移行をトリガーすることを意味します。これは技術的には可能ですが、元の MDM が引き続き稼働しており、ライセンスが有効である必要があります。 移行の成功を確認し、全デバイス群に対する移行後の検証を完了するまでは、元のMDM契約を解約しないでください。

大規模なデバイス群の場合、段階的な展開が標準的な手法です。重要度の低いチームから10～20台のデバイスをパイロットグループとして移行し、徹底的に検証を行った上で、バッチ単位で順次展開を進めます。各バッチについては、次のバッチを開始する前に検証チェックポイントを設ける必要があります。

移行後の検証とコンプライアンス確認

移行後の検証は、多くのチームが十分なリソースを割いていない領域です。移行先のMDMに登録されているように見えるデバイスでも、必ずしもコンプライアンスを満たしているとは限りません。移行したデバイスについて、以下の各項目を確認してください：

• 構成プロファイルが配信され、適用されているか（デバイスにインストールされているプロファイルを照会）
• 管理対象アプリがインストールされ、管理状態にあること
• FileVaultの復旧キーが移行先のMDMに預託されていること
• セキュリティツール（EDRエージェント、エンドポイント保護）がインストールされ、正常にレポートを送信していること
• デバイスがすべての必須ポリシーに準拠していること
• 証明書プロファイルがインストールされ、有効であること

これを正式な検証チェックリストに組み込み、各移行バッチを完了とマークする前に、そのバッチごとに実行してください。移行先のMDMにコンプライアンスダッシュボードやレポートビューがある場合は、それを利用してください。「登録済み」と表示されているがコンプライアンスを満たしていないデバイスについては、直ちに対応が必要です。

IruによるApple MDM移行へのアプローチ

移行は、多くの場合、チームがMDMベンダーだけでなく、ポリシーアーキテクチャ全体を見直す機会となります。 Iruは「アサインメントマップ（Assignment Maps）」と呼ばれる概念を中核として構築されており、これにより、デバイスやユーザーの属性を構成セットにマッピングする構造化されたポリシー階層を定義できます。レガシーMDMからの移行においては、これが特に有用です。なぜなら、旧システムで長年にわたり蓄積されたものを1対1で再現するのではなく、意図的なポリシー設計を強制するからです。

特にアプリ配信に関しては、Iruの自動アプリ展開機能は、DeviceConfiguredコマンドが完了する前に管理対象アプリを配信するように設定されています。これにより、OS 26への移行フローを経るデバイスは、ユーザーが利用中断として気づく可能性のあるバックグラウンドプロセスとしてではなく、初期登録シーケンスの一環としてアプリを受け取ることができます。

Iruは、ADE統合およびAPNs管理のためにApple Businessに直接接続するため、移行フローがシンプルに保たれます。Apple Business内でデバイスをIru MDMサーバーに割り当て、登録プロファイルと割り当てマップを設定するだけで、Appleの標準フローに従って移行が進められます。

移行後のセキュリティ態勢の検証については、Iruのコンプライアンスライブラリに、macOS向けのCISベンチマークや一般的なNISTコントロールに対応した既成の項目が含まれています。移行後、一からマッピングを構築する必要はなく、全デバイスに対してコンプライアンスレポートを実行することで、是正が必要なデバイスを即座に特定できます。

複雑なレガシープラットフォームから移行するチームにとって、IruのインターフェースはAppleの管理フレームワークの実際の動作に基づいて設計されているため、長年にわたり他のツールの抽象化機能に慣れていた管理者でも、習得にかかる時間を短縮できます。

Apple MDM移行を成功させるために

Apple MDMへの移行は、その性質上、業務に混乱を伴います。この移行を最も有利な形で乗り切るチームは、これを単なるベンダーの切り替えではなく、管理アーキテクチャの意図的な再設計として捉えています。つまり、プロジェクトを完了と宣言する前に、プロファイル構造を合理化し、実際のフレームワークに基づいてセキュリティベースラインを検証し、すべてのデバイスが真にコンプライアンスを満たしていることを確認する必要があるのです。

OS 26のネイティブ移行機能により、対象デバイスに対する工場出荷時設定へのリセットが不要となり、ユーザーにとって最大の混乱要因が解消されます。しかし、移行経路にかかわらず、計画作業、移行前の文書化、および移行後の検証は依然として不可欠です。

Iruへの移行を検討中、あるいは他のApple MDMプロバイダーからの移行を計画している場合は、デモをご依頼ください。「Assignment Maps」とIruのAppleネイティブアーキテクチャが、移行作業とその後の継続的な管理をいかに簡素化できるかをご確認いただけます。