iOSビルドマシンの移行で何をバックアップする？2026 Xcode 27チェックリスト

iOSビルドマシンの移行で何をバックアップする？2026 Xcode 27チェックリスト

2026年9月8日時点で、Xcode 27の対応macOSとSDKの組み合わせは Apple公式のシステム要件 で確認が必要です。したがって、Xcode 27 iOSビルドマシン移行の勝者は、プロジェクトだけでなく6つの復旧指標を新環境で実証できる方式です。旧Macは、実際のArchive、署名、アップロード、旧環境なしでの自動化を確認するまで消去・返却してはいけません。

このチェックリストは、退去予定のリモートMacに何を残すべきか判断できない独立開発者向けです。
別のMacへCIを移す担当者、外注案件の引き継ぎや故障したビルド機の再構築を行う小規模チームにも適しています。

最終更新：2026年9月8日。 Xcode 27の要件、署名、配布、API認証、Runner管理の確認には、本文中のApple公式資料と自動化基盤の公式手順を使用しています。将来のRC版や提出ルールは、移行の根拠にしていません。

コピー方式より復旧指標で判定する

「プロジェクトを新しいMacへコピーし、Xcode 27を入れ直せば終わり」という判断は危険です。古いビルド機にしかない署名秘密鍵、未追跡の設定ファイル、App Store Connect用のAPIキー、Runnerの登録状態が残っている可能性があります。

Xcode 27 iOSビルドマシン移行の合格条件は、次の6項目です。

  1. ソースと依存関係をクリーンな状態から再構築できる
  2. Xcode 27、SDK、コマンドラインツールの基準を再現できる
  3. Apple Distribution証明書と関連する秘密鍵で署名できる
  4. Provisioning Profileを目的の配布方法で使える
  5. xcarchive、dSYM、xcresultを必要な時に読み出せる
  6. 自動化タスクを新しいMacへ引き継ぎ、旧Runnerなしで実行できる

最後の確認は「Keychainに証明書が表示されたか」ではありません。新環境で実際にArchiveを作り、対象の署名方式で書き出し、アップロードまで完了できるかが基準です。

ソースとツールチェーンは再現性で比べる

移行時に再取得できるもの、失うと止まるもの

移行時にどのファイルをコピーすべきですか。
最初に保存するのは、ソースコード、サブモジュール、依存関係のロックファイル、ビルドスクリプト、設定テンプレート、必要なSecretsの参照方法です。依存関係を再取得できるか、プライベートリポジトリへ接続できるかも記録します。

一方、DerivedDataや一時キャッシュは復旧の中心にしません。容量の大きいキャッシュをコピーしても、SDKの不一致や署名設定の欠落は解決しないためです。必要なのは、クリーンなチェックアウトから依存関係を解決し、旧Macの特定ディレクトリに依存せずビルドできる証拠です。

次のように、プロジェクト入口とツールの所在を記録します。

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
git submodule status

出力例は次のように保存します。

/Applications/Xcode.app/Contents/Developer
Xcode 27.0
Build version ...

ビルド番号は環境ごとに異なるため、例示値を固定せず、実際の出力を移行記録へ貼り付けます。Xcode 27の対応macOSは、インストール前に 公式システム要件 と照合します。

再現テストと単なるフォルダー複製を分ける

新Macでは、クリーンな作業ディレクトリを作成し、ロックファイルから依存関係を解決します。次に、通常のBuildだけでなく、Archive用SchemeとRelease設定を指定して実行します。

xcodebuild \
  -workspace "App.xcworkspace" \
  -scheme "App" \
  -configuration Release \
  -archivePath "$PWD/build/App.xcarchive" \
  archive

合格条件は、旧MacのDerivedData、作業ディレクトリ、ローカル専用設定に依存せず、同じBundle IDのアプリをArchiveできることです。秘密情報をリポジトリへ戻すのではなく、環境変数や安全な保管場所から注入できる構成にします。

証明書と配布情報は「表示」ではなく署名で確認する

リモートMacの返却前に署名証明書と秘密鍵をどう保存しますか。
Apple Distribution証明書だけをコピーしてはいけません。署名に使う秘密鍵と一体のアイデンティティとして扱い、Keychainから移行可能な形式で保護して保存します。Appleの アイデンティティ導入とPKCS #12の説明 に沿い、書き出しパスワードはソースコードやShell履歴へ残さないようにします。

Provisioning Profileは証明書とは別の資産です。対象アプリ、配布方法、Teamの状態を確認し、必要なプロファイルを Apple Developerの管理画面 から再取得できる状態にします。

整理する項目は次の通りです。

  • Apple Distribution証明書
  • 関連する秘密鍵
  • Provisioning Profile
  • Team ID、Bundle ID、署名方式
  • Xcodeの自動署名設定
  • Keychainを使うCIスクリプトと環境変数

証明書の存在だけを確認するコマンドは、移行合格の証明にはなりません。

security find-identity -v -p codesigning

出力に証明書があっても、秘密鍵がない、Profileの用途が違う、CIユーザーにKeychain権限がない、といった失敗は起きます。新MacでRelease Archiveを作成し、予定しているTestFlightまたはApp Store向けの書き出しまで確認します。Archiveと配布の操作は Appleの公式手順 に合わせます。

高リスク操作には順番があります。証明書の失効、秘密鍵の交換、Profileの削除は、代替資産を新Macで確認してから行います。先に失効させると、旧環境だけでなく新環境も署名不能になるためです。

アーカイブはIPAだけでなく再調査能力で残す

xcarchiveとdSYMは長期保存が必要ですか。
正式リリースの再調査やクラッシュ解析を行うなら、IPAだけでは不十分です。xcarchive、dSYM、xcresult、ExportOptionsの設定、バージョン、ビルド番号、Archive UUIDを対応付けて保管します。

IPAは配布物ですが、dSYMはクラッシュログを人間が読めるシンボルへ戻すための重要な情報です。Appleの dSYM確認手順 を基準に、Archive内のUUIDと記録済みUUIDが一致するか確認します。

保存対象は次のように分けます。

  • 長期保存：xcarchive、dSYM、リリース用IPA、xcresult、書き出し設定
  • 再生成可能：DerivedData、Swift Packageのキャッシュ、作業用一時ファイル
  • 別管理が必要：証明書の秘密鍵、APIキー、Runnerトークン、環境変数

保存後は、Archiveを実際に開き、別ディレクトリへ書き出せるか確認します。バックアップ容量が確保されていても、壊れた圧縮ファイルや欠落したdSYMでは復旧できません。

自動化は旧Runner停止前に新Runnerを接管する

自ホストRunnerを新しいMacへ移す場合、何を先に切り替えますか。
先に新Macを登録し、隔離した検証ジョブを実行します。旧Runnerを先に停止すると、失敗時の比較対象と緊急復旧経路を同時に失います。

記録する項目は、リポジトリ権限、Runnerラベル、作業パス、Team ID、Key ID、APIキーの保管場所、ログ出力先です。値そのものは文書へ貼らず、次のような明確なプレースホルダーで管理します。

REPOSITORY=<REDACTED_REPOSITORY>
TEAM_ID=<REDACTED_TEAM_ID>
KEY_ID=<REDACTED_KEY_ID>
RUNNER_LABEL=<REDACTED_RUNNER>

新Runnerの検証ジョブでは、依存関係の解決、Archive、署名、アップロードを順番に確認します。二台が同時に本番ジョブを受ける設定は避け、検証後に旧Runnerの受付を止めます。

旧Runnerの削除は、登録解除だけでなく、関連するサービス、常駐プロセス、作業ディレクトリも確認します。自ホストRunnerの停止・削除手順は 公式のRunner管理資料 に従い、トークンやログを共有フォルダーへ残しません。

App Store Connect APIキーは証明書とは別の認証資産です。Key ID、Issuer ID、秘密鍵ファイルの保管場所を分離して記録し、ダウンロードや管理条件は App Store Connect APIの公式説明 と照合します。

6指標を比較して退去可否を決める

判定指標 新Macで確認する証拠 合格条件 不合格時の対応
ソース再現性 クリーンチェックアウトと依存関係の解決ログ 旧作業ディレクトリなしでBuildできる ロックファイル、サブモジュール、秘密設定を再確認
ツールチェーン Xcode、SDK、コマンドラインツールの出力 Xcode 27と対象SDKを選択できる macOS要件とXcodeパスを修正
署名可用性 Apple Distributionと秘密鍵、Profile Release Archiveを署名できる 秘密鍵、Profile、Keychain権限を確認
アーカイブ復元性 xcarchive、dSYM、xcresult、UUID記録 開いて再書き出しできる バックアップの完全性を再検証
自動化の引き継ぎ 新Runnerの隔離ジョブログ 旧Runnerなしで処理できる ラベル、権限、環境変数を修正
旧環境の清掃 サービス停止、認証情報の失効・交換記録 機密情報が残っていない 退去・削除を延期する

この判定表で一つでも署名または公開に関わる項目が未確認なら、旧Macは短期間だけ並行保持します。長期保管が不要なキャッシュを削除しても、唯一の秘密鍵やArchiveを先に消すべきではありません。

旧ビルドマシンはいつ安全に消去できますか。
新Macで実際のArchiveとアップロードを完了し、旧Macをネットワークから切り離した状態でも重要ジョブが復旧し、Runner停止と認証情報の整理まで終わった時点です。最後に、Shell履歴、共有フォルダー、CIログ、一時ファイルに秘密情報がないことを確認します。

現在の環境が間もなく期限切れになる場合は、先に SFTPMACのMacレンタル案内 で、Xcode 27のビルド、署名、常駐自動化を受けられる運用条件を確認すると安全です。レンタル期間や運用条件を比較する場合は、Macレンタル料金の確認ページ も移行計画と合わせて確認できます。

実際の移行では、新しいリモートMacで検証用ジョブを走らせてから本番切り替えを行います。既存環境をそのまま使い続ける方法は手早い一方、ディスク不足、管理者権限の不明確さ、単一マシンに秘密鍵とRunnerが集中するリスクが残ります。

ローカルMacの買い増しも、初期費用、保守、常時稼働、故障時の復旧を負担します。短期の移行、退去前の検証、継続的なiOSビルドを分離したい場合は、SFTPMACのMacレンタルを新しい復旧先として使う方が、旧環境を急いで消去するより安全な選択になり得ます。