増分コンパイルではなく Clean Build を見る理由
日常開発では、Swift ファイルを1つ変更すると、Xcode は影響を受けたモジュールのみ再コンパイルし、所要時間は十数秒程度。 しかしこの「増分コンパイル」はキャッシュに大きく依存し、A マシンで蓄積した派生データを B マシンに移しても役に立ちません。 以下のシーンでは、ゼロからのビルドが避けられません：
- CI/CD パイプラインで各 Job 起動時に DerivedData をクリア
- Xcode バージョン切替または macOS アップグレード後、旧キャッシュが無効
- 開発マシンを入れ替え、新マシンに履歴キャッシュなし
- 実行
xcodebuild clean buildまたはxcodebuild archiveの Release パッケージング
したがって、clean build 時間こそが「このマシンが iOS ビルドパイプラインを支えられるか」の真の基準です。増分コンパイルの速さは、 開発者個人の使用習慣とコード変更頻度を反映するものが多く、ハードウェア性能の上限ではありません。本文のすべてのデータは完全な clean build から取得し、 3台のマシンが同じスタートラインに立つことを保証しています。
実測環境とテストプロジェクトの説明
比較に意味を持たせるため、3台のマシンで完全に同一のプロジェクト、同一の Xcode バージョンを使用し、近い室温で独立して3ラウンドテストを実施、
中央値を結果としました。各ラウンド前に rm -rf ~/Library/Developer/Xcode/DerivedData を実行し、
ローカル派生データを完全にクリア、ゼロからのコンパイルを保証しました。
テストプロジェクト：SwiftUI 中規模 App、約 9.2 万行の Swift コード、2 つの Extension Target（WidgetKit + Share Extension）を含み、合計約 5,800 個の Swift ソースファイル、約 12 個のローカル Swift Package に依存。
Xcode バージョン：Xcode 16.4、macOS 15.5 Sequoia（3台のマシンでバージョン統一）。
テストラウンド：各マシンで3回 clean build + 3回 Archive を実行、中央値を取得。Clean build コマンド：xcodebuild clean build -scheme AppName -destination generic/platform=iOS；Archive コマンド：xcodebuild clean archive -scheme AppName -archivePath /tmp/app.xcarchive。
ハードウェア：① MacBook Air M2（2022）· 8 コア CPU · 16 GB 統合メモリ · 256 GB SSD；② MacBook Pro 14" M1 Pro（2021）· 10 コア CPU · 16 GB 統合メモリ · 512 GB SSD；③ VPSRox 専用 Mac mini M4（2024）· 10 コア CPU（4 性能コア + 6 効率コア）· 16 GB 統合メモリ · 256 GB NVMe SSD · データセンター托管（香港ノード）。
MacBook Air M2 は10コアの最上位ではなく、市場で最も一般的な8コア版を選択しました。 MacBook Pro M1 Pro と VPSRox M4 Mini はいずれも10コアで、近い CPU コア数のもと、 チップ世代差（M1 Pro 対 M4）と放熱能力が持続ビルドに与える影響を重点的に観察できます。
Clean Build フルコンパイル計測結果
下表は3ラウンド clean build の中央値実時間（wall-clock time）、メモリ圧力ピーク、Xcode 報告の CPU 使用率ピークを記録。
メモリピークは memory_pressure ツールと Activity Monitor でビルド中にサンプリングして取得。
| マシン | CPU | Clean Build 中央値 | メモリピーク | 第3ラウンド vs 第1ラウンド偏差 |
|---|---|---|---|---|
| MacBook Air M2（8 コア） | 8コア M2 | 5m 42s | 11.8 GB（軽微な swap が散発的に発生） | +38秒（放熱スロットリング顕著） |
| MacBook Pro 14" M1 Pro（10 コア） | 10コア M1 Pro | 4m 08s | 10.9 GB（swap なし） | +14秒（放熱スロットリング軽微） |
| VPSRox Mac mini M4（10 コア） | 10コア M4 | 3m 11s | 9.4 GB（swap なし） | +2秒（ほぼ誤差なし） |
最も注目すべき列は「第3ラウンド vs 第1ラウンド偏差」です。MacBook Air の3回目 clean build は1回目より38秒も遅く、 原因はファンレスパッシブ冷却により連続ビルド後にチップが温度管理降速をトリガーしたためです。MacBook Pro はアクティブ冷却により偏差は14秒に縮小、 それでも存在します。データセンターラック内で稼働する VPSRox M4 Mini は、3ラウンド間でわずか2秒の差、ほぼ計測誤差の範囲内です。
単発ビルドであれば、MacBook Pro M1 Pro のパフォーマンスはすでに十分優秀です。しかし CI シーンでは必要なのは初回の成績ではなく、 10 回目、50 回目の連続ビルドでの安定したパフォーマンスです。放熱能力の差はここで数倍に拡大されます。
Archive パイプライン所要時間比較
Archive は通常の clean build より本番環境に近い：コンパイルに加え、コード署名、bitcode コンパイル（有効時）、 dSYM 生成とシンボルテーブルのパッケージングが必要。同一プロジェクトでは、Archive の所要時間は通常 clean build の 1.2–1.4 倍。
| マシン | Archive 中央値 | Clean Build 比の増加 | 5回連続平均（推定） |
|---|---|---|---|
| MacBook Air M2（8 コア） | 7m 18s | +1m 36s | 約 8m 40s（放熱スロットリングの影響） |
| MacBook Pro 14" M1 Pro（10 コア） | 5m 22s | +1m 14s | 約5分45秒 |
| VPSRox Mac mini M4（10 コア） | 4m 06s | +55s | 約4分10秒（極めて安定） |
Archive データから、M4 チップは dSYM 生成とシンボルテーブル処理段階での速度優位がより顕著で、 M1 Pro より約 19% 短縮、単なる CPU コア周波数による線形向上にとどまりません。 これは M4 のメモリ帯域幅と Neural Engine による補助処理におけるアーキテクチャ改善と直接関連しています。
Fastlane を使用するチームでは、各 fastlane gym は実質的に完全な Archive + エクスポートに相当し、
2ステップ合計で M4 Mini 上は約 5 分 30 秒、同等構成の MacBook Air M2 では約 10 分 必要。
1日に複数バージョン（dev/staging/production の3パッケージなど）を出す必要がある場合、この差はリリースペースに直接影響します。
放熱スロットリングとメモリ圧力：ローカルマシンの隠れた変数
多くの開発者向けベンチマーク記事は単発のコールドスタート成績のみを報告し、重要な変数である熱蓄積（thermal accumulation）を見落としています。 Apple Silicon チップにはインテリジェントな温度管理戦略があり、筐体温度が設定閾値を超えると CPU と GPU 周波数を自動的に下げ、 放熱能力が追いつくまで待ちます。ファンレス設計の MacBook Air への影響は特に顕著です。
MacBook Air M2 の放熱スロットリング観測
テストでは、MacBook Air M2 の筐体底部は2回目 clean build 終了時（約11分後）に明らかな温度上昇、
pmset -g thermlog で CPU パワー制限（CPU_Speed_Limit）が100から約78に低下するのを確認、
3回目ビルドは1回目より30秒以上遅くなりました。MacBook Air 上で連続 CI タスクを実行する場合、
実際の所要時間はコールド状態より体系的に15%–30% 高く、予測も困難です。
MacBook Pro M1 Pro のアクティブ冷却の限界
MacBook Pro のアクティブ冷却システムにより状況は大幅に改善されますが、完全に免疫というわけではありません。環境温度が高い場合（室内 28°C 超）、 または複数の Simulator インスタンスを同時起動している場合、軽微なサーマルスロットリングが散発的に見られます。14 秒の偏差は主に環境温度がやや高かった第3ラウンドテストに由来し、 22°C の制御環境では偏差は約 8 秒に縮小しました。
データセンター環境の熱安定性
VPSRox ノードはデータセンターの恒温ラック内で稼働（通常 18–22°C を維持）、Mac mini M4 自体もアクティブ冷却ファンを搭載。 この2条件が重なることで、ビルド所要時間の一貫性はあらゆるノート PC を大きく上回ります。3ラウンドテストでは、 第1ラウンドと第3ラウンドの差はわずか2秒、完全に無視できます。ビルドウィンドウを予測する必要がある CI シーンでは、 この安定性の価値は巨大：p99 時間を基準にでき、予期せぬタイムアウトを心配する必要がありません。
MacBook Air を窓際のデスクに置き、夏季の室温が 27°C を超える場合、放熱スロットリングはより早く、より深刻に発生します。 冬季は同一マシンでも 20%–30% 良いパフォーマンスを示す可能性があります。ローカルマシンのコンパイル基準は、実際の使用環境で計測する必要があり、 恒温テストルームでのベンチマークサイトの数値を参照すべきではありません。
メモリピークと Swap 書き込みが速度に与える影響
16 GB 統合メモリのマシンでは、大規模 iOS プロジェクトのコンパイル時にメモリ圧力は現実的な問題です。
Xcode はリンク段階とコード署名段階で複数のツールプロセスを同時起動し、Swift コンパイラ自体もメモリを大量消費します。
vm_stat と memory_pressure の2つのツールでメモリピークを相互検証しました。
MacBook Air M2 の clean build 中のメモリピークは約 11.8 GB、2 つの Extension Target 同時コンパイルの並列ウィンドウ期間に短時間の swap 書き込み（約 200–400 MB）が発生、このとき SSD 読書速度がコンパイル進行に直接影響。 MacBook Pro M1 Pro のピークは約 10.9 GB、3ラウンドテストいずれも swap 未発生、M1 Pro のより効率的なメモリスケジューリングの恩恵。 VPSRox M4 Mini のピークはわずか約 9.4 GB、主に M4 チップのメモリ使用のさらなる最適化を反映—— 同一コンパイルタスクでも M4 上ではより少ないメモリコピーと中間オブジェクトで済みます。
| マシン | メモリピーク | swap 発生の有無 | コンパイルピーク時 CPU ピーク | SSD 書き込み量（Clean Build） |
|---|---|---|---|---|
| MacBook Air M2 | 11.8 GB | はい（~300 MB） | 約 780%（約 8 コアフル稼働） | 約4.2 GB |
| MacBook Pro M1 Pro | 10.9 GB | いいえ | 約 980%（10 コアフル稼働に近い） | 約3.8 GB |
| VPSRox Mac mini M4 | 9.4 GB | いいえ | 約 960%（10 コアフル稼働に近い） | 約3.5 GB |
プロジェクト規模がより大きい（20万行超など）場合や Swift Package 依存がより多い場合、 16 GB では MacBook Air 上でメモリボトルネックに遭遇しやすくなります。より大容量メモリが必要な場合、 VPSRox は SSD 拡張オプション（+1TB $2.6/日、+2TB $5.2/日）を提供しますが、16 GB を超えるメモリスペックは現時点では提供しておらず、 選定時に事前に考慮する必要があります。
ローカル MacBook で十分なケース
すべてのチームがクラウドノードを必要とするわけではありません。以下のケースでは、手元の MacBook で十分対応できます：
- プロジェクト規模が小さい（< 3 万行 Swift）：Apple Silicon MacBook なら clean build は2分以内、性能ボトルネックなし。
- CI 頻度が低い（1日 < 5 回ビルド）：clean build が1回7〜8分かかっても、1日の総ビルド時間は40分以内で許容範囲。
- 個人インディー開発者、ローカルデバッグ中心：増分コンパイルで十分なことが多く、clean build はリリース時のみ。MacBook Pro M1 Pro 以上で十分対応可能。
- MacBook Pro M3/M4 ユーザー：Apple 最新 MacBook Pro（M4 Max）の放熱と性能は Mac mini M4 にほぼ匹敵。差は主に連続ビルドの安定性にあり、単発速度ではない。
クラウドノードを真剣に検討すべきシーンは、主に以下の類型に集中：CI/CD パイプラインが1日20回以上ビルドをトリガー、 チームが同一のビルド環境を共有（「自分のマシンでは通る」問題の回避）、開発者が MacBook Air を使用しプロジェクトが拡大中、 または複数の独立プロジェクトのビルド分離を同時に維持する必要がある場合。
総合判断：コストとベネフィットの計算
クラウド Mac への切替コストは明確：VPSRox 専用 Mac mini M4 の日単位レンタルは $21.8/日、 月単位の継続利用は約 $109.1/月、新しい MacBook Pro より安いが、継続的な支出が必要。 別の角度から考えると、何を節約できるのか？
5人の iOS チームを例に：1日平均30回 clean build/Archive をトリガーすると仮定、 MacBook Air M2 上では平均8分/回（軽微な放熱スロットリング含む）、合計240分。 同じ作業量を VPSRox M4 Mini 上で行うと約123分。1日約117分のマシン時間を節約、 CI で複数ブランチを並列実行するチームにとって、この時間はより速いコードレビューフィードバックとリリースウィンドウに直接変換されます。
また、見落とされがちな潜在コストとして、ビルド待ち中の開発者の注意切替があります。5分以内の待ち時間なら、 多くの人はプログレスバーを見つめます；8分を超えると、他のタスクに切り替えて戻るのを忘れがちです。 一般的なフロー状態（flow state）の研究では、能動的な中断1回で約20分かけて効率的な作業状態に戻るとされています。 対照的に、月 $109.1 のノード費用は「集中力を維持するためのツールコスト」に近く、純粋なサーバーレンタル以上の意味を持ちます。
クラウドノードを検討すべき組み合わせ：プロジェクト > 5 万行 + MacBook Air + CI が1日 > 15 回ビルド、3条件が同時に成立。
ローカル Mac のアップグレードを優先する組み合わせ：主な作業がローカルデバッグ（CI ではない）+ 中規模プロジェクト + 予算が限られている場合、MacBook Pro M4 1台の方がクラウドノードのレンタルより適している可能性があります。
両者が補完し合う組み合わせ：ローカル MacBook で日常の増分コンパイルとデバッグ、CI パイプラインはクラウド専用ノードで実行、役割分担が明確で互いに干渉しない。