同一Mac CIランナーにBazel・Gradle・xcodebuildが同居するとき、遠隔キャッシュはI/O支配権が勝負。repository_cacheは依存Blob、disk_cache（Bazel）やGradleローカルは実行グラフ――レイヤが違うのでNVMe分区を先に決める。 詳しくは：2026 企業向け Mac CI リソースプール：マルチリポ並列ビルド、キャッシュ再利用、ディスク拡張——クラウドで借りるか自前で走らせるか？
1. BazelとGradle：遠隔キャッシュの当たり方の差
BazelはCAS＋メタ、Gradleはビルドキャッシュと依存Blobで帯域が伸びやすい。TLS・認証・接続プールは共通。Runnerは低RTT優先、キャッシュ専用経路を切ると尾が短い。
2. repository_cacheとdisk_cache：NVMe上の分区設計
repository_cacheはBlob連続書き込み、disk_cacheは小ファイル乱立。単一卷きはfsyncで互いに尾を引く。別ボリュームに分けGCをずらす。-derivedDataPathとGradleホームもキャッシュと物理分離し満杯の巻き添えを防ぐ。
3. 同機マルチJob×xcodebuild並列：CPUよりキュー深さ
複数xcodebuildはシミュレータと索引でRAM・ディスクキューを奪う。Bazel／GradleのGETが同一NVMeに刺さると命中が高くても壁時計が伸びる。同時xcodebuild本数を先に抑え、Gradleデーモンとexecutorを段階開放。読み取り専用遠隔はミス時別分区のローカル退避が必須。
- awaitとutil%でNVMe飽和を先に見る。CPUが余っていても意味がない。
- JDKとXcodeのメジャーをタグに載せ、キャッシュキーのドリフトを防ぐ。
- ローカルフォールバック用の空き容量は「最悪一Job分のフルビルド」以上。
4. プラットフォーム責任者向け選定FAQ
- 読み取り専用遠隔にすべきか：本番ブランチの再現性最優先なら推奨。書き込みは限定ロールまたは専用ビルドアグリゲータへ。
- 高NVMe機で並列度が頭打ち：帯域ではなくメタIOPSとロック。シャーディングや複数キャッシュエンドポイントを検討。
- BazelとGradleを同ディスクに置くリスク：GCタイミングの重なり。分区＋スケジュールずらしが定石。
- Apple系だけ別Runner：混在が厳しいチームは物理分離が最も説明しやすい。
高IOPSなビルド検証に向くApple SiliconとMac mini
macOSでxcodebuildとツールチェーンを揃えられる実利、Apple Siliconの統合メモリとNVMeはBazel小I/OとGradle Blobの両方に余裕。Gatekeeper／SIP／FileVaultは監査説明がしやすい。Mac miniの低待機電力はキャッシュ常時ウォームや夜間ビルドの総コストを抑える。
分区と並列度の実測はノード固定が早い。Mac mini M4を基準に、 Macstripeホーム で専有構成を確認し、遠隔キャッシュ距離を合わせたうえでスループット検証に使うなら今すぐ購入が合理的。
