2026年9月14日、Appleは「エンタープライズ向けiOSの新機能」ページ(What’s new for enterprise in iOS)を更新し、こう明記しました。「レガシーなソフトウェアアップデート管理は、27.0のすべてのOSで機能しなくなる」。アップデートコマンドやクエリ、推奨サイクルの設定、延期や段階的ロールアウトといった制限機能まで、まとめて使えなくなるという話です。どこかのMDMベンダーの不具合ではなく、Apple公式のアナウンスです。

一人情シスとして複数のMDM製品を見てきた身としては、この一文を読んで背筋が伸びました。今回は、iOS 27でエンタープライズ向けに追加・強化された管理項目を、キッティングと日々の運用に関わる部分を中心に整理します。

iOS 27.0系のすべてのOS(iOS/iPadOS/macOS/tvOSを含む)で、レガシーなソフトウェアアップデート管理コマンドが機能しなくなりました。対象になるのは、アップデートの実行命令やステータス確認クエリだけではありません。推奨アップデートサイクルの設定、延期(デファー)設定、Background Security Improvementsのような更新制限まで、一括で対象になっています。

これまでMDM側の「ソフトウェアアップデートポリシー」画面から延期日数を指定していた運用をしている会社は少なくないはずです。その設定自体が、iOS 27環境では意味を持たなくなります。Appleが案内しているのは、宣言型のソフトウェアアップデート管理への切り替えです。つまり「対応をやめる」のではなく「仕組みそのものが置き換わった」と捉えたほうが正確です。

宣言型デバイス管理(Declarative Device Management、以下DDM)は、MDMサーバーが都度コマンドを送るのではなく、デバイス自身が「あるべき状態」の宣言を受け取って、自律的に設定を維持し続ける仕組みです。iOS 27では、このDDMが扱える範囲が明確に広がりました。

まず、VPN・DNS・リレーの設定がDDMの対象に加わりました。これまでネットワーク関連の設定は従来型のMDM構成プロファイルに依存する部分が残っていましたが、今後はDDMの宣言としても配信できるようになります。もう一つ地味に大きいのが「レガシープロファイルを、宣言型アセットとして配信できる」ようになった点です。これまで作り込んできた構成プロファイルを丸ごと捨てる必要はなく、DDMの仕組みに乗せ替えて運用を続けられるという意味だと理解しています。

加えて、プライバシー許可をまとめて一度の同意プロンプトでユーザーに提示できる機能や、Siri AI・Visual Intelligence・自然言語でのカレンダー編集といったAI系機能を管理側で制限できる項目も追加されています。社用端末でどこまでAI機能を使わせるかという論点は、経営層を交えて判断すべきテーマになってきました。

地味ですが現場への影響が大きいのは、新しいLiquid Glassセットアップ画面を、デバイス管理側のスキップ対象にできるようになった点です。キッティング時に毎回同じ案内画面を手で飛ばしていた作業が、設定ひとつで省略できるようになるなら、1台あたり数十秒の差でも、台数が多い現場ではまとまった時間になります。

Return to Serviceは、紛失・盗難時のロック(ロストモード)とは別に、端末を初期化しつつ既存のMDM登録情報は保持したまま、すぐに再利用可能な状態へ戻すための消去コマンドです。回収した端末を次の担当者へ渡す前の再キッティングなどで使われてきました。

iOS 27では、このReturn to Service(erase)コマンドに「ソフトウェアアップデートの強制」が組み合わせられるようになりました。監督対象(supervised)端末であれば、消去コマンドを送るだけで、端末が最新OSへの更新まで同時に実行してくれます。これまでは「初期化→起動→手動または別コマンドでOS更新を待つ」という2段階の作業だったものが、1回の操作で完結するようになったということです。

回収した端末の再配布や、季節性のある人員増減(アルバイト・派遣スタッフの入れ替わりなど)が多い現場では、再キッティングの手間が地味に積み上がります。退職者から戻ってきた端末を、次の入社者に渡す前に「初期化して、OSも最新化して、プロファイルを再適用する」という一連の作業を、できるだけ少ない操作回数で終わらせたい場面は多いはずです。この強化は、まさにその積み上がりを減らす方向に働くはずです。

ここまで読んで「良いことばかりだ」と思うのは、まだ早いと感じています。現場で確認しておきたい点を3つ挙げます。

一つ目は、使っているMDM製品がDDMの新しい項目にどこまで対応しているかです。VPN/DNSの宣言型配信やレガシープロファイルの宣言化は、Appleが「扱えるようにした」だけで、各MDMベンダーのコンソール側の実装が追いついていないケースがあります。契約しているベンダーのリリースノートを確認してから、既存プロファイルの移行計画を立てるのが安全です。

二つ目は、レガシーコマンドに依存した自動化スクリプトや運用手順書です。社内Wikiや手順書に「ソフトウェアアップデートポリシーで延期日数を◯日に設定する」と書かれたままの箇所があれば、iOS 27環境では実質的に無意味な記述になります。棚上げせず、一度洗い出しておく価値があります。

三つ目は、Return to Serviceの強制更新を検証環境で試してからにする、ということです。消去と同時にOS更新まで走るということは、想定より通信量や所要時間がかかる可能性があります。本番の一斉再キッティングで初めて試すのではなく、まずは数台で挙動を確認してから運用に組み込むことをおすすめします。

もう一つ付け加えるなら、iOS 27ではリモートでのAppleCareログ収集が、supervised状態のiOS/iPadOS/macOS/tvOS端末でまとめて行えるようになっています。障害調査のたびに端末を手元に集める必要が減るのは、拠点が分散している会社ほどありがたい変更です。

端末管理の仕組みは、毎年のOSアップデートのたびに少しずつ姿を変えています。今回のiOS 27の変更も、「知らずに運用を続けていた」状態がいちばんリスクになるタイプの変更です。

iOS 27への対応方針の整理や、お使いのMDM製品でのDDM移行状況の確認、キッティング手順書の見直しなど、一人情シスだけで抱え込まずに相談したいことがあれば、Mobitech Solutionまでお気軽にお問い合わせください。

関連記事:[OSのメジャーアップデートのたびに情シスが消耗する理由(noteコラム)]

🛡️

この記事を読んだあなたにおすすめの「情シスの武器」

VPN / セキュリティ

NordVPN
プライバシー保護 + 海外接続

詳細を見る →
セキュリティソフト
🔒

ノートン 360
業界No.1セキュリティ

詳細を見る →
レンタルサーバー

ConoHa WING
WordPress最速サーバー

詳細を見る →