ビルド待ち時間が伸び、Xcodeの再導入と署名設定まで毎回やり直しているなら、Runnerの形態が業務に合っていない可能性があります。
低頻度で変動の大きいジョブはGitHubホステッドRunner、固定環境・私有ネットワーク・持続キャッシュが必要な本番ビルドは自前運用のMacが適しています。多くの企業では、ホステッドと自前運用を組み合わせる構成が最も現実的です。
本稿は、複数のiOSプロジェクトを管理し、GitHub Actionsの利用量や待ち時間を抑えたいプラットフォーム責任者向けです。署名証明書、社内ネットワーク、Mac構築ノードの購入またはレンタルを評価するIT責任者にも役立ちます。
[ SECTION_01 ] 先に決めるべき選定境界
最初に見る指標は、月間ビルド時間だけではありません。次の5項目を2週間分記録すると、Runnerの候補が絞れます。
- 月間の実行時間とジョブ数
- ピーク時の同時実行数と待ち時間
- 私有リポジトリ、社内API、VPNへの接続要件
- Xcode、SDK、証明書、キャッシュを固定する必要性
- 失敗時に復旧を担当できる人員と目標復旧時間
| 判断指標 | GitHubホステッドRunner | 自前運用のmacOS Runner | 混合構成 |
|---|---|---|---|
| 低頻度・変動の大きいビルド | 適しています | 空き時間の費用が発生しやすいです | 検証を担当します |
| 固定Xcode・SDK | ジョブごとの準備が必要です | 環境を固定しやすいです | 本番だけ固定します |
| 私有ネットワーク | 接続方式の確認が必要です | 社内経路を設計しやすいです | 本番経路を分離できます |
| 持続キャッシュ | 毎回の初期化を考慮します | キャッシュを保持できます | 大容量処理だけ保持します |
| 突発的な並列増加 | 追加ノードを使いやすいです | 容量上限があります | 余剰分を逃がせます |
| 運用責任 | GitHub側の比率が高いです | 自社または委託先が負います | 役割を分担します |
GitHubのホステッドRunnerでは、通常のジョブごとに新しい仮想マシンが用意されます。標準のプライベートリポジトリ向けmacOS Runnerには、M1の3コア、7GBメモリ、14GB SSD、arm64構成のラベルがあります。ラベルやイメージは変更されるため、固定運用ではGitHub-hosted runnersの公式仕様を確認してください。
[ SECTION_02 ] コストは実行分数ではなくTCOで比較する
GitHub Actions macOS Runner 選定で起きやすい失敗は、ホステッド側の分単価とMac本体価格だけを比べることです。自前運用には、初期構築、空き容量、更新、監視、障害対応、担当者の工数が含まれます。
ホステッド側の計算式は次の形です。
月額コスト ＝ 課金対象の実行分数 × macOS Runner単価 ＋ 並列実行に伴う追加費用 ＋ キャッシュ不成立による再取得時間
自前運用側は次のように分解します。
月額TCO ＝ Mac資源費 ＋ 保守・設置費 ＋ 初期構築費 ÷ 利用予定月数 ＋ 監視・障害対応工数 ＋ 空き容量の機会費用
GitHub Actions Runnerの公式料金表では、標準macOS 3コアまたは4コアの単価が1分あたり0.062米ドル、macOS 5コアのM2 Pro大型Runnerが1分あたり0.102米ドルと掲載されています。ジョブの分数は1分単位に切り上げられます。料金プランや対象Runnerが異なるため、実際の請求額は企業アカウントの請求画面で照合します。
自前運用の入力欄には、次の項目を入れてください。
- Macの購入費またはレンタル費
- XcodeとSDKの初期導入時間
- 月次のmacOS、Xcode、Runner更新時間
- 障害1件あたりの調査と復旧時間
- 監視、バックアップ、証明書ローテーションの工数
- 使われない時間帯の容量
- 追加ノードを確保する費用
この計算で、実行量が少ないのに自前運用を選ぶケースもあります。理由は、私有ネットワーク接続や固定署名環境の価値が、単純な実行分数より大きいからです。逆に、長時間稼働してもジョブが断続的で、担当者が保守できない場合はホステッドの方が管理しやすくなります。
Macの購入費、設置場所、故障時の交換体制まで含めて検討する場合は、Mac miniの企業導入条件も別に整理してください。ハードウェアの所有とRunnerの運用責任は、同じ問題ではありません。
[ SECTION_03 ] スループットはピークと定常を分けて測る
ホステッドRunnerは、突発的なジョブを処理しやすい一方、毎回の環境準備がビルド時間に加わります。自前運用のMacは、ツールや依存関係を保持しやすく、定常的なビルドでは準備時間を抑えられます。ただし、ノードが埋まるとジョブは待機し、空きノードが戻らなければキューが伸びます。
比較時は、同じリポジトリ、同じXcode、同じ依存関係、同じテスト範囲で測定します。別プロジェクトの結果を並べると、CPU性能ではなく、キャッシュやテスト数の差を見てしまいます。
測定手順は次のとおりです。
第一歩：基準ワークフローを固定する
checkout、依存関係の取得、コンパイル、ユニットテスト、アーカイブ、署名、成果物保存を同じ順番にします。キャッシュを使う場合と使わない場合を分け、ログには各ステップの開始・終了時刻を残します。
第二歩：ピーク時のキューを記録する
通常時間だけでなく、Pull Requestが集中する時間帯も測定します。待ち時間、実行時間、失敗率を別々に記録します。自前運用Runnerでは、オンラインだが処理中のノード数も必要です。
第三歩：増設条件を決める
定常的なビルドは自前運用へ送り、夜間やリリース直前の急増分はホステッドへ回す方法が有効です。ジョブのruns-onラベルとRunner Groupを用途別に分けると、同じワークフロー内でも経路を制御できます。
自前運用Runnerは、オンラインかつアイドル状態で、ラベルとグループが一致するノードへ割り当てられます。該当ノードがなければジョブは待機し、24時間を超えてキューに残ると失敗します。したがって、ノード数は平均負荷ではなく、復旧時間とピーク並列数から決めます。詳しい条件は自前運用Runnerの公式リファレンスで確認できます。
[ SECTION_04 ] Apple Siliconと環境固定を別々に評価する
Apple Silicon対応だけで、自前運用が必要になるわけではありません。GitHub公式のmacOS arm64 Runnerでは、公式Actionは対応していますが、コミュニティ製Actionは個別確認が必要です。Rosetta依存のスクリプト、古いバイナリ、小規模な社内ツールは、arm64でそのまま動かない場合があります。ホステッド環境の制約は、macOS Runnerの公式仕様と実際のワークフローで照合してください。
次の条件がある場合は、自前運用のMacを優先します。
- 特定のXcodeとSDKを長期間固定する
- 社内でしか取得できない依存関係がある
- 大容量の依存キャッシュを維持する
- 専用の署名証明書やキーチェーンを使う
- Apple Siliconで未検証のActionを利用する
- 端末識別子や接続先を固定する必要がある
一方、毎回クリーンな環境で検証したい場合は、ホステッドRunnerの方が適しています。自前運用は環境が残るため、前のジョブが生成したファイル、認証情報、設定変更が次のジョブへ影響する可能性があります。
[ SECTION_05 ] セキュリティはRunner Groupとワークフロー権限で決まる
自前運用Runnerの最大の問題は、Macを用意することではありません。悪意のあるワークフローが、Runner上の秘密情報やネットワーク経路へ到達する可能性です。
GitHubは、公開リポジトリのフォークからPull Requestを作成し、危険なコードを自前運用Runnerで実行されるリスクを理由に、原則としてプライベートリポジトリでの利用を推奨しています。自前運用Runnerを追加する際の制限は、GitHub公式のセキュリティ警告に沿って確認してください。
企業では、次の順で分離します。
- 公開リポジトリと署名用Runnerを同じグループに置かない
- リリース用、テスト用、開発用のRunner Groupを分ける
- Groupへのアクセスを許可したリポジトリだけに限定する
- 可能なら許可ワークフローを指定する
GITHUB_TOKENとクラウド資格情報を最小権限にする- 証明書をジョブ開始時だけ取り込み、終了後に削除する
- 作業ディレクトリ、キーチェーン、ログ、キャッシュをジョブ後に確認する
- Runner自身の管理権限とリポジトリ管理権限を分離する
Runner Groupは、Runnerをまとめるだけでなく、リポジトリへのアクセス境界として使えます。組織単位で対象リポジトリを選び、ワークフロー制限や同時実行数を設定できます。詳細はRunner Groupの公式仕様を参照してください。
注意：自前運用Runnerを「社内ネットワークにあるから安全」と判断してはいけません。ネットワークへの到達範囲、ジョブを実行できるリポジトリ、証明書の保存場所を別々に評価する必要があります。
[ SECTION_06 ] よくある判断をFAQで整理する
ホステッドと自前運用は、企業ではどちらが適していますか
低頻度で変動するジョブはホステッド、固定環境や社内接続を必要とするジョブは自前運用が基本です。環境要件とピーク負荷が混在する場合は、混合構成にして役割を分けます。
self-hosted runnerへ移行するタイミングはいつですか
実行時間の合計だけでなく、待ち時間、キャッシュ再構築、証明書設定、私有ネットワーク接続を評価します。月間利用量が少なくても、リリース作業の固定性や秘密情報の管理が重要なら、専用Runnerを先に導入する判断があります。
自前運用MacのTCOには何を含めますか
Macの資源費だけでなく、初期構築、更新、監視、障害復旧、空き容量、担当者の工数を含めます。ホステッド側も、課金分数だけでなく、毎回のツール導入とキャッシュ不成立による追加実行時間を入れて比較します。
署名証明書を複数プロジェクトで共有してもよいですか
無条件の共有は避けます。リポジトリとRunner Groupを用途別に分け、証明書の利用範囲、保管場所、取り込み時間、削除確認を決めます。署名専用ノードへ通常のPull Requestを流さない運用が必要です。
ホステッドRunnerとリモートMacは併用できますか
併用できます。通常のテストや一時的な並列増加はホステッドへ、固定Xcode、署名、社内API接続が必要な処理はリモートMacへ送ります。ラベル設計を先に決めると、構成変更時の影響を抑えられます。
[ SECTION_07 ] 運用責任まで含めた最終スコア
最終評価は、コストだけでなく、次の5軸を5点満点で採点します。
- コスト予測性
- ピーク時の処理能力
- 環境とキャッシュの固定性
- 秘密情報とネットワークの分離
- 障害時の復旧責任
低頻度の小規模チームは、ホステッドを4点以上、自前運用を2点以下とするケースが多いです。安定した本番ビルドでは、自前運用が環境固定とキャッシュで上回りやすくなります。複数プロジェクトを持つ企業では、ホステッドを弾性容量、自前運用を制御された本番容量として採点するのが現実的です。
判断の順番は、次の一枚に集約できます。
- 私有ネットワークが不要で、負荷が変動するならホステッド
- 固定Xcode、永続キャッシュ、署名環境が必要なら自前運用
- ピークだけ増えるなら、ホステッドを追加する混合構成
- 公開リポジトリのコードを署名用Runnerで実行する必要があるなら、設計を止めて権限境界を見直す
- 24時間以内の復旧が必要なら、予備ノードと監視をTCOへ加える
自社でMacを購入する場合と、Mac miniの導入条件を地域別に確認する場合では、資産保有、交換、設置、運用担当者の責任が変わります。価格だけでなく、障害時に誰が復旧するかを比較することが重要です。
GitHubホステッドだけで運用すると、固定環境の再構築、私有ネットワーク接続、署名設定の制約が残ります。自社所有のMacだけに寄せると、空き容量、故障対応、ピーク時の並列不足、更新作業が負担になります。2週間分のワークロードを集計し、本番タスクに固定Xcodeや私有接続が必要と判定された場合は、NOVAKVMのリモートMac構築ノードを候補に加えると、購入前に必要容量と運用分担を比較しやすくなります。NOVAKVMのMac環境も、候補整理の入口として確認できます。