2026 Macクラウドのビルドキュー：並列度・DerivedData・ディスク余裕でxcodebuildを安定化

iOS/macOSのCIをMacクラウドへ移したチームは、まず署名とプロファイルをRunbook化しがちですが、並列ジョブ・肥大化したDerivedData・満杯ディスクによる不安定な赤は、署名以前に現れます。本稿はXcode 26パイプラインを想定し、リソース系の失敗モード3類型、並列度とメモリの判断表、コピペ可能なディスク閾値チェックを含む5ステップ以上の運用手順、FAQまでをまとめ、キューとディスク方針を証明書と同列の可観測性に載せます。

1. キューとディスクを署名と同じRunbookに載せる理由

Linux VPSではCPUとキュー深さを見ますが、macOSビルダーではXcodeとSwiftがDerivedData・モジュールキャッシュ・SourcePackagesに巨大な中間生成物を書き込み、ディスクスループットと空き容量がCPUと同格のボトルネックになります。ヘッドレス署名のチェックリストとCI/CD接続ガイドまで済ませたら、次はリソース競合です。方針を書かないと「再実行すると緑」というパイプライン不信が残ります。

並列archiveはRAMとリンカ作業領域を奪い合う：複数のxcodebuild archiveはジョブ単位の想定を超えてメモリを使い、リンクは/tmpに数GBの一時ファイルをばらまきます。容量が尽きるとclang/ldは「ディスク満杯」とはっきり書きません。
DerivedDataは単調増加：既定の~/Library/Developer/Xcode/DerivedDataはブランチとスキームのたびに膨らみます。ジョブ単位の掃除がなければ数か月でシステム領域が5%未満になり、macOSの自動整理とビルド時間のブレを招きます。
ディスク指標がないと「ネットワーク不調」に見える：Swift Packageの再試行ログはCDN問題に似ますが、キャッシュディレクトリが書き込めない場合も同様です。dfとDerivedDataサイズをキュー遅延と同じダッシュボードへ載せてください。

2026年の推奨：署名ルール・最大並列度・ジョブ別DerivedDataルート・ビルド前後のディスク閾値を同一パイプラインテンプレートに宣言します。下表は並列度の粗い目安であり、xcodebuild -showBuildSettingsやCIメトリクスで必ずチューニングしてください。

2. ノードあたりの並列度とRAM/CPU

典型的なM4 / M4 ProクラウドSKUを想定したマトリクスです。原則：リンカピークを測っていない限り同時archiveは1〜2に抑える。コンパイル/テストはより高く設定しがちです。ログとスナップショット用に空き容量15%前後は残してください。

SKU（例）	推奨並列archive	コンパイル/テスト上限目安	DerivedData方針	空きディスク目標
16GB RAM / 10コア以下	1	2（プロジェクト依存）	ジョブ別サブディレクトリまたは夜間全消去	空き≥20%
24〜36GB RAM	1〜2	3〜4	ブランチ名前空間＋週次ディープクリーン	空き≥15%
48GB+ UMA	2〜3（リンカ実測必須）	4〜6	段階キャッシュ：直近Nコミット保持	空き≥15%、データボリューム分離が理想

Jenkinsラベルやセルフホストランナーでは、同一ログインで2つのarchiveが同じDERIVED_DATA_PATHを共有しないようロックを掛けてください。モジュールキャッシュロックは断続的な「ファイル変更」エラーを生みます。フリート拡張時はメモリと構成ガイドと突き合わせてください。

3. DerivedData・SPMキャッシュ・ディスク閾値（5ステップ以上）

以下をLinuxからMacへの移行プレイブックで説明しているSSHエントリと同じ場所にスクリプト化します。

ジョブごとにDerivedDataパスを切る：export DERIVED_DATA_PATH="$WORK/DerivedData/$BUILD_ID"のようにし、xcodebuildへ-derivedDataPathを常に渡します。
ディスク不足は即失敗：30分コンパイルの前に下のスニペットで早期終了します。
SPMキャッシュ方針を版管理：~/Library/Caches/org.swift.swiftpmを予測可能に保ち、Xcode大バージョンアップ後はフルパージを計画してバイナリ不整合ループを避けます。
成功/失敗後に回収：直近K件のDerivedDataは増分用に残し、失敗ジョブのディレクトリは即削除。夜間に7日超のフォルダを掃除します。
純CIではCOMPILER_INDEX_STORE_ENABLE=NO：IDE索引が不要ならIOを大きく削れます。解析専用パイプラインだけオンにします。
（追加）メトリクス送出：df -hとdu -shをログへ。大きな.ipa/.xcarchiveはオブジェクトストレージへ送ってローカル削除。

# ビルド前：空き容量が12%未満なら非ゼロ終了（マウントは環境に合わせて）
AVAIL=$(df -h / | awk 'NR==2 {gsub(/%/,"",$5); print 100-$5}')
THRESH=12
if [ "${AVAIL%%.*}" -lt "$THRESH" ]; then
  echo "空きディスクが ${THRESH}% 未満 — DerivedDataを掃除するかボリューム拡張"; exit 1
fi

                ヒント：同じmacOSユーザーで対話的XcodeとヘッドレスCIを混在させると既定DerivedDataが衝突します。署名と同様、CI専用アカウントまたは別クラウドノードを推奨します。
            

4. 引用できる技術事実とパラメータ

社内監査用メモ：①並列分離の第一スイッチはxcodebuild -derivedDataPath。②SPMのネット再試行ログは、実際はキャッシュ書き込み不可のケースがある。③APFSで空き5〜10%未満はローカルスナップショットと長尾ビルドを誘発し得る。④ObjC/Swift混在はリンク時にコンパイルピークの約2倍RAMが必要なことも—コア数が増えても並列archiveが増えるとは限らない。⑤成果物をデータボリュームに載せるとシステム領域の摩耗と保持ポリシーが単純化する。

5. 場当たりMacからスケールするビルド基盤へ

小さな個人Macでarchiveを四重化するのは「動く」までです。ディスクは静かに満杯になり、失敗は再現しにくく、停電一発でリリースが止まります。リモートデスクトップだけの運用はキュー方針をバージョン管理しづらく、APIでノードを引く構成とも噛み合いません。

一方、RAM/ディスク階層が読みやすく、SSH自動化とビルダ入替余地がある弾性Macクラウドにキューを固定すれば、Linuxランナー感覚でキャッシュ寿命を管理しつつフルXcodeツールチェーンを維持できます。Xcode 26標準化・DerivedData抑制・ディスク異常時のノード交換を重視するチームにとって、VPSMACのM4 Macクラウドをレンタルするのは、1台の脆い機械を絞り続けるより予測しやすいことが多いです。並列度と掃除をコード化し、基盤が計算とストレージのベースラインを提供すれば、「金曜の謎のディスク満杯」でリリース列車が止まる確率は下がります。

6. よくある質問

増分高速化のためDerivedDataを共有してよいか

同一ブランチの直列ジョブなら可。並列archiveは別ディレクトリ推奨。ロック競合とキャッシュ汚染を避けます。必要なら自前のリモートキャッシュへシンボリックリンク。

DerivedDataを積極削除すると毎回遅くならないか

コールドビルドは伸びますが計画可能で、満杯ディスクのランダム失敗よりマシです。バイナリキャッシュや直近数本の保持で緩和。

クラウドMacとオンプレMac mini群の違いは

オンプレは電源・ラック・ディスク交換の負担。クラウドはバースト並列が簡単。レンタルと購入のROI記事で判断枠組みを参照。