01

まず今週やること：4段階で遅さを記録する

同じコミットのビルドでも、遅さは「待機」「環境準備」「コンパイル・アーカイブ」「テスト」に分かれます。Appleの Xcode Cloudワークフロー資料を基準に、今週は正常な実行と異常な実行を各1件保存してください。

結論は明確です。1回遅かっただけでXcode Cloudから移行する必要はありません。継続して遅い段階が特定でき、そこが一時環境の初期化、常駐サービス、ホスト権限の制限に起因するなら、そのジョブだけをリモートMacへ移し、標準ビルドやリリース確認はXcode Cloudに残すのが安全です。

この記事は、Xcode Cloudのビルド時間が増えたAppleプラットフォーム開発者、複雑な依存関係やキャッシュを管理するCI担当者、計算使用量と運用費を見直す責任者向けです。単純なサービス比較ではなく、問題の発生箇所から移行単位を決めます。

02

最初に総時間を分解する

第一段階：待機時間と実行時間を分ける

ビルドレポートで最初に確認するのは、ジョブが開始されるまでの時間と、開始後に実際の処理へ進んだ時間です。全体が長いからといって、コンパイラーやテストが遅いとは限りません。

記録項目は次のとおりです。

  • コミットID
  • Scheme
  • ワークフロー名
  • 開始条件
  • 使用したテスト範囲
  • 待機時間
  • 環境準備時間
  • コンパイル、Archive、テストの時間
  • 成否と再実行の有無

Appleの Xcode Cloud使用データに関する資料も参照し、ログの時間と使用量を別々に見てください。使用量が増えている場合でも、原因がテスト数なのか、依存関係の再取得なのかで対策は変わります。

第二段階：環境準備の反復を調べる

Xcode Cloudは一時的なビルド環境を使います。ローカルMacに残っているDerived Data、認証状態、ツール、バックグラウンドサービスをそのまま利用する設計ではありません。

毎回のpost-cloneスクリプトに、次の処理が入っていないか確認します。

  • 実行に不要なツールのインストール
  • バージョン固定されていないパッケージの取得
  • Swift Package、CocoaPods、Carthageの重複処理
  • 非公開リポジトリへの認証確認
  • ビルドごとに再生成される大容量ファイル
  • 失敗しても終了せず待ち続けるダウンロード

依存関係は、ロックファイルとリポジトリ権限を含めて再現可能にします。Appleの Xcode Cloud依存関係管理ドキュメントに沿って、スクリプトが「準備」と「ビルド」を混同していないか見直してください。

次の条件が続くなら、最適化の停止候補です。

  • 毎回必要な初期化を短縮できない
  • 社内ネットワークや専用APIへの接続が必須
  • ビルド間で保持すべきサービスや生成物がある
  • 管理者権限がないとツールを準備できない

この場合は、環境を保持できるリモートMacで対象ジョブだけを再現します。

03

キャッシュ、テスト、スクリプトを別々に検証する

Clean Buildを基準にしすぎない

Clean Buildを常に有効にすると、実際の開発フローより厳しい時間を測ることになります。一方、キャッシュを無条件に信頼すると、古い生成物による再現性の問題を見落とします。

最低でも次の3種類を分けて比較してください。

  1. 依存関係を含む初回ビルド
  2. キャッシュが再利用されるビルド
  3. ソース変更後の増分ビルド

Derived Data、依存パッケージ、スクリプトが生成するファイルは、同じ「キャッシュ」ではありません。Appleの Xcode Cloudワークフロー設定資料を確認し、どの状態を保存し、どの状態を毎回破棄する設計なのかを記録します。

速さだけを目的に不透明な残存状態を維持するのは危険です。キャッシュの削除後にも同じ成果物を生成できないなら、リモートMacへ移しても問題が消えるとは限りません。

テスト行列は削減より分割を先に考える

プルリクエストごとに複数デバイスのUIテスト、Archive、完全回帰テストまで実行していると、1回の変更が複数の処理へ拡大します。

次の3層に分けると、待つべき処理が明確になります。

  • プルリクエスト：コンパイルと短い単体テスト
  • メインブランチ：代表デバイスの回帰テストとArchive
  • 定期実行：全デバイス、UIテスト、リリース候補確認

同じテストを減らす前に、複数ワークフローで重複していないかを調べてください。古いコミットが新しいコミットの後も走っているなら、Auto-cancel Buildsと開始条件を確認します。Xcode Cloudの ワークフローアクション資料で、実行条件とアクションの組み合わせを確認できます。

スクリプトの無言待機をなくす

カスタムスクリプトは、失敗の原因を隠す長い待機を作りやすい部分です。各コマンドに終了条件、適切な終了コード、十分なログを設定します。

特に確認する箇所は次のとおりです。

  • ダウンロードの再試行範囲
  • 外部APIの応答待ち
  • アップロード処理
  • 秘密情報をログへ出していないか
  • 失敗時に後続処理へ進んでいないか
  • タイムアウト後にプロセスが残っていないか

Appleの カスタムビルドスクリプト資料と環境変数リファレンスを使い、実行環境に依存する値を確認してください。プロキシ環境や認証情報を前提にする処理は、ローカルで成功しただけでは不十分です。

04

FAQ：判断前に確認したい4つの点

FAQでは、依存関係の再取得、ビルド時間の確認場所、テスト行列の整理、リモートMacへ移す条件をまとめています。ここで重要なのは、いずれも総時間だけで決めないことです。

05

作業を5段階で進める

  1. 同じ条件を固定する
    同じコミット、Scheme、ワークフロー、テスト範囲を使います。アカウント名、リポジトリ名、秘密情報、スクリプトパスは記録上のプレースホルダーに置き換えます。

  2. 正常例と異常例を保存する
    ビルドレポート、アクションログ、使用量を保存します。成功例だけでなく、失敗して再実行した例も残してください。

  3. 遅い段階を1つに絞る
    待機、準備、コンパイル、テスト、Archiveを分けます。複数の問題を同時に直すと、どの変更が効いたのか判断できません。

  4. 設定を1項目ずつ変更する
    Clean Build、依存関係の取得、テストデバイス、開始条件、Auto-cancel Buildsを個別に見直します。変更前後で同じ条件を再実行します。

  5. 移行対象を限定して比較する
    最も遅いジョブだけをリモートMacで動かします。ビルド成功、ログの完全性、再起動後の復旧、秘密情報の扱い、保守作業を確認してから範囲を広げます。

06

判定用チェックリスト：最適化、移行、二重運用を選ぶ

次の項目を上から確認してください。チェックが最も多い欄を、その時点での第一候補にします。複数の欄に該当する場合は、全体移行ではなく二重運用を優先します。

Xcode Cloudを継続する条件

  • [ ] 遅さが不要な依存関係取得、重複テスト、古いコミットの実行に集中している
  • [ ] 開始条件とAuto-cancel Buildsを整理すれば、不要なジョブを止められる
  • [ ] キャッシュを削除した後も、同じ成果物を再現できる
  • [ ] 社内ネットワーク、常駐サービス、専用ホスト権限を必要としない
  • [ ] 標準的なビルド、テスト、Archiveで目的を達成できる

この欄が中心なら、ワークフローとスクリプトを一つずつ修正します。移行先を先に作るより、原因を除去した後の再計測が先です。

リモートMacへ移す条件

  • [ ] 毎回の環境初期化が主な遅延で、スクリプト整理後も残る
  • [ ] 依存ツール、生成物、テスト資産、バックグラウンドサービスを保持したい
  • [ ] SSH、管理者権限、固定されたホスト環境が必要
  • [ ] 社内ネットワークや専用APIへ継続的に接続する必要がある
  • [ ] ノードの再起動、証明書、ディスク清掃を自分で運用できる

この欄に該当しても、最初から全ワークフローを移す必要はありません。該当するジョブを一つだけ選び、同じコミットとSchemeで比較してください。

Xcode CloudとリモートMacを二重運用する条件

  • [ ] 標準ビルドや公開前確認はXcode Cloudで問題なく完了する
  • [ ] 複雑なテスト、常駐サービス、内製ツールだけに専用環境が必要
  • [ ] 署名情報、成果物、通知、再実行の責任者を両環境で定義できる
  • [ ] リモートMac停止時の代替ワークフローを用意できる
  • [ ] 2系統のログを同じ形式で保管できる

二重運用は、速度と制御性を両立しやすい反面、管理対象が増えます。担当者と復旧手順を決められないなら、急いで分割しないでください。

07

判断ツール：3つの運用案を選ぶ

A. Xcode Cloudを継続する

次の条件なら、Xcode Cloudの最適化を続けます。

  • 遅さの原因が重複したテストや不要な取得処理
  • キャッシュを削除しても再現性を保てる
  • 常駐サービスや社内ネットワークが不要
  • 標準的なビルドとテストで完結する

利点は、ワークフロー管理を集約しやすいことです。弱点は、環境を完全に保持したい処理には向かないことです。

B. 対象ジョブをリモートMacへ移す

次の条件なら、リモートMacへの移行を検討します。

  • 初期化時間が繰り返し発生し、スクリプトでは圧縮できない
  • 依存ツール、生成物、サービスを保持したい
  • SSHでの運用やホスト権限が必要
  • 社内ネットワークや専用エンドポイントへ接続する
  • ノード再起動後の復旧手順を自分で管理したい

リモートMacでは環境を細かく制御できますが、Xcode、署名情報、OS更新、ディスク清掃、監視を自分で管理します。購入とレンタルを比較する場合は、Mac miniの構成と導入条件も確認し、短期検証なのか常用ノードなのかを分けて考えてください。

C. 二重運用にする

標準的なビルドと公開前の確認はXcode Cloudに残し、常駐サービスや複雑なテストだけをリモートMacで実行します。

この方式は、全移行の失敗範囲を小さくできます。反面、署名、成果物の保存場所、失敗通知、再実行方法が2系統になります。ジョブごとに所有者と復旧手順を決めないまま始めると、速度改善より運用負荷が増えます。

08

現在の構成とMac構成を比べてから決める

Xcode Cloudを使い続ける構成は、標準フローとの相性がよい一方、毎回の環境準備と外部依存の待機を細かく制御しにくい場合があります。テスト行列が大きいと、不要なブランチや古いコミットまで実行され、使用量の原因を追いにくくなります。

一方、リモートMacは持続する環境、SSH、管理者権限、常駐プロセスを扱いやすくします。ただし、OS更新、証明書、再起動復旧、ディスク使用量、アクセス制御を自分で維持する必要があります。短期間だけ遅い処理を検証したいなら、VpsMeshのMac利用方法を確認し、まず対象ジョブを限定したレンタルで比較する方法が現実的です。

今週の判断は、サービス全体を移すかどうかではありません。ログで最も時間を使う段階を特定し、その段階が一時環境の制約である場合だけ、リモートMacへ小さく移して再現性と復旧性を確認してください。そこで改善が確認できれば局所移行、標準ビルドとの役割分担が明確なら二重運用へ進めます。