企業iOS CIのMacノードは何台レンタルすべき？2026年の容量見積もり

GitHub Actionsの自社Runnerは、ワークフローの指定と一致するラベル・Runner Groupを持ち、オンラインで空いている場合にジョブを受け取ります。一致するRunnerがなければジョブは待機します。GitHubの自社Runnerの割り当てと待機条件を踏まえると、企業iOS CI向けMacノードの容量見積もりは、開発者数から台数へ換算せず、実際のキューと実行記録から始めるべきです。

今週のアクション： PR、シミュレーター、署名・公開のジョブを分類し、待ち時間と実行時間を記録してください。その後、負荷ごとの基準容量を仮置きし、試行運用の結果で追加レンタルの要否を判断します。

この記事は、iOS CIのMac資源を調達する企業IT担当者、GitHub Actions自社Runnerのルーティングを担うプラットフォームエンジニア、実負荷に基づく予算を作るFinOps担当者向けです。

人数換算ではなく、ジョブの証跡から見積もる

開発者の人数だけでは、CIが同時に要求するMacの容量はわかりません。同じ人数でも、PRごとの構築、シミュレーター試験、定期回帰、リリースの集中具合で、必要な処理能力は変わります。

まず、Macを必要としない静的解析や一般的な検査をワークフローから分けます。すべてのジョブをMacへ送ると、Macでしか実行できないXcode関連処理と競合し、必要台数を過大に見積もるおそれがあります。ワークフローの指定方法はRunner Groupとラベルによる実行先の選択で確認できます。

GitHubのworkflow_jobイベントには、created_at、started_at、completed_atの時刻情報があります。この記録から、キュー待ちと実行時間を分けて算出できます。また、イベントにはqueued、in_progress、completedなどの状態があり、workflow_job Webhookの仕様に沿って集計すると、待機から完了までの流れを追いやすくなります。

PR・シミュレーター・署名公開では負荷の性質が異なる

PRと通常ビルド： まずPR、コミット、メインブランチの各トリガーを区別し、Mac上で動くジョブだけを集計します。共通の検査処理をMac以外へ移せるなら、その分をMac容量の計算から外します。

シミュレーター試験： マトリクス実行や回帰試験は、実際に並行できるかを確認します。テストを並列化できても、同じmacOSやXcode環境が必要なら、任意の空きRunnerへ流せるとは限りません。通常ビルドと共用するかは、キュー待ちと環境要件の両方で判断します。

署名・公開： アーカイブにかかった時間だけで、同時実行できるジョブ数を決めないでください。署名資格情報、承認、公開環境の制約を先に整理します。アクセス範囲を分ける必要があれば、通常のPR用容量と切り離したRunner Groupを検討し、Runner Groupのアクセス制御に従って対象を限定します。

専用環境： 必要なmacOSやXcodeが異なるジョブを同じ容量プールにまとめると、空きがあっても条件不一致で実行できない場合があります。Runnerラベルの設定方法を確認し、ジョブの指定と実際の環境が一致しているか、履歴から確かめます。

待ち時間と実行時間を分け、基準枠とピーク枠を作る

容量見積もりは、記録から再計算できる形にします。ワークロードごとに、対象期間のジョブ数をJ、平均実行時間をD、実行時間帯に重なる割合をP、Mac Runnerが実際にジョブを受けられる割合をAと置きます。概算の同時処理需要はJ × D × Pで表せます。稼働可能時間を含めた基準ノード数の目安は、J × D × P ÷ Aをノードが対象期間内に処理できる時間で割って求めます。

これは企業側の試算モデルであり、GitHubが推奨するノード数や公式の待ち時間基準ではありません。短い時間帯にジョブが集中するピーク枠は、通常負荷とは別に履歴から見積もり、試行運用で妥当性を確かめます。

GitHub Actionsのプラットフォーム側の同時実行制限は、プランなどに応じて扱いが異なります。GitHub Actionsの利用制限を確認し、プラットフォーム側の上限と、自社が用意したMac Runnerの処理容量を混同しないでください。自社Runnerを増やしても、プラットフォーム側の制限や、条件に一致するRunnerが空いていない問題は別途確認が必要です。

今週から試行運用までの確認項目

次の項目を、実際のワークフロー履歴と運用ルールに照らして進めてください。

• [ ] Macで実行するジョブと、別のRunnerへ移せるジョブを分類する。
• [ ] PR、シミュレーター、署名公開、専用ツールチェーンの実行履歴を分けて集計する。
• [ ] created_at、started_at、completed_atから、キュー待ちと実行時間を算出する。
• [ ] Runner Groupとラベルの指定を照合し、空きがあるのに条件不一致で待機するジョブを探す。
• [ ] 署名資格情報や公開承認を確認し、共用できない負荷を別プールとして扱う。
• [ ] 基準容量とピーク時の追加枠を仮定し、小規模な試行運用で待ち時間と完了状況を検証する。

実行待ちが一時的なら、優先度の低い回帰試験を時間帯で分ける方法もあります。待ちが繰り返し続く場合は、追加ノードだけでなく、Runnerの条件指定やジョブのMac依存自体を見直してください。必要に応じて、Runner Scale Setsの仕組みとスケールセットの導入手順を読み、組織の運用要件に合う拡縮方式か確認します。ここで示す方式はGitHub側の機能説明であり、企業の容量や性能を保証するものではありません。

FAQ：待機・分離・追加枠の判断

PRビルド、シミュレーター試験、署名公開は、必ず別のMacに分けますか？
必須ではありません。環境条件が共通で、アクセス権限も共有でき、キュー待ちが許容できるなら共用を試せます。署名資格情報を扱うジョブや専用ツールチェーンが必要なジョブは、分離要件と実行履歴を確かめてから別のRunner Groupや容量枠に分けてください。

自社Runnerが待機しているとき、GitHubの制限とMacの不足をどう見分けますか？
ジョブのラベルとRunner Groupが合うか、対象Runnerがオンラインかつ空いているかを先に確認します。そのうえで、ジョブ時刻から待ち時間を出し、プラットフォームの同時実行制限も別に照合してください。条件不一致やプラットフォーム制限なら、Macを増やすだけでは解決しません。

ピーク用のMac枠は、いつ常設容量へ切り替えますか？
リリースや一括回帰の後だけに待ちが現れるなら、ピーク用の追加枠を試す余地があります。通常の作業時間にも待ちが継続するなら、基準容量やジョブ構成を見直す判断材料になります。いずれも実際の待機・実行履歴と、チームが定めた待ち時間の目標で検証してください。

Macの購入とレンタルは、どの負荷に向いていますか？
稼働が継続し、必要な構成も安定しているなら、購入したMacを基準容量として検討できます。案件やリリース時期によって必要量が変わるなら、追加分をレンタルする構成が候補になります。保守負担、調達期間、契約条件を確認し、手元の試算に含めて比較してください。

開発者数で一括調達する方法は、ピークに備えて余剰機材を抱えたり、逆にリリース時の待ちを見落としたりしやすくなります。自社設備だけでは追加調達に時間がかかり、変動分まで常設すると保守や更新の負担も続きます。負荷の変動が大きいチームは、安定分を自社で確保し、試行期間やピーク分をMacレンタルで補う構成を比較してください。長期にわたる安定した高負荷や、物理接続が必須の作業では、購入や社内設備のほうが適する場合もあります。

まずは実測した負荷と必要な環境を照らし合わせたうえで、VMSPINの料金・レンタル期間と利用できるMacの申し込み情報を確認してください。記載された構成や提供条件がチームの要件に合う場合に限り、試行用容量の相談へ進むと、台数を先に決めてから条件を合わせる手戻りを避けられます。