最初に書き込みを伴うジョブを停止し、空き容量・inode・実行中プロセスを記録してから、ワークスペース、DerivedData、Simulator runtime、Archive、依存パッケージキャッシュの順に所有者と再生成可否を確認します。削除後も通常の処理で容量が再び尽きるなら、全削除を繰り返さず、保管方針の見直し、ジョブ分離、ストレージ拡張へ進みます。

この手順は、Xcodeの容量不足でビルドが止まり、低リスクで復旧したい当番開発者向けです。共有リモートMac Runnerを維持するDevOps担当者、容量とリリース成果物を受け入れるプラットフォーム担当者にも適しています。

今週の対応は、次の時間軸で進めます。

  • 直後：新しいビルド、テスト、Archiveを止め、最初の有効なエラーとディスク状態を保存します。
  • 復旧中：停止済みジョブが残した再生成可能データだけを整理し、同じコミットと引数で再実行します。
  • 今週中：キャッシュ、Simulator、Archiveの保管責任者と削除条件を決め、必要なら別ノードや容量拡張を検討します。
01

障害現場の凍結

ログに No space left on device が出ても、それだけでは原因のディレクトリは分かりません。書き込みに失敗した対象がワークスペースなのか、一時ファイルなのか、Simulatorのデータなのかを確定する前に、開発ディレクトリ全体を消去するとArchive、署名に必要な材料、診断情報まで失うおそれがあります。

まず実行アカウントと対象ノードを確認し、書き込みを続けるジョブを停止します。パスやプロジェクト名は固定値で決めず、<WORKSPACE>、<RUNNER_USER>、<DEVICE_NAME> のような実際の値に置き換えてください。

id
pwd
df -h /
df -i /
du -sh "<WORKSPACE>" 2>/dev/null
ps aux | grep -E 'xcodebuild|simctl|swift|clang' | grep -v grep

df -h は容量、df -i はinodeの逼迫を確認するためのものです。容量が残って見えてもinodeが枯渇していれば新規ファイルを作れないため、容量だけを見て「まだ余裕がある」と判断してはいけません。macOSのストレージ確認については、Appleのストレージ管理説明も参照してください。

注意：rm -rf "<WORKSPACE>"、DerivedDataの一括削除、ノード再構築を最初の対応にしてはいけません。まず失敗ログ、ディスク情報、実行中ジョブ、対象アカウントを保存し、復旧不能になった場合の交接先を決めます。

02

当番開発者の作業領域

当番開発者が最初に行うのは、ソースコードと生成物の分離です。未コミットの変更、パッチ、設定ファイル、テスト用の入力データは保管対象であり、停止済みジョブの一時出力や重複クローンとは扱いが異なります。

次のように、候補を一覧化してから削除対象を絞ります。

find "<WORKSPACE>" -maxdepth 2 -type d -print
du -sh "<WORKSPACE>"/.[!.]* "<WORKSPACE>"/* 2>/dev/null | sort -h
find "<WORKSPACE>" -type f -name '*.xcarchive' -print

削除してよい候補は、停止済みジョブが作成し、再取得または再生成の方法が確認できる作業用ディレクトリです。実行中のジョブが参照しているパス、成果物として提出するArchive、署名や診断に使うファイルは残します。

削除後は、たまたま別のキャッシュが効いて成功したかを避けるため、同一コミット、同一スキーム、同一のビルド引数で再実行します。復旧後もすぐに容量が減る場合は、同じジョブを繰り返さず、ログと削除前後の一覧をノード管理者へ渡します。

03

ビルドキャッシュの所有権

DerivedDataは、Xcodeのビルド中間生成物を保管する代表的な場所ですが、すべてを無条件に不要とみなすことはできません。実行中のジョブが参照していないこと、対象プロジェクトと実行アカウントが一致していること、クリーンビルドで再生成できることを確認してから扱います。

xcodebuild -version
xcodebuild -showBuildSettings -workspace "<WORKSPACE>.xcworkspace" \
  -scheme "<SCHEME>" | grep -E 'BUILD_DIR|CONFIGURATION_BUILD_DIR|DERIVED_DATA'

実際の保存場所は、Xcodeの版、実行アカウント、ワークフローの引数によって変わるため、既知のパスを盲目的に削除してはいけません。Xcodeのコマンドラインツールの説明は、Apple DeveloperのXcodeコマンドラインツール資料とCommand-line tools資料で確認できます。

Swift Package、Homebrew、その他の依存パッケージキャッシュも同様です。最終更新時刻、所有プロジェクト、再取得に必要な認証、ネットワーク制約を確認し、キャッシュの削除によって次回の依存解決やコンパイルが重くなる点を運用記録に残します。

復旧判定は一回の成功では足りません。

  • [ ] 並行ジョブが対象ディレクトリを使用していない
  • [ ] 削除対象が再生成可能で、所有者が確認できる
  • [ ] Archive、署名材料、診断ログを保全した
  • [ ] 同一コミットと同一ビルド条件でクリーンビルドを実行した
  • [ ] 続けてキャッシュを再利用するビルドを実行した
  • [ ] 実行後の空き容量と生成された成果物を記録した
  • [ ] 容量が再び減る場合の交接先を決めた
04

Simulatorとプラットフォーム部品

iOS Simulatorの容量問題では、Simulator runtime、個別のシミュレーター端末、テスト生成データを別々に確認します。runtimeを削除すると、そのruntimeを必要とするテストマトリクスが実行できなくなるため、現在の対象OSを先に確認します。

Xcodeのコンポーネントは、対応する管理画面またはAppleのXcode追加コンポーネント資料に沿って扱います。シミュレーター端末の起動や管理については、Appleのシミュレーター管理資料を確認してください。

本機のコマンドが利用できるかを先に調べます。

xcrun simctl help
xcrun simctl list runtimes
xcrun simctl list devices

<DEVICE_NAME> が現在のテスト対象でないと確認できるまでは、端末の消去や削除を実行しません。runtimeと端末を混同せず、削除後には対象runtimeの認識、端末の起動、テスト実行、セッション切断後の再接続まで確認します。実機またはシミュレーターでの実行条件は、Appleのアプリ実行ガイドに沿って再確認できます。

05

Archiveとリリース資産

リリース担当者は、容量を空ける前にArchive、エクスポート済みパッケージ、シンボルファイル、アップロード中間物を一覧化します。Archiveは単なるビルドキャッシュではなく、後日の再配布、診断、リリース監査に必要となる成果物です。

find "<ARCHIVE_ROOT>" -type d -name '*.xcarchive' -print
find "<EXPORT_ROOT>" -type f -maxdepth 2 -print
du -sh "<ARCHIVE_ROOT>" "<EXPORT_ROOT>" 2>/dev/null

保留中のリリース、提出済みだが確認前の成果物、留保期限を過ぎた成果物を分け、移行・保管・削除の判断を記録します。キーチェーン、証明書、プロビジョニング関連ファイルは、空き容量を作るための削除対象にしてはいけません。

Archiveからのエクスポートや配布の流れは、AppleのArchiveと配布に関する資料を基準にします。デバッグ情報を含む成果物の扱いも、Appleのデバッグ情報とArchive資料で確認します。

復旧後は、単なる xcodebuild の終了コードではなく、Archiveの生成、エクスポート、必要なアップロードまたは受け渡し、シンボルの存在まで確認します。これらが成立しない場合、ノードを「復旧済み」と扱ってはいけません。

06

共有Runnerの容量ガバナンス

共有リモート Mac CIでは、複数プロジェクトの作業領域、依存キャッシュ、Simulator、Archiveが同じストレージを競合します。問題の所有者が曖昧なまま全員のキャッシュを消す運用は、再発原因を隠すだけで、次のビルドで同じ障害を起こします。

プラットフォーム担当者は、次の保管単位を分けて記録します。

  • プロジェクトのソースと未完了作業
  • ジョブごとの一時出力と再生成可能なDerivedData
  • 依存パッケージやツールのキャッシュ
  • テストマトリクスが必要とするSimulator runtimeと端末
  • リリース状態に応じて保管するArchiveとデバッグ情報

ジョブ終了時には一時出力の削除結果、リリース完了時にはArchiveの移行結果、ノード再起動時にはruntime・端末・署名環境の確認結果を残します。削除処理は、対象パス、実行アカウント、ジョブ状態、削除前後のディスク情報を記録できる形にします。

経験則：整理後も正常なビルド、Simulatorテスト、Archiveが通常どおり容量を消費し、保管期限を守っても空きが戻らないなら、原因は「掃除不足」ではなく容量設計です。開発用とリリース用のノードを分けるか、保持期間を短くするか、より大きいストレージ構成へ移行します。

07

FAQ

復旧後の判断基準

Xcode No space left on deviceを解消した後は、ビルドだけでなく、Simulatorテスト、Archive、エクスポート、ノード再起動後の再接続まで確認します。DerivedDataだけを削除して終了するのではなく、同じジョブを再現できること、成果物を受け渡せること、容量の減少が監視できることを復旧条件にします。

通常の保管対象を残しただけで容量が継続的に不足する場合は、全消去よりもジョブ分離と容量拡張が適切です。実プロジェクトでノードの保存量と復旧手順を確認したい場合は、NodeMiniのMac環境案内を参照し、必要な構成を個別に照合してください。

現在の構成が、開発用ワークスペースとリリース用Archiveを同じノードに集中させている場合、障害時の影響範囲が広くなります。Mac miniを長期運用する案と比較する場合は、Mac miniの利用方法に関する案内も確認し、物理機器の保守、保管期間、入れ替え作業まで含めて判断します。

現在のLinuxホストやローカルの小容量Macで運用を続ける方法は、初期費用を抑えられる一方、XcodeとSimulatorを必要とする処理、容量の異なる複数ジョブ、常時稼働するArchive保管を同時に扱うと制約が出ます。構築とテストを一時的に分離したい場合や、実プロジェクトでリモートMac CIのストレージと復旧性を確かめたい場合は、NodeMiniのMacレンタルを候補にできます。必要な期間だけ実環境を使い、清掃後の再ビルド、Simulatorテスト、Archive、再起動復旧まで確認してから、ノード分割や構成変更を決める方法が安全です。