最初に結論を出すと、GitHub Actions Runner Scale Set Clientは、Macノードの自動納品、初期化、回収、外部ログ保存まで用意できるチームの小規模な試行に向いています。クライアントを導入するだけでMacが自動的に増える製品ではないため、供給基盤が未整備なら固定Runner池を残し、予熱ノードと手動拡張の二重運用から始めてください。

今週の推奨アクションは、まず1台の使い捨てMacで「納品、JIT登録、ジョブ実行、自動注销、ログ転送、ノード再作成」を通しで検証することです。2026年9月6日時点では、公式リポジトリがRunner Scale Set ClientをPublic Previewとして扱っているため、いきなり本番の署名・リリース経路へ入れる判断は避けます。ステータスは公式リポジトリの説明で再確認してください。

この記事は、複数のMac Runnerを管理し、キューに応じてノードを増減したいDevOpsエンジニア向けです。署名タスクを分離したいモバイル開発基盤チーム、固定ノード、予熱池、タスク単位の一時ノードを比較しているCI責任者にも適しています。

まず「拡張信号」と「Mac供給」を切り分ける

Runner Scale Set Clientの役割は、Scale Set APIから拡張・縮小の信号を受け取り、JIT設定を使ってRunnerの稼働状態を組み立てることです。Macの購入、レンタル、起動、macOSの初期化、Xcodeの導入、ノードの破棄までを代行する仕組みではありません。公式READMEの処理フローでも、クライアントと実行基盤の責任を分けて考える必要があります。

判断の最初の証拠は、管理画面上の「要求を受け付けた」という記録ではなく、次の交付ログです。

  • Macノードの割り当て要求と実際の起動記録
  • macOS、Xcode、Simulator runtime、依存パッケージの初期化結果
  • Runner登録とジョブ受信の記録
  • ジョブ終了後の自動注销、ディスク消去、ノード回収
  • 途中で失敗した場合の再作成と旧ノードの隔離

この流れのどこかを人手で補っているなら、実態は弾力的なScale Setではなく固定池への補助制御です。自動交付の失敗を記録できない状態で「自動拡張済み」と扱うと、キューが増えた瞬間にMac不足と復旧不能が同時に起きます。

ノード供給と環境復元を先に検証する

Mac Runnerの登録が成功しても、Xcodeプロジェクトを実際にビルドできるとは限りません。Runner Scale Setは、Macイメージの作成、グラフィックセッション、証明書の配置、依存関係の復元を自動で解決しないためです。

検証は次の3段階に分けます。これは一般的な所要時間の基準ではなく、あなたの環境で再現性を確認するための順序です。

  1. 完全な新規ノードで初回ビルドする
    Xcodeのバージョン、Simulator runtime、Swift PackageやCocoaPodsなどの依存関係をゼロから復元します。Runnerが接続できるかではなく、実際のビルドが完了するかを確認します。

  2. 同じノードでキャッシュ利用時のビルドを行う
    キャッシュの復元に失敗した場合でも、ジョブが古いワークスペースを偶然参照していないかを調べます。キャッシュは再生成可能な成果物として扱い、秘密情報の保管場所にしないでください。

  3. ノードを破棄してから再構築する
    以前の署名状態、DerivedData、作業ディレクトリが残っていない新規ノードで同じ結果になるかを見ます。ここで失敗するなら、JIT Runnerを増やす前に環境構築をコード化する必要があります。

Xcodeの初期化処理を手作業のリモートログインに依存させると、ノード数が増えた時点で再現性が崩れます。環境定義、依存関係の固定、キャッシュの復旧、署名情報の投入を別々のログとして保存してください。

ライフサイクル別にMac Runnerの隔離を比較する

運用方式は、次の対照リストで判断できます。優劣を一律に決めず、ジョブの機密性、キャッシュ依存、復旧方法を並べてください。

長期稼働Runner

  • 待ち時間とキャッシュを管理しやすい
  • ワークスペース、環境変数、認証情報が残りやすい
  • ジョブ失敗後の状態汚染を検知しにくい
  • 少数の安定した開発ビルドや専用検証環境に向く

タスク単位の一時Runner

  • ジョブごとにノードを破棄しやすく、ワークスペースの再利用を抑えられる
  • Xcodeや依存関係の復元処理が毎回必要になる
  • ノード供給の失敗が、そのままキュー待ちへ波及する
  • 公開リポジトリや信頼できないプルリクエストを含む経路では、長期Runnerより隔離しやすい

予熱済みの一時ノード

  • Macを先に初期化し、ジョブ投入時の待ち時間を抑える設計です
  • 予熱中のアイドル時間と、ノードの状態監視がコストになります
  • 署名用と一般ビルド用で別の池を作りやすい反面、池ごとの設定差分が増えます

GitHub公式ドキュメントは、一時的な自前Runnerを使い、ジョブ後に破棄する考え方を示しています。自前Runnerのライフサイクルに関する公式説明と、JIT Runnerの安全な利用方法を確認し、登録情報やトークンをログへ出さない構成にしてください。

注意：Runnerがジョブを受け取れることは、安全に本番投入できることを意味しません。公開リポジトリ、外部からのプルリクエスト、署名・リリース処理は、同じMacノード池へ混在させないでください。

キュー待ちと初期化を別の指標で記録する

「ワークフロー全体が遅い」という記録だけでは、予熱池が必要か判断できません。少なくとも次の4区間を分けて保存します。

  • キューに入ってからMac割り当て要求が受理されるまで
  • Macノードの起動・納品が完了するまで
  • Xcode、依存関係、証明書などの環境準備が終わるまで
  • Runnerが登録され、実際にジョブを開始するまで

この分解を行うと、JIT Runnerの登録は速いのにMacの納品が遅い、あるいはノードはすぐ使えるのにXcode準備で詰まる、といった原因を分離できます。汎用的な秒数や同時実行数を当てはめるのではなく、実際のキュー記録とノード交付記録から判断してください。

比較する案は次の3つです。

  • 純粋なJIT方式：アイドルノードを持たず、タスク発生時にMacを作成します。利用率は管理しやすい一方、初回待ち時間と供給失敗の影響を受けます。
  • 最小の予熱池：一定数の初期化済みノードを待機させます。待ち時間を抑えやすい一方、未使用時間と状態監視が発生します。
  • 固定Runner池：ノードを常時維持します。環境の安定性は確認しやすいものの、負荷の少ない時間にも維持費と保守作業が続きます。

権限とログが本番移行の境界になる

認証方式は、GitHub Appと個人アクセストークンを同じものとして扱わないでください。比較する項目は、必要権限の範囲、発行主体、ローテーション担当、漏えい時の影響、失効後の復旧手順です。組織やリポジトリ、App ID、トークン、ノード名、パスはすべて環境変数やプレースホルダーで管理し、実ログへ直接出さない構成にします。

JIT設定の生成とRunner登録については、組織レベルのJIT設定を生成するREST APIを確認してください。APIのリクエストとレスポンス、認証条件は変更される可能性があるため、実装時には2026年版APIパラメーターの公式資料も突き合わせます。

ログはMacノードの中だけに残してはいけません。Runnerの登録、ジョブ開始、終了、破棄、失敗理由をノード外へ転送し、ノードが消えた後も失敗ジョブを追跡できる状態にします。公開リポジトリと非信頼の変更を受けるジョブでは、ログに秘密情報が混ざらないマスキングも確認してください。

GitHub Actions Runner Scale Set Clientを導入する6段階

導入を検討するなら、次の順序で小さく検証します。

  1. 対象ジョブを分ける
    まず通常の開発ビルドだけを対象にし、署名やリリースジョブを除外します。失敗しても配布物へ影響しないワークフローを選びます。

  2. Macの交付契約を決める
    起動要求、利用可能、初期化失敗、回収済みという状態を定義します。人が管理画面を見て判断する状態を残さないでください。

  3. JIT登録を使い捨てノードで検証する
    Runner Scale Setの公式概念説明を参照し、登録情報の発行からジョブ終了後の自動注销までを確認します。

  4. Xcode環境を再構築する
    新規ノード、キャッシュ利用ノード、破棄後の再作成ノードで同じビルドを実行します。結果だけでなく、復元ログと失敗時の中断処理を保存します。

  5. ログと認証を外部から検証する
    ノードを削除した後でも、どのジョブがどの状態で失敗したか追跡できるかを確認します。トークン、証明書、署名鍵がログやキャッシュに残っていないことも確認します。

  6. 試行・二重運用・保留を決める
    自動交付と回収が安定し、ログも外部保存できるなら通常ビルドで試行します。負荷は変動するが自動化が不完全なら固定池と予熱ノードを併用します。タスクが安定していてノード数も少ないなら、当面は固定Runnerを維持します。

FAQ：導入前に分けて考える論点

Runner Scale Set ClientでmacOSの自前Runnerを管理できますか？

macOSの自前Runnerと組み合わせることはできますが、Macホストの作成機能そのものではありません。Scale Setの信号とJIT設定を受け取るクライアント、Macを供給する基盤、macOS環境を初期化する処理を分けて設計してください。

GitHub ActionsのMac Runnerをキュー連動で増やす方法は？

キューの監視だけでなく、Macの割り当て、初期化、Runner登録、ジョブ後の回収までを自動化します。納品に失敗した場合の再作成と、失敗したノードを再びジョブへ割り当てない状態管理がない場合は、固定池を残すべきです。

Mac Runnerは一時ノードと長期稼働のどちらがよいですか？

通常の開発ビルドは一時ノードを試せますが、キャッシュとXcode復元の検証が前提です。コード署名やリリースは、専用のノード池と厳格な破棄処理を用意し、長期稼働Runnerとの共有を避けます。

Kubernetesなしでも利用できますか？

利用できます。ただし、Kubernetesが不要という意味は、運用機能も不要という意味ではありません。Macの供給、状態管理、失敗時の再試行、ログ転送を別の自動化基盤で実装する必要があります。

JIT RunnerでXcodeキャッシュと署名情報をどう分けますか？

キャッシュは再生成できる依存関係やビルド中間生成物に限定し、署名鍵や証明書を共有キャッシュへ入れないでください。JIT Runnerの破棄後に秘密情報が残らないことを確認し、署名ジョブは通常のビルドから分離します。

固定Mac池と弾力運用の総コストを比べる

費用を実行時間だけで比べると、判断を誤ります。Macのレンタル期間、予熱中のアイドル、環境準備、失敗ノードの再構築、ログ保存、人が対応する保守時間を分けて記録してください。

固定池は構成を安定させやすく、少ないノードで負荷がほぼ一定なら運用が単純です。一方で、繁忙期以外もノードを維持し、Xcodeや証明書の更新を同じ環境へ適用し続ける必要があります。

按分運用は負荷変動へ対応しやすい一方、Macの供給基盤、初期化スクリプト、回収監視、ログ保管という管理対象が増えます。自動化が未完成なら、待ち時間の短縮より障害時の切り分け負担が大きくなる可能性があります。

あなたの判断は次の3段階に落とせます。

  • 試行：Macの自動交付、JIT登録、単一ジョブ後の回収、外部ログが一通り確認できる。
  • 二重運用：負荷変動はあるが、自動供給または環境復元の一部が不安定。固定池を本番用に残し、予熱・一時ノードを限定的に使う。
  • 保留：ジョブ数が安定している、ノードが少ない、または失敗時に手動復旧が必要。Scale Set導入より固定Runnerの改善を優先する。

現在の固定Macや自前のMac mini構成は、環境を保ちやすい反面、繁忙期だけ増やしにくく、故障交換やmacOS・Xcode更新を担当者が抱え、遊休時間にも保守コストが発生します。反対に、VMSPINのMacレンタルを試験ノードとして使えば、購入前に独立したMacを用意し、納品・初期化・回収の検証を進めやすくなります。まずは日本語のMac利用プランと料金案内を確認し、公開しても問題のない開発ビルドだけで試してください。

今週はリリース署名を切り離した検証用ワークフローを作り、VMSPINのMacノードで一連のライフサイクルを記録します。交付失敗、環境復元、ログ欠落のいずれかが残るなら固定Runnerへ戻し、証拠がそろった段階で予熱池や追加ノードへ広げるのが安全です。