リモート Mac

Apple宣言型更新 macOS 27 Golden Gate

MacHTML Lab2026.08.09 約7分
Apple宣言型更新 macOS 27 Golden Gate

「更新命令は送信済みなのに、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などの旧更新命令を発行する処理
  • AvailableOSUpdatesOSUpdateStatusに依存する照会処理
  • 構成プロファイルの延期設定だけで公開時期を制御する処理
  • 管理コンソールで「命令済み」を成功扱いにする判定
  • 再起動後の再登録、リモート接続、CI Agent復旧を確認しない運用

Apple宣言型ソフトウェア更新 macOS 27への移行は、命令の置換ではなく状態管理で考えます

宣言型管理では、サーバーが毎回「今すぐ実行」と命令するのではなく、端末に望ましいOS状態を宣言します。端末はその宣言を評価し、適用状況を状態報告として返します。Appleのソフトウェア更新宣言ガイドでは、更新の状態としてwaitingdownloadingpreparedinstallingfailedなどが定義されています。

旧運用で確認していたもの 移行後に確認するもの 合格条件
旧MDM更新コマンドの受付 ソフトウェア更新の強制インストール宣言 宣言が端末で有効になっている
利用可能な更新一覧 Apple Software Lookup Serviceの公開情報 対象モデルに目標バージョンが適用可能
命令の完了レスポンス 宣言型ステータス報告 ダウンロードからインストールまで追跡できる
延期プロファイル 自動更新、提供延期、強制期限の分離 期限到来時の動作を再現できる
OSバージョンの再照会 OSバージョン、ビルド番号、宣言状態 再起動後も管理情報が更新される

利用可能なバージョンの判定には、管理サーバー独自の一覧を残さず、Apple Software Lookup Serviceの仕様を参照してください。目標OSだけでなく、対象ビルドを固定する場合はTargetOSVersionTargetBuildVersionの扱いを分けます。

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プロファイルのServerCapabilitiescom.apple.mdm.bootstraptokenを追加し、端末がトークンを作成してMDMへ保管する流れです。Bootstrap Tokenと強制更新の公式手順を確認してください。

確認順は次のとおりです。

  1. 端末が監督対象で、登録状態が有効か確認します。
  2. SecurityInfoCommandでBootstrap Tokenが必要な端末か判定します。
  3. トークンが管理サーバーへ保管済みか確認します。
  4. 目標OSと目標ビルドが端末モデルに適用可能か照会します。
  5. 強制インストール時刻を設定し、waitingdownloadingpreparedinstallingの変化を記録します。
  6. 再起動後に遠隔接続が戻るか確認します。
  7. 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環境をお選びいただけます。

クラウド Mac mini をレンタル
Apple Silicon クラウド Mac