要点
- 理由1（コンテキスト）：ベアメタル Mac サーバーは DerivedData、Pods インデックス、CI Keychain を長期保持できる。共有クラウド VM はセッションごとに状態を消すため、毎回コールドスタートになる。
- 理由2（実行）：Apple Silicon 実機には仮想化オーバーヘッドがなく、
xcodebuild archiveと codesign の所要時間が安定する。クラウド VPS では隣接テナントの IO 競合で「CPU は低いのに極端に遅い」状態が起きる。 - 理由3（権限）：専用ホストはセルフホスト Runner、ネットワーク分離、証明書ポリシーを自前で管理できる。時間分割 VM では複数 Team ID やコンプライアンス監査に対応しにくい。
- 本当の分岐点は「クラウド vs ローカル」ではなく、共有 VM vs 専用ベアメタル。多くのベンダーが両方を「クラウド Mac」と呼ぶ。
- 1日5回以上のビルドやリリース週の SLA があるなら、まず日単位のベアメタル PoC で warm archive の中央値を記録し、週/月契約を判断する。
- Xcode Archive のボトルネック、3倍コンパイル最適化、codesign 実践の詳細は、文末の同クラスター記事を参照。
リモート iOS ビルドが「クラウド VM」制限に当たる理由
チームにローカル Mac がない、または 7×24 の自動パッケージングが必要な場合、リモート iOS ビルドはほぼ避けられない選択になる。多くのプロバイダーが「クラウド Mac」「Mac クラウドホスト」「Mac VPS」など同じカテゴリとして販売している。月額は数十ドルから数百ドルまで幅があり、セールスコピーも似通っている。しかしリリースがスムーズかどうかを決めるのは、月額料金ではなく、基盤が共有クラウド VMかどうかであることが多い。
共有クラウド VM の典型的な制限には、セッション終了時のユーザーディレクトリ消去、ビルド間で残せない DerivedData、複数テナントによるディスク inode クォータと書き込み帯域の奪い合い、Apple 仮想化フレームワークに対するハイパーバイザー層の不完全なサポート、隣接テナントが大規模な Flutter pod install やシミュレーター群を同時実行しているかの不可視性がある。結果として、同じ xcodebuild archive コマンドが火曜は8分、木曜は22分かかる。「ネットワーク」や「Xcode のアップデート」のせいにしがちだが、実行環境が物理的に専用かどうかを問うことは少ない。
対照的に、ベアメタル Mac サーバー（ホスト型 Mac mini / Mac Studio、arm64 ネイティブ、時間分割なし）は CPU、ユニファイドメモリ、NVMe を丸ごと提供する。オフィスのビルドマシンのように運用できる：DEVELOPER_DIR を固定し、DerivedData を長期マウントし、CI 専用 Keychain を構成し、launchd 経由でセルフホスト runner を登録する。調達文書では「bare metal Mac」「dedicated Mac mini hosting」と表記されることもある。「4 vCPU クラウド Mac」とは別物だ。
- 誤解 A：リモートで macOS に SSH できれば iOS CI に使える。
- 誤解 B：共有 VPS の月額は安いが、エンジニアの待ち時間とリリース再試行のコストを無視する。
- 誤解 C：GitHub Actions ホスト macOS とセルフホストベアメタルはどちらも「クラウド」なので区別不要。
- 誤解 D：仮想化 Mac と Apple Silicon ベアメタルを同等とみなし、
sysctlや性能ベースラインを確認しない。 - 誤解 E：リリース週に共有ノードを追加するが Xcode / CocoaPods バージョンを固定せず、キャッシュをすべて無効化する。
リモート iOS ビルドの失敗の多くは「Mac がない」ことではなく、共有クラウド VM を再利用可能なビルドコンテキストとして扱っていることから生じる。
ベアメタル Mac サーバーを選ぶ3つの核心理由
以下の3理由は、五軸比較表の Context（コンテキスト）、Execution（実行）、Permission（権限） に対応する。調達の硬い基準として使い、vCPU 数と月額だけで判断しないこと。
理由1：永続的な実行コンテキスト——「毎回 CI がコールドスタート」を卒業する
iOS / Flutter のビルド速度は再利用可能なコンテキストに大きく依存する：DerivedData 内のモジュールグラフ、CocoaPods のローカルインデックス、Swift 増分コンパイル状態、ロック解除済み CI Keychain。ローカル MacBook で7〜9分の warm archive が、共有クラウド VM では18〜25分に膨らむのは、コンテキストが使い捨て扱いになるためだ。各ジョブが新しい一時ディレクトリを作り、夜間メンテで ~/Library が消え、キャッシュ復元がキーのドリフトで miss する。
ベアメタル Mac サーバーでは書面で永続パスを約束できる。例：/Users/ci/DerivedData/MyApp と固定 Pods/ ディレクトリ、ワークフローで -derivedDataPath を明示的に渡す。リリース週は不要な flutter clean を禁止し、10回の warm 実行の中央値を意味のある指標にする。これは対話型開発向けの「リモート Mac デスクトップのレンタル」とは異なり、パイプライン SLA の話だ。Archive 段階の詳細は Xcode Product → Archive：CI が止まる理由と全パイプライン を参照。
理由2：Apple Silicon 実機性能——ハイパーバイザー税と隣接 IO からの解放
2つ目の理由は予測可能な実行。Apple Silicon のユニファイドメモリは、大規模 iOS プロジェクトのリンク、並列 swiftc、Xcode インデックスに敏感だ。共有クラウド VM は「M シリーズ」と謳ってもハイパーバイザー負荷を払い、ディスク書き込み帯域を保証できない。隣接テナントのバックアップや DerivedData 全量リビルドが見えない IO キューを作る。
専用ベアメタル Mac サーバーでは、xcodebuild archive の CPU/IO 曲線はオフィスの Mac mini に近い。ピークはピークであり、CPU 30% のまま20分 IPA が出ないことはない。リリース週に複数 flavor とターゲットを並列化するチームにとって、この安定性は紙の vCPU 倍増より重要だ。warm パスが壁時計時間をどこまで圧縮できるかは、Xcode ビルド最適化：ベアメタルレンタルで iOS パッケージを3倍速く のベンチマーク手法で自前の中央値と比較する。
理由3：署名・ネットワーク・コンプライアンス境界を自前で管理
3つ目は、複数 Team ID、外注並行、金融/医療コンプライアンスが絡むまで過小評価されがちだ。iOS リリースチェーンは codesign、notarytool、Provisioning Profile、Keychain 設定が長期に安定している必要がある。共有クラウド VM は root 制限、カスタムファイアウォール禁止、テナント間での出口 IP 共有がありうる。最良でも署名スクリプトが毎回 Keychain を再構築し、最悪では Apple 側のリスク管理が発動する。
ベアメタル Mac サーバーはセルフホスト runner、専用 CI ユーザー、VLAN または SSH トンネル分離、プロジェクト単位の証明書ストレージをサポートする。「誰が archive を起動できるか」「署名素材がどのマシンにあるか」を監査文書に書ける。サードパーティ SaaS のブラックボックスに秘密をアップロードする必要はない。Keychain と公証の実践は Apple Silicon クラウド Mac での iOS CI codesign と公証 を参照。
5案×5軸：Entry / Execution / Context / Cost / Permission
下表で「共有クラウド VM からベアメタル Mac サーバーへ移行すべきか」を判断する。ヘッダーは統一し、調達とアーキテクチャレビューで同じ視点を共有する。
| 選択肢 | Entry | Execution | Context | Cost | Permission |
|---|---|---|---|---|---|
| ローカル MacBook | 導入摩擦ゼロ | warm 時は非常に高速；蓋を閉じると停止 | DerivedData 永続 | ハードウェア sunk cost | 個人 Keychain；監査証跡が弱い |
| GitHub Actions ホスト | YAML で素早く開始 | コールドスタートのばらつき；キュー待ち | キャッシュ miss が多い | 分単位；大規模リポは高額 | 毎回署名を bootstrap |
| 共有 Mac VPS（クラウド VM） | 低月額 | 隣接 IO ノイズ；所要時間が不安定 | よく消去；warm 維持が困難 | 表示価格は低い；待ち時間の隠れコスト大 | SSH は可；排他性は保証なし |
| ベアメタル Mac サーバー（専用） | 日単位 PoC + SSH | archive 中央値が安定 | DerivedData / Keychain を永続可能 | 日/週レンタルが柔軟 | セルフホスト runner；ポリシー自控 |
| Xcode Cloud | App Store Connect 連携 | 標準化；カスタマイズ制限 | Apple 管理のキャッシュ | コンピュート単位課金 | ASC に強く紐づく |
クラウド VM 制限の本質は、Context・Execution・Permission の三列が同時に失点することだ。
シナリオマトリクス：ベアメタルが必須になるとき
| チーム像 | 1日のビルド頻度 | 署名の複雑さ | 推奨 | 理由 |
|---|---|---|---|---|
| 個人開発者 | <3回/日 | 単一証明書 | ローカル Mac または Xcode Cloud | コンテキストは既にローカル；リモート化の利益小 |
| Windows + Flutter チーム | 5〜20回/日 | 複数 flavor | ベアメタル単一ノード | リモート iOS ビルドに warm DerivedData が必要 |
| 外注・複数プロジェクト | ピーク30回以上 | 複数 Team ID | ベアメタル双ノード | 権限分離 + ビルド/テスト分離 |
| 偶発検証のみ | 週1〜2回 | シンプル | 共有 Mac VPS で可 | 低コスト；コールドスタート許容 |
| 規制産業（金融/医療） | 中程度 | 監査 / HSM | ベアメタル + ネットワーク分離 | Permission 列は自前管理が必須 |
「Windows + Flutter」「外注・複数 Team ID」「コンプライアンス」のいずれかに当てはまるなら、共有クラウド VM は補助ノードにとどめ、唯一のリリース runner にすべきではない。
推奨スタック A / B / C
スタック A：ホスト型 CI + パス最適化（検証フェーズ）
GitHub Actions を継続しつつ -derivedDataPath を強制、Podfile.lock を固定、署名ジョブを分割。1日5回未満で製品方向を検証中のチーム向け。一部のクラウド VM 制限は緩和できるが、ベアメタル級の Context 永続には届かない。
スタック B：単一ベアメタル Mac セルフホスト runner（スイートスポット）
専用 M シリーズを1台レンタルし、launchd Runner を導入、DerivedData を永続化。Windows/Linux 開発者は Git push でリモート iOS ビルドを起動。多くの中小チームの主経路——中古 Mac クラスター購入よりコスパが良いことが多い。
スタック C：双ベアメタルノード + 署名専用ホスト（リリース週）
ビルドと署名/公証を分離するか、2台目を XCTest 専用にし、16GB 単機の swap を回避。クランチ時は hotfix 用に3台目を日単位で追加。壁時計 SLA と並列ブランチが厳しいチーム向け。
よくある誤解：ベアメタルでも直せないこと
- 落とし穴1：ベアメタルを借りたのに毎 CI で DerivedData を全消去——意図的にコールドスタートを選んでいる。
- 落とし穴2：物理的排他性の書面確認がなく、実は共有ホスト上の VM のまま。
- 落とし穴3：月額だけ比較し、エンジニアの待ち時間とリリース再試行を計上しない。
- 落とし穴4：リリース週に runner で
brew upgradeXcode し、キャッシュと署名チェーンを無効化。 - 落とし穴5：16GB 単機でシミュレーターと archive を同時実行し swap で「ベアメタルはダメ」と結論。
- 落とし穴6：リモートデスクトップの快適さを CI 能力と誤認し、10回の archive 中央値で検収しない。
7ステップ検証チェックリスト（購入前）
- 排他性を書面確認：arm64 ベアメタル（時間分割 VPS ではない）、ディスククォータ、DerivedData 長期保持の可否を要求。
- 現環境のベースライン：現行環境（共有クラウド VM 含む）で10回の archive 各段階時間を記録。
- 日単位 PoC レンタル：ベアメタル Mac サーバーを1週間借り、本番と同じワークフローを展開。
- パス固定：永続
DerivedData、-derivedDataPath、CI Keychain ロック解除ポリシーを設定。 - 署名フルチェーン：codesign → notarytool → TestFlight アップロードを end-to-end で実行。
- 中央値比較：PoC 前後で10回 warm 実行の中央値を比較——最速/最遅の1回だけで判断しない。
- 契約期間の確定：1日8回超で PoC の節約が明確なら、週/月契約と2台目を検討。
FAQ
クラウド Mac とベアメタル Mac サーバーの違いは？
「クラウド Mac」は共有 VM を含むカテゴリ名の場合がある。ベアメタル Mac サーバーは CPU・メモリ・SSD が他テナントに先取りされない専用 Apple Silicon 実機で、DerivedData 永続と安定署名が必要なリモート iOS ビルドに適する。
共有 Mac VPS でリモート iOS ビルドはできる？
軽い検証なら可能だが、主リリース runner には不向き。共有 VPS はディスク消去、隣接 IO 奪い合い、archive 時間の激しいばらつき、Keychain と DerivedData の長期保持の困難が多い。
ベアメタル Mac サーバーは GitHub Actions より高い？
分単位のホスト CI はコールドスタートと大規模リポで隠れコストが大きい。リリース週の日/週専用ベアメタルレンタルは有利なことが多く、warm archive 中央値はローカル Mac に近づく。
開発環境が Windows のみの場合は？
Windows でコードを書き、SSH または CI でリモートベアメタル Mac の archive と codesign を実行。重要なのは時間分割 VM ではなく専用ノードを選ぶこと。Windows のみで iOS 開発する6つの実証済みアプローチ を参照。
ベンダーが共有クラウド VM を売っているか素早く見分けるには？
物理的排他の保証、特定ディレクトリの長期保持可否、同一ホストのマルチテナント、性能 SLA の有無を質問する。書面回答がなければ共有 VPS リスクとして評価する。
ROI はいつ見える？
1日8回超のビルドで、各 CI がローカル比10分以上長いなら、1週間の PoC で明確な節約額が出ることが多い。リリース週は日単位課金でキャパシティを追加すればよい。
まとめ
リモート iOS ビルドにベアメタル Mac サーバーを選ぶのは、「よりクラウド」や「より高い」ためではない。共有クラウド VM 制限による三つの損失——Context が残らない、Execution が予測できない、Permission が監査できない——を避けるためだ。専用 M シリーズ + 永続 DerivedData + セルフホスト runner が、オフィスビルド Mac の経験を製品化する最短経路である。
- 調達時は vCPU と月額より先に Context と Permission を問う。
- 10回 warm archive の中央値で検収——幸運/不運の1回で決めない。
- スタック B が多くのチームに適合；リリース週はスタック C へ。
次のステップ：7ステップ日単位 PoC チェックリストを完了し、下記クラスター記事で Archive と署名のボトルネックを一気に解消する。
リモート iOS ビルド用の専用ベアメタル Mac が必要ですか？
kvmboot は専用 Apple Silicon ベアメタルホストを日/週/月単位で提供——SSH、セルフホスト runner、共有クラウド VM の消去と IO 競合を避ける長期 DerivedData パスに対応。Windows/Linux チームはコードをローカルに置き、archive と署名を warm 可能な M シリーズノードに任せられる。