「更新命令は送信済みなのに、macOS 27の端末が上がらない」なら、正式版を待たずに旧MDM更新フローを止め、Apple宣言型更新へ移行してください。まず非重要なリモートMacで、宣言の有効化、対象バージョン、再起動後の状態報告、CI Runnerの再接続まで確認してから本番へ広げます。
この記事は、旧MDMの更新コマンドや更新状態の照会に依存するIT管理者向けです。無人運用のApple silicon Mac、CI Runner、macOS 26とmacOS 27が混在する管理環境を担当する人は、正式版前の移行判定に使ってください。
最終更新:2026年8月9日。macOS 27 Golden Gateはベータ段階です。正式版の日付、最終ビルド番号、正式版の既知障害はAppleから確定発表されるまで判断材料にしないでください。最新のベータ情報はAppleのmacOS Golden Gate 27リリースノートで確認します。
旧MDM更新コマンドを残したままでは、27.0の管理判定が崩れます
典型的な失敗は、管理コンソールでは「命令送信済み」と表示される一方、対象Macが予定日に更新されず、旧OSのままCIジョブを受け続ける状態です。ここで問題なのは、命令がネットワーク上で届いたかではありません。macOS 27.0では、旧来のソフトウェア更新命令、更新可能バージョンの照会、推奨更新の判定、従来型の延期制御を、今後の制御基盤として扱えなくなります。
Appleは、ソフトウェア更新の宣言型管理を標準方式として位置付け、旧MDM方式を非推奨化し、将来のリリースで削除する方針を説明しています。WWDCのデバイス管理更新でも、旧方式は継続動作する場合があるものの、移行対象であることが示されています。したがって、27.0の正式版後に初めて直すのでは遅すぎます。
盤点する対象は、単なるアップデート設定だけではありません。
ScheduleOSUpdateなどの旧更新命令を発行する処理AvailableOSUpdatesやOSUpdateStatusに依存する照会処理- 構成プロファイルの延期設定だけで公開時期を制御する処理
- 管理コンソールで「命令済み」を成功扱いにする判定
- 再起動後の再登録、リモート接続、CI Agent復旧を確認しない運用
Apple宣言型ソフトウェア更新 macOS 27への移行は、命令の置換ではなく状態管理で考えます
宣言型管理では、サーバーが毎回「今すぐ実行」と命令するのではなく、端末に望ましいOS状態を宣言します。端末はその宣言を評価し、適用状況を状態報告として返します。Appleのソフトウェア更新宣言ガイドでは、更新の状態としてwaiting、downloading、prepared、installing、failedなどが定義されています。
| 旧運用で確認していたもの | 移行後に確認するもの | 合格条件 |
|---|---|---|
| 旧MDM更新コマンドの受付 | ソフトウェア更新の強制インストール宣言 | 宣言が端末で有効になっている |
| 利用可能な更新一覧 | Apple Software Lookup Serviceの公開情報 | 対象モデルに目標バージョンが適用可能 |
| 命令の完了レスポンス | 宣言型ステータス報告 | ダウンロードからインストールまで追跡できる |
| 延期プロファイル | 自動更新、提供延期、強制期限の分離 | 期限到来時の動作を再現できる |
| OSバージョンの再照会 | OSバージョン、ビルド番号、宣言状態 | 再起動後も管理情報が更新される |
利用可能なバージョンの判定には、管理サーバー独自の一覧を残さず、Apple Software Lookup Serviceの仕様を参照してください。目標OSだけでなく、対象ビルドを固定する場合はTargetOSVersionとTargetBuildVersionの扱いを分けます。
macOS 27の延期は、旧MDM設定から3種類の運用へ分解します
「macOS 27でもMDMの延期が使えるか」という問いには、旧方式をそのまま継続するのではなく、宣言型設定へ置き換える、が回答です。宣言型のSoftwareUpdateSettingsでは、公開後の提供を遅らせる設定と、特定時刻までに強制する設定を別々に設計します。
Appleの資料では、更新の提供延期は1日から90日まで設定できます。ただし、延期は対象バージョンに依存するセキュリティ改善の提供にも影響するため、長期間の一律延期は避けるべきです。延期と強制更新の公式説明を基準に、社内の保守期間と照合してください。
| 運用方針 | 設定の考え方 | 適するノード | 避けるべき判定 |
|---|---|---|---|
| 継続して暫定保留 | 提供延期を設定し、強制期限をまだ置かない | 重要な本番Runner、互換性未確認の開発機 | 「宣言がある」だけで安全と判断 |
| 利用者による導入 | 更新を提供し、強制インストールは後段にする | 開発用Mac、検証用Runner | 利用者の導入完了を本番合格と扱う |
| 期限で強制導入 | 対象OS・ビルドとインストール時刻を指定 | 退避済みの無人ノード | 再起動後の接続確認なしで放量 |
複数の宣言が同時に存在する場合、同じキーのマージ規則と、異なる目標バージョンの処理順を確認します。Appleの仕様では、複数の強制更新設定がある場合、早い目標日時の設定が先に処理され、更新後に残りの設定が再評価されます。古い延期設定を削除せずに残すと、管理画面の想定と端末の実際の適用順がずれるため、移行時に旧プロファイルの有効範囲も確認してください。
注意:延期設定を削除しただけでは、既存の宣言、保留中の強制期限、端末側の準備済み更新が消えたとは限りません。移行後は宣言の有効状態と端末のステータス報告を別々に記録します。
macOS 26とmacOS 27の混在環境は、同じ更新処理で押し切らないでください
混在期間は、OSバージョンだけでなく、宣言型管理の対応状態でグループを分けます。macOS 27対象グループには新しい宣言を適用し、macOS 26の残存グループには既存フローを維持しながら、移行準備の状態を別管理します。
第一段階:対象判定を固定する
シリアル番号、モデル識別子、OSバージョン、ビルド番号、監督状態を管理台帳に持たせます。Apple Software Lookup Serviceで対象モデルに目標リリースが提示されているか確認し、バージョンだけで対象を決めないでください。
第二段階:宣言の作用範囲を試す
macOS 27の非重要ノードだけに、対象OSと必要なら対象ビルドを指定します。宣言が有効化され、preparedからinstallingへ進み、再起動後に新しいOS情報と宣言状態が返ることを確認します。
第三段階:退出条件を決める
双轨管理を終える条件は、27.0ノードが宣言型更新の検証を完了し、macOS 26ノードにも「アップグレードする」「退役する」「当面旧方式で隔離する」のいずれかが決まっていることです。macOS 26を曖昧な例外として永久に残すと、旧MDM更新コマンドの廃止時に対象漏れが発生します。
無人Apple silicon Macは、強制更新前に認証経路を確認します
無人更新で最初に見るべきは、目標ビルドではなく認証条件です。監督状態、登録方式、Bootstrap Tokenの保管、ボリューム所有者の条件がそろっていない端末は、宣言が正しくても無人で更新できない場合があります。
Appleの資料では、Apple silicon Macの強制ソフトウェア更新を無人で承認するためにBootstrap Tokenを利用できます。MDMプロファイルのServerCapabilitiesにcom.apple.mdm.bootstraptokenを追加し、端末がトークンを作成してMDMへ保管する流れです。Bootstrap Tokenと強制更新の公式手順を確認してください。
確認順は次のとおりです。
- 端末が監督対象で、登録状態が有効か確認します。
SecurityInfoCommandでBootstrap Tokenが必要な端末か判定します。- トークンが管理サーバーへ保管済みか確認します。
- 目標OSと目標ビルドが端末モデルに適用可能か照会します。
- 強制インストール時刻を設定し、
waiting、downloading、prepared、installingの変化を記録します。 - 再起動後に遠隔接続が戻るか確認します。
- CI Agentが再登録し、ジョブを1件受けて完了するまで本番放量を止めます。
認証、再起動、復帰のどれかが未確認の端末は、強制更新グループへ入れません。人工対応へ切り替えるか、平行ノードにジョブを退避させます。
CI Runnerは、OSバージョンではなく再接客までを合格条件にします
CI環境では、システム情報が27.0になっただけでは成功ではありません。ジョブ排空、更新、遠隔接続、Agent起動、認証情報の復旧、ジョブ受け入れまでが一つの変更単位です。
宣言型管理は、従来のMDM命令やプロファイルと共存できます。宣言型管理の段階導入に関するAppleの説明でも、既存フローを一度に全交換せず、段階的に有効化できる設計が示されています。
試升から放量までは、次の出口で判定します。
- 継続して分割更新:状態報告、再接続、CIジョブ、予備ノードのすべてが確認済み。
- 一時停止:更新自体は成功したが、Agentの再登録やビルドツールの復旧が未確認。
- 平行Macノードを起動:本番ノードを止められず、再起動後の復旧時間を読めない。
- 旧方式を例外運用:macOS 26の対象だけに限定し、期限と退役計画を台帳化。
旧MDM更新コマンドを残したままmacOS 27へ移る方式は、管理画面の成功表示と端末の実状態が分離しやすく、無人ノードでは復旧作業そのものが停止要因になります。自前の既存環境だけで安全な試升枠を確保できない場合は、短期の検証用Macを別に用意し、管理コンソールの運用はMacHTMLの管理コンソール案内で確認してください。
特に、重要Runnerを止められない、再起動後の担当者対応が難しい、macOS 26と27の台数が多い、という条件が2つ以上あるなら、現在の構成を一括更新するより平行Macを用意する方が安全です。物理機を長期固定する必要がなく、移行期間だけ検証環境や代替Runnerが必要なら、MacHTMLの利用案内を見ながら、ノード数と保守窓口を先に決めてください。既存環境が長期の常時負荷、専用周辺機器、社内ネットワークへの物理接続を必要とする場合は、レンタルだけで置き換えず、自社保有機との役割分担を残す判断が適切です。
関連記事: macOS 27へのアップグレード前に確認したい新機能と対応機種 macOS 27移行時のアプリ互換性テストと回帰確認のチェックリスト CI/CD Runnerの復旧確認に役立つMac mini M4の性能検証
宣言型アップデートの検証環境をMacHTMLで整えませんか
MacHTMLなら、管理方式の移行前に更新ポリシーを実機に近いMac環境で検証できます。 遠隔操作に対応したMacを必要な期間だけ利用でき、無人更新や再起動後の状態確認にも活用できます。 異なる環境の混在管理やCI実行環境の復旧確認など、運用チームの検証用途に柔軟に対応できます。 用途や利用期間に合わせた料金プランから、アップデート運用を支えるMac環境をお選びいただけます。