Xcode 27 UI 自動化テストをどう拡張する？2026年、単一Mac、デバイスプール、それともクラウドMac

2026年9月2日時点で、Xcode 27はまだテスト版です。AppleのXcode 27リリースノートも更新される可能性があるため、今週はMacを増やす前に、テストの待ち時間、実行時間、失敗理由を分けて記録してください。Xcode 27 UI 自動化テストは、最初に分割とTest Planを見直し、安定した処理だけを並列化するのが先です。

Xcode 27 UI 自動化テストの容量拡張は、次の順番で判断します。

• テストの無駄が多いなら、分割と再実行範囲を修正します。
• シミュレーター処理が安定しているなら、単一Macの並列化を試します。
• 真機、固定OS、外部機器が必要なら、専用デバイスプールを作ります。
• リリース前だけ処理量が増えるなら、クラウドMacをピーク吸収に使います。
• 多くのチームでは、少数の固定真機と、弾力的なシミュレーター環境の組み合わせが現実的です。

まず今週、テスト容量の基準を作る

最初に、CIの1ジョブを「待機」「ビルド」「シミュレーターまたは真機の準備」「テスト実行」「失敗後の再実行」に分けます。単体、結合、UI、性能テストを一つの合計時間で扱うと、どこにMacを追加すべきか判断できません。

AppleはXCTestの公式ドキュメントで、テストコードを実行する仕組みと用途を説明しています。また、画面操作を伴う検証にはXCUIAutomationのドキュメントがあります。UIテストが遅いからといって、すべてのテストをUI層へ集める設計にすると、Macを増やしても処理量そのものが減らない点に注意が必要です。

記録する項目は、次のように固定します。

• ジョブが待機列に入った時刻
• ビルド開始から終了までの時間
• シミュレーター起動または真機接続にかかった時間
• テストごとの実行時間
• 失敗がアプリ、テスト、署名、接続、環境のどれに該当するか
• 再実行で成功したか、手動復旧が必要だったか

Xcode 27のシステム要件は、正式版やベータ版の更新で変わる可能性があります。導入前にはAppleのXcodeシステム要件とリリースノートを同時に確認し、開発者のMacとCIノードでXcode、macOS、SDKの組み合わせをそろえてください。

次に、UIテストへ回す処理を減らす

画面を起動しなければ検証できない処理だけをUIテストに残します。入力値の検証、状態管理、APIレスポンスの解釈、エラー処理は、より下位のテスト層へ移せる可能性があります。

Test Planでは、対象テスト、実行先、診断設定、再実行の扱いを整理できます。AppleのTest Plan設定ガイドを参照し、プルリクエスト用とリリース候補用でテスト範囲を分けてください。失敗したテストを無条件に何度も繰り返す設定は、待機列を長くし、実際の不具合を見えにくくします。

残すUIテストは、次の条件を優先します。

• 新規ユーザーが必ず通る主要フロー
• 過去に再発した画面上の不具合
• 権限、決済、通知など、画面状態の組み合わせが重要な処理
• 単体テストでは確認できない画面遷移

ここでテスト数を削ることが目的ではありません。高速なフィードバックに不要なUI操作を、適切な層へ移すことが目的です。

単一Macの並列実行を検証する

複数のXCTestを同時に走らせる前に、テスト間で共有しているものを洗い出します。DerivedData、シミュレーターのデータ、キーチェーン、ログイン済みアカウント、固定ポート、モックサーバーが代表的な衝突箇所です。

Appleは過去のXcode並列テストに関する説明で、テストを複数の実行先へ分散する考え方を示しています。ただし、並列化は常に短縮を意味しません。CPUやメモリの圧迫でシミュレーターの起動が遅くなれば、ジョブ数を増やしたのに完了時刻が変わらないことがあります。

まずは次の順で比較します。

1. 同じコミットを串行で実行します。
2. 同じテスト集合を少数の並列ジョブに分けます。
3. 待機時間、実行時間、失敗率、再実行時間を別々に記録します。
4. 失敗したジョブのログとシミュレーター状態を確認します。
5. 並列時だけ増える失敗を、アプリの不具合と環境汚染に分類します。

注意：並列化後に失敗が増えた場合、Macの性能不足と決めつけないでください。共有アカウントや残存したシミュレーター状態を消去して同じ比較を行い、環境依存の失敗かどうかを先に確認します。

拡張方式を比較する

小規模の固定デバイスプールを試す

真機テストが必要な場合は、いきなり大規模な設備をそろえず、代表的なOS、端末、アプリ構成で試験します。XcodeのDevice Hubに関するAppleの説明を確認し、接続端末の登録、状態確認、交換手順を決めておくと、担当者の手作業を減らせます。

固定プールでは、次の状態を標準化します。

• XcodeとmacOSのバージョン
• 署名証明書とプロビジョニング
• テスト用Apple Accountとアプリデータ
• 端末の初期化、再起動、再接続の手順
• USB接続、Wi-Fi、プロキシ、通知などの条件
• ジョブ終了後のログと機密情報の消去

iOSの真機では、カメラ、Bluetooth、プッシュ通知、実際の電源状態など、シミュレーターでは代替しにくい条件を残します。一方、画面レイアウト、一般的な画面遷移、複数OS向けの基本回帰は、再現性を確認したうえでシミュレーターへ寄せます。

固定プールとクラウドMacの使い分け

中部の判断をFAQで確認する

長期運用へ移る前に容量を組み替える

リリース高峰だけ待機列が伸びるなら、固定ノードを増やす前にクラウドMacを接続できる構成を試します。必要なのは、ジョブを受け取る仕組みだけではありません。Xcodeの準備、依存関係のキャッシュ、秘密情報の注入、テストログの回収、終了後の消去までを一連の処理にします。

クラウドMacへ送る候補は、再現可能で、物理端末を必要としないジョブです。コードを持ち出せない規則、ローカル証明書、社内ネットワークへの接続がある場合は、セキュリティ担当と移行範囲を先に決めてください。VPSSparkのサービスと運用方針も、候補環境を比較する際の確認材料になります。

次の条件なら、クラウドMacの優先度が上がります。

• 高峰時だけジョブが増え、平常時の稼働が低い
• シミュレーター用の環境をスクリプトで再構築できる
• Xcodeと依存関係を固定したイメージを用意できる
• ログ、成果物、秘密情報をジョブ単位で分離できる
• 失敗時に自動で環境を破棄して再作成できる

逆に、外部機器、特定の真機、社内限定ネットワークが中心なら、固定プールを残す方が安全です。

最後に、隊列指標で増設と縮小を決める

運用開始後は、待機時間だけを見ないでください。ジョブの利用率、失敗後の再実行、担当者が復旧に使った時間を同時に追います。待機時間が短くても、再実行と手動リセットが増えていれば、容量拡張は成功していません。

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

• 待機が長く、実行は安定している：並列ノードまたはクラウドMacを追加します。
• 実行時間が長く、待機は短い：テスト分割、UI操作、アプリ側の処理を見直します。
• 真機だけが詰まる：真機プールの予約とリセットを改善します。
• 並列時だけ失敗する：共有状態を分離し、ノード追加を止めます。
• 平常時の利用率が低く、ピークだけ増える：固定設備を増やさず、弾力的な環境を検討します。
• 使われないUIテストが多い：履歴のないテストや下位層で代替できるテストを整理します。

開発者のMacには、コミット前の高速な確認だけを残します。安定した基準テストは固定真機へ、複製可能なマトリクス処理は弾力的なMacへ分けると、予約競合と環境汚染を切り分けやすくなります。

現状のMacを買い足す方法は、環境を手元で管理できる反面、初期費用、保守、OS更新、端末のリセット担当が必要です。固定デバイスプールだけに頼ると、リリース高峰以外は遊休化しやすく、機種やOSの変更時には再構成も発生します。こうした短期的な容量不足には、必要な期間だけVPSSparkのクラウドMacを試し、シミュレーター処理を切り出してから固定設備との費用と安定性を比べる方法が適しています。利用地域や期間の候補は日本向けのMac利用プランで確認できます。

正式版の公開後は、代表的なUIテストを再実行し、Xcode、署名、シミュレーター、並列動作が同じ条件で成立するかを再確認してください。最初の一歩は、今週のキュー記録です。Macの台数ではなく、どの処理が本当に詰まっているかを確定してから、固定プールとクラウドMacの比率を決めてください。