時間課金や共有イメージのクラウド Macでは、自前 Mac より早く SSD が逼迫しがちです。プリインストール済みの Xcode、複数 Simulator、DerivedData の肥大化が重なり、突然ビルドやアーカイブが止まります。本稿は 2026 年に VNC で macOS を操作する個人開発者向けに、番号付きの痛点整理、削除優先度マトリクス、リモートデスクトップ上で進められる8 ステップ（ターミナル併用可）、運用で引用しやすい数値目安、FAQ をまとめます。初回セットアップは「30 分チェックリスト」、契約満了前は「データ保存 15 分チェック」、大容量転送はファイル同期記事と併読してください。およそ 20 分で数 GB 級の安全な領域を確保できます。
① 痛点：リモート環境でディスクが赤くなりやすい理由
- システム領域が小さい：コスト最適化でルートボリュームが控えめ。CLT と Xcode 後の余白は限定的です。
- DerivedData の積み上がり：ブランチ切替やツールチェーン更新のたびに
~/Library/Developer/Xcode/DerivedDataに別ツリーが残り、マルチターゲットで数 GB〜十数 GB に達します。 - Simulator のランタイム：古い iOS ランタイムとデバイスデータが
CoreSimulatorに滞留し、見落とされやすいです。 - Archives と IPA：
.xcarchiveは dSYM を含み数百 MB 単位。ポリシーがないと Organizer とダウンロードフォルダが静かに膨らみます。 - VNC 上の視認性：デスクトップの zip や画面録画は GUI で目につきますが、Git だけ見ていると忘れがちです。
- 怖さゆえの過小削除：ゴミ箱だけ空けてキャッシュを残す、あるいは逆にキーチェーンを触る——安全領域をはっきり分けます。
② 判断表：DerivedData / Simulator / Archives の順序
| 兆候 | 先に消す | 想定回収 | リスク |
|---|---|---|---|
| インデックス遅延、マージ後の初回ビルドが長い | DerivedData（プロジェクト単位または全削除） | 数 GB 級 | 次回フルビルド時間増；ソースは無関係 |
| 未使用ランタイムが多く、アーカイブ期限が近くない | CoreSimulator の端末／ランタイム | 幅広い | 再ダウンロード；使い捨てデータ喪失 |
| Organizer が長く、ASC に上げ済みビルドが多い | dSYM を退避後の古いアーカイブ | 本数に比例 | バックアップ欠如でシンボル化不能 |
| 空きが一桁 GB で今夜アーカイブ | DerivedData とダウンロードを先に | 複合 | 順序誤りでアーカイブ中断 |
| 共有ログイン | チャットで合意してから一括削除 | 中程度 | 他者の稼働中シミュレータ削除 |
他の VNCMac 記事と同様、SSH で du を速攻、VNC で Organizer・許可ダイアログ・ストレージグラフを確認する分担が安定します。
時間課金では「使い捨てだから後回し」になりがちですが、急なリリースアーカイブで破綻します。週次 10 分の軽整理（Organizer・Simulator・du メモ）を推奨します。ハイブリッド CI（Actions / Xcode Cloud + 専用リモート Mac）でもローカル検証ビルドはキャッシュを増やすため、ディスクは運用指標の一部にしてください。
③ 8 ステップ：VNC とターミナル
システム設定またはディスクユーティリティで空き容量を確認
使用率が約 90% を超えたら重いダウンロードを止めます。
Developer 配下のサイズ順ランキング
du -sh ~/Library/Developer/* 2>/dev/null | sort -hr | head -n 10
Xcode → Settings → Locations → DerivedData を Finder で表示
全削除する場合は Xcode を終了してから。
Devices and Simulators で古い端末と未使用ランタイムを削除
実際にビルドする iOS 版は 2 つ程度に絞るのが現実的です。
Organizer でチームストレージに dSYM があるアーカイブから削除
不明な場合はオブジェクトストレージへエクスポート優先。
ダウンロード、デスクトップの zip、巨大な画面録画を整理
署名書き出しの唯一のコピーでないか確認。
任意：xcrun simctl delete unavailable
Simulator 停止後に実行し、Xcode を開き直します。
ゴミ箱を空にし、Clean Build Folder → Debug ビルド → Archive 試験
次のリリース前に空き容量が安定しているか確認。
シナリオ：残り 6 GB からクリーンアーカイブへ
Simulator と録画を止め、du で DerivedData と CoreSimulator のどちらが支配的か見ます。DerivedData 優先なら休眠リポジトリのハッシュフォルダから削除し、次に Simulator、最後に Organizer——dSYM のミラーが無い限りアーカイブは最も取り返しが難しいからです。作業中はデスクトップにタイムスタンプ付きメモ（開始空き、各段階後）を残し、時間課金の急増原因（フルディスクでのリトライループ）の説明に使えます。空きが 12% 程度まで戻ったら遅いターゲットで Debug、続けて Release と Archive。失敗時は Spotlight の再索引が重なっていないかも疑います。
④ 引用できる数値とガードレール
duまたは macOS のストレージ画面で上位フォルダを確認した.xcarchive削除前に dSYM の保管ポリシーを満たした- Clean → Debug → 最小 Archive でスモークテスト済み
⑤ 削除後の検証と触ってはいけない境界
キーチェーンの配布鍵、唯一の .p12 / .mobileprovision、未プッシュのコミット、顧客納品物はキャッシュではありません。積極削除の前に契約満了前チェックリストのエクスポート項目と突き合わせてください。Swift Package が壊れたら File → Packages → Reset Package Caches を先に試します。プロバイダが VM を入れ替える場合、xcrun simctl list runtimes の一覧をテキストで残すと再構築が速くなります。
⑥ FAQ、関連記事、まとめ
Q：ディスク拡張だけで十分？ A：可能なら有効ですが、キャッシュ運用なしでは数週間で再逼迫しがちです。
Q：CI でも同じ？ A：パイプラインで自動化し、新イメージ立ち上げ時は VNC で一度目視確認するのが安全です。
関連：初回 30 分チェックリスト、クラウド Mac 契約満了前 15 分チェック、ファイルとクリップボード、帯域と遅延、Xcode Cloud と専用 Mac の役割分担。
まとめ：安全なキャッシュと署名資産を分離する
Windows / Linux 上の自作 VM はスナップショット肥大と実機署名環境との差分コストを生みます。SSH だけではストレージグラフと Organizer の体感が取りにくいです。物理リモート Mac への VNC なら、見えるものだけを削除し、アーカイブ方針をチームに引き継げます。短期案件でハードを買わず、GUI 完備の安定環境が欲しい場合は VNCMac の VNC 対応レンタル Mac が時間対効果で有利なことが多いです。ヘルプセンターの接続手順と本チェックリストを Runbook に組み込み、徹夜の緊急削除を減らしてください。