はじめに
「アップデートの延期設定、いつも通り効くはず」——そう思い込んだまま秋を迎えると、痛い目を見るかもしれません。
前回の記事では、iOS/Android混在環境で段階的にアップデートを配信する運用の組み方を紹介しました。
[ iOS 27・Android 17混在環境、秋のOS一斉アップデートに備えるMDM運用チェックリスト]
あの記事を書いたあとにAppleが公式に案内した内容を確認したところ、もう一段深刻な変化があることが分かりました。iOS 27をはじめとするOS 27世代では、これまでMDMが使ってきた「レガシー方式」のソフトウェアアップデート管理そのものが機能しなくなります。延期コマンドも、強制インストールコマンドも、対象OSでは動かなくなる。今回はこの変化と、実務でどう備えるかを整理します。
OS 27で何が終わるのか
Appleは開発者向けガイド「WWDC26 device management updates」の中で、OS 27世代（iOS 27・iPadOS 27・macOS 27・tvOS 27・visionOS 27・watchOS 27）からレガシーMDMによるソフトウェアアップデート管理を廃止すると案内しています。対象になるのは、これまでMDMコンソールから送っていた更新のインストールコマンド、更新状況の問い合わせ、そして本連載でも取り上げた「延期（Deferral）」設定です。
重要なのは、これが段階的な移行期間を伴わないという点です。端末がOS 27にアップグレードした瞬間から、旧方式のコマンドは一切機能しなくなります。「そのうち対応すればいい」ではなく、「アップグレードされた瞬間に手遅れになる」性質の変化だということを、まず押さえておく必要があります。
レガシーMDMからDDM（宣言型管理）へ
この変化の背景にあるのが、宣言型デバイス管理（DDM：Declarative Device Management）への全面移行です。
レガシー方式では、MDMサーバーが端末1台ずつに「このバージョンにアップデートしろ」「今回は延期しろ」というコマンドを逐一送信していました。端末がオフラインだとコマンドは届かず、オンラインに戻ったタイミングで改めて送り直す必要がある、という構造です。
DDMはこの発想を根本から変えます。サーバーは「この端末はこういう状態であるべきだ」という宣言（Declaration）を1回渡すだけです。あとは端末側がその宣言を自律的に解釈し、必要な処理を自分のタイミングで実行し続けます。オフラインから復帰したときも、サーバー側から改めて命令を送り直す必要がありません。管理の主体が「サーバーが逐一指示する」から「端末が自分で状態を維持する」へと移る、という点が最大の違いです。
MDMツールごとの対応状況
自組織が使っているMDMツールがDDM対応を終えているかどうかで、今すぐ動くべきか、少し様子を見られるかが変わります。
Jamf Proは、オンプレミス版のバージョン11.29.0以降でDDM経由のソフトウェアアップデート機能に対応済みです。ただし設定はこれまでの「ポリシー」単位ではなく、DDM前提の「Blueprint」という単位に作り直す必要があります。過去に組んだポリシーがそのまま移行されるわけではない点は、事前に把握しておいたほうがいいでしょう。
Microsoft Intuneも、DDMベースのApple向けソフトウェアアップデート管理への移行手順を公式に案内しています。Intuneを使っている組織は、この移行ガイドに沿って構成プロファイルの作り直しを進めるのが現実的な対応です。
一方でLANSCOPEについては、本稿を執筆している時点でDDM対応に関する公式なアナウンスを確認できませんでした。導入している組織は、ベンダーのサポート窓口や公式ロードマップで対応予定を個別に確認することをおすすめします。噂や推測で「対応済みのはず」と決めつけず、一次情報を取りに行く姿勢が、この移行では特に大事になります。
今すぐ着手すべき3つの勘どころ
1つ目は、自組織が使っているMDMのDDM対応状況を確認することです。ベンダーの公式リリースノートやサポート窓口に問い合わせ、いつからどの機能がDDM前提に切り替わるのかを把握しましょう。
2つ目は、既存の延期・強制設定を棚卸しすることです。現在レガシー方式で組んでいるアップデート関連のプロファイルやポリシーを洗い出し、DDM対応版に作り直す計画を立てます。特に、繁忙期の直前にOS 27へ意図せずアップグレードされてしまうと、延期のコントロールが効かなくなる恐れがあるため、優先度を上げて確認すべきです。
3つ目は、検証端末でDDMベースの設定を先に試すことです。前回の記事で触れた「フェーズ①：検証端末グループでテスト」の段階に、今回のDDM移行確認も組み込んでおくと、本番展開時の手戻りを防げます。
落とし穴：レガシー設定のまま放置するとどうなるか
一番の落とし穴は、「まだOS 27にはアップグレードしていないから大丈夫」という油断です。従業員の端末は、必ずしも情シスの想定したタイミングでアップグレードされるとは限りません。自動更新設定が有効なままの端末が、気づかないうちにOS 27へ移行し、その瞬間からレガシー方式の延期コマンドが効かなくなっていた——という事態は十分に起こり得ます。
また、DDM対応済みのMDMツールを使っていても、設定を作り直さない限り自動的にDDM方式へ切り替わるわけではありません。「ツールが対応した」と「自組織の設定がDDM化された」は別の話だという点を、混同しないよう注意してください。
移行スケジュールの目安
具体的にいつまでに何をすべきか、目安を立てておくと動きやすくなります。まず、今月中に自組織のMDMベンダーへ問い合わせ、DDM対応状況とロードマップを確認してください。回答が曖昧な場合は、公式のリリースノートやサポートページを自分でも確認しておくと安心です。
次に、確認が取れ次第、検証端末でDDMベースの設定を組んでみる期間を1〜2週間ほど確保します。前回の記事で紹介した「フェーズ①：検証端末グループでテスト」の枠組みと合わせて進めれば、二度手間になりません。
そして、OS 27の正式リリース（複数のメディアで9月半ば頃と予想されていますが、本稿執筆時点でApple公式の確定発表ではありません）までに、少なくとも主要な業務端末群についてはDDMベースの設定へ切り替えを終えておくことを目標にするのが現実的です。自動更新設定が有効な端末が意図せずOS 27へ移行してしまう前に、手を打っておきたいところです。
まとめ
OS 27世代への移行は、単なるOSアップデートではなく、モバイルデバイス管理の土台そのものが変わる出来事です。レガシー方式のコマンドが効かなくなるタイミングに備え、まずは自組織のMDMツールの対応状況を確認し、既存設定の棚卸しから着手することをおすすめします。
Mobitech Solutionへのご相談
DDMへの移行計画の立て方や、既存のアップデート関連プロファイルの棚卸しについて、Mobitech Solutionでは実務目線でのご相談を承っています。「自社のMDM、DDM対応はどこまで進めればいいのか分からない」という方は、ぜひ現状の設定を一緒に確認させてください。
