2026 iOS CI「エラスティックプール + 専用 Mac ベースライン」：GitHub Actions ホスト macOS の従量分と専用 Mac クラウドで PR と Nightly をどう分割するか（キュー SLO と容量閾値）
Actions YAML に慣れたプラットフォーム責任者ほど、月末の「分課金 + キュー待ち」に頭を抱えます。原因はコア不足ではなく、尖った PR トラフィックと低頻度だが重い Nightly/Archive を同一クラスに載せていることにあります。本稿では四つの痛み、三モードの比較表、PR/Nightly のルーティング規約、五ステップの導入、レビューで引用できる三指標、FAQ までを一気通貫で示し、2026 年に財務とエンジニアが同じグラフを見られるようにします。
1. 四つの痛み：ホストのみ／Mac のみでは足りない理由
成熟チームの議論は「macOS が要るか」ではなく、「キュー分散を誰が持ち、ディスクとキーチェーンのドリフトをどう抑えるか」に移っています。
- 分課金とキューの結合：ホスト macOS はプール待ちと実コンパイルが一枚岩の請求曲線になります。指標を分解しないと、財務はコード肥大と誤認し、実際は組織並列が共有天井に当たっているだけ、という切り分けが遅れます。
- 単一ベアメタルの競合：Nightly Archive、UI 行列、実験ブランチを一台に積むと、DerivedData とキーチェーン争奪で flaky に見える失敗が増えます。根は IO と並列ポリシーです。
- イメージドリフト対ゴールデンツールチェーン：ホスト側はセキュリティ更新で速く動きますが、Xcode マイナー固定や Ruby/Node の側車を要するチームには、ドリフトが「先週は通った」の調査コストを押し上げます。
- 低頻度重処理の予測可能性：dSYM 送信、公証、長時間 UI スイートは安定した出口と空き容量に敏感です。エラスティック側でも動きますが、尾部遅延と再試行分の方が専用スロット確保より高くつくことがあります。
2. 意思決定表：エラスティックのみ／ベースラインのみ／ハイブリッド
ハイブリッドはミドルウェアを増やすのではなく、尖りをホストが吸い、重い鎖を専用 Mac が受け止めるという契約です。
| 観点 | ホスト macOS のみ | 専用 Mac のみ | PR エラスティック + Nightly ベースライン |
|---|---|---|---|
| 向き先 | ブランチ多・PR 頻度が高い軽〜中ジョブ | コンプライアンス、固定出口、複数 Xcode、常駐デーモン | 分課金の山を抑えつつリリース鎖を安定化 |
| キュー | 組織並列と共有プール | max parallel は自前、リスクはローカルディスクへ | PR はプール待ち、リリース系はプールを迂回 |
| 課金形 | コミット頻度に連動しやすいスパイク | リース型で滑らか | 高頻度軽処理は分、重い尾はリース |
| 運用観点 | YAML とキャッシュ | SSH、launchd、ディスク水位 | ラベル統一とダッシュボード一枚化 |
3. PR と Nightly のルーティング（既定のおすすめ）
ブランチ保護とタグ方針に書き込み、YAML を先に編集した人が優先度を握る構造を避けます。
- PR：既定は
runs-on: macos-latestなどホスト SKU。行列の上限を決め、PR 既定で全目的地 UI 行列を開かない。 - main 取り込み後 Nightly：
runs-on: [self-hosted, mac-ci-baseline]のようなラベルで専用 Mac に向ける。Archive 同時実行は 1〜2 に抑える。 - Release タグ：ベースライン強制、単一ビルドユーザーと監査領域に束ね、成果物レジストリとリージョンを揃えてアップロード尾部を短縮。
archive:
if: startsWith(github.ref, 'refs/tags/')
runs-on: [self-hosted, mac-ci-baseline]
4. 五ステップ：計測からパイロット承認まで
- 請求と時間の分割：四周分の Actions データをキュー／コンパイル／アップロード／キャッシュ復元に分ける。閾値超えなら最重ステージをホストから外す。
- ラベル契約の文書化：
mac-pr-elasticとmac-ci-baselineを明文化し、個人リポが既定で baseline を占有しないようにする。 - ディスク予算：重い Archive ごとに約 40GB の空きを見込む。
DERIVED_DATA_PATHをジョブ単位で分離し、夜間 gc は非同期。 - Nightly のキュー SLO：開始までの P95 を定義。違反なら baseline スロット追加か鎖の分割。ホスト並列だけを盲増ししない。
- 非クリティカル_repo で二週トラック：失敗タイプ別に比較し、分課金曲線を見てからモノレポを切替。
5. レビューで使える三指標
- キュー比率：端到端の約 15% を超えてコミット率と相関なら、プール構造的飽和のサイン。
- ディスク余白：NVMe 空きが約 15% を下回ると Swift 大規模リンクの尾部が伸びる。専用ノードで最も多い隠れ障害。
- 再試行分数：再試行が総分数の約 25% を超えるなら、Archive と軽い lint が同一キュー規則に載っていないか確認。
6. FAQ
ハイブリッドは運用が二倍？ 謎の遅延から「観測可能な二種 runner」へ移るだけで、監査は楽になることが多いです。
Mac 一台で足りる？ baseline として Nightly と release がロックを奪い合わないなら十分。PR はホストへ。成長に合わせ二台目をホットスタンバイに。
複数 Xcode は？ PR プールは単一ゴールデン。baseline はパーティションか別アカウントで DEVELOPER_DIR を隔離し、暗黙の xcode-select ドリフトを防ぐ。
7. まとめ
ホスト分を積むだけでは長期宿主としての公証・Archive の監査性に弱く、Mac 一台運用だけでは PR 尖りとの競合で flaky が増えます。ルーティングを分けるのが 2026 年の最短経路です。
マルチテナントのディスクと並列規約のままでは、macOS を完全に「自分の土地」として扱えません。一方で自前 Mac 単体ではパッチと監視の半径が肥大化します。製造ラインとして iOS 納品を安定させたいチームにとって、VPSMAC の Apple Silicon Mac クラウドをリースし、Linux VPS で培った SSH と launchd の習慣を継ぎつつ重い鎖を共有プール待ちから解放する方が、請求一枚に尖りを押し込むより問題の本質に近いことが多いです。