Macビルドマシンの無人起動は、CI Agentを専用サービスアカウントのLaunchAgentで動かし、LaunchDaemonはホスト監視と復旧補助に限定する構成を推奨します。今週は、既存ノードでユーザーセッション、Keychain、実ビルドの復旧証跡を確認し、条件を満たせなければ独立して復旧できるMacノードを追加してください。
この判断は、コード署名、iOS Simulator、ユーザーディレクトリ、ログイン後のKeychainを使うCIに適用します。単にSSH接続できることや、管理画面でAgentがオンラインになることだけでは、本番ビルドの復旧とは判定しません。
本記事は、Mac構築ノードを無人運用するIT責任者、iOS CI/CDを管理するプラットフォーム担当者、遠隔Macの調達と検収を担う技術責任者を対象にしています。
「起動した」と「ビルドできる」を分けて判定する
macOSのlaunchdでは、システム起動、ストレージのロック解除、ユーザーのログイン、Agentの登録、実際のビルド成功が別々の状態になります。Macが再起動後にSSHへ応答しても、署名用の秘密鍵やSimulatorを使えるユーザーセッションがなければ、CIは実行可能になりません。
Appleの公式資料では、LaunchDaemonはシステムコンテキストのサービス、LaunchAgentはユーザーセッションに関連するプロセスとして説明されています。サービスの種類を決める前に、launchdジョブの作成に関するApple公式資料で実行コンテキストを確認してください。
| 状態 | 確認できること | まだ保証できないこと |
|---|---|---|
| システム起動済み | 電源投入後にOSが動作している | ユーザー用KeychainやSimulatorの利用 |
| SSH接続可能 | ネットワークとリモートログインが応答している | CI Agentが正しいユーザーで登録されていること |
| Agentオンライン | CI基盤からジョブを受け取れる状態に見える | 署名付きアプリの生成 |
| 実ビルド成功 | ソース取得、依存関係、署名、成果物生成まで確認できる | 次回再起動でも同じ状態になること |
特に「Agentオンライン」を復旧の合格条件にすると、ユーザーセッションの欠落やKeychainのロックを見逃します。合格条件は、最後の実ビルドまで含めて定義します。
実行コンテキストを比較して配置を決める
配置場所と実行ユーザーは、plistの見た目より重要です。一般的な配置先は、システム全体のLaunchAgentが/Library/LaunchAgents、ユーザー単位のLaunchAgentが~/Library/LaunchAgents、LaunchDaemonが/Library/LaunchDaemonsです。実際の読み込み条件はmacOSのバージョンとサービス管理方法に依存するため、導入時には対象OSの公式資料と現行環境で確認します。
| 起動方式 | 主な実行主体 | 適する役割 | iOS CIでの判断 |
|---|---|---|---|
| LaunchDaemon | システムコンテキスト | 到達性確認、監視、ログ収集、復旧補助 | 実ビルドの主プロセスには原則使わない |
| 全体向けLaunchAgent | ログインした対象ユーザー | チーム共通のユーザーセッション処理 | 専用アカウントの管理方針が必要 |
| ユーザー単位LaunchAgent | 専用CIユーザー | Keychain、署名、Simulator、ワークスペース | 署名を伴う構築の第一候補 |
| 二層構成 | システム層とユーザー層 | 復旧とビルドの責任分離 | 本番運用の標準候補 |
公式のCI Agent導入資料でも、macOS向けにユーザーモードのLaunchAgentを前提とする製品があります。ただし、これはすべてのCI製品に適用できる一般規則ではありません。採用するAgentについて、公式のサービスインストール方式を必ず確認してください。たとえば、macOS向けCI Runnerの公式導入手順では、ユーザーモードでの導入条件が示されています。
構成を確認する際は、設定ファイルを先に編集するのではなく、現在のドメインと所有者を確認します。
id
launchctl print-disabled user/$(id -u)
launchctl print system
launchctl print gui/$(id -u)
systemとgui/UIDで見えるサービスが異なるなら、同じAgent名でも監視対象を取り違える可能性があります。不要なKeepAliveを追加してプロセスを常時再起動させる前に、終了理由、実行ユーザー、標準エラー出力を確認してください。
注意：KeepAliveは「正常に復旧した」ことを意味しません。設定ミス、存在しないパス、権限不足を隠したまま、同じプロセスを繰り返し起動しているだけの場合があります。
Keychain、署名、Simulatorを指標にする
LaunchDaemonがKeychainへ期待どおりアクセスできないのは、単なる権限設定の問題とは限りません。Keychainはユーザーセッション、ロック状態、秘密鍵へのアクセス許可、署名ツールの実行主体に左右されるため、システムコンテキストへ資格情報を移すだけでは解決しない場合があります。
AppleはmacOSのKeychainについて、ログインKeychainと専用Keychainを含む扱いを説明しています。秘密鍵とCIの実行ユーザーを整理する際は、MacのKeychainに関するAppleの技術資料を基準に、企業の資格情報管理規則を併記してください。
| 依存対象 | ユーザーセッションへの依存 | 検収で確認する内容 |
|---|---|---|
| 署名証明書と秘密鍵 | 高い | 対象ユーザーで署名処理が完了するか |
| 一時Keychain | 高い | 作成、ロック解除、削除が想定どおりか |
| iOS Simulator | 高い | 対象ユーザーのホーム領域とGUI関連サービスが使えるか |
| ソースと依存キャッシュ | 中程度 | 所有者、保存場所、クリーン実行時の再取得 |
| 配布用資格情報 | 高い | ビルド用ユーザー以外から読めないか |
署名処理では、AppleのMac向け署名済みコード作成資料に沿って、証明書、秘密鍵、署名対象、成果物の検証を分けて記録します。LaunchDaemonへ管理者権限を与えて解決しようとすると、コード、ワークスペース、ネットワーク、配布用資格情報の露出範囲が広がります。
再起動復旧は四つの証跡で検収する
復旧試験は、再起動操作そのものではなく、依存関係が戻ったかを検証する作業です。最低限、次の順に証跡を残します。
- [ ] ホストがSSHなどの管理経路から到達できる
- [ ] FileVault解除後に想定したユーザーセッションが確立している
- [ ] 専用ユーザーのLaunchAgentが登録されている
- [ ] CI Agentが正しいプロジェクトとタグでジョブを受け付ける
- [ ] Keychainが利用可能で、署名処理が完了する
- [ ] iOS Simulatorを含む実際のパイプラインが成功する
- [ ] ログ、終了状態、復旧時刻、設定変更履歴が保存されている
- [ ] 代替ノードへ切り替えた場合も成果物と資格情報の扱いが確認できる
FileVaultを有効にした環境では、電源投入後に暗号化ボリュームを解除できるか、解除後に自動ログインを許可するか、有人操作を要求するかを分けて判断します。AppleのFileVault復旧キーに関するサポート資料と、Appleプラットフォームのデータ保護資料を参照し、セキュリティポリシーに反する自動解除を前提にしないでください。
| 検収シナリオ | 主な失敗点 | 合格条件 |
|---|---|---|
| 計画再起動 | Agentだけ起動しない | ユーザーセッションから実ビルドが成功する |
| 予期しない電源断 | Agent登録前に監視が復旧する | ホスト、Agent、署名、成果物を順に確認できる |
| ユーザーログアウト | CIがアイドル状態になる | 仕様どおり停止し、誤った資格情報を使わない |
| FileVault解除後 | SSHは使えるがユーザー環境がない | 解除方針と有人操作の要否が記録されている |
| 設定変更後 | 別アカウントで起動する | 実行ユーザー、plist、ログの対応が一致する |
FileVault環境の復旧要件を満たせない場合、サービス側で無理に自動ログインを実現するのではなく、有人解除を含む運用手順、待機ノード、または別のノード配置を比較します。無人運用の要件と暗号化ポリシーが衝突しているなら、launchdの設定だけでは解決できません。
最小権限と運用記録を本番条件にする
システム層は、ホストの状態確認、Agentプロセスの存在確認、ログ転送、復旧通知に限定します。ユーザー層は、ソース取得、依存関係、Simulator、署名、成果物生成を担当させます。この分離により、root権限を持つプロセスが配布用秘密鍵や開発者の作業領域まで読み取る構成を避けやすくなります。
Appleのデーモン設計資料では、システムサービスをユーザーセッションの処理と混同しない設計が示されています。LaunchDaemonの設計に関するApple公式資料を参照し、rootで動かす理由を設定ファイルと企業の承認記録に残してください。
運用ログには、少なくとも次の項目を含めます。
- launchdのドメインとサービスラベル
- plistの配置場所と所有者
- Agentの実行ユーザー
- 起動時刻、終了状態、再起動回数
- OS、Xcode、CI Agentの変更履歴
- Keychainの準備結果と署名処理の結果
- 実ビルドのジョブ識別子と成果物の検証結果
構成変更は、本番ノードへ直接適用しません。OS更新、Xcode更新、Agent更新、plist変更を分けて隔離ノードで検証し、失敗時に元の設定へ戻せる状態を維持します。ログを見ずにlaunchctl kickstartを繰り返す運用は、プロセス障害とユーザーセッション欠落を区別できないため、復旧手順として不十分です。
調達判断は「復旧可能なノード数」で決める
LaunchAgent単層は構成が簡単ですが、ホスト監視とユーザー構築が同じ責任範囲になります。LaunchDaemon単層はホスト監視には適する一方、Keychain、Simulator、ユーザーホーム領域を使うCIには制約が出やすくなります。二層構成は設定項目が増えるものの、復旧責任と資格情報の範囲を分離できます。
次の条件を満たせない既存Macは、設定変更だけで本番投入しない方が安全です。
- リモートから再起動できない
- 再起動後にユーザーセッションの状態を確認できない
- 専用CIアカウントと管理者アカウントを分離できない
- 署名用Keychainの利用結果をログに残せない
- 実ビルドを使った復旧試験ができない
- 失敗時に代替ノードへ切り替えられない
自社でMacを保有する場合は、物理接続、長期固定負荷、社内ネットワークへの直接接続、資産管理規則を優先して判断します。一方、短期のCI増強、検証環境、チームごとの分離、故障時の交換を重視するなら、NodeMiniのようなMacレンタルを調達候補に加える価値があります。まずはMacレンタルの利用条件と、必要な地域のMac環境の案内を確認し、独立したユーザーセッション、遠隔再起動、予備容量、権限範囲を契約前に照合してください。
よくある判断をFAQで整理する
Macビルドマシンを再起動した後、CI Agentを自動起動させるにはどうすればよいですか？
署名、Keychain、iOS Simulator、ユーザーディレクトリを使うCI Agentは、専用サービスアカウントのユーザーセッションでLaunchAgentとして起動する構成が基本です。LaunchDaemonにはホスト到達性の確認、ログ収集、復旧補助だけを担当させ、実際のビルド処理をシステムコンテキストへ移さないようにします。
LaunchAgentとLaunchDaemonはiOS CIでどのように使い分けますか？
LaunchDaemonはシステムコンテキストで動くため、ユーザーがログインしていない状態でもホスト監視や復旧処理を実行できます。一方、LaunchAgentはユーザーセッションに属し、署名資産やSimulatorなどユーザー環境に依存する処理に向きます。iOS CIでは両者の役割を分離する構成が安全です。
LaunchDaemonからKeychainへ正常にアクセスできない理由は何ですか？
LaunchDaemonはユーザーセッションの外側で動作するため、ログインユーザーが利用するKeychain、アクセス許可、署名用秘密鍵をそのまま共有できるとは限りません。Keychainの種類、ロック状態、署名ツールのアクセス制御を個別に確認し、Daemonへ資格情報を無理に渡すのではなく、専用ユーザーのLaunchAgentで処理する方が管理しやすくなります。
FileVaultを有効にしたMacを無人で再起動した場合、ビルドを復旧できますか？
FileVaultが有効なMacでは、ディスク暗号化の解除とユーザーセッションの確立を分けて確認する必要があります。ホストがネットワーク上で見えても、ログインセッション、Keychain、CI Agent、署名処理が順番に利用可能になるとは限りません。復旧要件として、解除方法と有人操作の要否を企業のセキュリティ方針に記録してください。
遠隔MacのCI Agentを本番投入する前に、どの再起動シナリオを検証すべきですか？
通常の再起動だけで合格にせず、計画再起動、予期しない電源断、ユーザーのログアウト、FileVault解除後の復旧を個別に確認します。各試験では、SSHなどによるホスト到達、ユーザーセッション、Agent登録、Keychain利用、実際の署名付きビルド成功を証跡として保存し、管理画面のオンライン表示だけで判定しないことが重要です。
既存の単一MacをLaunchDaemonだけで動かす方式は、SSHの復旧確認には向いていても、Keychain、Simulator、署名、ユーザーセッションまで含む本番CIの復旧を保証しにくい構成です。NodeMiniのMacレンタルなら、現行ノードの購入・保守負担を増やさず、専用ユーザー、遠隔操作、追加ノード、切り替え余地を含めた構成を比較できます。長期に固定された高負荷処理や物理デバイス接続が必要なら自社保有が適しますが、期間限定のCI増強や復旧可能な検証環境では、実ビルドの検収証跡を条件にレンタルを検討してください。