チームのiOS CI/CDではMacビルドマシンを何台見積もる？2026年の容量計画

適合する判断：AppleのXcode Cloud資料では、ワークフローにビルド、テスト、アーカイブなどのアクションを設定できます。このように処理の種類と実行時間を分けて記録し、同時実行のピークと許容待ち時間を測ってから台数を決めてください。開発者数だけでMacビルドマシン数を決めるのは避け、安定負荷は固定容量、短時間のピークは弾力的な追加を検討します。 (Xcode Cloudのワークフローアクション)

このガイドは、iOSチームのCI容量をこれから見積もる技術責任者向けです。
Macビルドサーバーで待ち行列が発生しているIT担当者や、固定購入と追加容量の費用を比べたい調達担当者にも役立ちます。

まず、既存CIの記録から負荷の基準を作る

台数を見積もる前に、CIのジョブを処理の種類ごとに分け、発生から完了までの記録を集めます。Xcode CIでは、ビルドやテスト、アーカイブなどを別のアクションとして捉えられます。Appleの継続的インテグレーションでSwiftパッケージやアプリをビルドする資料も、ビルド対象やワークフローを確認する際の参照先になります。

記録の粒度は、CIが出力するログとチームの運用に合わせて決めます。平均値だけで判断せず、日常の負荷、リリース前の集中、テスト範囲を広げたときの変化を別々に確認してください。

同時実行と許容待ち時間から必要容量を見積もる

次に、時間帯ごとに実行中のジョブがどう重なるかを調べます。単に「ジョブが多い」ではなく、実行時間の長いアーカイブと短いPR確認が同じ時間帯に集中しているか、再実行が続いているかを見ます。集計上の平均では隠れるピークが、実際の待ち時間の原因になり得ます。

待ち時間の目標は、タスクの用途ごとにチームで定めます。PR確認ならレビューの流れを止めないこと、リリース作業なら必要な確認を期限内に終えられることが判断材料になります。全チーム共通の「何分待ったら増設」という基準は置かず、現在の待ち時間と業務上許容できる時間の差を比較してください。

runnerへ容量を割り当て、設定上の制約も確認する

必要な並列数の仮説ができたら、CIのジョブを受け付けるMac runnerへ対応づけます。ただし、Macを追加すれば常に同数のジョブが並行して動くとは限りません。CIプラットフォームの同時実行上限、runnerのラベルやグループ、リポジトリへのアクセス権が、実際の割り当てを制限することがあります。

GitHub Actionsを利用している場合は、セルフホストrunnerの管理に関する公式資料で登録や管理の条件を確認し、ワークフロー構文の公式リファレンスで並行実行やジョブ設定を点検できます。これはGitHub Actions固有の確認例です。別のCIプラットフォームに、runnerのスケジュールや上限のルールをそのまま当てはめないでください。

たとえばrunnerが空いているのにジョブが開始されないなら、台数を増やす前に、ラベルの不一致やグループへの割り当て、権限、同時実行上限を確認します。制約を解消してもピーク時の待ち時間が目標を超えるなら、追加容量を試す根拠になります。

代表的なジョブで仮説を検証する

記録だけで決めず、チームで負荷の代表となるジョブを選んで検証します。PR確認だけでなく、長時間のテストやアーカイブがある場合は、それらも含めて実行し、待ち時間、実行時間、失敗・再実行、リソース競合を記録します。検証結果は、あらかじめ定めた待ち時間や安定性の目標と比べます。

評価としては、常に使う基準負荷には固定容量が合わせやすく、短時間のピークには追加容量の柔軟性が有効です。一方、runner設定やジョブの依存関係が原因なら、マシンを増やしても待ち時間の改善につながらない可能性があります。費用比較には実際の見積もりと使用量を入れ、ハードウェア、保守、遊休時間、追加利用、運用作業を同じ期間で並べます。

注意：検証時は成功したかどうかだけで終わらせず、失敗後の再実行や一部ジョブの遅延も記録してください。Xcode Cloudを使う場合は、ワークフローリファレンスと環境変数の資料を確認し、対象ワークフローの設定や実行環境を把握したうえで比較します。

FAQ：台数判断で迷いやすい点

開発者数からrunnerの台数を決められますか？

開発者数だけでは、ジョブの起動頻度や処理時間、同時実行の重なりが分からないため、台数へ直接換算するのは適切ではありません。チーム規模の変化は負荷変化の兆候として記録し、最終判断はCIログと代表的なジョブの検証に基づいて行います。

待ち時間が発生したらすぐにMacを増やすべきですか？

待ち時間が一時的なピークなのか、日常的に続く状態なのかを分けてください。runnerの空きがない状態で目標待ち時間を超えるなら追加容量を検討できますが、空きがあるのに開始されない場合は、同時実行上限やラベル、権限などの設定を先に調べます。

履歴データが少ない段階では何から始めればよいですか？

まずジョブの種類、発生時刻、開始・終了時刻、キュー待ち、失敗と再実行を記録できるようにします。PR確認とテスト、アーカイブを分けて観察し、記録の偏りを把握してから代表的な負荷を再現してください。データが少ない段階では、確定台数ではなく検証する仮説として扱います。

ピークだけに備える方法はありますか？

日常の安定負荷と、リリース前など短時間のピークを分けて計画します。ピークが一時的なら、追加容量を利用できる条件と費用を確認し、固定で抱える場合と比較します。利用可能なMacの構成や契約期間が要件に合うかは、導入前に個別に確認してください。

記録を定期的に見直し、増設の理由を残す

容量は一度決めて終わりではありません。新しいXcodeへの更新、テスト対象の追加、プロジェクト数の増加、タスク時間の変化は、以前の見積もりを変える可能性があります。CIの記録を定期的に見直し、次の点を確認します。

• ピーク時の同時実行数とキュー待ちが、チームの目標から外れていないか。
• 実行時間や失敗・再実行の傾向が変わり、特定種類のジョブが滞留していないか。
• runnerの設定やCIの並行実行上限が、必要な容量を妨げていないか。
• 固定容量の遊休時間と、追加容量の実利用・運用費を同じ基準で比較できているか。

安定性の評価では、単にMacが起動しているかだけでなく、ジョブが継続して実行できるか、障害時の復旧手順が運用に合うかも確認します。遠隔環境の運用条件を検討するときは、Mac環境の信頼性に関する案内も参照し、チーム側の監視・復旧要件と照らし合わせてください。

チームのiOS CI/CDで必要なMacビルドマシン数は、開発者数ではなく、記録で確認したピークと許容待ち時間から決めます。 日常的な負荷を自社で保有する方法は運用を固定しやすい一方、先行投資、利用の少ない時間帯の費用、保守の負担が残ります。短時間のピークまで固定設備でまかなう前に、実際の構成と利用条件が合う遠隔Macを追加候補として比べると、必要な容量だけを補えるか判断しやすくなります。

すでに負荷を検証できていて、ピーク分の補充や期間を区切った利用が必要なら、SDKMacの利用可能なMac構成とレンタル期間を確認してください。要件に合う構成が見つからない場合や、物理接続が必要な運用では、購入や社内設備の継続が適することもあります。

よくある質問