GitHub Actions Mac Runner 固定か弾力運用か？2026年の構成

2026年9月5日時点で、Runner Scale Set Clientの公式リポジトリは、この仕組みをPublic Previewとして扱っています。したがって、GitHub Actions Mac Runnerの弾力的なスケールアウトは、APIに任せればMacが自動で増える機能ではなく、Macの供給と回収まで自社で組み立てる構成です。

今週は、まず直近のワークフロー記録から日常負荷とリリースピークを分けてください。負荷が安定し、リポジトリが少なく、Xcodeや依存関係の準備を毎回やり直したくないなら固定Runnerを残します。ピークが明確で、複数リポジトリの隔離が重要なら一時Runnerを加え、最終的には「固定基線＋突発用プール」を第一候補にします。

この記事を読むべきチーム

モバイル開発チームの責任者は、リリース時の待ち時間と、平常時に余るMacノードの両方を判断できます。DevOpsやプラットフォーム担当者は、Runner登録、ジョブの振り分け、ホスト回収、ログ保存の境界を確認できます。

セキュリティ担当者やリリース担当者は、証明書、キーチェーン、社内依存リポジトリを一時ノードへ渡してよいかを、運用条件付きで評価できます。

平常時のXcode CIは固定Runnerが有利です

単一リポジトリ、または信頼関係が明確な少数のリポジトリで、ジョブの発生量がほぼ一定なら、固定Runnerの方が設計を短くできます。Xcode、Ruby、依存パッケージ、シミュレーター関連の準備を保持しやすく、毎回クリーンなMacを用意する制御面も不要です。

ただし、固定とは無制限に共有するという意味ではありません。GitHubの自ホストRunnerに関する参考文書に沿って、利用可能なリポジトリ、管理者、メンテナンス時間、代替ノードを決めます。

固定構成を選ぶ条件は次の通りです。

• ワークフローの発生元を管理でき、外部から任意のジョブを受けない。
• Xcodeや依存関係の準備時間が長く、キャッシュを捨てるコストが大きい。
• 待ち時間の増加が一時的で、基線ノードの追加だけで吸収できる。
• ノード障害時に別の固定Macへ切り替えられる。
• 共有範囲をRunner Groupとラベルで制限できる。

開発者数をそのままノード数へ変換してはいけません。ワークフロー履歴から、待ち時間、実行中の占有時間、失敗原因、リリース時のジョブ種別を取り出し、どのジョブが同時に詰まらせているかを見ます。

リリースピークは一時Runnerで吸収します

バージョン公開や大規模マージの直後だけ待ち行列が伸びるなら、常設ノードを年間通じて増やす前に、ピークの性質を確認します。待ち時間が短く、Macの起動とRunner登録に同程度以上の時間がかかるなら、弾力プールを追加しても利用者の体感は改善しません。

逆に、ピークの発生時刻が予測でき、ビルド、テスト、アーカイブのジョブを分離できるなら、事前にMacを起動しておく一時Runnerが候補になります。キュー信号を受けてからノードを供給する方式は、突発負荷には向きますが、ノードの納入時間を実測しなければ判断できません。

GitHub ActionsのRunner監視とトラブルシューティング資料を参照し、次の順で確認します。

• ピーク時に増えるジョブが、並列実行できる種類か確認する。
• 待ち行列の発生からMac起動要求までの遅延を記録する。
• Macが利用可能になってからRunner登録が完了するまでを記録する。
• ジョブ終了後、登録解除、作業領域の消去、ホスト回収を個別に確認する。
• 供給失敗時に固定基線へ戻せるか、実際のリリース手順で試す。

注意： ephemeral runner の登録解除と、Macホストの完全な清掃は同じ処理ではありません。登録情報が消えても、作業領域、キャッシュ、キーチェーン、診断ログがホストに残る可能性があります。

共有Macを組織で使う場合は隔離を先に決めます

複数リポジトリでMac算力を共有する場合、最初に決めるべきなのはノード数ではなく、信頼レベルとジョブの境界です。公開コードを扱うリポジトリ、社内コードを扱うリポジトリ、署名を行うリポジトリを同じRunner Groupへ置くと、固定Runnerの残留状態がリスクになります。

Runner Groupのアクセス制御に関する公式説明を基準に、リポジトリ単位で利用範囲を制限します。さらに、Xcodeの版、Apple Siliconの有無、署名の有無をラベルで分けます。ラベルの付け方は公式のラベル管理資料と矛盾しないようにします。

この場面では、長期Runnerを使うならワークスペースと一時ファイルの消去を定期化し、外部ログへ実行結果を保存します。一時Runnerを使う場合も、登録解除だけで合格にせず、ホストの停止、ディスク消去、資格情報の撤回まで確認します。

署名ジョブは通常のビルドから分離します

通常のコンパイルや単体テストと、配布用アーカイブや署名を同じ高権限Runnerで処理する必要はありません。証明書、キーチェーン、社内パッケージ、専用ネットワークへの接続が必要なジョブは、固定Runnerの方が状態を維持しやすい一方、利用できるリポジトリを厳しく制限しなければなりません。

一時Macへ署名処理を移すなら、資格情報の注入、利用時間の制限、ジョブ後の撤回、ホスト回収を再現可能にします。秘密情報をワークフローのログへ出さないことや、外部ログの保存範囲も含めて、自ホストRunnerの安全な利用に関するGitHubの資料を確認します。

固定か一時かを決める条件は、次のように分岐できます。

• 署名資産が常時必要で、接続先も固定なら、署名専用の固定基線を選びます。
• 署名資産を短時間だけ注入でき、撤回とホスト消去を自動検証できるなら、一時Runnerを選びます。
• 通常ビルドと署名配布が混在しているなら、まずジョブを分流し、共有権限を減らします。
• 失敗時に資格情報を撤回できないなら、弾力化を止め、固定基線の隔離を見直します。

Runner Scale Set ClientはMac供給基盤そのものではありません

Runner Scale Set Clientは、Runner Scale Set APIとの連携や一時設定の生成を担う部品です。公式リポジトリが示す対象にはmacOSを含むカスタム構成がありますが、Macホストの作成、起動、初期化、停止、破棄はチーム側の基盤に残ります。

これは、Kubernetes上でRunner Podを扱うActions Runner Controllerの公式概念を、実Macの増設手順へそのまま置き換えられないという意味です。Macの電源管理、SSH到達性、macOSの初期状態、Xcodeの準備は別の運用対象です。

最低限、次の連鎖を一つの検証用ワークフローで通します。

• キュー信号が発生する。
• Macを供給し、到達性を確認する。
• Runnerを一時登録し、対象ラベルでジョブを受ける。
• ジョブ終了後に登録解除する。
• ホストを消去または回収し、外部ログを保存する。
• 起動失敗や登録失敗が起きた場合、固定基線へ降格する。

Runnerの追加手順は公式の自ホストRunner登録資料で確認できますが、登録手順を読んだだけでは、Macホストの安全な廃棄まで検証したことにはなりません。

固定・一時・混合を決めるチェックリスト

以下のチェックリストを、直近のワークフロー記録とリリース手順に照らして使います。チェックが付いた項目の選択肢を採用し、条件を満たさない項目では右側の代替案へ戻してください。

• [ ] 平常時のジョブ量が安定し、Xcodeや依存関係の準備を保持したい
  固定Runnerを選びます。障害時の代替Macとメンテナンス時間が決まっていなければ、ノード増設より先に復旧手順を整えます。

• [ ] リリースピークが予測でき、Macの事前起動が待ち行列より先に完了する
  一時Runnerを追加します。供給が間に合わなければ、キュー信号による起動をやめ、ピーク開始前の予熱へ戻して再計測します。

• [ ] 複数リポジトリを共有し、信頼レベルや署名権限を分離する必要がある
  Runner Group、ラベル、ノードプールを分割します。ホスト消去を確認できない場合は、共有一時Runnerを避け、用途別の固定基線へ戻します。

• [ ] 署名資産を短時間だけ注入し、ジョブ後の撤回とホスト回収を自動検証できる
  署名ジョブを一時Runnerへ移せます。資格情報の撤回に失敗した場合は、固定の署名専用Runnerへ戻します。

• [ ] Runner Scale Set Clientの信号と、Macの作成・回収を別々に管理できる
  弾力構成を候補にします。Macの供給、初期化、登録解除、消去、ログ保存を一つの試験手順で通せない場合は、導入を保留します。

• [ ] 制御面やMac供給が停止しても重要な配布を継続する必要がある
  固定基線を残し、突発用プールを追加する混合構成を選びます。固定基線がない場合は、全面的な弾力化を避けます。

判断を簡単にするため、次のように整理できます。

• チェックが平常負荷の項目だけに集中する場合は、固定Runnerです。
• リリースピークと隔離の項目が中心なら、一時Runnerです。
• 平常負荷、ピーク、障害継続の項目が同時に該当する場合は、固定基線＋突発用プールです。
• 署名の回収条件だけ満たせない場合は、一般ビルドだけ弾力化し、署名処理は固定Runnerへ残します。
• 供給や消去の検証項目を確認できない場合は、増設を止め、まず運用の空白を埋めます。

このチェックリストで固定条件と一時条件の両方に該当するなら、全面移行ではなく混合構成を採用します。どちらにも該当しない場合は、直近の失敗ジョブと待ち時間を再分類し、容量ではなくジョブの流れに問題がないかを確認します。

障害時は固定基線へ戻せる構成にします

弾力制御面が停止した場合、Macの起動に失敗した場合、Runner更新が壊れた場合、外部ログが保存できない場合を先に想定します。リリースを止められないチームでは、固定基線を残し、突発ジョブだけを一時プールへ送る方が復旧手順を短くできます。

一時プールには最大待ち時間を設定し、超過したら自動で再試行を続けるのではなく、拡張を一時停止して担当者へ通知します。署名ジョブを無条件に別ノードへ再送すると、資格情報の状態を追跡できなくなるため、手動接管の条件も決めておきます。

経験則： 「ノードが増えた」ことではなく、「キュー発生から回収とログ保存までが再現した」ことを成功条件にしてください。供給だけ成功しても、回収に失敗すれば次のジョブへ汚染を持ち越します。

平常時まで全ノードを持ち続ける構成は、ピーク以外のアイドル時間、保守対象、署名資産の管理負担を抱えます。一方、すべてを一時Runnerへ移す構成は、Macの供給失敗、ツールチェーン準備、署名回収の複雑さを増やします。

そのため、まずシナリオごとに日常基線とリリースピークを分け、実際のワークフローで弾力化を試すのが妥当です。年間を通して全台を保有する必要がない場合は、JexMacのレンタル期間と料金を確認し、必要な期間だけMacを用意する方法も比較対象になります。CIノードとしての接続性、SSH、ログ、回収条件まで含めて試したい場合は、Macレンタルの利用手順を確認したうえで、小さなリリースジョブから検証するのが安全です。

よくある質問