2026年独占リモート Mac iOS UI 自動化：Maestro 自ホストと Maestro Cloud はどう選ぶ？——Simulator 枠、SSH ヘッドレス GUI セッションと xcodebuild パイプライン並行の再現可能な意思決定マトリクス＋FAQ
独占リモート Mac（SSH ヘッドレス）で Maestro の UI フローを回すとき、自ホスト（maestro test で本機 Simulator）と Maestro Cloud（maestro cloud で .app と flows をアップロードしデバイスプールで実行）の二択になります。本稿は Simulator 枠、SSH ヘッドレス GUI セッション、xcodebuild パイプライン並行の三軸でマトリクスを揃え、FAQ を Runbook に貼れる形でまとめます。XCTest／Swift Testing と UI 層の役割分担は
2026年独占リモート Mac CI：Swift Testing と XCTest 混走、コンパイルと Simulator の SSH ヘッドレス flaky 意思決定
、ホスト型 CI 全体の比較は
2026年 iOS/macOS CI：Codemagic ホスト型パイプラインと独占リモート Mac 自ホスト Runner の選び方
と併読すると構成が揃います。
1. 二つの経路を同じ座標系に置く
Maestro 自ホスト（独占リモート Mac）：テナント専用 macOS に Maestro CLI を入れ、本機の iOS Simulator で YAML flows を実行。成果物は Simulator 向け .app（通常 xcodebuild -sdk iphonesimulator）が前提。並行上限はCPU・メモリ・同時 boot できる Simulator 数と有効な GUI セッションの有無で決まります。
Maestro Cloud：maestro cloud --app-file … --flows … でパッケージと用例をアップロードし、マネージドデバイスプールで実行。機種・OS は Cloud プランと maestro list-cloud-devices の一覧（--device-os、--device-model など）に拘束されます。Cloud 側 Simulator へビルド機から長期 SSH することはできず、排障はアップロードログ・録画・コンソールに寄ります。
よくあるハイブリッドは、PR／日次 UI スモークは Cloud（ファーム保守を省く）、リリース前や xcodebuild と同一 Job の統合 UI は自ホスト（Derived Data や社内 Mock を共有）。同一ブランチで flows の二重管理にならないことが重要です。
2. 三軸意思決定マトリクス（Simulator 枠 · SSH ヘッドレス GUI · xcodebuild 並行）
アーキテクチャレビュー用の一枚表です。Cloud 枠は契約と list-cloud-devices、自ホスト枠は専用機スペック・simctl・launchd 方針が根拠になります。
| 軸 | Maestro 自ホスト（独占リモート Mac） | Maestro Cloud |
|---|---|---|
| Simulator 枠 | 枠≈購入した機械：M シリーズのユニファイドメモリが同時 Simulator 数を規定。並行 Job ごとに UDID・データディレクトリ・ビルド後クリーンアップ（xcrun simctl shutdown 等）を設計する必要があります。 |
枠はCloud 並行スロットと機種在庫。拡張はプラン変更かキュー待ち。ピーク時の機種/OS 組み合わせはプラットフォーム一覧が上限で、物理コアは自前では増やせません。 |
| SSH ヘッドレス GUI セッション | Simulator と Maestro は有効な WindowServer セッションに依存しがち：ディスプレイなしの純 SSH では launchctl asuser、自動ログインユーザ、VNC／画面共有で GUI を維持。さもないと「boot 済みだが UI 自動化がハング」が起きやすい。SSH で boot・録画・log show まで再現できます。 |
本機 GUI セッションの保守不要。運用面は「アップロード＋Cloud 結果ポーリング」。標準化された失敗には向くが、本機 sysdiagnose 必須の難症例には弱い。 |
| xcodebuild パイプライン並行 | 同一 Job 内順序（build → maestro test）やマトリクス Job（複数 UDID）と整合可能。Derived Data・モジュールキャッシュと UI テストで同一ディスクを共有する場合は concurrency やディレクトリ分離が必要。並行 xcodebuild test との Simulator 奪い合いに注意。 |
多くはビルドと UI を分離：CI が .app を出してから maestro cloud。並行度はアップロードキューと Cloud スロット次第。compile Job と並行で壁時計を短縮しやすい一方、成果物サイズと出口帯域は別予算が要ります。 |
3. 独占リモート Mac 自ホストの再現ポイント
3.1 ビルド成果物と flows の単一真源
- iOS の Maestro は Simulator 用
.appが前提。実機.ipaを誤って Cloud／ローカル flows に渡さない。 - flows と
.maestro/は App リポジトリと同じバージョン管理に置き、CI は同一 commit でビルドとテストを走らせる。
3.2 SSH ヘッドレスでの GUI セッション（Runbook 断片）
独占 Mac では「Maestro を実行する macOS ユーザー」と「SSH 運用ユーザー」を分け、launchd ＋ グラフィカルセッションで Simulator を操作可能にします。
- CI 専用ユーザーの自動ログイン、または VNC でセッション確立後に Runner が
maestro testを起動。 - Job 終了時に
simctl shutdown allと一時 Derived Data の削除で、次 Job のディスク・ポート枯渇を防ぐ。 - 「WindowServer なし」系失敗は検索可能なログキーワードにし、flaky 用例と切り分ける。
3.3 xcodebuild 並行の二つの安全モード
モード A（直列・デフォルトで再現性高）：単一 Job 内で xcodebuild build → maestro test。Simulator は Maestro 専用、単体テストは別 Job。
モード B（並行・枠が必要）：コンパイル Job と UI Job を並行するが、UI 側は専用 Simulator UDID と作業ディレクトリを固定。16GB メモリ機で UI を 2 本以上並行する前に必ず負荷試験。Runner プールと並行 TCO は Jenkins SSH ビルドエージェント vs GitHub Actions 自ホスト macOS Runner：並行と TCO 意思決定マトリクス も参照してください。
4. Maestro Cloud が向く境界
- 多機種／多 OSの回帰を回したいが、自前で Simulator マトリクスを維持したくない。
- ビルドノードで恒常 GUI セッションが禁止、または WindowServer を保証できないが UI カバレッジは欲しい。
- アップロード帯域と Cloud 分を払って、Simulator ファーム運用と標準レポートを外注したい。
アップロード前に maestro list-cloud-devices で対象組み合わせがプールにあるか確認。CLI 例（公式ドキュメント準拠）：
maestro cloud \
--device-os "iOS-26-2" \
--device-model "iPhone-17-Pro" \
--app-file build/MyApp.app \
--flows .maestro/5. 自ホスト優先か Cloud 優先か
| シグナル | 傾向 |
|---|---|
| 社内 Mock・証明書・テストデータがテナント境界を越えられない | 自ホスト |
| xcodebuild と同一 Derived Data／同一 commit 成果物で分単位フィードバックが欲しい | 自ホスト |
| SSH で Simulator 状態・録画・システムログをその場で再現したい | 自ホスト |
| 機種マトリクスが広く、ファームと Xcode 小バージョン保守を避けたい | Cloud |
| ビルドノードは厳格に GUI なし、UI テストは compile と強並行で壁時計を奪いたい | Cloud（ビルド後アップロード） |
6. FAQ
Q1：独占リモート Mac で Maestro と xcodebuild test を同時に回せるか？
可能ですが、Simulator は共有リソースです。UI 単体テストと Maestro は Job または UDID で分け、並行度ごとにメモリとディスクを確保しないとランダム timeout が flows の flaky と誤判定されます。
Q2：SSH で手動実行は成功、CI だけ失敗するときの優先確認は？
まず同一 GUI ユーザー・セッションか、環境変数（PATH、DEVELOPER_DIR）、Runner が WindowServer なしで動いていないか。次に前 Job が残した Simulator 占有です。
Q3：Maestro Cloud は独占 Mac を置き換えるか？
コンパイルと署名は置き換えません。Cloud が消費するのはビルド済み .app です。macOS 上の xcodebuild は依然必要で、Cloud は本機 Simulator ファームと一部 UI 並行容量の代替です。
Q4：Simulator 並行上限の見積もり方は？
対象 OS・機種・同時 boot 数で負荷試験し、メモリ圧力と maestro test の P95 を記録。M4 16GB で軽量 UI 2 本はよく通るが、重いアニメーション App は 1 本＋コンパイル直列が安全。ビルド時間の基線は
2026年 Mac レンタルで Xcode ビルド実測
を参照してください。
Q5：ハイブリッドで flows を二重管理しないには？
リポジトリ内単一 flows ディレクトリ。CI はパラメータで maestro test か maestro cloud を切替。Cloud コンソールと Git に別々の用例を置かない。
Q6：実機 UI は Maestro Cloud か？
iOS の Maestro Cloud は主に Simulator パッケージ向け。実機ファームは別能力とコンプライアンス境界です。Simulator スモークだけなら、実機は手動や専用デバイスクラウドに残す設計が現実的です。
Mac mini で Maestro 自ホストを安定させる
独占リモート Mac で Maestro 自ホストを選ぶとき、安定性の半分は flows と CI 編成、もう半分はハードと macOS です。Apple Silicon のユニファイドメモリは複数 Simulator と xcodebuild 並行時のメモリ揺らぎを抑え、macOS ネイティブ Unix 環境は SSH・launchd・simctl・キーチェーンを同一ツールチェーンで閉じます。待機時わずか約 4W の低消費電力と静音は、7×24 の UI テストノードに向き、高消費電力 Windows ワークステーションの電気代やドライバ保守より総コストが読みやすくなります。
「SSH ヘッドレス GUI セッション＋ Simulator 枠＋ xcodebuild 並行」を長期無人でも信頼できる一台に載せるなら、Mac mini M4 は性能・エネルギー効率・TCO のバランスが明確です。独占ビルドと UI 自動化ホストが必要なら、今すぐ Mac mini M4 を手に入れ、本稿のマトリクスを予測可能なハードで回してください。