リモートMac SSH切断後、ビルドは止まる？2026年継続タスクの方法

AppleのXcode資料では、コマンド実行の終了状態を確認でき、成功と失敗を終了コードで区別できます。xcodebuildの公式リファレンスも、SSH画面が表示されているかどうかを成功判定にはしていません。したがって、リモートMac SSH切断後のビルドは、前面のSSHから直接起動しただけでは継続を保証できません。短時間の手動作業は再接続可能なセッションへ移し、繰り返し実行する処理はCI Runnerまたは管理されたバックグラウンドジョブへ分けます。

本週は、既存のArchiveを同じコマンドで再実行する前に、プロセス、ログ、終了状態、成果物の順で確認してください。夜間ビルドや定期配布を担当している場合は、断線だけでなくユーザーログアウトとMac再起動も検証対象にします。

この記事は、手元にMacがなく、SSH経由でiOS Archiveやテストを実行するWindows・Linux開発者向けです。リモートMacに夜間ビルド、定期テスト、TestFlight向けの配布処理を任せたい小規模チームにも適しています。

通信中断後に「処理が続いているのか、失敗したのか、画面だけが消えたのか」を判断できない環境管理者は、単にSSHの再接続方法を増やすのではなく、タスクの所有者、セッション依存、証拠の保存場所を分離してください。

Archiveの実行中にローカル回線が切れると、再接続後に以前の画面を見られないことがあります。このとき、結果は大きく次の三つに分かれます。

• SSHのシェル終了とともに、ビルドプロセスも終了している。
• ビルドは完了または継続しているが、標準出力を画面にしか出しておらず、ログの証拠が残っていない。
• プロセスは存在するものの、署名、Simulator、Keychain、ユーザーセッションなどで処理が待機している。

macOSのプロセスとログインコンテキストは同一ではありません。Appleのシステムコンテキスト説明が示すように、プロセスが存在することだけで、必要なユーザー環境やGUI環境が有効だとは判断できません。

ここでは、ターミナル画面の更新を成功の根拠にしないでください。再接続後に確認する証拠は、プロセスの状態、完全な標準出力、標準エラー、終了コード、xcresultまたはxcarchive、そしてアップロード記録です。

一度だけ実行するxcodebuildのBuild、Test、Archiveであれば、処理を再接続可能な端末セッションの中で起動します。ただし、セッションを用意するだけでは不十分です。出力先と成果物の場所を先に固定し、再接続後に同じ証拠を参照できるようにします。

mkdir -p "<LOG_DIR>" "<OUTPUT_DIR>"

xcodebuild \
  -workspace "<WORKSPACE_PATH>" \
  -scheme "<SCHEME_NAME>" \
  -configuration "<CONFIGURATION>" \
  -destination "generic/platform=iOS" \
  archive \
  -archivePath "<OUTPUT_DIR>/<ARCHIVE_NAME>.xcarchive" \
  > "<LOG_DIR>/archive.stdout.log" \
  2> "<LOG_DIR>/archive.stderr.log"

status=$?
printf '%s\n' "$status" > "<LOG_DIR>/archive.exit"
exit "$status"

この例では、ユーザー名、ホスト名、プロジェクト名、Scheme、Bundle ID、Team ID、実際の秘密情報を含めていません。実環境では秘密鍵やトークンをコマンド履歴とログへ書き込まないでください。

再接続後は、次の順で確認します。

• [ ] 対象の端末セッションへ再接続し、画面表示だけでなく保存済みログを開く
• [ ] psなどで対象プロセスが残っているかを確認する
• [ ] 標準出力と標準エラーの末尾に、待機・失敗・完了の手掛かりがあるか確認する
• [ ] 終了状態ファイルが存在し、成功を示す値になっているか確認する
• [ ] 指定した場所にxcarchiveまたはxcresultが生成されているか確認する
• [ ] Archive後のexportとアップロードを、既存のバージョン番号・ビルド番号と照合する
• [ ] 同じ処理を再実行する前に、既存成果物を別名で保全する

AppleのXcodeテスト資料でも、テスト結果は実行画面だけでなく結果データを確認する流れになっています。テスト結果の確認方法を基準に、画面ログを唯一の証拠にしない運用へ変えてください。

注意：Archive、export、バイナリのアップロード、App Store Connect側の処理は別々の段階です。アップロードコマンドが終了していても、App Store Connectで処理が完了したとは限りません。

長時間のArchiveでは、処理を一つの巨大なコマンドとして扱わないことが重要です。Archive、exportArchive、バイナリのアップロード、App Store Connectでのバックグラウンド処理に、それぞれログと完了印を設けます。

Archiveが完了してxcarchiveが残っているなら、まずその成果物からexportを試します。アップロードが通信中断で失敗した場合も、バージョン番号とビルド番号を確認し、まだ受け付けられていないことを確認してから再試行します。すでに受付済みか不明な状態で同じバイナリを何度も送ると、重複や識別ミスの原因になります。

App Store Connectへの配布手順では、Xcode側の処理と配布先での処理が分かれています。したがって、復旧単位は「最初から全部」ではなく、最後に確実に完了した段階の次からにします。

xcodebuild archiveの再実行が必要なケースと、既存のxcarchiveを使ってexportだけ再試行できるケースを区別すれば、署名やビルド時間の無駄な繰り返しを避けられます。

手動のSSH接続は、担当者が開始と確認を行う作業には向いています。しかし、夜間の定期ビルド、頻繁なコミットごとのテスト、定刻の配布処理を長期的に任せるには、起動条件と失敗時の記録が不足しやすい構成です。

CI Runnerは、リポジトリの変更や手動実行を起点にしやすく、ログ、成果物、終了状態をジョブ単位で管理できます。一方、launchdはMac上で指定した条件のジョブを管理する仕組みであり、Appleのlaunchdジョブ設定資料を確認して、実行ユーザー、作業ディレクトリ、環境変数、標準出力先を明示する必要があります。

判断は次のように分けます。

• 手動で一度実行する長いArchive：再接続可能な端末セッション
• リポジトリ更新ごとのBuild・Test：CI Runner
• Mac起動後に決まった処理を開始：launchdなどの管理ジョブ
• 署名やGUI許可を含む処理：ログイン状態とKeychainを含めた専用検証

CI Runnerを導入する場合も、Runnerが登録済みであることだけを完了条件にしません。Mac再起動後にジョブを受けられるか、失敗ログを取得できるか、成果物を保存できるかまで確認してください。自動化の構成を整理する場合は、GitHub Actions自作Mac Runnerの設定ガイドも関連する設計材料になります。

純粋なコマンドラインBuildと、Simulatorを使うテスト、Keychainを使う署名、GUI許可を必要とする操作は分けて考えます。プロセスが動いていても、ログインユーザー、ロック状態、Keychainのロック、Simulatorサービスの状態が同じとは限りません。

まず、署名を使わない単純なビルド、Simulatorテスト、配布用Archiveを別々の小さなジョブにして、SSH接続中とグラフィカルなログインセッション中の差を確認します。権限変更やKeychainの設定変更を行う場合は、対象アカウント、影響する証明書、元へ戻す方法を記録してから実施してください。アクセス制限を広げることを、標準の復旧策にしてはいけません。

FAQは、画面の再表示ではなく、処理の証拠をもとに復旧するための判断基準をまとめたものです。特にアップロード済みか不明な場合は、バージョン番号とビルド番号を照合してから再試行してください。

再起動と三段階の受け入れ確認

本番運用へ移す前に、次の順で確認します。各段階でログ、終了状態、成果物を保存し、失敗した段階を明記します。

• [ ] SSH切断：Archiveまたはテストの途中でSSH接続だけを切り、再接続後にプロセス、ログ、終了状態、成果物を確認する
• [ ] ユーザーセッション変更：処理中にログアウトまたはセッション切り替えを行い、署名、Simulator、Keychainの状態を確認する
• [ ] Mac再起動：再起動後にSSHサービス、Runnerまたは管理ジョブ、ログ保存、テスト用の小さなBuildを確認する
• [ ] 配布確認：既存のArchiveを使ったexportとアップロードを行い、App Store Connect側の状態まで記録する
• [ ] 回退判断：失敗時に一時的な手動接続へ戻すのか、常駐Runnerへ移すのか、環境自体を変更するのか決める

SSH接続の設定自体は、macOSのRemote Login設定とSSH接続形式を参照してください。ただし、Remote Loginが有効であることは、ビルド処理の継続や署名環境の復旧を保証するものではありません。

自動テスト用の常駐環境を整える場合は、iOS自動テストサーバーの配置と再起動確認のように、起動後のサービス確認まで含めて設計します。Macが常時稼働できず、ログの保全や再起動後の復旧を検証できない場合は、個人の開発用PCを無理に常時起動するより、遠隔MacのiOSビルド環境と利用期間の選び方を比較するほうが判断しやすくなります。

現在の個人PCや一時的なSSH環境を使い続ける方式には、電源状態を自分で管理しなければならないこと、回線断後のログが欠けやすいこと、再起動後にRunnerや署名環境を手作業で戻すことという弱点があります。断線・ログアウト・再起動の受け入れ確認を通過できないなら、JEXCLOUDのリモートMacレンタルで、常時利用できるMac環境とroot権限を持つ構成を検討する価値があります。短期の手動Archiveなら再接続可能なセッションで足りますが、夜間テストや継続配布では、最初から復旧手順とログ保存を組み込める環境を選ぶほうが、再実行による時間と署名事故を抑えやすくなります。

必要な期間だけMacを確保したい場合は、利用地域と期間を確認したうえでJEXCLOUDの日本向けMacレンタル案内を参照してください。導入後も、まず小さなBuild、次にArchive、最後に配布処理の順で断線と再起動を検証し、確認できない状態を本番の夜間ジョブへ広げないことが重要です。