GitHub Actions Runner Scale Set Clientは、2026年のMac CIで試す価値がありますが、固定Mac Runnerをすべて置き換える用途には向きません。Macの供給、初期化、タスク後の消去、外部ログ保存、障害時の固定池への切り替えまで実装できるなら、PR検証などの再構築可能なジョブだけを弾力的な池へ移してください。
管理対象は、複数リポジトリのGitHub Actions Mac Runnerやリリースピーク時の待ち行列です。残留データ、署名資格情報、Mac容量のTCOを同時に見直したいIT責任者、プラットフォームエンジニア、技術部門責任者に向けた判断材料をまとめます。
SECTION 01先に決めるべき適用境界
GitHubが提供するのはScale Set API、JIT構成、クライアントコンポーネントです。macOSホストの作成、初期化、Runnerの登録、作業領域の消去、ホストの廃棄は企業側の責任であり、クライアントを導入しただけで実機Macが自動的に用意されるわけではありません。公式のactions/scalesetリポジトリでも、拡張機構と利用者側のインフラ実装を分けて説明しています。
2026年9月20日時点で、macOSを含むカスタムインフラストラクチャ対応は確認されていますが、Runner Scale Set ClientはPublic Previewです。GitHub Changelogの公開プレビュー説明を確認し、正式提供と誤認しないでください。
| 選択肢 | 向いているジョブ | 必要な運用能力 | 主な否決条件 |
|---|---|---|---|
| 固定Mac池 | 本番署名、低遅延ビルド、常時利用 | パッチ、容量監視、長期的な環境管理 | ピーク時だけ大量の待ち行列が発生する |
| Scale Set弾力池 | PR検証、使い捨ての回帰処理、非署名ジョブ | Mac供給、初期化、消去、ログ転送、再試行 | ホストを安全に再構築できない |
| 混合池 | PRは弾力池、署名と重要リリースは固定池 | ジョブ分類、権限境界、障害時の切り替え | 信頼境界を分けられない、代替池がない |
最初の否決条件は、ピークの大きさではありません。Macを自動で再構築できないこと、失敗したノードを確実に隔離できないこと、本番署名を専用境界へ置けないことのいずれかです。これらが解消されない限り、固定池の拡張またはMACNOXのような管理済みのMacレンタル環境を比較する方が現実的です。
SECTION 02容量指標と待ち行列
Scale Set Clientの導入効果は、イベントの受信数ではなく、実際の待ちジョブと供給可能なMac数で判断します。TotalAssignedJobs、実行中ジョブ、待機中ジョブ、利用可能なMacを別々に記録し、1件の通知を1台のMac作成命令として扱わないでください。公式READMEの拡張処理説明が示すように、割り当てと実行環境の供給は別の責務です。
企業側では、リポジトリ別に次の記録を持ちます。
- ジョブ到着時刻と待機開始時刻
- Macホストの供給開始から利用可能までの時間
- Runner登録から最初のジョブ受信までの時間
- 実行中、待機中、失敗、再割り当ての状態
- 供給失敗時に固定池へ切り替えられたか
完全なオンデマンド方式は空き容量を抑えやすい一方、ピークの最初のジョブがホスト起動を待ちます。最小限の予熱容量を持つ方式は待ち時間を抑えやすい一方、利用されない時間のコストが発生します。固定池は挙動が読みやすい反面、プロジェクト間でピークが重なると、追加のMacを確保するまで待ち行列が伸びます。
ここで必要なのは、一般的な「何台あれば足りる」という回答ではありません。過去のキュー記録から、到着分布、ジョブの同時実行数、ホスト供給の失敗率を確認し、予熱容量を段階的に決めることです。
SECTION 03JIT Runnerと消去境界
JIT Runnerは短期的なRunner登録と削除の設計に使えますが、Runnerの登録ライフサイクルとmacOSホストのライフサイクルは同じではありません。自托管Runnerの公式リファレンスを基準に、次の境界を分けて監査してください。
- Runner登録：GitHub上で実行対象として認識される期間
- macOSホスト：OS、ユーザー、インストール済みツールが残る期間
- ワークスペース：ソース、生成物、DerivedData、依存キャッシュが残る期間
- Keychain：証明書、秘密鍵、トークンが利用可能な期間
一時Runnerが自動的に登録解除されても、同じMacが再利用されれば、前のジョブのファイルや認証情報が残る可能性があります。特に、信頼できないブランチからのPR検証と、本番署名を同じホストへ割り当てる設計は避けてください。GitHubのSecure use referenceでも、信頼境界と秘密情報の扱いを分離して検討する必要があります。
注意：JIT Runnerを導入したことは、ホスト消去の証明ではありません。次のジョブを受け入れる前に、作業領域、キャッシュ、Keychain、ユーザーセッション、ログをどの方法で初期状態へ戻したかを証跡として残してください。
SECTION 04起動遅延と環境交付
弾力的なMac CIでは、次の段階を一つの「起動時間」にまとめないことが重要です。
- Macホストが供給されるまで
- OSが利用可能になり、必要なロック解除が完了するまで
- Runnerが登録されるまで
- Xcodeと依存コンポーネントが初期化されるまで
- 最初のジョブを受信するまで
完全なオンデマンド、最小予熱、固定基盤の三方式を、同じジョブで比較してください。Xcodeの初期化、コンポーネント取得、署名環境の準備に必要な時間は、企業のイメージ、接続条件、キャッシュ方針によって変わるため、一般的な固定値を採用してはいけません。
受け入れ条件は、平均値だけでは不十分です。ピーク時間帯の待機時間、供給失敗時の再試行、初回ジョブの失敗率、固定池への切り替え完了を記録します。Apple Silicon環境を採用する場合も、Xcode、依存ライブラリ、既存のスクリプトが同じCPUアーキテクチャで動作するかをリポジトリ単位で確認してください。
SECTION 05制御面と障害復旧
Scale Set Clientの認証には、GitHub Appや適切なアクセストークンの権限設計が必要です。公式認証説明とRunnerのアクセス管理文書を参照し、リポジトリ、組織、Runner groupの境界を先に決めてください。
確認すべきなのは、クライアントプロセスが再起動するかだけではありません。メッセージ確認、重複配信、Runner登録の失敗、Mac供給の失敗、ノード失踪後の再割り当てを含めて検証します。診断ログは一時Macの破棄前に外部ストレージへ転送し、ジョブID、ホストID、Runner状態を関連付けておく必要があります。
障害時の最低限の経路は、次のように定義します。
- クライアント停止：同じMacで無限再起動せず、監視から隔離してログを回収する
- Mac供給失敗：固定Mac池または予備のリモートMacへジョブを戻す
- Runner登録失敗：資格情報を再利用せず、短期資格情報を再発行する
- ノード失踪：未完了ジョブを再試行し、残留した署名情報を失効対象にする
公式の監視・トラブルシューティング文書を参照し、クライアントの復旧とCIサービス全体の復旧を別の指標として扱ってください。
SECTION 06TCOと混合ノード池
TCOは、Macの利用料だけでなく、次の変数を足し合わせて比較します。
固定容量費 + 予熱容量費 + オンデマンド容量費 + 自動化開発費 + 監視・ログ保管費 + 失敗時の再実行費 + 障害によるリリース遅延費
固定購入では、資産の減価、保守、交換、設置場所、予備機の確保が加わります。レンタルや管理済みMacでは、利用期間、接続方式、必要な専用容量、障害時の切り替え条件を確認します。金額や削減率は契約条件と地域によって変わるため、出典のない節約率を前提にしないでください。料金比較を始める場合は、まずMACNOXの日本語料金案内で比較対象の契約単位を確認してください。
ジョブの分類は、次のようにすると判断しやすくなります。
- PR検証：再構築可能で、弾力池へ移しやすい
- シミュレーター回帰：容量変動を測定し、信頼できるイメージに限定する
- アーカイブ作成：依存関係とXcodeを固定し、予熱または専用池で管理する
- 本番署名：署名資格情報を持つ専用Macへ分離する
判断の着地点
固定池を継続するのは、ジョブ量が安定し、起動待ちよりも環境の再現性を優先する場合です。Scale Setの限定試行は、PRジョブを再構築可能なMacへ移せ、消去証跡と外部ログを確認できる場合に限ります。
混合池を構築するのは、ピーク容量を増やしたい一方で、本番署名と低遅延ジョブを固定境界に残す必要がある場合です。これは単なる容量対策ではなく、信頼度の異なるジョブを異なるMacライフサイクルへ割り当てる設計です。
Scale Set Clientは、Macの供給を魔法のように速くする機能ではありません。GitHubの制御面と、企業が管理する実機Macのライフサイクルを接続する部品です。まずは再構築可能なPRビルドを限定的に移し、起動、回収、ログ、固定池への切り替えを確認してください。現在の自前Mac運用は、初期購入、予備機、保守、ピーク時の遊休容量を抱えやすく、全ジョブを弾力化する運用は障害時の切り分けも複雑になります。必要な期間だけ実機Macを確保し、固定池の代替経路まで検証したい場合は、MACNOXのMacレンタル構成を比較対象に含めると、購入一択ではない混合池のTCOを具体化できます。
SECTION 07よくある質問 FAQ
Runner Scale Set ClientだけでMacのビルド機を自動作成できますか？
できません。クライアントはScale Set APIからジョブ情報を受け取り、Runnerの登録や処理を仲介しますが、実際のMacを作成、初期化、消去、廃棄する仕組みは企業側で用意する必要があります。物理Macや専用ホストを使う場合は、供給失敗時の代替経路も先に設計してください。
GitHub Actionsの弾力的なMac RunnerにはKubernetesが必須ですか？
必須ではありません。Kubernetesは供給コントローラーやワークロード管理に利用できますが、Runner Scale Set Client自体は、企業が用意したMacのライフサイクル管理方式を限定していません。Kubernetesを導入しても、macOSホストの起動、ログ取得、消去、署名情報の管理は別途検証が必要です。
JIT RunnerでXcodeの作業領域と署名資格情報を分離できますか？
JIT RunnerはRunner登録の短期化に役立ちますが、それだけでMac全体が消去されるわけではありません。同じホストを再利用すれば、ソース、DerivedData、キャッシュ、Keychainの情報が残る可能性があります。信頼できないブランチと本番署名を同じ弾力的な実行環境へ置かない設計が必要です。
固定Mac Runnerと弾力的なScale Setはどう分担すべきですか？
再構築でき、署名資格情報を必要としないPR検証や一時的な回帰処理は弾力的な池へ移し、リリースアーカイブ、本番署名、低遅延が重要なジョブは固定または専用のMacへ残す構成が安全です。ジョブの信頼境界、起動待ち時間、障害時の代替経路を基準に分けてください。