GitHub Actions 自ホストmacOS Runner | 弾性プールと常駐ノード（2026）

iOS／macOS チームが短いサイクルで出荷するとき、CI の負荷は平坦な直線にはなりません。同じ時間帯に複数ワークフローが重なる「短い山」が立ちます。GitHub ホストの macOS 分数もすぐに足りなくなるため、多くの組織が Apple ハードウェア上の 自ホスト Runner を足します。次の分岐点は、出入りする 弾性プール と、温かいまま待機する 常駐ノード のどちらで持つかです。答えはベンダーのスローガンではなく、キュー形状、許容できる遅延、そして キャッシュの置き場 にあります。

p95

キュー＋コールドスタート予算

Duty

稼働率（忙しい時間／遊休）

Cache

既定ブランチのヒット率目標

容量を買う前にピーク形状を描く

忙しい分数は疎だが 同時実行の山は高いとき──月に数日だけ Runner を6台欲しいが、普段は2台で足りる──は弾性プールが有利になりやすいです。一方、仕事が時間帯を跨いで途切れない夜間ビルド、PR マトリクス、常時待機のボットまで含むなら常駐ノードが有利です。Actions ログから7日分の Runner 時刻を取り、キュー深さの中央値、queued から in_progress までの p95、同一ホスト上で署名資産を奪い合う頻度を描いてください。p95 の待ち時間が「開発者が許容するアイドル時間」を超えているなら、弾性で台数を増やすのは 追加マシンが待ち行列の伸びより先に実行可能になる ときだけ意味があります。さもなければ、コールドスタートのコストがキュー待ちに上乗せされます。

App Store 週の圧と「買うか借りるか」の整理は、別の意思決定マトリクスに分けました。財務チェックとして流用できます：2026年の突発ビルドとApp Store審査：Macを買うか、日額／週額でクラウドMacを借りるか？

遅延はひとつのスローガンではなく三つの数値

制御面の遅延（Runner がジョブを拾うまで）、データ面の遅延（git fetch、キャッシュ復元、アーティファクト転送）、ツール面の遅延（Xcode コンパイル）に分けて観測します。弾性プールはラベル分けで制御面の競合を減らせますが、新しい VM が毎回5分の依存ブートストラップを繰り返すなら、壁時計はほとんど動きません。常駐 Runner はそのブートストラップを数百ジョブに分散して償却する代わりに遊休電力と、イメージを固定しないときのドリフトリスクを抱えます。

ネットワーク経路も要です。Runner から Git ホスト、リモートキャッシュ（S3 互換、Artifactory、Actions Cache）までの RTT とスループットを測ってください。遠いリージョンへの TLS ハンドシェイク遅延は、スクショ上では「Xcode が遅い」に見えます。ヘッドレス常駐や launchd 前提の観点は、2026、クラウドMacでOpenClawを置く：Linux VPSと違う環境チェック、launchd常駐、再現できるトラブルシュートFAQ も参照してください。

定義のすり合わせ

ここでの「弾性」とは、数分スケールで容量を足し、遊休時に外せることです。ゼロ待ちの魔法ではありません。プロバイダが山を終える前に Mac を割り当てられないなら、常駐のベースライン容量は依然として必要です。

キャッシュ：ローカル SSD と共有オブジェクトストア

Apple 系ビルドはキャッシュ感受性が高く、DerivedData、CocoaPods、SwiftPM の成果物が復元時間を支配します。シャットダウンでディスクを捨てる弾性ノードは、キャッシュを外へ──Xcode のマイナーバージョンとロックファイルのハッシュに厳密に紐づけたバケットや読み多めの共有──に押し出す設計が向きます。常駐ノードはホットキャッシュをローカルに置けますが、ブランチ間で汚染しないよう 決定的な退避 が要ります。どちらのモデルでも、キャッシュミスはレアな事故ではなく SLO 設計の一部 として扱ってください。

署名と隔離

同一ユーザーで複数の自ホスト Runner を並べると、キーチェーンやプロビジョニングプロファイルの競合が指数関数的に増えます。マシン単位で Runner 身份を分けるか、オーケストレーションが許すならエフェメラルユーザーを優先し、共有ホームでリリース署名だけを並列化しないでください。

意思決定マトリクス（俯瞰）

表は一次フィルタです。確定は下のパラメータチェックリストでログに照らして行ってください。

シグナル	弾性プール寄り	常駐ノード寄り
デューティサイクル	平均利用率は低いが、高い山は稀	タイムゾーンを跨いで高い利用率が続く
キュー SLO	追加マシンが素早く現れれば山は許容	日中ほぼ常に厳しい拾い上げ遅延（例：30秒未満）
キャッシュ戦略	コールド Runner でもヒット率の高いリモートキャッシュ	大容量ローカル SSD と再現性の高いウォームパス
コンプライアンス	エフェメラルディスクが保持ポリシーに合う	固定ホストに長期の監査証跡が欲しい

実行可能なパラメータチェックリスト（Runbook に貼る）

フリートを数えるとき、私たちは YAML、Terraform の変数、社内 Wiki の表に次の「つまみ」をそのまま書き込みます。名前はオーケストレーション層に合わせて置換して構いません。意図が伝われば十分です。

ワークフロー＋Runner 設計（参考）

# ワークフロー同時実行（騒がしい経路の直列化）
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

# マトリクス扇の上限（キャッシュを踏み荒らさない）
strategy:
  max-parallel: 4

# Runner フリート（UI だけでなく ops リポに文書化）
baseline_always_on_runners: 2   # 最低限のホット容量
burst_elastic_runners_max: 8    # プロバイダが許す上限
idle_shutdown_minutes: 45       # 弾性のみ。振動を避ける

# キャッシュキー（ツールチェーン＋ロックファイル必須）
cache_key_prefix: xcode-16_2-spm-${{ hashFiles('**/Package.resolved') }}

# SLO（超えたらアラート）
queue_pickup_p95_seconds: 60
cache_restore_p95_seconds: 120

現場で残るハイブリッド

既定ブランチとリリースタグ向けに小さな常駐ティアを置き、実験ワークフローは弾性ラベルへ流します。弾性 Runner のキャッシュヒット率は別系列で見てください。崩れるなら、キュー時間を復元時間に置き換えているだけです。

毎週、課金 Runner 時間とマージされた PR スループットを比較してください。コストだけが伸びて出荷速度が上がらないなら、金属を足す前に concurrency グループとキャッシュキーを締めます。