DerivedData・Pods・sccache をリモートに置くか本地NVMeに置くかで、短周期CIのジョブ時間とエグレス請求の形が変わります。差を表とコピペ用パラメータに落とします。
5–20分
大容量キャッシュ復元の目安レンジ
数GB級
Pods＋DerivedDataの日次エグレス例
専有NVMe
再利用が効くとき最強になりやすい層
リモートキャッシュと本地NVMe、何が違うか
リモートは restore が支配的で帯域で頭打ち、エフェメラル本地は再利用が弱く、専有なら本地NVMeが最短になりやすいです。Runnerプールは GitHub Actions 自ホストRunner：弾性プールと常駐ノードの比較 と併読で整理しやすいです。
| 状況 | リモート寄り | 本地NVMe寄り |
|---|---|---|
| 短命Runner・スケール多 | 共有で均しやすい | 毎ジョブウォームが重い |
| 専有・常駐 | 二重管理になりやすい | 本地DerivedDataが最短 |
| エグレス厳しい | 差分同期で改善余地 | 外向きは減るが容量圧迫 |
| 複数Xcode並行 | キー分離しやすい | パス運用が増える |
三層を分けて考える：DerivedData · Pods · sccache
三層はIOパターンが違うので tarball 一括は慎重に。常駐とディスク監視は クラウドMacの launchd 常駐FAQ の観点と通じます。
コピペ用パラメータ例（環境変数・フラグ）
# Xcode：DerivedData を明示（本地 or 事前マウントしたパス） xcodebuild -scheme App -configuration Debug \ -derivedDataPath "$CI_DERIVED_DATA_PATH" \ -clonedSourcePackagesDirPath "$CI_SPM_CLONE_DIR" \ -disableAutomaticPackageResolution # CocoaPods：キャッシュディレクトリを固定し再利用 export CP_HOME_DIR="$CI_PODS_HOME" pod install --deployment --verbose # sccache：リモートストレージへ（バックエンドはインフラに合わせて選択） export RUSTC_WRAPPER=sccache export SCCACHE_DIR="$CI_SCCACHE_LOCAL_FALLBACK" sccache --start-server # 例: SCCACHE_BUCKET / SCCACHE_REGION または自前Redis URL などをセット
打ち切り条件を先に書く
restore が SLO を超えた週は本地ウォーム優先へ切替、と Runbook に1行置くと判断が速いです。
同期帯域と再利用の合わせ技
中間案：Pods／SPMだけリモート＋DerivedData本地、または逆。計測は restore 秒・CPU・エグレスGB／日の三本で足ります。
クラウドMac mini なら、キャッシュ設計の試行錯誤が速い
キャッシュ分割の検証は、ネイティブmacOSと高速ローカルディスクがあるほど回しやすいです。Apple Silicon のメモリ帯域はリンクとSwiftの山場で効き、Xcode・Homebrew・launchd がそのまま通ります。待機電力おおよそ 4W 級の静音筐体は常駐Runner向きです。
無人CIでは macOS の低クラッシュ率と Gatekeeper／SIP による小さな攻撃面が、署名環境の信頼に効きます。電力効率と開発体験のバランスも取りやすいです。
リモートと本地のハイブリッドを試すなら、VPSSpark のクラウド Mac mini M4 は現実的な起点です──プランを今すぐ確認し、短周期CIのボトルネックをデータで切り分けましょう。