iOSビルドサーバーのディスク容量不足？2026 Xcode 27は清掃か拡張か

遠隔MacでArchiveが突然失敗し、ソースコードも署名情報も正常なのに「ディスク容量不足」だけが表示されるなら、今週は全削除ではなく、構築キャッシュ、Simulator Runtime、依存関係、リリース成果物の順に分類してください。低頻度の単一アプリは清掃ルールを先に整え、高頻度の複数プロジェクトで満杯が繰り返す場合だけ、ディスク拡張か独立したビルド環境へ進むのが安全です。

対象読者

遠隔Macを1台だけ使い、最近ビルド中の容量警告が増えた独立開発者向けです。Xcode 27、複数のSimulator Runtime、過去のArchiveを同時に残したい場合も、削除してよいものと保管すべきものを分けて判断できます。

複数アプリの自動ビルドを運用する小規模チームは、単一ホストの清掃、ストレージ拡張、開発・テスト・公開環境の分離を、実際の使用場面ごとに比較できます。

容量不足を4層に分ける

Xcodeのビルドシステムでは、ソース以外にも中間生成物、ビルド出力、テスト結果、デバッグ用情報が発生します。Appleの Xcode Build Systemの説明 と Build Settings Reference を基準に、実際のホストでプロジェクトごとの出力先を確認してください。

ここで重要なのは、同じ「Xcode関連ファイル」でも回復方法が異なることです。DerivedDataは作り直せても、ArchiveやdSYMを失えば、後から再エクスポートしたり、クラッシュを記号化したりできない場合があります。

最初の30分で行う停止確認

削除操作より先に、次の順番で作業状態を固定します。

1. CIや手動操作で、Build、Test、Archive、Exportが実行中でないことを確認します。
2. 実行中のジョブがある場合は停止または完了を待ち、対象プロジェクト、Scheme、使用中のXcodeを記録します。
3. ディスク使用量を、プロジェクト別、Xcode世代別、ユーザー別、依存関係別に分けて確認します。
4. Archive、IPA、dSYM、xcresult、アップロードログを、保管対象と一時ファイルに分類します。
5. 清掃前に、ソース、署名情報、依存関係の定義、再構築手順が別の復旧経路に存在するか確認します。
6. ひとつの分類だけを処理し、同じプロジェクトで再解決、ビルド、Archiveを順に検証します。

xcodebuildでは派生データの保存先を指定できるため、プロジェクトごとに生成物の所在を固定しやすくなります。保存先の考え方は、Appleの xcodebuildと派生データに関する公式例 と照合してください。

Archive専用サーバーの整理境界

Release Archiveだけを作る遠隔Macと、日常開発で増分コンパイルやSwiftUI Previewを使う環境では、清掃の許容度が違います。

Archive専用なら、UIテスト用のSimulator Runtimeや大量のアプリデータを同じホストに常備する必要性は低くなります。ただし、公開用のArchive、dSYM、Export結果、アップロードログは、再提出やクラッシュ解析に必要になる可能性があるため、キャッシュと同じ規則で削除しないでください。

DerivedDataの扱い

DerivedDataは、現在のジョブが終了し、同一の依存関係とビルド設定から再生成できることを確認したプロジェクトから整理します。削除後は、単にビルドが通るだけでなく、署名付きArchiveとExportまで確認してください。

複数のXcodeを使う場合は、どのXcodeで生成されたデータかを記録します。全ユーザーディレクトリや、すべてのXcode関連フォルダを一括削除する方法は、別プロジェクトの復旧材料まで失うため避けます。

xcarchive、IPA、dSYMの扱い

xcarchiveは、再エクスポートや後日の調査に使うリリース単位の証跡です。IPAは配布物、dSYMはクラッシュログの解析に関係し、役割が異なります。Appleの デバッグ情報に関する公式説明 も確認し、3種類をまとめて「古いビルド」と扱わないでください。

Simulator Runtimeとテストデータ

Simulator Runtime、作成済みの仮想端末、アプリデータ、スクリーンショット、テスト結果は、すべて同じ一時ファイルではありません。Appleの 追加コンポーネント管理 を参照し、テストマトリクスに必要なRuntimeだけを残します。

Archiveだけを担当するサーバーなら、開発用の全Runtimeを維持する構成を見直せます。一方、複数OS世代のUIテストや回帰確認を行う場合は、削除前に対象Scheme、テスト計画、必要なRuntimeを一覧化してください。

シミュレーターは、実機のカメラ、性能特性、センサー、OS固有挙動を完全には代替しません。Appleの シミュレーターと実機のテスト範囲 が示す境界を踏まえ、容量を理由に実機検証まで省略しないことが重要です。

複数プロジェクトと依存関係キャッシュ

複数アプリを1台で処理すると、どのキャッシュを消せばよいか分からなくなりやすくなります。プロジェクト、Xcode、依存関係の取得元、保管成果物を別々の台帳で管理し、「一括削除」で運用を済ませないでください。

依存関係を整理する場合は、次の証拠を連続して確認します。

• PackageやPodのバージョン固定がリポジトリに残っている。
• キャッシュを整理した後、依存関係を再解決できる。
• 初回のコールドビルドが完了する。
• Archiveが作成される。
• 署名付きExportと、必要なアップロード処理が完了する。

Schemeの設定やArchive対象は、Appleの Schemeカスタマイズ資料 と照合してください。依存関係キャッシュを削除しただけで、すぐに「安全」と判断するのではなく、リリース経路全体を再確認する必要があります。

清掃、拡張、分離の判断

次の条件分岐で、今週の対応を決めます。

• 単一アプリで、主な占有が再生成可能なDerivedDataや不要なテストデータである場合は、ジョブ停止、分類、限定清掃、Archive検証の順に進めます。
• 複数のXcodeや複数アプリを扱い、依存関係とArchiveの保管が必要な場合は、清掃だけでなく保存先の分離を先に行います。
• UIテスト用Runtimeを維持しながら公開Archiveも保管する場合は、テスト用Macと公開用Macを分ける候補にします。
• 整理後も通常のビルド運用で空き容量が戻らない場合は、ディスク拡張を検討します。
• 発版時だけ容量が急増し、平常時は低頻度である場合は、唯一の本番ホストを大きく改造するより、期間限定の独立した遠隔Macを追加する方が回退しやすくなります。
• 清掃のたびに署名資産やArchiveを移動しなければならない場合は、容量問題だけでなく復旧設計の問題として、環境分離を優先します。

現在の遠隔Macが、開発、UIテスト、署名付き公開、Archive保管をすべて担当しているなら、容量を増やしても管理対象が増えるだけです。反対に、単一アプリの低頻度Archiveで、問題が明確なキャッシュだけなら、まず清掃ポリシーを整える方が合理的です。

VPSMACの遠隔Macを追加する場面

短期のOS対応、季節的なリリース集中、複数アプリの並行検証が原因なら、1台の本番ビルドサーバーを削り続けるより、作業期間に合わせて別のMac環境を用意する方が安全です。VPSMACの 遠隔Macサービス を確認し、必要な期間と作業分担を整理してください。

本番用ホストを共用し続ける構成では、テスト用Runtimeが増えるたびに公開用Archiveの保管領域を圧迫し、清掃時に誤削除の範囲も広がります。用途別に環境を分ければ、テスト終了後に環境を停止または返却し、唯一の署名・公開経路を直接触らずに済みます。

接続拠点を検討する場合は、VPSMACのMacノード一覧 から、作業者の所在地、接続経路、利用期間、必要なツールチェーンを照合してください。自前機の購入が向くのは、長期間にわたり安定した高負荷を継続し、物理デバイス接続や常時保管を自分で管理したい場合です。短期の容量ピークだけであれば、レンタルの方が不要になった環境を戻しやすいでしょう。

よくある確認事項

Xcode 27のビルドマシンが満杯になったとき

最初にBuild、Test、Archive、Exportが実行中でないことを確認し、ディスク使用量をDerivedData、Simulator Runtime、作成済みシミュレーター、依存関係キャッシュ、xcarchive、IPA、dSYM、xcresultに分けて記録します。分類前にホームディレクトリ全体やKeychainを削除する方法は、原因と復旧経路を同時に失うため避けてください。

削除しても戻しやすいファイル

再生成できるDerivedDataや、検証済みの一時ビルド出力は、実行中のジョブがなく、同じソースと設定から再構築できることを確認した後に候補になります。ただし、依存関係キャッシュを消すと再解決とコールドビルドが必要になり、xcarchive、dSYM、署名資産は単なるキャッシュとして扱えません。

Simulator RuntimeとArchiveの保管

同じ基準では管理できません。Simulator Runtimeはテスト対象のOSバージョンとテストマトリクスに必要なものだけを残す対象ですが、Archiveは再エクスポート、審査対応、クラッシュ調査に使う証跡です。Archiveを削除する場合は、IPA、dSYM、ソース、署名情報、再構築手順の代替経路を先に検証します。

DerivedDataの定期清掃

定期削除そのものは可能ですが、スケジュールだけで実行せず、ジョブ状態とプロジェクト単位の再構築結果を条件にしてください。BuildやTestの途中で消すと、処理の失敗や診断情報の欠落につながります。削除後は依存関係の復元、コールドビルド、Archive、署名付きExportまで確認してから運用へ戻します。

拡張へ切り替える基準

一度の不要データ整理で解決せず、複数のXcode世代、複数アプリ、UIテスト用Runtime、保管すべきArchiveが同時に必要なら、清掃だけでは再発します。まず保管対象と削除対象を分離し、それでも通常の運用サイクルで空き容量が戻らない場合は、ディスク拡張またはテスト用・公開用Macの分離を検討します。

iOSビルドサーバーのディスク容量不足は、単純な削除作業ではなく、再生成できるデータと失うと復旧できない証跡を分ける運用問題です。低頻度の単一アプリなら清掃と保管ルール、高頻度の複数アプリなら拡張または分離を選び、短期的な容量ピークではVPSMACの遠隔Macを追加する構成も比較してください。