すでに専用リモート Mac上で xcodebuild archive を安定運用できていても、XCTest + Simulator では並列性、ヘッドレス前提、ときどきの GUI 依存でつまずきます。本稿は Linux でシャードしたテスト と同様のキューイングと分離を macOS で求めるチーム向けです。テスト固有のばらつきを炙り出す 7 項目、ビルド専用 CI とテスト Runner のための意思決定表、そして6 ステップの引き継ぎ Runbookを、Runner・再現可能ビルド・スナップショットと長寿命ノードの各記事と整合する形でまとめます。失敗が製品リグレッションと誤読されないようにします。
リモート Mac はコンパイル中は長寿命ビルドサーバーのように感じられますが、xcodebuild test に入ると CoreSimulator のライフサイクル、Metal とウィンドウ系サービス、多くのコンパイルグラフを上回るメモリスパイクを引き受けます。以下 7 項はプラットフォームチェックリストです。該当が多いほど、テスト用ペルソナをコンパイル用ペルソナから分離すべきサインです。
並列ワーカーと物理コア：計測なしで -parallel-testing-worker-count を上げると Simulator 起動嵐で I/O と RAM が飽和し、キューは健康でも個別テストがタイムアウトします。
UI テストとヘッドレス単体の混在：UI はウィンドウスタックとスクリーンショットに当たり、ヘッドレス大量バッチと GPU を奪い合うと「ローカルは緑、CI ではときどき赤」になります。
既定 DerivedData の衝突：プロジェクト単位のキャッシュルートなしで並列リポジトリ／ブランチを走らせるとモジュールキャッシュが壊れ、ビルドは通るのにテスト解決だけが不可解に失敗します。
非対話セッションでの冷えた CoreSimulator：デスクトップと同じログイン前提を置けない SSH では、最初のバンドル大量起動がまとめて落ち、flaky に見えがちです。
xcode-select と xcrun のズレ：複数 Xcode とユーザー差（runner と開発者）で「simctl はあるのに xcodebuild は別 SDK」になります。
Keychain・プッシュ・ネットワーク権限テスト：TCC プロンプトや対話的 Keychain 解除が必要なケースは CI ではスキップまたはスタブが必要で、さもないと並列プール全体がリトライ嵐になります。
アーティファクトとログの契約欠如：終了コードだけで xcresult もない失敗はシェルでの手探り調査を強い、「VPS のように引き継ぐ」とは逆です。
根本原因は「コンパイルが緑ならテストも安定」と仮定することです。テストはセッションモデル、GPU、RAM スパイク、キャッシュ名前空間に敏感です。台帳に記録し、次の表で同一専用ノードを共有するか、ビルド Runner とテスト Runner に分けるかを決めます。
運用上、XCTest の並列は Linux の pytest -n auto とは別物です。Simulator は安いプロセスプールではなく、イメージ・端末状態・システムサービスを束ねます。レビューにはピーク並列度（キャパシティ）と定常並列度（日次 SLA）の両方を書き、CPU 数だけの調達はメモリ真のボトルネックを隠しがちです。
見落としやすいのがテストデータと外部依存です。固定 localhost ポートのスタブやモックは並列で衝突するため、動的ポートかより強い隔離が必要です。Runner がコンパイルキャッシュをマウントするなら、テストと同じマウント名前空間を共有しないか、「テスト後片付けがコンパイルの温まりを壊す」ことを受け入れるかを決めます。
最後に「flaky」という語を台帳フィールドに置き換えます。失敗テスト名、並列度、端末種別、初回バンドルか定常か、メンテ窓。フィールドがないと無思考リランでクラウド Mac 分を浪費します。下の表はアーキ議論を 1 枚の合意に収めます。
万能解はありません。小規模チームは機械節約で同居し、成長チームはキューを分けてコンパイル側のホットキャッシュを守りつつ、テストは別メモリ曲線を抑えた並列で回します。レビューに 3 つの SLA を書きます：キュー遅延、失敗の説明可能性、リストアコストです。
| 次元 | ビルド＋テスト共有の専用ノード | 分割キュー（2 台目または追加ラベル） |
|---|---|---|
| メリット | 同一ツールチェーンと署名文脈；tarball なしでローカル成果物からテスト | 並列嵐を隔離；コンパイルキャッシュがテスト I/O で飢えない；テスト専用ノードでスナップショット運用が容易 |
| リスク | RAM/GPU 競合；大きな UI バッチが緊急コンパイルホットフィックスを遅らせる | アーティファクト契約とランタイム整合が必要；マルチノードのペルソナ漂移は監査が増える |
| キュー適合 | リリース頻度が低くコンパイル偏重でテスト量は控えめ | コミット率高、シャード多、テスト独立スケールアウト |
| Runner ラベル | 競合ステージを直列化できるなら単一ラベルでも可 | mac-ci-build / mac-ci-test 分割を推奨—Runner 記事参照 |
| リストラ戦略 | 1 回のスナップショットでコンパイルとテスト両方 | テストノードは頻繁にリストア、コンパイルノードは長寿命キャッシュ維持 |
テスト層で「Mac を VPS のように借りる」とは、ノート PC 的なランダム赤ではなく、予測可能なセッションとリソース曲線を買うことです。並列度と SLA を決める前に、テスト負荷を独立したペルソナとして扱います。
エンタープライズビルドプールを運用するなら、クォータ文書でテスト並列度を上限し、署名アーティファクトをハード化パーティションに置いてテストジョブがリリース用 Keychain に触れないようにします。
キュー分割を選ぶ場合はアーティファクト転送契約を更新します。バイナリと dSYM はチェックサム付きオブジェクトストレージ経由か、単一ホスト上ディスクに留まるか。ネットワーク越しなら TLS・検証・リトライをワークフローに焼き込み、さもないと一時的なジッターが「テスト不安定」に見えます。中規模チームは第 2 ボックス購入前にラベル分割＋競合ステージ直列化から始め、干渉が数値で示されたときだけ完全分割します。
スナップショットと長寿命ノードと併読してください。テスト Runner は Simulator 状態の漂移が速いためリストア頻度が上がりがちです。テスト側のリストアループを短くすると、コンパイルキャッシュ寿命を犠牲にせずばらつきを下げられます。
順序が重要です。まずプロファイル、次に並列化、最後に最適化。フィンガープリント取得スクリプトを 再現可能ビルドの記事に揃え、テストが別のドキュメント外環境を増やさないようにします。
Xcode とコマンド接頭辞を固定：CI ユーザーで xcode-select -p と xcodebuild -version を台帳に記録し、テストジョブ内の場当たりパス切替を禁止します。
テスト専用 DerivedData ルート：-derivedDataPath をコンパイルジョブと別の repo/branch バケットへ向け、キャッシュ踏みつぶしを防ぎます。
並列度を意図的に選択：保守的なワーカー数から始め、RAM と simctl 安定性を見てから段階的に上げます。UI とユニットはワークフローまたはステージで分けます。
必要なら Simulator をウォームアップ：空き時間に同一非対話セッションで boot/shutdown カナリを走らせ、初回バンドル失敗率をヘルス指標にします。
観測可能な成果物を強制：-resultBundlePath 等を有効化し、失敗時は要約コンソールと xcresult へのポインタを必ず残します。
リストア頻度に合わせる：大きなアップグレードやイメージ巻き戻し後は、全並列に戻す前に同じカナリスイートを再実行します。スナップショットと長寿命ノードのメンテナンス窓フローとセットで運用します。
#!/usr/bin/env bash set -euo pipefail xcode-select -p xcodebuild -version xcrun simctl list devices available | head -n 40 sysctl hw.memsize hw.ncpu
注記：同一ホストで Fastlane リリースも動かす場合、GPU や Keychain を奪い合うリリース時間帯からテストジョブを外し、メンテナンス窓か厳格ラベルで隔離します。
GitHub Actions などでは「testing」を少なくとも 2 ジョブに分けます。高速ゲート（低並列・クリティカルパス）とナイトリー全行列（高めの並列）です。専用リモート Mac は日中キュー短縮と、ゲート失敗で環境かコードかを早く切り分けられます。timeout-minutes とリトライ方針を文書化し、悪いコミットがキューを塞がないようにします。
Test Plan やタグ付きターゲットに依存するなら、Xcode で最後にクリックされた状態ではなく CI の CLI エントリを固定します。さもないと「ローカルはすべて緑」と「CI はサブセット」が永久に乖離します。エントリコマンドを Dockerfile のようにレビュー可能なインフラとして扱います。
Apple 系で「ヘッドレス」がゼログラフィックを意味することは稀です。多くのチームは素の SSH からすべての UI テストを回すのではなく、不要 UI を止めた固定ログインセッションを運用します。スイートを分類します：純ロジック単体、Simulator が要るが非ウィンドウのフロー、真の UI ドライバ。最後の桶はナイトリーか専用ラベルに置きます。
デバッグではまず同一端末タイプを再現性高く起動できることを示します。起動時失敗はサービス・ディスク・権限、起動後ランダムクラッシュは RAM スパイクや並列度が疑わしいです。SSH と VNCを照合し、VNC は対話トリアージの狭い窓に限定し、恒常的な CI 依存にしません。
警告：「初回許可ダイアログ」系テストをスタブやゴールデンイメージへの一度きり承認の文書化なしで並列 CI に投入しないでください。リストアのたびに大量失敗が再発します。
Metal やカメラ負荷の高いスイートにはリソース段ラベルを付け、対応する専用ノードを予約します。キュー遅延を決めるなら重い UI と大きなヘッドレスバッチを同居スケジュールしないでください。高解像スクリーンショットや動画が製品上必須なら、低頻度パイプラインへ移します。
再現可能ビルドの Keychain 方針に合わせます。テストユーザーとリリースユーザーが異なる場合は、Simulator のみ実行でも最低限の署名素材に届くか検証します。ユーザーを共有する場合はディレクトリと Keychain パーティションを締め、1 件のテスト失敗がリリース資産を汚染しないようにします。
閾値は並列度とスイート構成に合わせて調整してください。ここは整合のためのアンカーであり、ベンダ保証ではありません。
jetsam や Terminated (exit code: 137) が頻出するなら、盲目的リトライの前に並列度を下げます。ノート PC はスリープ・アップデート・ランダムなデスクトップ負荷でテストを壊し、Linux は Apple 公式 Simulator スタックをホストできません。テストを専用・常時稼働・プロファイル済みのリモート Mac に移すと、並列とヘッドレス戦略が「画面ロックを誰が外したか」ではなく契約になります。場当たりハードや騒がしい共有 Runner に比べ、NodeMini の Mac Mini クラウドレンタルは固定 SSH、明瞭なディスク段、反復可能なペルソナで XCTest をプラットフォーム工学に収めます。スペックは Mac Mini レンタル価格で比較し、オンボーディングは ヘルプセンターで仕上げます。
社内「CI 段」を定義して Runbook を運用に落とします：L1 はコンパイルのみ、L2 はゲート付き単体、L3 は Simulator 全量、L4 はナイトリー UI のみ。各昇格には監視ゲートが必要で、プロダクト都合の場当たりスコープではなく、財務と開発が同じキューとコストの物語を読めるようにします。
必須ではありません。成果物を動かさず同一署名文脈にしたい場合は同居します。コンパイルキャッシュがテスト I/O と争ってはいけない場合はラベルまたはホストを分割します。分割後は Xcode バージョンとプロファイル取得元を揃え、偽の「ビルド緑・テスト赤」信号を避けます。
1) xcodebuild コンソール末尾と xcresult、2) CoreSimulator エラー周辺の Unified Log、3) ディスクとメモリ圧力の順です。エスカレーション時は断片を束ね、ヘルプセンターからチケットを起票します。
最重のテストワークフローをカナリホストで実行し、RAM と I/O ピークを取得してから Mac Mini レンタル価格の段にマッピングします。コンパイルに十分な CPU クラスが並列 Simulator に十分とは限りません。