2026年9月19日時点で、AppleはmacOS 26以降のApple Silicon Macについて、条件を満たせばFileVaultをリモート解除できることを案内しています。AppleのFileVault展開ガイドにある条件どおり、リモートログインが有効で、起動前環境からネットワークへ到達できる場合に限り、macOS 26 FileVaultのリモート解除を運用対象にできます。したがって、今週は実機の冷間再起動で検証し、単一ノードの本番運用には個人用復旧キーと予備のリモートMacを組み合わせる判断が安全です。

このガイドは、Apple Siliconのビルドノードを遠隔管理し、再起動後の無人復旧を担う企業IT、プラットフォームエンジニア、技術責任者向けです。単にSSHへ接続できるかではなく、FileVault解除、macOS起動、CI Agent、Xcode、署名、成果物の送信までを一つの復旧条件として確認します。

01

まず区別すべき6つの復旧状態

「リモート解除できる」と「CIが再開する」は同じ意味ではありません。企業運用では、次の状態を別々に記録しなければ、再起動後に接続できたのにリリースだけ失敗する事態を見逃します。

  1. FileVaultの起動前ボリューム解除
    暗号化されたデータへアクセスできる状態です。まだ通常のmacOSユーザーセッションが成立したとは限りません。

  2. macOSのシステム起動
    OSが立ち上がり、管理用の接続経路が戻った状態です。SSHが応答しても、署名用キーチェーンが利用できるとは限りません。

  3. SSHセッションの確立
    リモートログインが可能な状態です。SSHの応答だけでは、CI AgentやGUIを前提とする処理の復旧証拠になりません。

  4. CI Agentのオンライン化
    RunnerやAgentがCI管理側へ再接続し、ジョブを受け取れる状態です。

  5. Xcodeビルドの実行
    Xcode、依存パッケージ、証明書、プロビジョニング情報がそろって初めて成立します。

  6. 本番署名と成果物送信
    署名ID、キーチェーンのロック状態、配布先への接続がすべて正常である必要があります。

AppleはFileVaultの管理に、Secure Token、ボリューム所有者、個人用復旧キーなど複数の要素を関係させています。Apple Platform SecurityのFileVault説明を確認し、共有管理者パスワードだけで復旧できる設計にはしないでください。

02

計画メンテナンスでは再起動前の記録が復旧時間を決めます

macOS更新やXcode更新の前には、対象ノードを「再起動しても戻るはず」と扱わず、解除に必要な条件を記録します。最低限、次の項目を変更管理チケットへ残します。

  • macOSのバージョンとApple Siliconの機種
  • リモートログインが有効かどうか
  • FileVaultの有効状態
  • 解除に使えるユーザーとSecure Tokenの状態
  • ボリューム所有者の確認結果
  • 個人用復旧キーの保管先、参照権限、最終確認日
  • 起動前環境で利用できる有線または登録済みWi-Fi
  • CI Agentの現在のジョブ、キュー、接続状態
  • 署名用キーチェーンと証明書の有効期限

FileVaultの管理方法と復旧キーの扱いは、Appleのデバイス管理向けFileVault資料に沿って確認します。デバイス管理製品がキーの保管、ローテーション、監査を完全に実装しているとは限らないため、製品名だけで要件充足と判断しないことが重要です。

macOS 26の再起動後にFileVaultをリモート解除するには、何を先に確認すべきですか。
対象がmacOS 26以降のApple Silicon Macであること、リモートログインが有効であること、起動前環境にネットワーク経路があること、解除可能な認証情報または復旧キーを企業が管理していることを順番に確認します。通常ログイン後のSSH接続だけを根拠にしてはいけません。

実行手順は次の順序に固定すると、復旧判定がぶれにくくなります。

  1. CIキューから対象ノードを外し、実行中ジョブを完了または別ノードへ退避します。
  2. 現在のAgent状態、ビルド番号、署名結果を記録します。
  3. FileVault、トークン、リモートログイン、復旧キーの管理状態を再確認します。
  4. 管理された再起動を実行し、起動前ネットワークとリモート解除を検証します。
  5. macOS起動後にSSHで接続し、Agentのオンライン化を確認します。
  6. 最小のビルドと署名を実行し、成果物の送信まで確認してからキューへ戻します。

トークン状態の確認は、許可された管理者セッションで最小限のコマンドにとどめます。

sudo fdesetup status
sysadminctl -secureTokenStatus builduser

出力例は次のように記録します。実際の表示文言はOSの版やローカライズによって異なるため、文字列の完全一致ではなく、記録項目の意味を確認します。

FileVault is On.
Secure token is ENABLED for user builduser.

Bootstrap Tokenはソフトウェア更新などの認証に関係しますが、FileVaultのあらゆる解除障害を代替する万能キーではありません。AppleのBootstrap Tokenとソフトウェア更新に関する展開資料と対象OSの管理仕様を分けて確認します。

03

意外な電源断では起動前ネットワークを別に検証します

計画再起動が成功しても、停電や強制電源断で同じ結果になるとは限りません。起動前環境では、ユーザーセッションで動くVPN、企業プロキシ、802.1X、ネットワークエージェントがまだ利用可能とは限らないためです。

企業ITが確認すべき経路は、次の二つに限定して考えると安全です。

  • 起動前環境で利用できる、事前登録済みの特定Wi-Fi
  • 追加認証を必要としない、到達性を確認済みのEthernet

Appleの展開資料では、FileVaultの解除に関係するネットワーク条件がOSの通常起動後とは分けて説明されています。FileVaultと起動前環境のネットワーク要件を読み、VPN接続後なら到達できるという構成を無人復旧の根拠にしないでください。

FileVaultを有効にしたリモートMacが接続できない場合、最初に疑うべき点は何ですか。
最初に、起動前環境がネットワークへ出られるかを確認します。通常ログイン後のSSH、VPN、プロキシが成功していても、電源断後のFileVault解除画面から同じ経路が使えるとは限りません。

冷間再起動の検証では、正常な再起動だけでなく、電源断に近い条件を含めます。検証記録には、電源操作の方法、ネットワーク接続の種類、解除操作の成否、OS起動後のSSH、Agent復帰、最小ビルドの結果を残します。復旧時間を社内SLAへ記載する場合は、公開仕様から推定せず、企業自身の記録または実測値だけを使います。

注意：起動前のネットワーク到達性を証明するには、ログイン後のpingやSSHでは不十分です。少なくとも一度は、対象ノードを冷間状態から復旧させ、FileVault解除から署名付きビルドまで通してください。

04

認証情報の失効時は復旧キーを接管手段として設計します

担当者の退職、ローカルパスワードの不一致、管理者アカウントの無効化が起きると、通常のユーザー認証だけに依存した設計は止まります。個人用復旧キーは、このような場合の接管手段になり得ますが、共有パスワードの代用品として扱うものではありません。

運用では、次の役割を分離します。

  • ローカルユーザーのパスワード：通常のログイン認証
  • Secure Token：FileVaultの暗号化解除に関係するユーザー資格
  • ボリューム所有者：暗号化ボリュームの管理権限に関係する主体
  • 個人用復旧キー：対象ボリュームの復旧用秘密情報
  • 機関用復旧キー：組織管理向けに使われる復旧情報。利用可否や運用方法は管理方式の確認が必要です

復旧キーは暗号化された保管庫へ保存し、参照できる担当者を限定します。使用後はキーのローテーション要否を判定し、誰が、どのノードに、何の理由で使用したかを監査記録へ残します。Appleが説明するFileVaultの復旧キー管理と、実際のデバイス管理製品の監査機能は別の確認項目です。

FileVaultの復旧キーは、リモートのビルドMacに使えますか。
条件を満たすApple Silicon Macで、起動前環境へ復旧キーを届けられる運用経路があれば、無人復旧の選択肢になります。ただし、キーを持っているだけではネットワーク到達性もCI復旧も保証されないため、実機演習と監査手順を組み合わせます。

05

CI復旧の判定は「接続できた」から署名成功まで伸ばします

FileVault解除後にSSHへ接続できても、ユーザー会ッション、キーチェーン、証明書、Runnerの起動コンテキストが復旧していないことがあります。特に本番署名ノードでは、ホストのpingやAgentのオンライン表示を復旧完了の条件にしないでください。

検収は、次の順番で行います。

  • ディスクが解除され、macOSが起動している
  • 管理用SSHへ接続できる
  • CI Agentが管理側へオンラインとして登録される
  • Xcodeのバージョンと利用可能なSDKを確認できる
  • 依存パッケージとプライベートリポジトリへ到達できる
  • 署名証明書とキーチェーンが期待どおり利用できる
  • 最小のiOS/macOSビルドが完了する
  • 署名済み成果物を保管先または配布先へ送信できる

確認コマンドは、環境の秘密情報を出さない範囲に絞ります。

ssh build-node 'sw_vers; id; launchctl print system | grep -i runner'

出力例：

ProductVersion: 26.0
uid=0(root) gid=0(wheel)
com.example.ci.runner = running

この出力だけでは署名成功を証明できません。CI側で最小ジョブを実行し、ビルドログ、署名結果、成果物ハッシュ、送信結果を一つの復旧記録へ結び付けます。既存のMacビルドマシンの無人起動に関する運用記事を参照する場合も、LaunchAgentやLaunchDaemonの起動確認とFileVaultの起動前解除を同じ問題として扱わないことが重要です。

06

ノードの重要度に応じて単一運用と予備Macを選びます

すべてのMacに同じ冗長性を持たせる必要はありません。決定には、停止時の影響、署名資格情報の集中度、冷間復旧を実証できるか、予備ノードへ切り替えられるかを使います。

運用方式 適するノード 必須の検証 判断
単一ノードの遠隔復旧 非重要なテスト、夜間停止を許容できる処理 FileVault解除、SSH、最小ビルド 冷間復旧を定期的に実証できる場合
温備ノード 日常ビルド、復旧待ちを短くしたい処理 予備MacのOS、Xcode、依存関係、Agent接続 主ノード停止時に手動または自動切替できる場合
2台の専用公開プール 本番署名、リリース時間が固定された処理 両ノードの署名、成果物送信、資格情報分離 片系のFileVault復旧失敗でも公開を継続する場合

遠隔Macをレンタルする場合は、CPUやメモリだけで比較せず、冷間再起動の証跡、起動前ネットワーク、復旧キーの責任分界、リモートコンソール、交換時の手順、利用期間を契約前に確認します。NodeMiniの企業向けMacレンタルの相談窓口を検討する際も、単にSSHが使えるかではなく、前述の復旧検収を実施できるかを確認項目に含めてください。

自社購入のMacは物理アクセスや長期固定運用に向きますが、設置場所の電源、交換部品、ネットワーク、保守担当を自社で持つ必要があります。通常のクラウドVMはApple Silicon上のmacOS実行環境や起動前のFileVault操作を代替できないため、iOS署名ノードの選択肢として同じ土俵に置けません。

今週の実行順は明確です。まず非本番ノードでFileVault解除と起動前ネットワークを冷間検証し、次にCI Agent、Xcode、署名、成果物送信までを確認します。その記録を基に、テストノードなら単一運用、日常ビルドなら温備、本番署名なら専用の2台構成へ段階的に移行します。

現在の単一Mac運用は、電源断後に手動解除が必要になること、VPNや802.1Xに依存して起動前ネットワークが止まること、SSH接続だけでは署名環境の復旧を確認できないことが弱点です。自社購入ではさらに設置拠点の保守と交換対応が加わります。冷間再起動の検証環境や予備ノードを短期間で用意したい場合は、NodeMiniのリモートMacをPoCに使い、契約または増設前に無人復旧演習を完了させる方法が現実的です。必要なノード数がまだ確定していない企業ほど、単一ノード、温備、専用公開ノードのどこまで必要かを実測結果で判断できます。