Xcode Cloudのビルドが遅すぎる：2026年 Xcode 27プロジェクトをどう高速化する？

Xcode Cloudのビルドが遅すぎると感じたら、最初にワークフロー全体の終了時刻だけを見ないことです。待機、ソースコードの取得、依存関係の準備、Build、Test、Archive、後処理を分け、どの工程が最初に継続して時間を使っているかを確認します。

AppleのXcode Cloudワークフロー戦略でも、ワークフローは目的とトリガーを分けて設計する考え方が示されています。計算時間、キューでの待機時間、開発者が結果を受け取るまでの体感時間は別の指標です。

記録する項目

• 同じコミットであるか
• 同じワークフローであるか
• 同じXcode 27のBeta版であるか
• 待機、依存関係、Build、Test、Archiveのどこが長いか
• 失敗した場合、最初の失敗工程はどこか
• 生成されたテスト結果、ログ、Archiveを後から確認できるか

Xcode 27はBeta段階のため、Betaの更新前後で結果を混ぜないことも重要です。AppleのXcode 27 Beta公開情報とRelease Notesを照合し、ツールチェーン変更後の記録には使用した版を残します。

毎回のコミットで時間がかかる理由

毎回のブランチ更新で、全デバイスのシミュレーター、UIテスト、Archive、TestFlight向けアップロードまで実行していれば、短いフィードバック用の処理に公開前の処理が混ざっています。Xcode Cloudそのものが遅いと決める前に、トリガーとActionの役割を分離します。

Pull Requestでは、コンパイル確認と変更に関係する主要なユニットテストを中心にします。全デバイスの互換性、UI自動化、署名、配布用Archiveは、定時実行、リリースブランチ、タグ、または手動開始へ移します。

Auto-cancel Buildsを使う場面

短時間に複数のコミットが追加されるブランチでは、古いコミットのビルドが新しいコミットに置き換えられることがあります。Xcode Cloudのワークフロー設定とAuto-cancel Buildsの仕様を確認し、同じ変更系列の古い実行を残す必要があるか判断します。

ただし、すべてを自動キャンセルしてよいわけではありません。再現性の確認、リリース候補の記録、断続的な失敗の調査では、古い実行のログが必要です。

シミュレーターのテスト時間を減らす方法

シミュレーターを一律に削るのではなく、単一環境のヘルスチェック、複数デバイスの互換性、UI自動化、リリース前回帰を分けます。Pull Requestでは単一環境と重要なユニットテスト、定時実行では互換性テスト、リリース前には完全な回帰を置く構成が検討対象です。

削減の安全性は、テスト数では判断しません。テスト結果の保存、失敗画面の確認、実際に不具合を見つけた記録を一定期間追い、削った組み合わせで見逃しが増えていないか確認します。固定の時間目標を先に置くと、必要な検証まで削る危険があります。

注意：Xcode Cloudのシミュレーター実行時間やキュー時間に、一般化できる固定値はありません。プロジェクト、依存関係、テスト内容、利用時点の環境が異なるため、同じコミットと同じワークフローで比較してください。

テスト結果と生成物の保存方法は、Xcode Cloudのワークフローと生成物に関する公式説明に合わせます。結果を残さずにテストだけ削ると、速度は変わっても判断材料が失われます。

Xcode Cloudの依存関係準備が遅い場合

Swift Package、CocoaPods、第三者ツール、リポジトリ認証を別々に調べます。依存関係の取得が毎回発生しているのか、ロックファイルが変わったときだけ発生しているのかをログで確認します。Appleの依存関係をXcode Cloudで利用可能にする方法と、匿名化したログを突き合わせて再現性を確認します。

自作スクリプトも、すべてのActionで同じ準備を実行していないか確認します。Pull Request用、テスト用、Archive用で、必要な処理だけ条件付きで実行します。環境変数を使う場合は、Xcode Cloudの環境変数リファレンスを基準にし、APIキー、Team ID、Bundle ID、パスはログから匿名化します。

切り分けの手順

1. 同じコミットのログを保存します。
2. ソースコード取得、パッケージ取得、ツール導入を別工程として記録します。
3. 各Actionで同一のインストール処理が繰り返されていないか確認します。
4. ロックファイルとリポジトリ認証の失敗を確認します。
5. 自作スクリプトを、起動元とBuild、Test、Archiveの条件で分岐します。
6. 変更後に同じコミットで再実行し、改善した工程と新しい失敗を記録します。

通常のBuildが成功しても、署名、Archive、アップロード、App Store Connect側の処理まで成功したとは限りません。Appleのアップロードと処理の流れでは、アップロード後にも処理段階があり、ビルドのアップロード状態で状態を確認できます。

そのため、ArchiveをPull Requestのたびに走らせる設計は見直し対象です。正式なリリースブランチ、タグ、手動開始のいずれかに結び付け、Archive、署名、アップロード、App Store Connectの処理状態を独立したログとして保存します。

一度は実際のリリース候補で、次の項目を確認します。

• 期待したXcode 27の版でArchiveできるか
• 証明書とProvisioning Profileを取得できるか
• 生成物を後から識別できるか
• アップロード後の処理状態を確認できるか
• 途中で失敗した場合、再実行の手順があるか

判断条件

次の条件で分岐します。

• 一時環境で再現でき、依存関係の準備も管理できるなら、Xcode Cloudのワークフロー分割を続けます。
• Pull Requestのフィードバックだけが遅いなら、軽量検査と完全検証の起動頻度を分けます。
• 固定したXcode版、持続する依存関係、常駐サービスが必要なら、リモートMacを追加します。
• 重いArchiveを頻繁に実行し、ログインして即時に障害対応したいなら、常駐環境への移行を評価します。
• 物理インターフェースや現地接続が必要なら、リモートMacの前に手元のMacを選びます。

Xcode CloudとリモートMacの役割を比較すると、判断は次のようになります。Xcode Cloudは一時的な検証と標準化された処理に向きます。リモートMacは固定環境、持続するキャッシュ、常駐プロセス、手動の障害調査に向きます。

まず一回の実際のArchiveを分解し、それでも依存関係の準備や固定環境の不足が主因なら、Xcode 27向けリモートMacの構成と負荷確認を確認します。購入前に、必要なXcode版、同時実行数、署名情報の管理方法、接続方法を決めておくことが重要です。

Xcode Cloudだけで十分なのは、軽量なPull Request検証と再現可能なリリース処理です。二本立てが適するのは、Xcode Cloudで軽量検査を続けながら、重いArchiveや常駐処理だけをリモートMacへ移す場合です。重い処理の大半が固定環境に依存するなら、移行候補になります。

Xcode Cloudのまま計算時間を追加する方法は、工程を分けても必要な実行量が変わらない場合には合理的です。しかし、重複したテスト、不要なArchive、依存関係の再準備を残したままでは、待機と消費の問題を先送りするだけです。

現在の構成が一時的なXcode Cloud環境だけの場合、固定版の維持、常駐サービス、失敗時の即時調査、重いArchiveの反復に制約があります。先に一度の実Archiveで停止条件を確認し、それでも固定環境が必要なら、MESHLAUNCHのリモートMac利用の選択肢を比較するのが現実的です。短期の検証やリリース前の集中作業なら、Mac実機を購入して管理するより、必要な期間だけ借りるほうが運用範囲を限定できます。