ホスト Runner の請求が急に跳ねるのはなぜ？

キュー待ちが課金対象に含まれること、キャッシュミスでコンパイルが伸びること、複数リポが同時ピークすることなどが重なります。キューとコンパイルを分けて観測してください。

セルフホストで不安定になるときは？

空き容量、DerivedData 競合、キーチェーン、並列 xcodebuild のメモリピークを確認します。

第二ノードが必要なのはいつ？

SLA を超える待ちやディスク警告、第二リージョンが必要なとき。並列だけを上げずラベルとクリーンアップを複製します。

2026 GitHub ホスト macOS Runner と専用 Mac クラウドビルドプール：並列度・分課金・キャッシュ戦略

プラットフォーム責任者が直面するのは「GitHub の macOS 分課金で足りるか、専用 Mac クラウドで self-hosted を張るべきか」という問いです。本稿は Git 側 CI のスループットとキューを扱う選択であり、Xcode Cloud の代替ではないことを明確にし、請求・並列上限・DerivedData・ディスク水位を同時に見る枠組み、比較表、5 ステップ、レビュー向け硬指標、FAQ を提示します。

1. 要約：各アプローチが最適化するもの

GitHub ホスト macOS Runner は運用ゼロの分課金を提供し、PR 検証や変動の大きいチームに向きます。専用 Mac クラウドプールはディスク、ツールチェーン、出口ポリシーを自分で固定し、self-hosted ランナーでラベル単位に並列を制御します。いずれも Git 側 CI の問題であり、App Store Connect 連携を担う Xcode Cloud とは役割が異なります。max-parallel を増やせば速くなるとは限らず、ホスト側は組織キューと分単価の制約を受け、セルフホスト側は DerivedData 競合・キーチェーン排他・ディスク急増で p95 が悪化します。分単価、p95 のうちキューとコンパイルの内訳、キャッシュ、空き容量をセットで見ることが重要です。

Linux VPS 出身のチームは、同一ユーザキーチェーンへの同時 Archive、Spotlight の干渉、ノート PC とサーバの Xcode 微差による再現性の差に注意してください。ホスト Runner は毎ジョブでイメージが新しくなる一方、セルフホストは再現性と運用負荷の両面を露呈します。コスト試算ではエンジニア時間も含め、リリース週のキュー待ちで分が膨らむケースと、定額近い Mac クラウドで p95 を安定させるケースを比較してください。

2. 痛点：請求・キュー・キャッシュ・競合

請求：ホストはコミットとピークに連動し複数リポが重なると急伸します。Mac クラウドは時間・月額＋転送が中心で長時間 CPU 占有に向くが、アイドル配分が要ります。
キューと並列：ホストはスケジューラと組織上限の影響を受けます。セルフホストは CPU/RAM/IO が上限で、並列 xcodebuild 過多はリンクや Swift ピークで振れます。
DerivedData：ホストの一時 FS と永続ボリュームではキャッシュ意味が異なります。パスを分けクリーンアップを設計しないとヒット率かディスクかの二極化になります。
セキュリティ共存：企業 PKCS・固定出口・常駐デーモンを同居させるなら専用プールが現実的です。

第五の論点は可観測性の対等性です。GitHub はキューをダッシュボード化しますが、セルフホストはディスク・CPU・launchd を自前で監視しないと「分が増えた」「赤がランダム」で語彙が割れます。ci-pr / ci-release などラベルを標準化し、ワークフローとコストセンタに直結させてください。

3. 判断マトリクス

観点	GitHub ホスト macOS	専用 Mac クラウドプール
課金	分課金、並列で変動	賃料＋転送、重いコンパイルに平滑化しやすい
並列制御	組織枠と共有スケジューラ	自前ラベルと executor
ディスク	キャッシュ API＋エフェメラル	永続パスと独自クリーンアップ
ツールチェーン	プラットフォームイメージのペース	複数 Xcode 共存
署名	Secrets パターンに従う	match / API キーを企業 PKI に合わせやすい

ヒント：軽い検証はホスト、重い Archive は self-hosted ラベルへ。ブランチ規則と concurrency を README に明記し DerivedData の衝突を防ぎます。

4. 測定からスケールまで 5 ステップ

p50/p95・キュー待ち・実効 $/分を測定。キュー支配なら先に並列ウィンドウを調整。
SSH で xcodebuild -version、システム巻 40GB 以上空き、プロキシ/DNS、Git までの RTT を確認。
ラベルごとに DerivedData パスを分離。ナイトリーと PR で保持ポリシーを変える。
concurrency でリリース再入を防ぎ、メモリピークを見てから並列を上げる。
SLA 違反が続く、ディスク警告、第二リージョンが必要ならノードを水平追加。並列だけを上げない。

on:
  push:
    branches: [ release/* ]
jobs:
  ios-archive:
    runs-on: [self-hosted, macOS, ARM64, pool-prod]
    concurrency:
      group: ios-archive-${{ github.ref }}
      cancel-in-progress: false

5. レビュー用の硬指標

ディスク：数日で DerivedData が数十 GB に達し、空き 10GB 未満でリンクが不安定化しやすい。
メモリ：Apple Silicon の単発 Archive で 12〜18GB ピーク例があり、同時実行数の上限算定に使える。
RTT：git fetch とバイナリ取得が遠方だと線形に遅延。キュー分とコンパイル分を分離計測。
ホスト分：スパイクをキュー膨張とコンパイル遅延に分解し、対策を分ける。
失敗分類：署名・依存解決・OOM・アップロードをタグ化し、GitHub 設定か Mac 側ディスクかを即断。
キャッシュ ROI：同一 DerivedData でのビルド短縮率から SSD 追加を正当化。
組織並列予算：複数リポのピーク週を重ねるとキューが乗算される。
成果物保持：巨大 .xcarchive が分と帯域を圧迫するため、ランナー側の古い成果物削除を忘れない。

財務レビューでは GitHub の利用 CSV とセルフホスト稼働レポートを並べ、ホスト分はコミット速度と相関し、Mac クラウド賃料はベース負荷と相関すべきです。コミットが横ばいなのに分だけ増えるならキャッシュミス、ミラー遅延、キュー競合を疑ってください。

6. 並列よりノード追加を優先する条件

分課金だけに頼ると固定出口や無人署名で頭打ちになり、単一セルフホストはディスクと競合で赤ビルドを繰り返します。現実的なのは軽検証をホストに残し、重いコンパイルとリリースを専用 Mac クラウドへ寄せ、SLA 逸脱や第二リージョン要件で水平拡張することです。オフィスの物理 Mac を常時見張るより、専用 Mac クラウドを数時間で立ち上げ SSH で Linux VPS 感覚に揃え、ホスト分を積み上げるより予測しやすい年間予算に寄せられます。Xcode Cloud と併用する場合も、GitHub ホストと Mac クラウド self-hosted は Git CI 算力の話であり、ブランチ責務を明確にしてください。ノード開通とパイプライン接続を API 体験に近づけるには、VPSMAC の 90 秒 API と CI/CD 連携記事でノードから自動化までを一気通貫させます。