2026 マルチリージョンリモート Mac の並列 XCTest／UI テスト容量：
シミュレータ枠、DerivedData のディスク余裕、M4／M4 Pro 対照表

約18分で読めます · MACCOME

ビルド用ホストはシンガポールに置きつつ、オーケストレーションと成果物の出口は米国や EU にある——そんな構成ですか。 本稿は、リモート Mac 上で XCTest のユニットテストと UI テスト を並列化するチーム向けです。「ローカルは緑、CI は赤」をフレークに見せかける六つの誤解、M4／M4 Pro・シミュレータ数・DerivedData のディスク余裕・租期 をひとまとめにした二枚の表、貼り付け可能な xcodebuild フラグ・ディスク確認コマンド・六ステップの Runbook を用意しました。読了後、ワーカー数やディスクアラートのしきい値を説明し、Runner のタイムアウトを調整すべきかリージョンを動かすべきか判断できるようになります。

XCTest 並列化に関する六つの誤解（「並列度を上げるほど不安定が増幅しがちな理由）

  1. CI の赤をすべてフレーク（不安定）なテストとみなすこと： 複数のシミュレータが同じディスク IO と WindowServer の予算を奪い合うと、タイムアウトとアニメーションのアサーションが先に揺らぎます。単一ワーカーでの対照実行なしにハードウェアを増やすと、方向を誤ります。
  2. 並列度を CPU コア数にそろえること： Xcode のテストランナーとシミュレータ起動は RAM のスパイクとファイル記述子を伴います。UI スイートを並列実行 する場面では、M4 と M4 Pro の差がスワップのスラッシングなしに済むかどうかとして現れます。
  3. DerivedData と CoreSimulator の合算増加を無視すること： 並列ビルド一つで中間生成物が広がります。空き容量がおおよそ 10% を切ると、きれいな ENOSPC が出る前にメタデータ書き込みが詰まります。
  4. xcodebuild だけをいじり Runner のタイムアウトを無視すること： 並列度が上がると JUnit のアップロード、キャッシュ同期、成果物処理が列に並びます。RTT が倍になると、アサーションではなくテスト後のステップで失敗が出ます。
  5. クリーンアップ方針なしに一台のホストを共有すること： 混在プロジェクトは古いデバイスデータと孤児プロセスを残します。シミュレータの起動時間が階段状に伸び、「環境ドリフト」に見えます。
  6. ヘッドレス CI の UI テストを対話デバッグと同一視すること： 無人実行では待機・スクリーンショット・ログ取得を厳格化する必要があります。目の前で動くスイートが、並列 CI では競合します。

次にメモリ・ディスク・ネットワークを一枚の地図にし、パラメータ化した表に落とし込みます。

リモート Mac での並列テストのリソース座標（RAM、ディスク IO、WindowServer、ネットワーク）

並列ユニットテスト は CPU と RAM のピークを押します。ディスク書き込みは DerivedData のインデックスとビルド成果物に集中します。キャッシュが温まっていると、リンクのバーストとプロセス数が生の GHz より先に上限になります。並列 UI テスト はシミュレータの描画、WindowServer、一時ファイルを足します。N 本目の並列レーンでテールレイテンシが膨らむと、スピードアップは線形ではなくなります。

DerivedData の増え方はモジュールキャッシュ、並列コンパイル、クリーンの頻度に追従します。ディレクトリサイズとビルド頻度を月額だけでなく FinOps の信号として追跡してください。クロスリージョンの経路 はローカルディスク要件を緩めませんが、結果とログのテールレイテンシを増幅します。「xcodebuild は成功」と「パイプラインのステップは成功」を分けないと、切り分けの層を誤ります。

Runner のラベルと並列度 の記事、および 再現可能なビルドと DerivedData のチェックリストと併読してください。ジョブの振り分け、ビルドルートの固定、シミュレータ数の上限は別々のつまみです。

観点Mac mini M4（基準）Mac mini M4 Pro（高並列向け）
想定用途ユニットテスト 2〜4 ワーカー程度。UI は並列度を下げるか時間分割するユニットテスト 4〜8 ワーカー程度。UI の並列度はソークテストのあとで引き上げる
メモリ負荷の兆候スワップ、シミュレータ起動の遅化、負荷時の UI のもたつき同じ並列度ではスワップが起きにくい。ディスク IO が先に頭打ちになることもある
ディスク指針512 GB はブランチが増えるとすぐ逼迫しがち。並列＋多ブランチなら 1 TB を計画する並列 UI と複数 Xcode 版なら 2 TB を優先するか、クリーンアップを積極的に行う
向き小〜中規模リポ、ユニット中心、夜間に一度まとめて実行大規模モノレポ、UI パック多数、PR ビルドが頻繁
レンタルとの組み合わせ月額のベースラインに、リリース週だけ短いバーストを足す月額／四半期のロックでピーク時の取り合いを避ける

レーンの切り方：ユニット並列、UI 並列、混在パイプライン

UI 付きの xcodebuild test では、コンパイルの並列度 と テストの並列度 を切り離します。ビルドでは -parallelizeTargets を上げられますが、-parallel-testing-enabled と -maximum-parallel-testing-workers は別途ソークテストが必要です。GUI での切り分けが必要なら、高い UI 並列を 24 時間 WindowServer に貼り付けたままにせず、SSH と VNC のガイド に沿って短い対話ウィンドウを確保する運用と組み合わせます。

シナリオ並列戦略リモート Mac での追加確認
純ユニット、短いスイート中程度のワーカー を RAM ピークに対してサンプリングするDerivedData の増加カーブを監視する
重い UI テスト低並列＋キューイングする時間帯。必要ならスキーム分割シミュレータのクリーンアップと WindowServer 再起動の方針を文書化する
モノレポ、多ブランチRunner ラベルで隔離し、DerivedData ルートを分けるシークレットと並列上限を Runner チェックリスト と整合させる
グローバルチーム、ログ出口が遅いローカルのテスト並列度は維持し、集計／アップロードを抑制するHTTP／SSH のタイムアウトと再試行を調整し、マルチリージョンのレンタルガイド でリージョンを見直す
夜間フルマトリクス＋日中 PR夜は高並列、日中は main を守るガードをかけるオフピークにディープクリーンをスケジュールする
xcodebuild
# 例：並列テストワーカー数の上限（プロジェクト／機器ごとに調整し、そのままコピーしないでください）
xcodebuild test \
  -scheme YourScheme \
  -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.4' \
  -parallel-testing-enabled YES \
  -maximum-parallel-testing-workers 4 \
  -resultBundlePath ./TestResults.xcresult
bash
# DerivedData／Simulator の使用量確認（しきい値はディスクに対する割合など、各自で設定）
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null
df -h /
info

注意： 単一ワーカー時の基準線と現在の並列度を並べて——合計時間、テストごとの P95、ピーク RAM、ディスク書き込み——を取得してから、調整完了と宣言してください。

並列テスト容量を Runbook に落とし込む六ステップ

  1. Xcode とシミュレータランタイムを固定する： 本番系の列車に合わせ、ビルド番号を記録します。バージョンの漂いは比較を無効にします。
  2. 単一ワーカー基準線： フルスイート時間、ピークメモリ、DerivedData の増分、失敗テストを記録します。
  3. 2→4→6 と段階負荷をかける： -maximum-parallel-testing-workers を変え、各段階で連続三回のグリーンを条件にします。
  4. ディスクのガードレール： 例として、システムボリュームの空きが 15% を下回ったら並列レーンを中止し、無言のハングを避けます。
  5. クロスリージョンのタイムアウトを揃える： 接続、結果アップロード、キャッシュ同期のタイムアウトを分け、どれが先に発火したかをログに残します。
  6. フレークを週次でレビューする： 「リソース競合の疑い」と「論理のフレーク」に分け、後者だけをテストバックログに入れます。

アーキテクチャレビューに載せたい三つのメトリクス

  1. 並列効率 R： 同一 Xcode・同一スイートでの直列ウォールタイム ÷ 並列ウォールタイムです。R がワーカー数から大きく離れていれば、IO か WindowServer がボトルネックです。
  2. ディスクの傾き： PR あたり、またはナイトリーあたりの DerivedData＋CoreSimulator の増分です。2 TB やキャッシュ方針の根拠にします。
  3. 出口の失敗率： 「テストは緑だがパイプラインは赤」を別カウントします。リージョンと相関するなら、テスト並列を上げる前に配置かアップロード戦略を直します。

ノード選定、Runner、ゼロトラスト接続との組み合わせ

本稿は 一台のリモート Mac で並列テストをどこまで押すか に答えます。マルチリージョンのノードガイド は ホストをどこに置くか、ゼロトラスト接続のチェックリスト は トラフィックがどう届くか に答えます。読む順序は、リージョンと租期 → 接続と Runner → 並列テスト容量とし、不安定な経路の上に並列度を積み上げないでください。

「ノート PC で並列」が専用リモートホストの代わりにならない理由

ノート PC はスリープ方針、コンシューマ向けネットワーク、パッチの漂いを引き継ぎ、チーム SLA には不向きです。並列度を上げると、CI ワーカーとして設計されていない機器の熱とディスク負荷が増えます。専用のリモート Mac は実行を個人端末から契約上切り離し、自動化の面を安定させます。

リージョン配置、ピーク時のレンタル統制、OpenClaw のような長寿命エージェントと共有するクリーンなホスト が必要なとき、MACCOME のクラウド Mac で並列テストを走らせる方が、不安定なノートにワーカーを積み上げるより承認を得やすいです。まず 料金 を確認し、主要ユーザーに合わせて シンガポール、東京、ソウル、香港、米国東海岸、米国西海岸 から注文へ。接続の切り分けは ヘルプセンター の SSH やトンネルの項目を参照してください。

よくある質問

M4 で安全に始められる並列度はどのくらいですか？

インターネット上の定番値をそのままコピーするのではなく、ソークテストで確認します。まずはワーカー 2 から始め、RAM とディスクをサンプリングしてから、上の表を手がかりに段階的に増やします。レンタル階層の比較は Mac mini レンタル料金 ページで行ってください。

DerivedData がほぼ一杯のとき、最初に何を変えればよいですか？

無言のハングを避けるため並列度を下げ、続けてクリーンアップを実行します。ディレクトリ境界は 再現可能ビルドと DerivedData のチェックリスト に合わせてください。

CI は失敗するのにローカルは成功します。どこを調べればよいですか？

アップロードや集計のタイムアウトとテスト失敗を切り離して調べます。ノード配置は マルチリージョンのノードガイド で検証してください。

フレークが急増しました。すぐにマシンを増やすべきですか？

単一ワーカーでの対照実行とリソース監視により、競合由来の不安定さを除外してから判断します。コア追加や M4 Pro／2 TB へのアップグレードはその後の選択肢です。