2026年独占リモート Mac セルフホスト CI：永続 Runner と Ephemeral Runner プールはどう選ぶ？──キャッシュウォームアップ、キュー尾部遅延、資格情報注入面と SSH 可観測性の再現可能な意思決定マトリクス＋FAQ

1. TL;DR──デフォルトがひっくり返る条件

• 永続寄り：ウォームキャッシュ（Derived Data、SPM、CocoaPods、Tuist 出力など）が wall time を支配し、OS ユーザー分離や APFS ボリュームで爆発半径を抑えられ、Xcode／macOS アップグレード用の maintenance 窓を許容できるとき。
• エフェメラル寄り：ジョブごとに既知のファイルシステムスナップショットから始めたい、信頼できない fork 由来の PR が多い、コンプライアンス上ユーザ Keychain や ~/Library キャッシュにジョブ痕跡を残さない証明が要るとき。
• ハイブリッドが現実解：マージキューとリリース列車用の小さな永続層＋コントリビュータ向けバーストのエフェメラル層──ただし p95 キュー待ち と p95 ジョブ実行時間 を別メトリクスで測ることが前提。

2. 定義（財務とセキュリティが同じ語を使うため）

永続 Runner：ジョブを跨いでホストに紐づく Runner 同一性（または固定プール）。ワークスペースは掃除されても、OS インスタンス・ユーザプロファイル・多くの場合ローカルキャッシュは残ります。

Ephemeral Runner：単一ジョブまたは短命リース用に Runner プロセス（多くはワーカー VM または捨てユーザホーム全体）を起こし、破棄または再イメージする設計。実機 Mac では「エフェメラル」は秒単位のクラウド VM ではなく、APFS スナップショット＋消去 や ジョブ単位ユーザ が現実的な形になりがちです。

キュー尾部遅延：ジョブが実行可能になってから Runner が拾うまでの時間で、スロットが埋まっているときに顕在化します。ジョブ内で課金されるビルド分とは別物です。

3. 軸 A──キャッシュウォームアップと再現性

永続 Runner はコールドスタートを償却します：xcodebuild の index store、モジュールキャッシュ、巨大な依存グラフが NVMe に残ります。エフェメラルは、厳密なコンテンツアドレスキー付きの リモートキャッシュ（HTTP キャッシュ、オブジェクトストア、共有読み取り専用ボリューム）を付けない限り、そのコストを毎ジョブに押し出します。

• 測る：restore＋compile の中央値と p95。リモートキャッシュなしのエフェメラルは、中央値は良くても p95 で負けることが多い。
• 再現性の罠：機械間で黙って乖離した永続キャッシュは「runner-03 だけ通る」バグを生む──キャッシュキーはツールチェーン指紋（Xcode build ID、Swift バージョン、lockfile）に固定する。

4. 軸 B──キュー尾部遅延とプールサイズ

Apple silicon の Mac CI は多くの場合 スロット拘束型：重い Xcode ビルドと複数 Simulator がメモリ帯域を食い切ります。1 台に 登録 Runner 数 だけ増やしても分離が足りなければ、むしろ競合で尾部が悪化します。

• 永続プール：並列上限がハードに合っていれば尾部は予測しやすい。リスクは毒ジョブがシステムサービスを詰まらせるヘッドオブラインブロッキング。
• エフェメラルプール：本当に 独立した 実行セル（追加の Mac mini、または有効な CPU／メモリ cgroup 等）を増やしたときだけ尾部が改善──同一ホストの再利用を速めるだけでは並列度は増えません。

5. 軸 C──資格情報注入面

永続 Runner は プロセス環境クラス にシークレットが滞留します：ログイン Keychain、.netrc、ビルドユーザ直下の API キー、Runner サービストークンなど。エフェメラルは滞留時間を縮めますが、ブートストラップの信頼境界（プロビジョニングプロファイル配布、App Store Connect API キー注入、Git クレデンシャルヘルパー）は依然必要です。

• 経験則：各シークレットを 最狭のファイルパスと最狭の OS ユーザ に写像する。任意の fork ワークフローと署名ユーザを共有しない。
• fork PR リスク：信頼できないコードが同一 Keychain 名前空間でシークレットと走るなら、ジョブ単位ユーザまたはハード分離 Runner は任意強化ではなく必須です。

6. 軸 D──SSH 可観測性（深夜 2 時に何がデバッグできるか）

独占リモート Mac の運用者は ssh、log show、sysdiagnose、ディスク空きグラフに住みます。永続 Runner は失敗アーティファクトが残りやすくポストモーテムが楽です。エフェメラルの teardown は証拠を消すので、ログのストリーミングと失敗時の xcresult をオブジェクトストアへ退避しないと手がかりが消えます。

• 最低限の可観測性：構造化されたジョブ開始／終了マーカー、Runner ハートビート、Simulator 起動タイムアウトのヒストグラム、重いステップ前後の明示的な df -h スナップショット。

7. 再現可能な意思決定マトリクス（runbook 用コピペ）

8. FAQ

Q1: 1 台の Mac mini だけで「エフェメラル」と言い切れる？

ファイルシステムとユーザ同一性のリセット が本物なら言える：ジョブ単位 macOS ユーザとホーム消去、APFS スナップショット復元、ジョブ間で再イメージする外部オーケストレーションなど。ワークスペースフォルダだけ掃除して同一ログイン Keychain を残すのは、セキュリティ観点ではエフェメラルではありません。

Q2: キュー尾部が悪い──もう 1 台買うべき？Runner をエフェメラル化すべき？

尾部が PR 量に線形に伸び、各ジョブが CPU 飽和なら、もう 1 台の Mac（または 1 台あたりの同時ジョブ数削減）が物理を直します。同一 CPU 予算内でホストを速く回すエフェメラル再利用は、主に衛生と隔離の改善で、スループットそのものはあまり増えません。

Q3: 再現性を壊さずキャッシュを温めたい

キャッシュを コンテンツアドレスストア として扱う：キーに Xcode build ID、lockfile のダイジェスト、Runner イメージ版を含める。リリース週の前に、クリーン checkout からビルドする cache canary ジョブを定期実行し、ドリフトを先に検知する。

Q4: ユーザーが怒る前に Runner 飢餓を SSH で掴むには？

vm_stat、memory_pressure、APFS コンテナ空き、固着した Simulator プロセスを自動取得する。キュー深さが中央値ジョブ長を超えて N より長く続いたらアラート──尾部の痛みはスケジューリング信号であり謎ではありません。

本番のセルフホスト Apple CI に Mac mini が据わり続ける理由

Runner 方針の議論はハードの上に乗ります。iOS／macOS ビルドは 高速なユニファイドメモリ、24/7 ラックや机置きに向く静音サーマル、macOS ネイティブの Simulator スタックを欲しがります。Apple Silicon の Mac mini は xcodebuild と依存 index にワット当たりのスループットが高く、アイドル電力はごく低い二桁 W に収まりやすく、コンパイルより待ちが長いプールの TCO に効きます。署名と公証のフルチェーンは依然 macOS が本拠で、エフェメラルのブートストラップも最終的にはそこへ触れます。Gatekeeper、SIP、FileVault は永続 Runner が長寿命鍵を抱えるときのリスク面を下げ、典型的な Windows CI イメージよりマルウェア面を小さくします。過剰なマネージド VM より、制御できる小型実機の総所有コストが勝ちやすい、というのが現場の帳尻です。

永続とエフェメラルのプール設計をフリート化する前に、一台で試すなら Mac mini M4 は 2026 年時点でも信頼できるベースラインです。下のカードから SSHMac のトップページでプランを比較し、このマトリクスを社内 ADR に添付してください。