リモートMac CIのディスク容量不足はどうする？2026年の調査ガイド

ビルドやアーカイブの途中で容量不足になり、リモートMacのCIが止まっていませんか。

今週の対応は、まず空き容量と増加したディレクトリを記録し、DerivedData、シミュレーター、Archives、作業領域のどこが占有しているかを切り分けることです。再生成できると確認したデータだけを対象にし、開発用ディレクトリ全体を一括削除しないでください。自前Runnerでは、ジョブ後の清掃と容量の監視も運用に加えます。

iOS／macOS開発者は、ビルドやアーカイブの失敗箇所を特定したいときに活用できます。
CIエンジニアは、持続稼働するmacOS Runnerに残るデータの管理に役立ててください。
小規模チームの運用担当者は、清掃で足りるのか、ワークフローやホスト容量を見直すべきか判断できます。

失敗した工程と空き容量を記録する

「ディスク容量不足」は、ビルド成果物を書き込めない、アーカイブの作成に失敗する、ホスト側で容量警告が出るなど、異なる現象を指すことがあります。エラー表示だけでは原因のディレクトリまで判断できません。

まず、失敗した工程、ログの該当箇所、作業ディレクトリ、発生時点の空き容量を記録します。同じホストでジョブを繰り返した後に悪化しているのか、一度の大きな処理で発生したのかも分けてください。単発の失敗と、ジョブごとに空き容量が減っていく状態では、対処が異なります。

空き容量と大きなフォルダを調べる例です。

df -h /
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
du -sh "$HOME/Library/Developer/Xcode/Archives" 2>/dev/null
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

dfでファイルシステムの空きを、duで指定した場所の使用量を確認します。作業領域やログの場所は環境によって異なるため、Runnerの設定に合わせて対象を追加してください。権限不足で結果に表示されない項目もあります。macOSのストレージ表示とコマンドの結果が異なる場合は、Appleのストレージ確認手順も参照し、表示上の分類だけで削除先を決めないでください。

Xcodeの生成データとArchivesを分けて調べる

XcodeのDerivedDataには、プロジェクトのビルド生成物だけでなく、索引やログなども含まれます。保存場所や生成データの扱いは、Xcodeのビルド生成ファイルに関する資料で確認できます。

DerivedDataを消せば常に安全、とは限りません。ビルド中のプロセスが使っていないか、消した後に必要な依存関係や設定を再現できるかを先に確認します。対象のプロジェクトを指定できるなら、フォルダ全体ではなく、そのプロジェクトの生成データに範囲を限定してください。macOS CIのキャッシュとして残しているデータは、再生成にかかる時間や取得先も踏まえて、清掃するか決めます。

ArchivesはDerivedDataとは別に扱います。アーカイブの保存先や、問題を調査するときの注意点はAppleのアーカイブ関連の技術資料を確認してください。配布や保守に必要なアーカイブを消すと、容量は空いても後から必要な成果物を復元できない場合があります。保管対象を明確にしてから、不要と確認できたものだけを処理します。

注意：容量を急いで空けたいときほど、Archives、認証情報、作業領域をまとめて削除しないでください。再生成できるデータと、保存が必要なデータは別の手順で判定します。

シミュレーターのランタイムと端末データを切り分ける

iOSシミュレーターを使うテストでは、ランタイム、シミュレーター端末ごとのデータ、プロジェクトの生成物を区別します。どれか一つを減らしても、実際の占有先が別なら空き容量は十分に戻りません。

利用中のXcodeとテスト対象を確かめ、Xcodeの管理画面でインストール済みのプラットフォームや端末を確認します。Appleのシミュレーター追加手順とXcode追加コンポーネントの説明を基準に、使われていない対象かどうかを調べてください。Xcodeやテストが使用中のファイルを、確認せず手作業で消すのは避けます。

対象を一つずつ整理したら、同じ計測方法で空き容量を再確認します。iOSシミュレーターを使うテストも再実行し、対象のランタイムが利用可能で、アプリのビルドと起動が完了することを確かめます。Appleのビルドと実行に関する案内を参照し、テスト対象や実行条件をそろえて復旧を確認してください。

自前Runnerの残留データをジョブ単位で管理する

ホストされたRunnerと自前Runnerでは、次のジョブにデータが残るかどうかが異なります。GitHubのジョブを実行するRunnerの選び方と自前Runnerの管理上の特性を確認し、どの実行環境の運用責任を自分たちが持つかを整理します。

持続稼働する自前Runnerでは、作業領域、依存キャッシュ、ログ、成果物、認証情報を別々に扱います。たとえば、プロジェクトの一時作業データはジョブ終了後に片付ける一方、調査用ログや配布用成果物は保存期限と保管場所を決めます。認証情報を作業領域の清掃に巻き込まないよう、保存場所と権限も分離してください。Runnerのコンテナを使う構成では、コンテナのカスタマイズに関する公式説明も確認し、コンテナ内外の保存先を混同しないようにします。

接続方法や利用環境の確認が必要な場合は、MangoVMの利用案内を参照できます。実際のホストで作業する前に、保存対象と清掃対象をチーム内で共有してください。

清掃後の再現テストと再発防止を行う

清掃後は、容量が戻ったかだけでなく、ジョブが最後まで完了するかを検証します。失敗したビルド、テスト、またはアーカイブのうち該当する処理を同じ条件で実行し、成果物が想定した保存先に作成されることと、次のジョブを開始できることを確認します。作業前後の空き容量とログを残すと、対処の効果を後から比較できます。

• [ ] 失敗した工程、ログ、作業領域、作業前の空き容量を記録した
• [ ] DerivedData、Archives、シミュレーター、作業領域を個別に調べた
• [ ] 保存が必要なアーカイブ、成果物、ログ、認証情報を削除対象から分けた
• [ ] 再生成できると確認したデータだけを、対象を限定して整理した
• [ ] 代表的なビルドやテストを再実行し、成果物の保存と次のジョブを確認した
• [ ] ジョブ前後の容量を記録し、清掃ルールと容量警告の条件を見直した

清掃後も同じ工程で空き容量が急減するなら、キャッシュの保存期間、ジョブの並列実行、成果物の置き場所を確認します。個々のジョブが一時的に使う容量と、Runnerに積み上がるデータを分けて考え、実際の負荷に合わせて警告条件やホスト容量を見直してください。容量が不足するたびに手動削除する運用では、原因の再発を見逃しやすくなります。

よくある確認事項

DerivedDataは削除する前に何を確認しますか？

対象プロジェクトのビルドやテストが動作中でないことを確かめ、削除後に同じ環境で再ビルドできるかを確認します。プロジェクト単位で対象を絞れる場合は、広い範囲をまとめて消さず、消去後に空き容量とビルド結果を記録してください。

Runnerのキャッシュを毎回消せばよいですか？

キャッシュを毎回消すと容量は解放できますが、依存データを再取得・再生成する構成になります。再利用するキャッシュとジョブ固有の作業領域を分け、再利用の効果と残留リスクを比べてルールを決めます。削除対象に認証情報や保管必須の成果物を含めないでください。

シミュレーターの整理後、何をもって復旧と判断しますか？

空き容量が増えたことだけでは不十分です。使用するランタイムと端末を選べること、同じ条件のビルドやテストが完了すること、成果物が保存され、後続ジョブも開始できることを確かめます。検証前後の記録を残せば、同じ障害が再発したときに比較できます。

一時的な清掃で直らない場合はどうしますか？

ジョブ前後の空き容量を継続して記録し、どのデータが増加しているかを確かめます。不要データの清掃だけでは足りず、継続的な負荷に対してホスト容量が不足しているなら、ワークフローの保存方法や実行環境を見直します。

清掃で解決しないときは実行環境も見直す

ログと再現テストで容量の増加先を特定できたら、まず清掃範囲とRunnerの運用を修正してください。LinuxのCI環境だけではmacOS専用のビルド工程を担えず、手元のMac一台に集約すると、その端末の利用状況や接続に運用が左右されます。一方、自前のMacを常時稼働させる方法では、キャッシュや作業領域の清掃、容量監視を自分たちで続ける必要があります。

一時的な検証環境や、手元のMacでは不足するmacOS CIの工程が必要なら、MangoVMのリモートMac環境も選択肢になります。継続する重い負荷や物理接続が必要な処理では、自前機材のほうが適する場合もあります。まず清掃後の代表ジョブを再確認し、それでもホスト容量と負荷が合わないと分かった段階で、作業内容に合う環境を選んでください。

よくある質問