Mac管理者向けmacOS 27ガイド：MDMアップデートコマンドの廃止とTLS要件の厳格化

Macを管理している方にとって、macOS 27 Golden Gateはユーザーの画面には表示されないものの、パッチ適用プロセスやエンロールメントフローを一日で止めてしまいかねない2つの変更をもたらします。第一に、ほとんどのフリートが10年近く使ってきたMDMソフトウェアアップデートのコマンド、クエリ、制限が、27.0を実行するデバイスでは動作しなくなります。第二に、管理パス上のすべての接続——MDM、Declarative Device Management、Automated Device Enrollment、プロファイルのインストール、アプリのインストール、ソフトウェアアップデート——について、これまでは警告をログに記録するだけだったものが、App Transport Securityのルールを満たさないサーバーを拒否するようになります。

どちらの変更も目新しい情報ではありません。Appleは両方ともWWDC 2026以前とその場で発表済みです。しかし27.0が実際にリリースされた（9月14日、ビルド26A428）今、アップグレードするすべてのMacでこれらが有効になります。本ガイドでは、Apple自身のスキーマとサポート文書を基に、何が動作しなくなるのか、最初のMacが問題に直面する前にサーバーをどう監査するか、そして各レガシー機構の代替が何かを順に説明します。

重要なポイント

• 従来のソフトウェアアップデート管理は27.0で機能しなくなります。 Appleは次のように述べています。「従来のソフトウェアアップデート管理は、27.0系のすべてのオペレーティングシステムで機能しなくなります」。これにはScheduleOSUpdate、ScheduleOSUpdateScan、AvailableOSUpdates、OSUpdateStatusの各コマンド、com.apple.SoftwareUpdateペイロード、および延期制限が含まれます。
• 代替となるのは宣言型の仕組みです。 softwareupdate.enforcement.specificは期限までに特定のバージョンを強制します。softwareupdate.settingsは延期、自動アクション、Background Security Improvements、ベータ登録をカバーします。クエリの代わりにステータス項目が使われます。
• 推奨ケイデンスに相当するmacOS向けの機能はありません。 Appleのスキーマでは、宣言型のRecommendedCadenceキーはmacOSでは利用不可とされています。
• 管理パスに対してTLSルールが強制されるようになりました。 具体的には、TLS 1.2以降、Forward Secrecyを備えた暗号スイート、SHA-2で署名されたRSA 2048ビット以上またはECDSA 256ビット以上の証明書、そしてExtended Master Secret拡張が必要です。例外となるのはSCEPサーバーとコンテンツキャッシュサーバーのみです。
• デバイスがアップグレードする前に監査できます。 以前のリリースでも同じチェックが行われており、警告としてログに記録されます。Appleはそれらを見つけるためのログプレディケートを公開しています。

変更点1：従来のソフトウェアアップデート管理が機能しなくなる

AppleのWWDC 2026デバイス管理アップデートは、これを一文でこうまとめています。「従来のソフトウェアアップデート管理は、27.0系のすべてのオペレーティングシステムで機能しなくなります」。続けて、その対象としてソフトウェアアップデートコマンド、ソフトウェアアップデートクエリ、推奨ケイデンス設定、延期やBackground Security Improvementsを含むソフトウェアアップデート制限を挙げています。

Appleが公開しているデバイス管理スキーマ——MDMベンダーが実装のベースにするapple/device-managementリポジトリのYAMLファイル——には、各項目の正確なステータスが記載されています。macOSの場合は次のとおりです。

従来の仕組み	スキーマ上のステータス（macOS）	宣言型の代替
ScheduleOSUpdateコマンド	26.0で非推奨、27.0で削除	com.apple.configuration.softwareupdate.enforcement.specific
ScheduleOSUpdateScanコマンド	26.0で非推奨、27.0で削除	不要——デバイスが自動的にスキャンし、ステータスを報告する
AvailableOSUpdatesクエリ	26.0で非推奨、27.0で削除	ステータス項目softwareupdate.pending-version
OSUpdateStatusクエリ	26.0で非推奨、27.0で削除	ステータス項目softwareupdate.install-state、softwareupdate.failure-reason、softwareupdate.install-reason
com.apple.SoftwareUpdateプロファイルペイロード	26.0で非推奨、27.0で削除	com.apple.configuration.softwareupdate.settings
制限forceDelayedSoftwareUpdates、forceDelayedMajorSoftwareUpdates、forceDelayedAppSoftwareUpdates、enforcedSoftwareUpdateDelay	26.0で非推奨、27.0で削除	softwareupdate.settings → Deferrals

今回参照したスキーマのスナップショットは、2026年9月18日時点のリポジトリのreleaseブランチです。MDMベンダーのコンソールに従来のオプションがまだ表示されている場合、それらは26.x以前のデバイス向けです。27.0を実行しているMacでは何も効果がありません。

宣言型設定がカバーする範囲

softwareupdate.settings構成は、従来の制限の大部分が移行した先です。Appleのスキーマによるトップレベルのキーは次のとおりです。

キー	制御する内容
Notifications	ユーザーにアップデート通知を表示するかどうか
Deferrals	CombinedPeriodInDays、MajorPeriodInDays、MinorPeriodInDays、SystemPeriodInDays
AutomaticActions	Download、InstallOSUpdates、InstallSecurityUpdate
RapidSecurityResponse	Enable、EnableRollback——スキーマ上は「Background Security Improvements settings」（Background Security Improvements設定）と表記
AllowStandardUserOSUpdates	管理者権限を持たないユーザーがOSアップデートをインストールできるかどうか
Beta	AppleSeedおよびデベロッパーベータ向けのProgramEnrollment、OfferPrograms、RequireProgram
RecommendedCadence	スキーマ上macOSでは「n/a」と表記

スキーマにはさらに、Background Security Improvementsは「Major、Minor、Systemいずれの延期機構でも考慮されない」と記載されています。メジャーアップデートの延期は、バックグラウンドのセキュリティ修正を止めることはありません。これらを制御したい場合はRapidSecurityResponseキーを使用してください。これらのアップデートの詳細については、Background Security Improvementsガイドで解説しています。

推奨ケイデンスの空白

従来のMDMでは「推奨ケイデンス」を設定でき、マイナーアップデートと新しいメジャーバージョンの両方が利用可能な場合に、ユーザーにどちらを提示するかを決めることができました。Appleは推奨ケイデンスを、機能しなくなる従来の設定の一つとして挙げており、現在のスキーマの宣言型RecommendedCadenceキーはmacOSに対してintroduced: n/aとなっています。つまり、現時点のMacには同等の代替機能が存在しないということです。

実務上は、指定した日数だけリリースを非表示にする**延期（deferrals）と、期限までに希望するバージョンを固定する強制（enforcement）**を組み合わせて、ユーザーに何を見せるかを形作ることになります。単一のケイデンス切り替えよりも手間はかかるため、メジャーアップグレードが突然表示されるようになった理由をユーザーから問い合わせられる前に、サービスデスクにこの変更を伝えておく価値があります。

27.0でバージョンを強制する

最も頻繁に使うことになるのが、この強制（enforcement）宣言です。対象バージョンと期限を指定します。

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.su.macos-27-0-1",
  "Payload": {
    "TargetOSVersion": "27.0.1",
    "TargetLocalDateTime": "2026-10-15T18:00:00",
    "DetailsURL": "https://intranet.example.com/updates"
  }
}

TargetOSVersionとTargetLocalDateTimeが中心となるキーです。正確なビルドを指定するためのTargetBuildVersionもあり、両方が設定されている場合はこちらが優先されます。例に挙げたバージョンはあくまで説明のためのものです——本稿執筆時点で27.0.1はまだリリースされていません。MDMベンダーは通常、生のJSONではなくフォームを提供しますが、キーを知っておくことで、インストールされなかった理由を調べる際にデバイスのステータス上の宣言を読み解きやすくなります。

同じポリシーを両方の書き方で

具体例を見ると、移行のイメージがつかみやすくなります。よくあるポリシーを例にとります。メジャーアップグレードを30日間保留し、自動ダウンロードとセキュリティアップデートは有効のままにする、というものです。

従来のバージョンでは、com.apple.applicationaccessペイロード内の一連の制限キーとして表現します。

<key>forceDelayedMajorSoftwareUpdates</key>
<true/>
<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>30</integer>

Tahoe搭載のMacはこれに従いますが、Golden Gate搭載のMacは無視します。

宣言型のバージョンでは、同じ意図を1つの構成にまとめます。

{
  "Type": "com.apple.configuration.softwareupdate.settings",
  "Identifier": "com.example.su.settings",
  "Payload": {
    "Deferrals": { "MajorPeriodInDays": 30 },
    "AutomaticActions": {
      "Download": "AlwaysOn",
      "InstallSecurityUpdate": "AlwaysOn"
    }
  }
}

自分で構成を書く前に知っておく価値がある、Appleのスキーマ上の3つの詳細があります。

• 延期の値は1日から90日までの範囲で、従来の遅延キーと同じ範囲です。
• 複数の宣言が同じキーを設定している場合、デバイスは規則に従ってそれらを結合します。 Deferralsはnumber-max（最も長い延期が勝つ）、自動アクションはenum-last、Notificationsはboolean-andを使用します——いずれかの宣言で通知がオフになっていれば、通知はオフになります。90日の延期を持つテスト用の宣言が消し忘れられていると、静かに30日のポリシーを上書きしてしまうため、ほかのデバッグをする前にまず何が割り当てられているかを確認してください。
• 自動アクションはAllowed、AlwaysOn、AlwaysOffのいずれかの値を取り、デフォルトはAllowedです。AppleのスキーマではAlwaysOnを「常に有効」、AlwaysOffを「常に無効」と説明しています。ユーザーに選択を委ねたい場合はAllowedを選んでください。

結果を読み取る

宣言型管理では、クエリではなくステータス項目を通じて状態が報告されます。softwareupdate.install-state項目は、none、downloading、prepared、installing、failedの5つの値のいずれかを取ります。これに、デバイスが何をインストールしようとしているかを示すsoftwareupdate.pending-version、何か問題が起きたときのsoftwareupdate.failure-reasonを組み合わせれば、かつてのOSUpdateStatusクエリが教えてくれていたことはすべて揃います。しかも、こちらから尋ねることを思い出したときではなく、状態が変化したタイミングでデバイスから送られてきます。

混在フリートの落とし穴

今後1年間、フリートには従来の非推奨機構にまだ従うTahoe 26.x搭載のMacと、それらを無視するGolden Gate 27.0搭載のMacが混在することになります。これにより3つのリスクが生じます。

1. 半分しか効かない延期。 従来のforceDelayedMajorSoftwareUpdates制限は、Tahoe搭載のMacに対しては今も効果があります。しかしMacが27になると、宣言型のDeferrals設定だけが影響します。両方に同じポリシーを適用したい場合は、両方の場所で定義する必要があります。
2. 空白になるレポート。 OSUpdateStatusやAvailableOSUpdatesの応答をもとに構築されたダッシュボードは、27.0デバイスについては何も表示しません。それらのデバイスが「unknown」と表示されるようになる前に、レポートを宣言型のステータス項目に切り替えてください。
3. コマンドが届いたことを前提にしたスクリプト。 ScheduleOSUpdateを送信して結果を待つ自動化は、27.0搭載のMacに対しては永遠に待ち続けることになります。ランブックやMDMに対するAPIスクリプトに、従来のコマンド呼び出しが残っていないか確認してください。

最もシンプルなアプローチは、DDMのソフトウェアアップデート宣言がすでに機能するTahoe搭載のMacも含め、すべてのMacを今のうちに宣言型のソフトウェアアップデート管理に移行することです。従来の設定は、まだ移行できていないデバイスのためのセーフティネットとしてのみ残しておきましょう。延期がそもそもアップグレードを提示するかどうかをどう左右するかについては、macOS 27がソフトウェアアップデートに表示されない理由のガイドで解説しています。

変更点2：管理パスに対するTLSの厳格化

Appleはこの要件を、2026年6月9日付のサポート記事『Prepare your network environment for stricter security requirements』で公開しており、macOS 27のリリースノートでも改めて繰り返しています。管理パス上のサーバーは以下を満たす必要があります。

要件	詳細
プロトコル	TLS 1.2以降。「可能な限り」TLS 1.3
暗号スイート	Forward Secrecy——任意のTLS 1.3スイート、またはECDHEを用いたTLS 1.2スイート
証明書の鍵	RSAは2048ビット以上、ECDSAは256ビット以上
署名ハッシュ	256ビット以上のダイジェストを持つSHA-2
TLS 1.2拡張	Extended Master Secret（EMS）、RFC 7627

影響を受けるワークフローとしてAppleが挙げているのは、モバイルデバイス管理、Declarative Device Management、Automated Device Enrollment、構成プロファイルのインストール、（エンタープライズアプリ配布を含む）アプリのインストール、ソフトウェアアップデートです。

例外は2つ明記されています。プロファイルのインストール中やDDMアセットの解決中に行われるSCEPサーバーへの接続は影響を受けません。コンテンツキャッシュサーバーも同様に、アプリやソフトウェアアップデートのアセットを配信する場合であっても影響を受けません。

27.0で変わるのは、その結果です。Apple記事いわく「要件を満たさない接続はブロックされ、ログメッセージは警告ではなくエラーとして表示されます」。チェック自体は新しいものではありません。以前のリリースでもこれらの違反はすでに警告としてログに記録されており、だからこそ今のうちに監査ができるのです。

古いTLSがまだ潜んでいる場所

公開されているMDMサービスは、何年も前から要件を満たしています。リスクがあるのは、自分自身がホストしている、あるいは経路上に置いているものです。

• 自前でホストするMDMが、TLS設定が一度きり行われてそれ以降見直されていない、古いリバースプロキシやロードバランサーの背後にある場合
• 社内アプリ配布——エンタープライズアプリのマニフェストや.ipa、.pkgファイルをホストするサーバー
• パッケージ・アセットホスト——DDMアセット宣言やカスタムのインストールワークフローが指し示す先
• TLSインスペクションを行うファイアウォールやプロキシ——自らの証明書でトラフィックを再署名するため、その証明書自体が同じ鍵サイズ・ハッシュ要件を満たす必要がある
• 古い証明書チェーン——社内CA上のRSA 1024ビット鍵やSHA-1署名
• 古いTLSスタック——TLS 1.2は交渉できるものの、Extended Master Secret拡張には対応していないもの

Macがアップグレードする前に監査する方法

ステップ1：nscurlで各サーバーをテストする

macOSにはATSのテストツールが同梱されています。管理パス上の各サーバーに対して実行します。

nscurl --ats-diagnostics https://mdm.example.com

このツールは一連のATS構成の下で接続を試み、それぞれについてResult : PASSまたはResult : FAILを出力します。ここで重要なのは最初のブロックであるDefault ATS Secure Connectionです。健全性チェックとして、Tahoe搭載のMacから2つの公開サーバーに対して実行してみました。www.apple.comは61項目すべてに合格しました。TLS 1.0しか提供しない公開のテストサーバーは、デフォルトのセキュア接続の時点から、1つも合格しませんでした。

ステップ2：Extended Master Secretを確認する

nscurlはEMSを個別には切り分けて表示しませんが、これは古いTLSスタックが最も見落としがちな要件です。OpenSSL 3.xであれば直接報告してくれます。macOSに標準搭載のopensslはLibreSSLなので、Homebrewから入れたものを使ってください。

echo | openssl s_client -connect mdm.example.com:443 -tls1_2 -servername mdm.example.com 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Extended master secret"

www.apple.comに対して実行すると、Protocol: TLSv1.2、ECDHE-RSA-AES256-GCM-SHA384という暗号スイート、2048ビットのサーバー鍵、そしてExtended master secret: yesが表示されます。経路上のすべてのサーバーが、これと同等かそれ以上であることが望まれます。

ステップ3：デバイス自身に語らせる

サーバーを一台ずつテストする方法では、自分が把握しているサーバーしかカバーできません。Appleが推奨する監査方法は、デバイスが実際に接続している先を記録することで、それ以外も捕捉します。

1. テスト用MacにAppleのNetwork Diagnostics Loggingプロファイルをインストールします。
2. 確認したいワークフロー——エンロールメント、プロファイルのインストール、アプリのインストール、ソフトウェアアップデート——を実行します。
3. そのMacからsysdiagnoseを収集します。
4. Appleのプレディケートを使ってログアーカイブを検索します。

log show --archive system_logs.logarchive --info -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

26.xを実行しているMacでは、ヒットしたものはすべて警告です。つまり、そのMacがアップグレードした際にそれらの接続はブロックされることになります。27.0搭載のMacでは、同じヒットがエラーとして表示され、それらの接続はすでに失敗しています。

Tahoe搭載のMacでこのテストを実行すれば、実際に何かが壊れる前に、何が壊れることになるかの一覧を手に入れられます。

ロールアウトチェックリスト

最初の27.0アップグレードを迎えようとしているフリートに対して、私たちなら次の順序で進めます。

1. 管理パス上のすべてのサーバーを洗い出す：MDMサーバーとチェックインURL、Automated Device Enrollmentの構成、アプリのマニフェストやパッケージのホスト、DDMアセットのURL、そしてそのトラフィックを検査するプロキシやファイアウォール。
2. それぞれに対してnscurl --ats-diagnosticsを実行し、デフォルトのセキュア接続に失敗するものを修正する。
3. TLS 1.2を終端するすべてのサーバーでOpenSSL 3.xを使いEMSを確認する。
4. Appleのログ監査を実行する——1台のTahoeテスト用Macで、エンロールメントからアップデートまでの一連のサイクルを通して。
5. アップデートポリシーを宣言型で再構築する：対象バージョン向けの強制宣言、延期・自動アクション・Background Security Improvements向けのsoftwareupdate.settings。
6. レポートを切り替える——OSUpdateStatusやAvailableOSUpdatesから宣言型のステータス項目へ。
7. 自動化スクリプトを検索する——ScheduleOSUpdate、ScheduleOSUpdateScan、AvailableOSUpdates、OSUpdateStatusといった従来のコマンド名がないか。
8. サービスデスクに伝える——ケイデンスに基づくアップデートの非表示が27.0では廃止されたこと、代わりにユーザーが何を目にすることになるか。
9. パイロットグループをアップグレードし、対象を広げる前に、実機の27.0ハードウェア上でエンロールメント、アプリのインストール、アップデートの強制がすべて問題なく機能することを確認する。

よくある問題のトラブルシューティング

27.0搭載のMacが設定したアップデート期限を無視する

問題：Golden Gateにアップグレードしたにもかかわらず、ポリシーで要求しているマイナーアップデートがインストールされない。

解決策：そのポリシーがどの仕組みを使っているかを確認してください。従来のScheduleOSUpdateコマンドやMDM制限であれば、27.0ではもう機能しません。代わりにsoftwareupdate.enforcement.specific宣言を配布し、それでもインストールされない場合はデバイスのsoftwareupdate.failure-reasonステータスを確認してください。

新しいMacのアップデートレポートが「unknown」と表示される

問題：パッチ管理ダッシュボードに、27.0搭載のMacのアップデートデータが表示されない。

解決策：ダッシュボードが従来のクエリの応答を読み取っています。宣言型のステータス項目softwareupdate.install-stateとsoftwareupdate.pending-versionに切り替えてください。

Tahoeではエンロールメントが成功し、Golden Gateでは失敗する

問題：27.0を実行している新しいMacがAutomated Device Enrollmentの途中で失敗する一方、同じ構成のTahoe搭載Macでは成功する。

解決策：他に証拠がない限り、これはTLSの変更が原因です。エンロールメントフロー内のすべてのURLをnscurl --ats-diagnosticsでテストし、mdmclient、Setup Assistant、profilesからのATSエラーがないかデバイスのログを確認してください。

エンタープライズアプリが27.0にインストールされない

問題：自社サーバーから配布しているカスタムアプリのインストールに失敗する。

解決策：マニフェストまたはパッケージのホストがTLS要件を満たしていない可能性が高いです。多くの場合、MDMの強化対応の対象になっていなかった古いWebサーバーが原因です。コンテンツキャッシュサーバーは対象外なので、問題はオリジンのホスト側にあります。

TLSインスペクションを行うファイアウォールが管理トラフィックを妨げる

問題：社内ネットワークの外では問題なく動作するが、社内ネットワーク上では失敗する。

解決策：インスペクションを行っている機器は、自らの証明書とTLS設定で接続を再署名しており、それらも今ではATS要件を満たす必要があります。その機器の設定をアップグレードするか、管理用ホストとAppleのMDMエンドポイントをインスペクションの対象から除外してください。

よくある質問

macOS 26では、従来のソフトウェアアップデートコマンドはまだ使えますか？

はい。Appleのスキーマでは26.0で非推奨、27.0で削除とされているため、Tahoe搭載のMacは今も従います。27.0搭載のMacは従いません。移行期間中は、すべてのMacで同じ結果になるよう、ポリシーを宣言型で定義してください。

推奨ケイデンス設定の代わりになるものは何ですか？

macOSでは、直接の代替はありません。Appleのスキーマでは宣言型のRecommendedCadenceキーはmacOSで利用不可とされています。リリースを非表示にするには延期を、希望するバージョンを要求するには強制宣言を使ってください。

コンテンツキャッシュサーバーはTLSの変更の影響を受けますか？

いいえ。Appleはコンテンツキャッシュサーバーを例外として挙げており、「アプリのインストールやソフトウェアアップデートに関連するアセットをリクエストする場合であっても」対象外としています。SCEPサーバーも同様に対象外です。

Macがアップグレードする前に、どのサーバーが要件を満たしていないかをどう知ればよいですか？

Tahoeのテスト用MacにAppleのNetwork Diagnostics Loggingプロファイルをインストールし、自分たちのワークフローを実行し、sysdiagnoseを収集して、Appleのサポート記事にあるログプレディケートで検索してください。26.xでは違反が警告として表示されるため、何かが壊れる前にそれを確認できます。

管理下にないMacにとって、この変更は何か意味がありますか？

ソフトウェアアップデートの変更については影響しません。TLSルールはすべてのMacのソフトウェアアップデートとアプリのインストールもカバーしていますが、それらは通常Apple自身のサーバーに接続しており、要件を満たしています。Macが管理下にあるかどうかはprofiles status -type enrollmentで確認できます。管理下にないMacでは、両方の行が「No」と表示されます。

まとめ

macOS 27は、宣言型管理が登場して以来Appleが示唆し続けてきた流れを完成させるものです。アップデート制御は27.0で宣言型のみとなり、管理パスも現代的なアプリ接続と同じトランスポートセキュリティを強制するようになりました。どちらの変更もユーザーインターフェースには触れないため、フリートは気づかないままこの両方に足を踏み入れてしまいかねません——期限を逃すか、エンロールメントが失敗するまでは。

どちらも、今日Tahoe上でできる準備によって避けられます。サーバーをテストし、1台のMacでAppleのログ監査を実行し、アップデートポリシーを宣言型で再構築し、レポートの向き先を変えてください。最初の27.0搭載Macが到着する前にそれを済ませておけば、アップグレードはごく普通の作業になります。

関連記事：macOS 27がソフトウェアアップデートに表示されない理由 ・ Background Security Improvementsの解説 ・ macOS 27は他のアプリのデータへのアクセスをブロックする ・ macOS 27 Golden Gateリリース初日アップデートガイド ・ macOS Tahoeエンタープライズ導入ガイド