2026年・6リージョンリモートMacのストレージ不足：1TB/2TB拡張 vs キャッシュ治理 vs 第2台追加のFinOps三択マトリクス

読了目安 約11分 · MACCOME

結論：シンガポール、日本、韓国、香港、米国東岸、米国西岸の専用リモートMac（M4 / M4 Pro）で「ディスクが満杯に近いのにビルドが遅い」状態が繰り返される場合、本記事は署名可能な答えを提示します。1TB/2TB拡張、キャッシュ治理、第2台ピーク機の三択を決定マトリクス + 6手順Runbook + 3つの水位閾値で選び、日次/月次/四半期リースと結び付けます。リージョン選定やPOC全体の話は繰り返さず、本番前安定性受入の次に来る典型的な問い——ディスクに投資すべきか、使い方を変えるべきか——に答えます。

リモートMacが満杯のとき、最も誤判定されやすい6つの痛点

  1. 「削除可能な膨張」を「構造的なディスク不足」と混同する：DerivedData、古いSimulator runtime、Dockerレイヤー、Gradleキャッシュは、しばしば解放可能容量の40–70%を占めます。週次クリーンアップ後も7日以内に空き15%を下回る場合のみ、拡張/第2台の議論に入ってください。
  2. dfのパーセンテージだけを見て、ディレクトリ帰属を見ない：APFSスナップショット、ローカルTime Machineスナップショット、「その他ユーザー」がルートを赤く見せても、Xcodeを遅くするのは単一ディレクトリの線形成長であることが多いです。一括rm -rfではなく、duによる層別サンプリングが必要です。
  3. ディスク拡張を万能薬とみなし、CPU/メモリキューを無視する：iostatでディスク利用率が長期40%未満なのにコンパイルが遅い場合、ボトルネックは並列度またはリンカメモリです。M4 Proまたは第2台の方が2TBより効果的です。
  4. Monorepo + 複数Simulatorを256GBベースラインで回す：partial cloneは取得サイズを減らしますが、ローカル中間成果物とシミュレータイメージはブランチとOSバージョンごとに蓄積します。Monorepoスリム化チェックリストと併読してください。
  5. 6リージョンで「1台に全部載せる」：ビルド、UIテスト、署名アップロードが同一ディスクだと、ピーク週に水位が同時に満杯になります。多機ビルドプールFinOpsは役割分担を扱い、本記事は単一ノードのディスク方針を先に決めます。
  6. 短期プロジェクトに月次拡張、長期基線に日次削除だけ：FinOps上、予測可能な常駐膨張は1TB/2TB + 月次/四半期リース向き、2週間スプリントはクリーンアップ + 日次レンタルの第2台が適します。14日のために年間ティアを固定しないでください。

6リージョン専用Macの強みは物理ディスク境界が明確なことですが、明確さは容量の自動適合を意味しません。Apple Silicon統一メモリでは、ディスク圧力とメモリ圧力が同相で現れやすい：Simulator並列、Swift増分コンパイル、コンテナレイヤーキャッシュがIOとRAMを同時に押し上げます。三択決定がなければ、「もう一度ディスクを空ける」と「もう1台追加」の間を行き来し、リースを無駄にしリリースを遅らせます。

多リージョンノードレンタル・コストガイドは「どの国・どのリース期間か」を答え、本記事は選んだノード上のディスクボトルネックの第一処置順序を答えます。CocoaPods/SPMミラーとディスクチェックリストと補完関係にあり、依存ダウンロード最適化は「疑似満杯」を減らしますが、DerivedDataとシミュレータ資産の治理は代替できません。

シグナル 優先：キャッシュ治理 優先：1TB/2TB拡張 優先：第2台 / Pro
クリーン後7日で空き <15% duで解放可能>30%かつ標準清理未実施の場合のみ デフォルト：構造成長（多分支DerivedData） CPUキューp95も同時飽和
単一リポ <8GB、Simulator OS 3+ 未使用runtime + デバイスセット削除 2+大バージョンOSイメージ常駐 並列UIテストworker >2
Monorepo + affected有効でも毎週満杯 bloblessとキャッシュパス確認 デフォルト：中間成果物隔離失敗 ビルドとテストはディスク/機器分割必須
リリースピーク10–14日のみ デフォルト：清理 + スナップショット出力 2週間のため四半期固定は非推奨 日次/週次第2台が有利
2TB後もiowait <8%で遅い ディスク主因ではない、拡張停止 拒否：これ以上ディスク追加しない デフォルト：算力/並行ボトルネック
storage

仕組み：APFSのコピーオンライトにより、大ディレクトリ削除後も「空き容量」表示が即座に回復しないことがあります（ローカルスナップショット存在時）。治理手順にはスナップショット一覧の確認を含めてください。「200GB削除したのにdfが20GBしか戻らない」という誤判断を防ぎます。

6手順Runbook：サンプリングから三択署名まで

  1. 水位ベースラインを固定：総容量、空き率、主要マウントポイントを記録。ノードID、Xcodeバージョン、直近クリーンアップcommit（スクリプト版）を記載します。
  2. 層別duサンプリング（Top 12ディレクトリ）：~/Library/Developer、DerivedData、CoreSimulator、~/.gradle、~/Library/Containersなどを層別に。CSV出力で監査可能にします。
  3. 標準クリーンアップパック実行：順序どおりDerivedData（現行schemeは保持可）、未使用Simulator runtime、Docker danglingイメージ、旧Archives（リリース責任者確認）。
  4. 24時間斜率を再測定：説明可能なリリース活動がなく、空きが1日3ポイント以上減る場合は構造成長とマークします。
  5. マトリクスで分岐選択：キャッシュ治理 / 1TB·2TB / 第2台。根拠なしに「清理 + 拡張 + 加機」を同時投入しないでください。
  6. FinOpsメモでリース固定：構造的 → 月次/四半期 + 拡張；短ピーク → 日次/週次第2台。台帳に再確認日を記載します。
bash
# ディスクTopディレクトリサンプリング（リモートMac上で実行、WORKパスを置換）
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

レビュー会議に書く3つの定量閾値（定数はチーム基線に置換）

  • クリーンアップ収益比：標準パックは現在使用中容量の18%以上を解放すべきです。12%未満なら膨張は構造化しており、拡張/第2台マトリクスへ進みます。
  • 空き容量レッドライン：本番ビルド機は空き20%以上を維持。15%未満ではフルArchive + 並列UIテストを禁止（POC拡容KPIとゲート項目を共有可能）。
  • 拡張後IO検証：1TB/2TB拡張後48時間以内に、ディスクbusy%中央値が25%未満でビルド時間が改善しない場合、レビューで「さらにディスク追加」オプションを閉じ、CPU/メモリと成果物RTTを調査します。

締め：「もう1枚ディスク」でアーキテクチャ分担を隠さない

6リージョンリモートMacにおけるディスク決定の本質は、非圧縮可能なワーキングセットと圧縮可能なキャッシュを分離することです。削除できるものは治理、削除できないものは拡張または分機、削除できず算力も飽和ならディスク追加をやめてください——それはキューボトルネックへの安慰剤に過ぎません。

自前Macホスティングや短期クラウドインスタンスは「ディスク」と「運用」を別請求にしがちで、スナップショット、シミュレータ資産、複数人共ディスクの複利を過小評価します。ノートPCでのビルド引き継ぎは、リリース週にディスクとスリープポリシーを同時に踏みます。専用Apple Silicon、予測可能なディスクティア、6リージョン就近ノードが必要なチームには、本マトリクスを調達添付に組み込み、MACCOME Macクラウドで1TB/2TBとリースを一度に揃える方が、場当たり的なディスク追加や盲目的な第2台より総コストが低く、CIとオンコールが同じ水位言語を共有できます。

拡張または第2台が確定したら、ノードリージョンとリース項目を同じレビューに持ち込んでください。価格とサイクルは製品ページを参照し、安定性受入とMonorepo記事を添付として残し、リリース週に容量だけでなくパイプラインも議論できるようにしてください。

よくある質問

DerivedDataを削除してもディスクが満杯のままです。拡張と第2台追加、どちらを選びますか？

クリーンアップ後7日以内に空き15%を再び下回り、Developerサブディレクトリのdu比率が高いままなら、1TB/2TBと月次リースを優先検討してください。CPU/メモリキューも飽和している場合は、多機ビルドプール記事を参照して第2台を追加します。ティアと料金はレンタル料金をご覧ください。

2TBに拡張してもビルドが遅いのはディスク問題ですか？

必ずしもそうではありません。IOが暇なのにコンパイルが遅い場合は、安定性受入とアーキテクチャマトリクスで算力とネットワークを切り分けてください。操作詳細はヘルプセンターをご参照ください。