クラウドAgentと高頻度PRが重なるとmacOS Runnerのキュー待ちが支配要因になる。先に「誰のSLOを守るか」を固定し、列・弾性・ディスクの順で割り当てる。 関連：本機Agentと遠隔MacへXcodeを逃がす例
1. 待ち行列：レーンと優先度
単一FIFOはPR遅延と夜間ヘビーが潰し合う。main直結は高優先レーン、Agentの小ジョブはバーストレーンに分離し、ラベルやruns-onで固定。可視化は待ちP95と同時実行の二軸で足りる。
2. 弾性スケール：ウォームプールと起動SLO
専有Macは秒起動VMとは型が違う。ウォーム待機とイメージ事前焼き、Runner登録の再利用でキュー解放時間を短縮。コストはピーク幅と遅延損失で比較し、常時N＋バーストMの二段が多い。
3. NVMeキャッシュのリース
DerivedData等はジョブID／PRでプレフィックスし、TTL掃除か容量LRUを併用。共有NVMeは書き込み競合が先に飽和するので、リース中の排他と読み取り専用共有層を分ける。
関連：大規模リポの冷起動とキュー隔離FAQ
4. 同時実行スライスとマルチリポSLO
同一Runnerのxcodebuild並列はRAMとNVMe IOPSが上限。リポごとにスライスを数字で割る。SLO表はリポ・ジョブ種・待ち目標・失敗率を横並びにし、レーン占有とキャッシュTTLを紐づける。
- PR：キューP95と初回FB分。
- main：マージ後グリーンまでの分。
- 夜間：完了窓だけ別SLO。
5. 実装FAQ
- Agent：人間PRと混ぜるなら別レーンで上限。
- 弾性：先にキャッシュ命中率と浅いclone。
- 監査：レーン占有を相関IDで追える形に。
専有MacとMac miniで詰まりを減らす
共有ランナーでは隣ジョブのI/OがNVMeの尾を引き、Agent小ジョブがPR体感を悪化させる。専有Apple Siliconなら列とキャッシュリースが素直に効く。macOSはxcodebuildとGatekeeper／SIP／FileVaultを一続きで説明でき、Apple Siliconの統合メモリはスライス並列に向く。Mac mini M4は待機電力が低くウォームコストを抑えやすい。
専有ノードは変数が少ない。ホームで構成と総合コストを確認し、今すぐ購入して列とSLOを固めるのが合理的だ。
