GitHub Actionsのworkflow_jobイベントは、Jobをqueued、in_progress、completedの3状態で観測できます。GitHub公式のWebhook仕様にあるこの区別を使えば、GitHub Actions iOS並列ビルドのMac台数は、開発者数ではなく、ピーク同時実行数、Jobの占有時間、許容待ち時間、公開環境の分離要件で決められます。
今週は、まず1週間分のWorkflow履歴から待機時間と実行時間を分けて記録します。低頻度の個人開発なら単機から始め、Build、Test、Archiveが重なるなら2台構成または発行期間だけの追加を選びます。複数Appを扱うチームは、実測したキューを基準に容量を更新します。
この判断が必要な開発者
対象は、次のいずれかに当てはまる開発者です。
- 1人でiOS Appを管理し、GitHub Actionsの自前Runnerをすでに設定している
- Pull Requestのテスト中でもTestFlight向けArchiveを止めたくない
- 複数人、複数リポジトリで同じMac環境を共有している
- 発行期間だけ負荷が上がるため、Macを長期購入せず週単位または月単位で追加したい
ここでいうJobは、Workflow全体ではありません。Workflowの中にはBuild、Test、Archive、署名、アップロードなど複数のJobがあり、それぞれがRunnerを占有する場合があります。一方、App Store Connect側の処理は、Mac上のRunnerを占有し続けるとは限りません。Appleのビルドアップロード手順とJobログを分けて確認します。
第一段階：開発者数ではなく、Jobの波形を記録する
まず測るのは「毎日のビルド数」ではない
「1日に何回ビルドするか」だけでは、必要なMac台数は分かりません。見るべき項目は次の4つです。
queuedになってからRunnerが受け取るまでの待機時間- RunnerがJobを実行している時間
- 同じ時間帯に存在するJob数
- 失敗による再実行と、発行処理による優先Jobの有無
GitHubのActionsメトリクスでは、実行時間や待機時間などのWorkflow運用データを確認できます。Actionsの公式メトリクス説明を参照し、個人リポジトリで組織単位の表示が不足する場合は、Workflow履歴とJobログをCSVや表計算に記録します。
ここで、依存パッケージの取得、キャッシュ復元、署名処理、Xcode内部の並列タスクを1つの「ビルド時間」に混ぜないことが重要です。Xcodeのビルド時間は、AppleのBuild Timing Summaryに関する資料で確認できる内部計測と、GitHub Actions上の経過時間を分けて扱います。
一台のMacで複数Jobを同時に実行できるか
一台のGitHub Actions自前Macで複数のiOS Jobを同時に動かせますか。
Runnerの登録台数と、Mac上で同時に安全に処理できるJob数は別問題です。Runnerのルーティングはラベルや利用可能なRunnerの条件で決まり、同じMacへ複数Jobを送れる設定でも、Xcode、シミュレーター、DerivedData、キーチェーン、署名ファイルが競合すれば安定運用にはなりません。Runnerの選択ルールを確認したうえで、同時実行数は実機で検証します。
特にArchiveとTestを同じ作業ディレクトリ、同じDerivedData、同じ署名コンテキストで走らせる構成は避けます。1台で複数Jobを許可する場合でも、まずは独立した作業パス、キャッシュ方針、シミュレーターの状態、キーチェーンアクセスを確認します。
人数別に見る、単機・2台・追加租用の判断
単人・低頻度：単機を維持する
独立開発者が一台のリモートMacでiOS CIを回す構成は足りますか。
Pull Requestの数が少なく、テストマトリクスが小さく、正式Archiveを時間差で実行できるなら、まず単機を維持します。ここで重要なのは、Runnerが常に稼働していることではなく、緊急の修正や発行Jobが許容待ち時間を超えないことです。
通常の検証、定期テスト、正式Archiveに優先順位を付けます。GitHub Actionsの同時実行制御で古い検証を取り消せば、不要なJobが発行作業を塞ぐ状況を減らせます。WorkflowのConcurrency設定では、グループ単位の実行とキャンセル方針を設計できます。
次のような場合は、Macを増やす前にWorkflowを直します。
- 同じ依存関係を毎回取得している
- 使っていないテスト対象まで常に実行している
- 古いブランチのJobが新しい修正より先にRunnerを占有している
- Archive後のアップロード待ちをRunnerの実行時間として数えている
単人・高頻度：重なり方で2台目を決める
機能ブランチ、定期テスト、TestFlight用Archiveが同じ時間帯に重なるなら、平均利用率だけでは判断できません。平均的には空いていても、発行時にキューが積み上がるなら、2台目には並列化と故障時の回避という価値があります。
ただし、2台目を追加しても、1つのJobそのものが速くなるとは限りません。単一Jobの速度改善は、Xcodeのビルド設定、キャッシュ、依存関係、テスト対象を確認します。2台目は「別のJobを同時に処理する」ための容量です。
小規模チーム：フィードバック時間を基準にする
小規模チームでは、Runnerを待たせないことより、レビュー用結果が許容時間内に返ることを基準にします。
高速な静的確認、シミュレーターTest、Archiveとアップロードでは、Macの占有条件が異なります。通常のPull Request Jobを公開用環境へ送らないよう、RunnerラベルやRunner Groupを分けます。self-hosted runnerのラベル適用方法に沿って、リポジトリ、Job種別、セキュリティレベルをルーティング条件にします。
iOSのTestとArchiveは別のMacに分けるべきですか。
必ず分ける必要はありません。単一Appで発行頻度が低く、署名情報を安全に管理でき、TestのキューがArchiveを妨げないなら同一環境でも運用できます。反対に、公開用証明書やProvisioning Profileを持つ環境へ通常の検証Jobを流したくない場合、または発行中もPull Requestを止めたくない場合は、公開用Macを分けます。
複数App・固定発行チーム：容量を階層化する
複数リポジトリが同じRunnerラベルを使うと、単純な台数追加だけでは優先順位が曖昧になります。開発検証用、シミュレーターTest用、公開用に役割を分け、各Workflowが要求するラベルを固定します。
発行用環境には、リポジトリだけでなく署名資格情報、Bundle ID、Team ID、キーチェーン、保存先パスも分離します。記事やログを共有するときは、これらの値を必ず脱敏します。Appleのテスト結果は、Xcodeのテスト結果に関する公式説明とActionsログの両方で確認し、テスト失敗とRunner障害を混同しないようにします。
注意：Xcode 27を含む新しいツールチェーンを検証する場合、公開用の安定環境と検証環境を最初から同じRunnerに載せないでください。Xcodeの選択、証明書、キャッシュ、シミュレーター状態を分離し、失敗時に発行を戻せる経路を残します。
5段階で作る容量判断カード
1. WorkflowをJob単位に分解する
Build、Test、Archive、署名、アップロードを一覧にします。App Store Connect側で処理される時間は、Macが占有される時間と分けます。
2. 履歴からピーク時間帯を抜き出す
最低でも、通常日と発行日を別に集計します。組織メトリクスが利用できない場合は、各Jobの開始時刻、終了時刻、待機開始時刻、失敗と再実行を記録します。workflow_jobの状態遷移も確認します。
3. 待機時間の原因を分類する
Mac台数不足、ラベル不一致、Runnerオフライン、依存関係取得、無効なテストマトリクスを分けます。Runnerがオフラインなのに台数を増やしても、キューは改善しません。
4. 公開用Jobの回避経路を試す
単機なら、通常TestとArchiveを同時に発火させ、優先順位とキャンセル方針を検証します。2台構成なら、公開用ラベルへ通常Jobが流れないこと、片方のMac停止時に発行できることを確認します。
5. 停止条件を決めてから追加する
次の発行期間に向けて、どの待機時間を超えたら追加Macを使うか決めます。追加後は、キューが下がったか、署名隔離が守られたか、Xcodeとキャッシュが一致したかを再確認します。
3つの構成を比較する判断表
| 構成 | 向いている負荷 | 実施する確認 | 回避すべき状態 |
|---|---|---|---|
| 単機 | 単人・低頻度、発行を時間差で実行 | 優先順位、キャンセル、再起動後の復旧 | Archiveが通常Testを長時間待たせる |
| 2台 | TestとArchive、複数ブランチが頻繁に重なる | ラベル分離、署名隔離、片方停止時の発行 | 2台とも同じ資格情報と作業パスを共有する |
| 発行期間だけ追加 | 発行窓口や定期テストだけピークになる | 追加環境の交付、ツールチェーン一致、撤去手順 | 追加Macの準備が発行開始より遅い |
| 常駐の分離環境 | 複数Appで公開処理が継続する | 公開経路、監査ログ、復旧経路 | すべてのJobを同じRunner Groupへ送る |
台数はこの表だけで確定しません。ピーク時のJob数と占有時間を測り、許容待ち時間に収まるかで決めます。
料金と租用期間を比較する表
価格の具体値は、構成、地域、租用期間、交付条件で変わるため、公開ページで確認できる条件だけを比較します。根拠のない月額や時間単価を容量計算に入れないでください。
| 選択肢 | 支払う主な項目 | 容量上の利点 | 見落としやすい費用・作業 |
|---|---|---|---|
| 既存の単機 | 現在のMac利用費 | 追加作業が少ない | 発行時の待機、故障時の代替 |
| 常駐の2台目 | Macの追加租用期間 | Jobの並列化、回避経路 | 署名設定、監視、パッチ、Runner登録 |
| 発行期間だけの追加 | 必要な租用期間 | ピークだけ容量を増やせる | 交付待ち、Xcode設定、撤去と情報消去 |
| 自前ハードウェア購入 | 本体、保守、設置 | 長期の固定負荷に向く場合がある | 閑散期の遊休、故障、設置場所、更新 |
短期間の負荷だけが問題なら、MESHLAUNCHのMac租用案内で利用可能な租用期間と交付方式を確認し、追加環境の準備時間を発行スケジュールに合わせます。購入判断は、毎回のJob数ではなく、発行しない期間にも維持費と管理作業が発生するかで比較します。
実行前に確認する構成チェック
- [ ] WorkflowをBuild、Test、Archive、アップロードのJobに分けた
- [ ]
queuedからin_progressまでの待機時間を記録した - [ ] Mac上の実行時間とApp Store Connect側の処理時間を分けた
- [ ] ピーク時の同時Job数を通常日と発行日で比較した
- [ ] 失敗による再実行を容量計算へ別項目で記録した
- [ ] 通常Testと公開用Archiveに異なるラベルを設定した
- [ ] Bundle ID、Team ID、証明書、キーチェーン、パスを脱敏した
- [ ] Runner停止、再起動、ネットワーク切断後の復旧を確認した
- [ ] 2台構成で片方を停止しても発行できることを確認した
- [ ] 追加Macの交付からXcode設定完了までの時間を実測した
- [ ] 追加を止める条件と、常駐へ切り替える条件を決めた
構成別の最終判断
| 観測結果 | 今週の判断 | 次に行うこと |
|---|---|---|
| 待機が短く、発行も通常Testを妨げない | 単機を継続 | Workflowの履歴を定期記録 |
| 発行時だけTestが待機する | 発行期間だけ追加 | 追加Macの交付と署名隔離を先に検証 |
| 開発TestとArchiveが頻繁に重なる | 2台構成を検証 | ラベル、Runner Group、失敗時の回避を確認 |
| 2台でも複数Appの発行が競合する | 公開用容量を分離 | Appとセキュリティレベルで環境を分割 |
| 待機の主因が依存取得や無効Job | 台数を増やさない | キャッシュ、キャンセル、テスト範囲を修正 |
独立開発者が一台のリモートMacでiOS CIを回す構成は足りますか。
発行を時間差で実行でき、実測したピーク待機が許容範囲なら足ります。待機が発行窓口だけで発生するなら、常駐の2台目ではなく、その期間だけ追加する方が合理的です。
GitHub Actionsの待機時間からRunner台数を見積もるには、何を使いますか。
Workflow履歴、Jobログ、Actionsメトリクス、workflow_jobの状態遷移を突き合わせます。ピーク同時Job数、各JobのRunner占有時間、失敗再実行、許容待ち時間を一つの判断カードにまとめます。
iOSテスト用とArchive用のMacを分けるべきタイミングはいつですか。
通常Testが公開用Archiveを遅らせる場合、または公開用の署名資格情報を通常Jobから隔離したい場合です。単純な性能不足だけでなく、復旧経路と資格情報の安全性も分離理由になります。
Appの発行期間だけリモートMacを増やす方法は適していますか。
ピークが発行期間に限定され、追加環境を事前に検証できるなら適しています。交付後にXcode、証明書、キャッシュ、Runnerラベルを設定する時間を見込めない場合は、常駐環境の方が安全です。
GitHub Actions iOS並列ビルドでは、単機の平均利用率が低いことと、発行時にキューが伸びることが同時に起こります。既存のWindowsやLinux環境で代替し続けると、Xcode、署名、Archive、App Store Connect対応を別経路で管理する負担が残ります。Macを購入して常時稼働させる方法もありますが、発行しない期間の遊休、故障時の回避、署名環境の復旧まで自分で持つ必要があります。
まず容量判断カードを作り、缺口がテストのピークまたは発行窓口だけにあるなら、MESHLAUNCHで利用可能な租用期間と交付方式を確認し、追加のリモートMacで並列化と復旧を検証します。長期の固定負荷や物理ポートが必要な運用には購入が向きますが、期間限定のiOS CI容量には、必要な期間だけ環境を増やす方が管理しやすい場合があります。
Macの利用条件と対応地域を確認する際も、台数だけでなく、交付後にRunnerを登録し、Xcode 27を含む対象ツールチェーンと署名設定を再現できるかまで確認してください。