なぜこの比較を行ったのか
iOS 開発の現場では「ビルドが遅い」がほぼ共通の悩みです。Swift のフロントエンド意味解析、モジュール依存グラフの構築、大規模バイナリのリンク処理——どれも CPU とメモリを大量に消費します。個人開発者にとって最も身近な開発機は MacBook Air。軽くてバッテリー持ちも良い一方、8 GB メモリとファンレス設計では、Xcode のフルビルドに耐えきれないことが多いのが実情です。
クラウド Mac のレンタル自体は新しい話ではありませんが、市場には仮想化インスタンスや共有ホストも混在し、スペック表と実際のビルド体験にギャップがあるケースも少なくありません。ZilCloud が提供するのは物理 Mac mini M4 の専有利用——仮想化レイヤーなし、オーバーセルなし。公式スペックどおり：10コア CPU（パフォーマンスコア 4 + 効率コア 6）、16 GB ユニファイドメモリ、256 GB NVMe SSD、1 Gbps 専有パブリック帯域です。
ここで明確にしたい問いはこうです：ローカル PC を買い替えずに、ビルドだけクラウド M4 ノードに移せばどれだけ速くなるのか？日常の開発ループはスムーズになるのか？コストと体験のバランスは取れるのか？ 以下の数値はすべて同一テストマシン・同一スクリプト・同一 Xcode バージョンで取得したもので、再現可能です。
ローカル機：MacBook Air 15インチ（M2、8コア CPU、8 GB ユニファイドメモリ、512 GB SSD）、macOS 15.4、Xcode 16.3、室温約 26°C、電源接続でビルド。
クラウド機：ZilCloud シンガポールリージョン Mac mini M4（10コア CPU、16 GB ユニファイドメモリ、256 GB SSD、1 Gbps 専有帯域）、macOS 15.4、Xcode 16.3、決済後およそ 4 分で開通、SSH + ブラウザ VNC で接続。
テストプロジェクトと計測方法
テスト対象は実運用レベルの SwiftUI アプリ（以下 RetailApp）です。規模は次のとおりです。
約 186 個の Swift モジュール（ローカル Swift Package 3 個、CocoaPods 依存 2 個を含む）、1,240 超のソースファイル、Release 構成でのリンク成果物は約 84 MB。Swift 6 の厳格な並行性チェック、SwiftLint と SwiftFormat のビルドフェーズスクリプトを有効にしています。個人開発の文脈ではすでに「中〜大規模」に入り、8 GB マシンではクリーンビルド時に明確なメモリ圧迫が発生します。
統一ビルドコマンド
GUI 操作の差を避けるため、計測はすべてコマンドラインの xcodebuild で行い、/usr/bin/time -l で実時間とピークメモリを記録しました。
# Clean build folder first
xcodebuild -project RetailApp.xcodeproj \
-scheme RetailApp \
-configuration Release \
-destination 'generic/platform=iOS' \
clean build \
CODE_SIGNING_ALLOWED=NO \
| tee /tmp/xcodebuild.log
# Wall-clock timing wrapper
/usr/bin/time -l xcodebuild -project RetailApp.xcodeproj \
-scheme RetailApp \
-configuration Release \
-destination 'generic/platform=iOS' \
build CODE_SIGNING_ALLOWED=NO各マシンでテスト前に sudo purge を実行してファイルキャッシュをクリアし、クリーンビルドを 3 回連続実行して中央値を採用。インクリメンタルビルドは単一の View ファイル（約 120 行の SwiftUI コード）を変更したあと build（clean なし）を 3 回実行し、同様に中央値を取りました。テスト中は Spotlight インデックスとその他のバックグラウンドアプリを停止。ローカル機は低電力モード OFF、ファン挙動は powermetrics でサンプリングしています。
リモートビルドワークフロー
クラウドノードでは git clone でコードを取得（リポジトリ約 380 MB）、依存関係は pod install と swift package resolve をクラウド側で実行——両端のビルド環境を揃えています。日常開発では SSH でクラウド上の xcodebuild を直接叩くか、MacBook 上の VS Code Remote SSH でコードを編集し、ビルドコマンドだけクラウドで実行する形が現実的です。ローカルはコーディングとログ確認に専念できます。
クリーンビルド（Clean Build）の実測データ
クリーンビルドは差が最も出やすいシナリオです。Derived Data キャッシュがなく、Swift フロントエンド・Clang バックエンド・リンカがフル稼働します。以下は 3 構成の中央値（ローカル対照として同僚の MacBook Pro M3 Pro 18 GB も併記。「ローカル買い替え」参考用）：
| テスト機 | クリーンビルド時間 | ピークメモリ | ビルド中 CPU 平均 | クラウド M4 比 |
|---|---|---|---|---|
| MacBook Air M2 · 8 GB（ローカル） | 21 分 34 秒 | 7.6 GB + 4.2 GB swap | 68%（頻繁にスロットル） | 2.18× 遅い |
| MacBook Pro M3 Pro · 18 GB（対照） | 11 分 52 秒 | 14.1 GB | 91% | 1.20× 遅い |
| ZilCloud Mac mini M4 · 16 GB（クラウド） | 9 分 54 秒 | 13.8 GB | 94% | 基準 |
クラウド M4 は MacBook Air M2 より約 2.18 倍速く、M3 Pro 18 GB の MacBook Pro よりも約 20% 速い結果でした。差の要因はチップ世代だけではありません。Air の 8 GB メモリはビルドピーク時に 4.2 GB のスワップを発生させ、powermetrics ではパフォーマンスコアがビルド 6 分目以降、温度壁により 3.4 GHz から約 2.6 GHz まで低下。一方 Mac mini M4 はデータセンター環境の散热条件下で高クロックを維持し、10 コア利用率はほぼフル、16 GB ユニファイドメモリは swap ゼロでした。
体感として、ローカル Air でクリーンビルドを走らせると 2 分以内にファンが最大回転に達し、キーボード周辺が明らかに熱くなり、その間は快適にコーディングを続けるのが難しくなります。クラウドビルドなら処理はすべてリモート側で、ローカルは静音・低温のままドキュメント閲覧やビデオ会議に集中できます。
インクリメンタルビルドと日常の開発ループ
日常開発ではクリーンビルドよりインクリメンタルビルドの頻度が圧倒的に高い。SwiftUI の View ファイルを 1 つ直して再ビルド——「開発ループが快適か」を測るうえでより実践的な指標です。
| シナリオ | MacBook Air M2 | MacBook Pro M3 Pro | ZilCloud M4 クラウド |
|---|---|---|---|
| 単一 View ファイル変更後 build | 4 分 18 秒 | 2 分 06 秒 | 1 分 42 秒 |
| Swift Package モジュール追加 | 7 分 52 秒 | 4 分 11 秒 | 3 分 28 秒 |
| Bridging Header 変更（広範囲再コンパイル） | 12 分 44 秒 | 6 分 33 秒 | 5 分 19 秒 |
| ユニットテスト並行（build + test） | 9 分 06 秒 | 5 分 22 秒 | 4 分 37 秒 |
インクリメンタルビルドの差はクリーンビルドより小さめですが、クラウド M4 はすべてのシナリオで先行しています。特に Bridging Header の変更のような「一点変更が全体に波及する」ケースでは、Air では約 13 分かかるのに対しクラウドでは 5 分 19 秒。Objective-C ブリッジ層を頻繁に触るレガシー移行プロジェクトでは、この差がそのまま生産性に直結します。
クラウドで初回 clone したあと、Derived Data の保存先をローカル SSD パスに固定することをおすすめします（defaults write com.apple.dt.Xcode IDECustomDerivedDataLocation ...）。キャッシュヒット率が上がるほどインクリメンタルビルドはさらに短縮されます。今回のテストでは 3 回目のインクリメンタル build が最短 1 分 18 秒まで到達しました。
発熱・騒音・安定性
ビルド性能は「数秒速い」だけの話ではなく、マシンが長時間フルパワーを出し続けられるかも重要です。2 時間連続で 15 分おきにクリーンビルド（計 8 回）を走らせ、安定性を記録しました。
| 指標 | MacBook Air M2 | ZilCloud Mac mini M4 |
|---|---|---|
| 8 回クリーンビルドの時間劣化 | 21:34 → 26:12（+21%） | 9:54 → 10:08（+2%） |
| 筐体ピーク温度 | 46.8°C（キーボード付近） | 38.4°C（データセンター環境） |
| ファン騒音（主観） | 常時最大回転、約 42 dB | ファンレス（パッシブ散热） |
| ビルド中のローカル作業可否 | 明らかなカクつき、マルチタスク困難 | ローカル機は完全に影響なし |
| 8 回中の SSH / VNC 切断 | — | 0 回 |
MacBook Air は連続ビルド負荷下で明確なサーマルスロットリングが発生。8 回目は 1 回目より 21% 遅く、swap 使用量も 4.2 GB から 6.1 GB へ増加しました。クラウド Mac mini M4 の 8 回のばらつきは 2% 以内——ZilCloud が謳う 99.9% SLA の期待値と整合します。長時間 CI やバッチ Archive を回すシナリオでは、安定性そのものが生産性です。
シミュレータと Archive パッケージング
通常の build 以外に、開発者がよく使う 2 つのシナリオも計測しました。
iOS シミュレータ起動 + インストール：クラウド M4 で iPhone 16 Pro シミュレータを起動し RetailApp Release パッケージをインストール。xcrun simctl boot からアプリ初画面表示まで約 38 秒。同操作を Air M2 で行うと約 52 秒で、シミュレータ稼働中のメモリ占有でローカル環境がさらに窮屈になります。ブラウザ VNC でシミュレータ画面を直接確認でき、UI のざっとした確認に向きます。アニメーションの細かいデバッグには RealVNC などの専用クライアントがおすすめです。
Archive と IPA エクスポート：クラウドで xcodebuild archive + -exportArchive の合計 14 分 22 秒（コード署名込み）。Air M2 では 28 分 51 秒。署名証明書は Keychain からエクスポートしてクラウドノードにインポートすれば、手順はローカルと同じです。エクスポートした IPA は scp でローカルに戻すか、そのまま TestFlight にアップロード。シンガポールリージョンから Apple サーバーへの RTT は約 180 ms、84 MB の IPA アップロードは約 3 分で完了しました。日本国内から使う場合は日本（東京）リージョンを選べば、Apple への経路もさらに短くなります。
コストと利用パターン
性能データだけでは長期利用の判断はできません。ZilCloud の標準 Mac mini M4 ノードは日額 $20.9、月額 $103.9、契約縛りなし。今回のテスト結果を踏まえた典型的な使い方は次のとおりです。
パターン A — ビルド専用ノード（日額）：クリーンビルド、リリースビルド、統合テストが必要な日だけレンタル。例えば週 2 日集中ビルドなら月額 $20.9 × 8 ≒ $167。クリーンビルド 1 回あたり 11 分以上短縮でき、ローカル Air はビルドに占有されません。
パターン B — 常駐 CI ノード（月額）：Git リポジトリの Webhook に紐づけ、push のたびにクラウドで xcodebuild test を実行。月額 $103.9。GitHub Actions の macOS runner は従量課金（約 $0.08/分、20 分のクリーンビルド 1 回で $1.6）なので、ビルド頻度が高いチームなら 1 週間で元が取れる計算です。
パターン C — 短期スプリント（週額）：リリース前 2 週間だけ $55.9/週でレンタル。大規模リファクタリングや TestFlight 申請を集中処理し、リリース後にノードを解放——アイドルコストゼロ。
すでに M3 Pro 以上でメモリ 18 GB 超の MacBook Pro をお持ちなら、クラウドの主な価値は「絶対速度」より「ローカル機の解放」と CI 並列化に寄ります。一方 8 GB / 16 GB の MacBook Air ユーザーにとって、クラウド M4 はコスパ最良の高速化ルートに近い——M4 Mac mini を新規購入しても $599 からで、ディスプレイや運用コストは別途かかります。
GitHub Actions と自前 CI との比較
多くのチームはすでに GitHub Actions の macos-latest runner を使っています。同一プロジェクトをプライベートリポジトリに push し、標準 workflow で比較しました。
jobs:
build:
runs-on: macos-14
steps:
- uses: actions/checkout@v4
- name: Install deps
run: pod install --repo-update
- name: Build
run: xcodebuild ... clean buildGitHub Actions 側のクリーンビルド合計（キュー待ち + 依存インストール + ビルド）は約 34 分 20 秒。内訳はキュー待ち 8 分、pod install 6 分、実ビルド 20 分強。ZilCloud ノードでは Derived Data と CocoaPods キャッシュをローカルディスクに永続化できるため、2 回目以降の同種パイプラインは 12 分以内に圧縮でき、キュー待ちもありません。
Actions の強みは GitHub との深い統合と運用ゼロ。弱みは共有 runner の性能ばらつき、コールドスタート、キャッシュ制約、高負荷時の長いキューです。両者は排他的ではありません。lint とユニットテストのゲートは GitHub Actions、Release Archive は ZilCloud 専用ノード——というハイブリッドが現場ではよく採用されています。
リモート開発体験とハマりどころ
ビルドをクラウドに移すと、ワークフローは必ず変わります。実測でまとめたノウハウと落とし穴です。
SSH 編集 + クラウドビルド（推奨）：ローカルで VS Code / Cursor の Remote SSH からクラウドに接続。コード補完と LSP はリモート側で動き、保存後にターミナルで xcodebuild を実行。タイピングへの影響はほぼありません（東京からシンガポールリージョンへ ping 約 65 ms、NTT 回線）。git push で大きなバイナリを扱う場合は git-lfs を検討してください。
ブラウザ VNC：ZilCloud コンソールからワンクリックで Web VNC を開けます。Xcode GUI やシミュレータを目視確認したいときに向きます。静止 UI の確認ならデフォルトのフレームレートで十分、アニメーションの細かいデバッグは RealVNC クライアントへ。
ハマり 1 — Keychain 証明書の同期：クラウドで初めて署名する際は .p12 と provisioning profile をインポート。Keychain で codesign が秘密鍵にアクセスできるよう設定を忘れると errSecInternalComponent が出ます。
ハマり 2 — Xcode コマンドラインツールのパス：新規開通ノードでは sudo xcode-select -s /Applications/Xcode.app が必要な場合があります。xcodebuild が Command Line Tools を指していると SDK が見つかりません。
ハマり 3 — タイムゾーンとログ：クラウドのデフォルトは UTC。CI ログの時刻をチームと揃えるなら sudo systemsetup -settimezone Asia/Tokyo（または Asia/Singapore）を設定しておくと楽です。
ローカル MacBook で足りるなら、クラウドは不要？
数値を読み終えたあと、自然と出てくる疑問です。ハードウェアを買い替えるか、プロジェクト最適化で解決できないのか？
予算に余裕があれば MacBook Pro M4 Pro 36 GB への買い替えは、メモリと散热の問題を根本から緩和できます。ただし本体価格は通常 $2,499 からで、フルビルド中はローカル機が占有され、Figma・Slack・Zoom を快適に並行するのは依然として難しい場面があります。個人開発者や小規模チームにとって、一括投資のハードルは高めです。
AWS EC2 Mac インスタンスを検討する人もいます。Apple 純正ハードウェアですが、起步価格は約 $1.083/時間、最短 24 時間契約（約 $26/日）で、ZilCloud の $20.9/日より高く、日単位の柔軟な起動停止や Thunderbolt 5 クラスター拡張にも対応していません。さらに EC2 Mac は専用ホストの割り当てフローが重く、ZilCloud の決済後 1〜5 分自動開通とは運用感が異なります。
GitHub Actions、Bitrise などの共有 CIは標準化されたパイプラインに向きますが、クリーンビルド時間、キャッシュ永続化、シミュレータ操作の自由度では専用物理ノードに劣ります。ピーク時に 10〜20 分キュー待ちになることも珍しくなく、リリース日のスケジュールに直撃します。
クラウド Mac mini M4 の立ち位置は明確です：ローカル PC を買い替えず、常にフルパワーで動くビルド専用機をオンデマンドで手に入れる。10 コア CPU 専有、16 GB ユニファイドメモリ、1 Gbps 専有帯域、シンガポール / 日本（東京）/ 韓国（ソウル）/ 中国香港 / 米国東部の 5 リージョンから選択可能。日額 $20.9 から、オーバーセルや「隣テナント」の干渉なし。スプリント週だけ借りるも、常駐 CI として使い続けるも——新しい Mac を買うか、長期クラウド契約を結ぶかでは得られない柔軟性があります。
記事冒頭のシナリオに戻ると、MacBook Air で iOS 開発は不可能ではありません。しかしプロジェクトが成長したあとは、ビルドをクラウド M4 に任せ、静かさとバッテリー寿命をローカルに残す——現時点で最もコスパの良い分業のひとつかもしれません。