Mac mini M4 ビルドマシンの必要台数は、開発者数ではなく、ピーク時のジョブ到着量、タスク別のP95ビルド時間、目標待ち時間、実効稼働率、障害用の余力から算出します。非重要な検証なら1台から実測を始め、運用中のCIでは基準ノードに冗長ノードまたは弾力的な遠隔Macを組み合わせます。
この判断は、iOSチームの構築予算を作るIT担当者、キューによる合併・リリース遅延を調査する開発生産性責任者、固定購入とレンタルの混在を比較するCTO・技術責任者に向いています。
[ SECTION_01 ] 容量計画に必要な4つの入力
Mac mini M4 ビルドマシンの容量計画では、最初に次の入力をCIログから取り出します。月間平均ではなく、プルリクエスト、定時処理、リリース処理が重なる最繁忙時間帯を対象にします。
- ピーク時のジョブ到着量：時間帯ごとのコード検査、単体テスト、UIテスト、Archive、署名・配布ジョブの件数。
- タスク別のP95実行時間：平均ではなく、遅い側の実行時間。処理内容ごとに分けて記録します。
- 目標待ち時間：ジョブがRunnerへ割り当てられるまでに許容する時間。夜間処理とリリース処理を同じ基準にしません。
- 許容中断範囲：保守、Xcode更新、ホスト障害が起きた際に、どの処理を待たせられるかです。
この4項目のどれかが欠ける場合、必要台数を信頼できる形では答えられません。特に「CPU使用率が高いから増設する」という判断は、キューの長さや実行時間を見ないため不十分です。
注意：ジョブの待ち時間が長い原因は、ノード不足とは限りません。依存パッケージの取得、署名鍵の待機、Runnerラベルの誤設定、壊れたキャッシュも先に切り分けます。
[ SECTION_02 ] 仕事量の分解とピーク換算
コード検査とArchiveを「平均ビルド時間」という1つの数字にまとめると、容量計算が崩れます。処理の性質、失敗時の影響、同時発生しやすい時間帯が異なるためです。
タスク別にログを分類する
まずCIログを次の単位に分類します。
- コード検査、Lint、依存関係の解決
- 単体テスト
- UIテストとシミュレーター起動
- Archive
- 署名、配布、成果物の保存
- 定時実行や再実行されたジョブ
各分類について、ピーク時間帯の到着件数を λi、P95実行時間を Ti とします。ピークの総作業量は、次のように表せます。
Wpeak = Σ（λi × Ti）
ここで重要なのは、同じ時間帯に発生するジョブだけを合算することです。夜間の定時処理とリリース処理を、発生時刻を確認せずに足してはいけません。
XcodeのBuild Phasesには、コンパイル以外にもスクリプトや成果物処理が含まれます。処理の構成を確認する際は、XcodeのBuild Phasesに関するApple公式説明を参照します。
P95を採用する理由
平均値は、キャッシュが効いた短いビルドや軽い変更を過大評価します。実際の待ち行列に影響するのは、依存解決、UIテスト、署名処理などが重なった遅いジョブです。
P95はすべての障害を表す値ではありません。しかし、平均値よりもリリース前の資源需要を捉えやすい指標です。異常なタイムアウトや外部サービス障害は、別の失敗率指標として分けて扱います。
[ SECTION_03 ] 1台の実効処理量
M4とM4 Proの仕様は、候補となるハードウェアの範囲を定める材料です。AppleのMac mini公式技術仕様を確認しても、特定のプロジェクトが1時間に何件ビルドできるかまでは導けません。
必要なのは、自社コードと自社依存関係を使った基準タスクです。測定条件を変えると、構成間の比較ができなくなります。
基準タスクの測定手順
次の順番で記録します。
- 使用するコミットを固定し、XcodeのバージョンとSDKを記録します。
- Swift Package Managerやその他の依存関係を同じ状態にそろえます。
- キャッシュあり、キャッシュなしの条件を分けます。
- コード検査、単体テスト、UIテスト、Archiveを個別に実行します。
- 各タスクの実行時間、失敗、再試行、待ち時間を保存します。
- 同じタスクを複数回実行し、P95と失敗率を計算します。
- 同時実行数を段階的に変更し、処理時間とキューの変化を確認します。
Xcodeのビルド時間を調べる場合は、AppleのIncremental Build高速化に関する計測方法を使います。Build Timing Summaryで遅いターゲット、直列化されたスクリプト、不要な依存関係を確認してから、ノード数を計算します。
実効容量の式
1台の実効処理量を Cnode とすると、基準ノード数は次の式になります。
Nbase = ceil（Wpeak ÷ Cnode）
ただし、これは作業量を処理できる最低限の数です。目標待ち時間を満たすには、ピーク到着量の時間分布、ジョブの優先順位、長時間のArchiveがキューを占有する影響を別途評価します。
Xcodeのターゲット依存関係や並列ビルドの挙動は、ビルドスキームとターゲット依存関係の公式資料で確認できます。ハードウェアのコア数を、そのままCIジョブ数へ置き換えてはいけません。
[ SECTION_04 ] 待ち時間と並列実行の評価
同じMacで複数タスクを走らせる構成は、見かけ上の並列性を高めます。一方で、DerivedData、シミュレーター、Keychain、署名証明書、ワークスペースを共有すると、処理時間の悪化や環境汚染が起きます。
単一ノードの多重実行と、多ノードの単一ジョブ実行は、次の観点で比較します。
- スループット：同じ時間内に完了した成功ジョブ数。
- 故障ドメイン：1台の停止で失われる実行枠。
- 隔離性：キャッシュ、シミュレーター、署名環境を分離できるか。
- 清掃コスト：失敗後に作業領域を安全に初期化できるか。
- 再現性：同じコミットを同じ環境で再実行できるか。
同時実行数の上限は、一般論では決めません。企業側の負荷試験、またはNOVAKVMの同一基準タスクによる試験で、P95時間と失敗率を確認します。Runnerのラベルとグループを分ける場合は、GitHub ActionsのセルフホストRunner割り当て規則が参考になります。
容量不足と設定不良の切り分け
次の順に確認します。
- 同一ジョブの実行時間だけが伸びたか。
- 待ち時間だけが伸び、実行時間は変わっていないか。
- 特定のRunnerラベルにジョブが偏っていないか。
- 署名証明書やKeychainのロックで停止していないか。
- 依存関係の取得や外部サービスが遅くなっていないか。
- キャッシュのヒット率低下でディスクI/Oが増えていないか。
実行時間が正常で待ち時間だけが継続的に目標を超えるなら、ノード不足の可能性が高まります。逆に実行時間と失敗率が同時に悪化する場合は、増設前にワークスペースと署名環境を分離します。
[ SECTION_05 ] 運用目的別の構成判断
必要台数は、日常の平均処理量ではなく、守るべきサービス目標で変わります。
-
非重要な夜間処理
失敗時に翌朝再実行でき、待ち時間の目標も緩やかな場合は、単一ノードで基準値を取ります。まずキャッシュ、依存関係、直列スクリプトを改善します。 -
日常の合併検証
開発者の作業を止めない待ち時間を定義し、その時間を継続的に超えたら固定ノードを追加します。コード検査とUIテストは、同じRunnerプールに混在させない方が分析しやすくなります。 -
リリース重視の流水線
Nbaseとは別に、保守、Xcode更新、ホスト失聯、ピーク集中に備える冗長枠を用意します。予備ノードを日常の満載容量として数えると、障害時に余力が残りません。
固定ノードだけで対応するか、固定基盤に弾力的な遠隔Macを足すかは、次の3項目で判断します。
- 固定ノード総コスト：購入費、保守、設置、交換、電力、管理工数。
- 弾力容量コスト：必要な期間だけ利用するレンタル費、接続、環境準備、データ転送。
- 待機損失：キュー待ちで発生する開発者の待機時間、リリース遅延、再実行工数。
レンタルが常に安いとは限りません。長期間にわたり安定した高負荷を処理し、物理ポートや社内ネットワークへの直接接続が必要なら、自社購入が適する場合があります。一方、リリース時だけ負荷が跳ねる場合は、固定基線ノードと遠隔Macの組み合わせが、過剰な常設容量を避ける選択肢になります。
経験則：利用率の単発ピークでは増設を決めません。目標待ち時間、P95実行時間、失敗率が連続して悪化した記録を、増設の根拠にします。
[ SECTION_06 ] 容量算出の実行チェック
以下を埋められない場合、台数の結論を出す前に計測を続けます。
- [ ] 最繁忙時間帯のジョブ到着量を種類別に抽出した
- [ ] コード検査、テスト、UIテスト、Archive、署名を別々に分類した
- [ ] 各分類でP95実行時間を計算した
- [ ] キャッシュあり・なしの条件を分けた
- [ ] Xcode、SDK、コミット、依存関係を固定した
- [ ] 同時実行数を変えた負荷試験を実施した
- [ ] DerivedData、シミュレーター、Keychainの共有範囲を確認した
- [ ] 目標待ち時間を夜間、合併検証、リリースで分けた
- [ ] 保守とホスト障害の際に必要な予備容量を別枠で計算した
- [ ] 固定容量、弾力容量、待機損失を同じ期間で比較した
日本国内の購入候補を調査する段階では、日本向けMac mini M4導入情報も参照できます。ただし、購入候補の仕様確認と、CIでの実効処理量の測定は別の作業です。
[ SECTION_07 ] 固定購入と遠隔Macの使い分け
現在の構成が自社購入のMac miniだけの場合、ピークに合わせると平常時の資源が余り、ピークを無視するとリリース時にキューが伸びます。さらに、故障時の交換、Xcode更新時の検証、署名環境の復旧を社内で担う必要があります。
固定ノードは安定した長期負荷に向きます。遠隔Macは、同一の基準タスクを先に実行し、実測したCnodeを容量式へ入れられる場合に有効です。NOVAKVMの遠隔Mac利用環境を検証候補に加えれば、ピーク時だけ必要な処理枠を別経路で測定できます。
判断の順序は明確です。まず現在のCIログでWpeakを求め、次に同じコミットとXcode環境で1台のCnodeを測ります。その結果、日常負荷とリリース負荷の差が大きければ、固定台数を先に増やすのではなく、固定基線ノードに弾力的な遠隔Macを接続して待ち時間と失敗率を比較します。
Mac mini M4を購入して常設する方式は、安定した高負荷、物理接続、社内閉域要件に強い反面、余剰容量、交換対応、Xcode更新時の検証負担が残ります。遠隔Macのレンタルは、長期の満載運用では必ずしも最安ではありませんが、ピーク増加時の追加購入、遊休ノード、故障交換の負担を抑えやすい方式です。まず同じ基準タスクを実行して数値を取得し、固定構成と混合構成を比較するのが安全です。
必要な判断材料がまだない場合は、実運用に近いジョブを1台の遠隔Macで測定し、取得したP95時間と実効処理量を容量式へ代入します。その結果、ピークが日常負荷を大きく上回るなら、固定ノードを過剰購入せず、基線ノードと必要時だけ使うNOVAKVMの遠隔Macを組み合わせる構成を検討できます。