ローカル MacBook のビルドが遅くなる理由
個人開発者や小規模チームの主力機は MacBook Air やエントリー MacBook Pro であることが多く、
メモリは 8 GB または 16 GB にとどまります。Xcode、Simulator、Chrome の多数タブ、Slack、Preview を同時起動すると、
swift-frontend と ld に割ける物理メモリはほとんど残りません。
macOS は DerivedData やインデックスキャッシュを SSD に追い出し始めます。表面上は「数分多く待つだけ」に見えますが、
実態は swap によってメモリ帯域が奪われている状態であり、その後の増分ビルドも一段遅くなります。
見落とされがちな要因がサーマルスロットリングです。ノート PC の放熱には限界があり、 フルビルドが 8〜15 分続くと CPU クロックはピークから 15〜25% 低下し、ファン音はビデオ会議の邪魔になります。 データセンターに設置された Mac mini は冷却が安定しており、「ビルド専用機」として向いています—— 手元のマシンは編集に集中し、重い処理はリモートの物理ノードへ任せる構成が現実的です。
本記事が答える問いは明確です：実プロジェクト規模で、SpinMac クラウド M4 専用ノードにビルドを移すとどれだけ速くなるか。 コストはいくらか。クラウドが過剰になるケースはどこか。
テスト環境と計測方法
再現性のため、両環境で Xcode バージョンと DerivedData 削除手順を統一し、
xcodebuild と /usr/bin/time -l で計測して GUI のインデックスやバックグラウンド処理の影響を避けました。
各ラウンド前に rm -rf ~/Library/Developer/Xcode/DerivedData/* を実行し、不要なアプリは終了しています。
ローカル A：MacBook Air M2 · 8コア CPU · 8 GB ユニファイドメモリ · 256 GB SSD · macOS 15 Sequoia。
ローカル B（対照）：MacBook Pro 14" M1 Pro · 10コア CPU · 16 GB ユニファイドメモリ · 512 GB SSD · 同一 OS。
クラウド：SpinMac Mac mini M4 · 10コア CPU · 16 GB ユニファイドメモリ · 256 GB NVMe SSD · 1 Gbps 専用帯域（シンガポールノード）。
ツールチェーン：Xcode 16.4、Command Line Tools は Xcode と一致。
サンプリング：memory_pressure で swap、powermetrics を 5 秒間隔で CPU 周波数、ファン騒音は筐体から 30 cm でピーク計測。
対象アプリは自社 SwiftUI 製品「PulseTrack」：Swift 約 8.2 万行、メイン App・Share Extension・Widget Extension・Watch App の 4 target、 Swift Package Manager 経由のサードパーティ 6 件（Alamofire、Kingfisher など）。 App Store 基準では中規模——巨大 monorepo ではありませんが、8 GB マシンには十分きついサイズです。
3つのビルドシナリオとコマンド
日常開発からストア提出まで、開発者が毎日遭遇する 3 パターンを選びました。
シナリオ 1：フルクリーンビルド（Debug）
CI の初回 checkout やブランチ切り替え後のコールドスタートを想定：
xcodebuild -scheme PulseTrack -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 16 Pro' clean build CODE_SIGNING_ALLOWED=NO
署名を無効化し、キーチェーン差の影響を除外してコンパイル本体だけを比較。各マシン 3 回実行し中央値を採用。
シナリオ 2：単一ファイル増分ビルド
Swift ソース 1 ファイル（UI ロジック約 40 行）を変更し、clean せず build。 最も頻度が高く、空きメモリとインデックス状態への依存が強い操作です。
シナリオ 3：Release Archive
Distribution 証明書でフル Archive、コンパイラ最適化（-O）と bitcode 剥離を有効化。
CPU 占有が最も長く、ノート PC でスロットリングが起きやすいシナリオです。
ローカル B（M1 Pro 16 GB）は「すでに高性能ノートを持つ場合」の対照組で、
クラウド M4 の優位がチップ世代によるものか、ビルド専用で他アプリと奪い合わないことによるものかを切り分けます。
クラウド計測は SSH 上で実施し、ネットワーク遅延は wall-clock に含めません（ソースは事前に rsync 済み）。
所要時間の比較：コアデータ
下表は 3 ラウンドの中央値です。クラウド M4 は全シナリオで先行し、差が最も大きいのは Archive—— 最適化フェーズは長時間フルロードが続くため、ラック冷却の安定性が効きます。
| シナリオ | MacBook Air M2 · 8 GB | MacBook Pro M1 Pro · 16 GB | SpinMac M4 · 16 GB |
|---|---|---|---|
| フルクリーンビルド（Debug） | 11′42″ | 7′08″ | 5′18″ |
| 単一ファイル増分ビルド | 48″ | 26″ | 17″ |
| Release Archive | 18′35″ | 11′20″ | 8′12″ |
| ピーク swap 使用量 | 2.8 GB | 0.4 GB | 0 GB |
| ビルド中ファン騒音ピーク | 46 dB | 41 dB | （データセンター・該当なし） |
MacBook Air M2 ではクリーンビルド 6 分付近で明確な swap が発生（memory_pressure で
system-wide memory free percentage が 4% まで低下）。
続いて swift-frontend の平均 CPU 利用率は 680%（マルチコア合算）から約 420% へ落ち込みます。
Xcode が遅くなったのではなく、カーネルがページングしている状態です。
クラウド M4 は物理メモリに余裕があり、10 コアはピーク時 85〜92% を維持、スロットリングの記録はありませんでした。
参考までに、M1 Pro 16 GB ローカルのクリーンビルドはクラウド M4 より約 34% 遅いだけ——Air 8 GB の 2.2 倍差よりはるかに小さい。 メモリ容量がチップ世代より先にボトルネックになる典型例です。すでに 16 GB 以上のローカル機がある場合、 クラウドの価値は「絶対速度」より「ビルド専用・日常作業への干渉ゼロ」にシフトします。
並行負荷：Simulator 起動中のビルド
上表は「デスクが片付いた状態」の理想値です。現実には Simulator で UI を見ながらフルリビルドを走らせる場面が多く、 Build Configuration の切り替えや DerivedData 削除後の再構築などが該当します。
この組み合わせ負荷では、Air M2 の Simulator が 20 fps 未満に落ちることがあり、 クリーンビルドは 11′42″ から 14′28″ に延長。M1 Pro は 8′45″ で実用域。 クラウド M4 は VNC で Simulator を遠隔表示しながらビルドしても、わずか約 40 秒の増加（5′58″）にとどまりました。 Simulator とコンパイルがそれぞれ十分なメモリ・CPU 余裕を持ち、8 GB プールを奪い合わないためです。
3 回のクリーンビルド後、Air の DerivedData は 4.7 GB。256 GB SSD では許容範囲ですが、 8 GB RAM ではインデックスキャッシュとビルド成果物が競合します。 クラウドノードは +1 TB SSD 拡張（日額 $2.5〜）に対応し、複数ブランチのキャッシュを温存したいチーム向けです。
比較を無効にする落とし穴
以下の条件が揃わないと、結果は 30% 以上ずれることがあります：
-
01
インデックス完了前にビルド
初回オープン時、バックグラウンドインデックスが 2〜4 GB を消費することがあります。進捗完了を待つか、
xcodebuildで GUI インデックスのノイズを避けてください。 -
02
Build System 設定の不一致
両環境で New Build System と
COMPILER_INDEX_STORE_ENABLEを揃えないと、増分ビルド時間は比較不能です。 -
03
クラウドへのソース同期方法
rsync --deleteでワークツリーを一致させる。FUSE マウントのクラウドドライブ上でコンパイルすると、ネットワーク I/O が隠れボトルネックになります。 -
04
シミュレータアーキテクチャの差
Apple Silicon シミュレータは既定で arm64。片方だけ x86_64 をビルドすると、時間がほぼ倍になることがあります。
一部 VPS 事業者の「macOS クラウド」は仮想化または共有ホストであり、完全な Xcode ツールチェーンや安定 CPU 割当が保証されません。 本テストは超過販売の影響を除くため SpinMac の物理 Mac mini M4 専用ノードを使用しました—— 仮想化環境のクリーンビルドはランごとに 40〜60% ばらつきやすく、ベースラインに不向きです。
リモートビルドワークフロー：ローカルで編集、クラウドでビルド
8 GB 機、あるいは会議と開発を並行する 16 GB ノートをお使いでも、Mac Studio に買い替える必要はありません。 現実的な分業は Xcode のコンパイルと Simulator の重負荷をクラウドへ移し、手元にはエディタと Git だけ残すことです。
よくあるシーン：午後のデモ直前に、フルビルドが必要なブランチが push され、Air のファンが最大になり Zoom がカクつく—— スキル不足ではなく、算力がビルドに奪われています。 クラウド M4 は日額 $21.2〜。リリース週だけオンにし、平常時はオフ——ハードウェア更新より安く収まることも多いです。
-
01
SpinMac ノードを開通
最寄りリージョンを選択（シンガポール / 日本・東京 / 韓国・ソウル / 中国香港 / 米国東部）。支払い後 1〜5 分で SSH・VNC が届きます。詳細はヘルプセンター。
-
02
コードと依存関係を同期
初回は
rsync -avz --exclude DerivedData ./ user@host:~/PulseTrack/でリポジトリを送信。SPM はクラウドでxcodebuild -resolvePackageDependenciesを実行。 -
03
ローカル編集・リモートビルド
VS Code Remote SSH や Cursor Remote でリモートツリーを編集し、ビルドコマンドは SSH セッションで実行。UI 確認はブラウザ VNC 経由の Simulator。
-
04
CI Runner として接続（任意）
チームの自動ビルドには同一ノードを GitHub Actions self-hosted runner に登録。クラウド Mac Xcode CI/CD 実践ガイドを参照。
5 リージョンすべて 1 Gbps 専用帯域と独立したグローバル IPv4 を提供します。
東京のオフィスネットワークから日本（東京）ノードへ rsync で約 120 ファイルの差分同期したところ 2〜4 秒——増分ビルドフローへの影響はほぼありません。
国内ユーザー向けアプリなら日本（東京）ノードが遅延と帯域のバランスに優れます。APAC 全体向けならシンガポールも有力です。
コストと選定：クラウドが向くタイミング
| 状況 | 推奨 | クラウドの役割 |
|---|---|---|
| MacBook Air 8 GB、日常的に swap で苦戦 | コンパイルと Simulator をクラウド M4 へ | 日単位レンタル、リリース集中週のみ |
| 16 GB ローカル、速度は足りるがファン音が会議の妨げ | フル / Archive はクラウド、増分はローカル | ハイブリッドで干渉を低減 |
| 3〜10 人チーム、共有ビルド機が 1 台 | 常時オンのクラウド M4 + CI Runner | 月額 $106.1、専用物理機・待ち行列なし |
| Mac Studio 64 GB 保有、ボトルネックなし | クラウドは必須ではない | 並列 Archive なら TB5 クラスターを検討 |
ざっくり試算：クリーンビルドを 12 分から 5 分に短縮し、1 日 6 回ビルドすれば約 42 分の節約。 エンジニアの時間単価で換算すれば、半日で日額 $21.2 のノード代を回収できることも——ファン音、会議品質、バッテリー消耗はまだ含みません。 クラウドはローカル開発機の代替ではなく、コンパイルに誰にも邪魔されない専用物理マシンを与える選択肢です。
ビルドパイプラインの自動化を進めるなら、 GitHub Actions と Jenkins 実践ガイドへ。 複数台での並列 Archive は Thunderbolt 5 クラスター実測を参照してください。