XcodeのDerivedDataがMacの容量を圧迫しているとき、まず何をクリーンアップすべきか

Macで毎日アプリをビルドしているなら、DerivedDataは遅かれ早かれ、重要だと分かっていながら誰かがすでにクリーンアップしてくれていればいいのにと思うフォルダの一つになります。

そしてある日、フォルダが巨大になり、ディスクが逼迫し、Xcodeがいつもより重く感じられ、クリーンアップの問いが切迫します：安全に削除できるのか、それとも作業日をリビルドの混乱に変えようとしているのか？

短い答えは、DerivedDataは通常、より安全なXcodeクリーンアップターゲットの一つです。より長い答えは、開発者がDerivedDataに過剰に集中し、すぐ近くにあるAppleエコシステムのフットプリントの残りを見落としがちだということです。

簡潔な回答

通常安全にクリーンアップできるものと要注意なもの

XcodeのDerivedDataが実際に何であるか

DerivedDataは、Xcodeが開発ワークフロー用の生成ビルド出力と関連する作業データを保持する場所です。実用的には、通常、ビルド成果物、インデックス、中間ファイル、プレビュー関連の出力、およびXcodeが次回ビルド時やプロジェクトを開く際に高速化するのに役立つその他の生成アーティファクトを意味します。

だからこそフォルダが簡単に大きくなるのです。すべてのプロジェクト、ターゲット、ブランチ、SDKの組み合わせ、およびシミュレータワークフローが、時間とともにより多くの生成状態を追加します。

これも、開発者がDerivedDataを通常のプロジェクトファイルとは異なる扱いをする理由を説明しています。

• これはアプリコードの信頼できるソースではありません;
• ビルドとインデックスの時間を節約するために存在します;
• 必要に応じて再生成されることが想定されています。

この再生成の動作が、DerivedDataが多くのアプリ所有またはシステム所有のパスよりも安全なクリーンアップターゲットとして分類される理由です。

XcodeのDerivedDataがこんなに大きくなる理由

最もシンプルな答えは蓄積です。

アクティブなアプリが1つでも、すでに多くのビルド出力を生成できます。複数のアプリ、複数のブランチ、プレビュー、シミュレータ実行、テストビルド、パッケージ解決の履歴が、フォルダをほとんどの開発者の予想をはるかに超えて押し上げます。

DerivedDataが膨張する一般的な理由：

• 複数のアクティブなプロジェクトが同じマシンを共有している;
• 古いプロジェクトごとのフォルダが、プロジェクトの重要性が失われてからも長く残っている;
• プレビュー、インデックス、シミュレータ中心の作業が余分な負荷を生成する;
• 長期間使用されるXcode環境が、古いビルド出力を予想以上に長く保持する;
• 他のものはクリーンアップするが、生成されたApple開発アーティファクトには触れない。

重要な点は、大きいDerivedDataは開発者のMacでは珍しくないということです。正しい答えが常に「今すぐすべて削除」であると想定せず、他に何が大きいか、タイミングが適切かを確認せずに問題になるだけです。

DerivedDataの周辺で大きくなりやすい他のもの

開発者はDerivedDataを blame しがちです。使い慣れているからですが、それはAppleエコシステムフットプリントの一つのプロファイルにすぎません。

StorageRadarの現在のApple側開発プロファイルは、これらのXcode周辺領域を分離しています。同じリスクモデルを共有していないためです。

これが、単一ディレクトリに固執するよりも完全なDeveloper Folderスキャンが有用な本当の理由です。DerivedDataが12 GBでも、CoreSimulatorが35 GBでArchivesが18 GBであれば、クリーンアップ計画は完全に変わります。

DerivedDataと共に大きくなりがちなApple開発者フォルダ

Archives

Archivesは単なる生成されたスクラッチスペースではありません。実際に保持したい成果物を表すことがあります。だからこそ、DerivedDataとは別のクリーンアップバケットに属します。

CoreSimulator

シミュレータデータは、特に多くのランタイムでテストする場合や、シミュレータの状態を長期間保持する場合、ひっそりとDerivedDataを超える大きさになることがあります。これは単なる破棄可能なキャッシュフォルダではありません。まだ気にするシミュレータ環境が含まれている可能性があります。

もしシミュレータストレージが本当の問題であれば、Xcode Simulator Taking Up Space on Mac? What to Clean Firstの特集ガイドがランタイム、デバイスの状態、クリーンアップのトレードオフについてさらに詳しく解説しています。

iOS DeviceSupport

この領域は、異なる物理デバイスバージョンとサポートアセットが蓄積するにつれて大きくなります。DerivedDataほど有名ではないため見落とされがちですが、それでも重要な大きさになります。

パッケージ関連のキャッシュ

これらはシミュレータやアーカイブデータよりも安全なクリーンアップターゲットになることがありますが、DerivedDataとは別物です。回収可能な容量を本格的に追っている場合、各プロファイルを独自のクリーンアップ問題として扱ってください。

すべてを削除するより選択的クリーンアップが良い場合

開発者のデフォルトの反射行動は、多くの場合完全なクリーンアップです：フォルダ全体をワイプし、Xcodeに再構築させ、先に進みます。

それで問題ないこともありますが、常に最善の選択とは限りません。

選択的クリーンアップが通常より良い場合：

• 古いプロジェクトがいくつかだけでサイズの大部分を占めている場合;
• 現在アクティブなアプリの高速で予測可能なビルドが必要な場合;
• 今日すべての完全な再インデックスを強制したくない場合;
• 古いブランチや使用されなくなったワークスペースが本当の問題であり、現在のプロジェクトではないと疑う場合。

完全なワイプがより合理的な場合：

• フォルダ全体が多くの古いプロジェクトで膨張している場合;
• 生成された出力のクリーンリセットがしたい場合;
• 現在の遅延が制御されたリビルドの時間枠と交換する価値がある場合;
• グローバルな生成状態が問題の一部であると疑う場合。

これは実際にはストレージの決定に見せかけたタイミングの決定です。容量の節約は似ていても、ワークフローのコストは異なります。

XcodeのDerivedDataをリビルドの混乱なくクリーンアップする方法

安全な目標は単に「容量を空けること」ではありません。安全な目標は「次の数時間の開発を予測可能に保ちながら、適切な容量を空けること」です。

1. まず開発者全体の状況を確認

DerivedData単独ではなく、Developer Folderから始めてください。目的は、Xcodeの出力が本当に主要な問題なのか、他のApple開発プロファイルの方が大きいのかを確認することです。

より広範な開発者フットプリントが問題である場合、DerivedDataだけをクリーンアップしても予想より回収が少ないかもしれません。

2. 安全な生成出力とCautionプロファイルを分離

この区別は重要です。

• DerivedDataとキャッシュは、生成されたものであるため、通常はSafeスタイルのクリーンアップターゲットです;
• Archives、CoreSimulator、iOS DeviceSupportは、まだ必要な成果物、ランタイム、または状態を保持している可能性があるため、より慎重な対応が必要です。

これらを混同すると、「開発者クリーンアップ」は単なる危険なフォルダパージになってしまいます。

3. 選択的クリーンアップか完全クリーンアップかを意図的に決定

何かを削除する前に、次の質問に答えてください。

1. 最大のDerivedDataディレクトリは、古いプロジェクトとアクティブなプロジェクトのどちらに関連していますか？
2. 今日、高速なビルドとインデックスが必要ですか？
3. 隣接するプロファイルが実際にDerivedDataより大きいですか？
4. 完全なリビルドの時間枠が現在のスプリント、デモ、またはリリース作業に影響しますか？

この短い確認で、ほとんどの不要な完全ワイプを防げます。

4. データの消失ではなくリビルドコストを予想

DerivedDataでは、クリーンアップの通常のコストは通常次のとおりです。

• 次のビルドが遅くなる;
• インデックスの再構築;
• プレビューやシミュレータの起動が重くなる;
• 生成された出力が戻るまでの一時的な摩擦。

これは、まだ必要なアプリサポートデータ、アーカイブ、または気にしていたシミュレータの状態を削除するのとは全く異なります。開発者クリーンアップは、これらのカテゴリを分離しておく場合にのみ安全であり続けます。

5. 通常のファイル削除ではなく、開発者クリーンアップワークフローを使用

通常のファイルブラウザは、何かが大きいことは教えられても、そのパスが既知の開発プロファイルかどうか、SafeかCautionバケットかどうか、起こり得る結果は何か、クリーンアップ前にガイド付きプレフライトが必要かどうかは教えられません。

この欠けているコンテキストが、リスクが高まるにつれて開発クリーンアップが通常の「最大ファイル」クリーンアップに崩壊すべきでない理由です。

Xcodeのクリーンアップが通常のファイルクリーンアップと違う理由

通常のファイルクリーンアップはシンプルな質問を投げかけます：何が大きいか？

Xcode、Docker、SDK中心のセットアップ、開発者リスクプロファイルにまたがるより広範なガイドが必要な場合は、Macで開発者キャッシュを安全にクリーンアップする方法をお読みください。

開発者クリーンアップはより難しい質問をする必要があります。

• これは生成されたものか、ユーザーが作成したものか;
• このプロファイルはSafe、Caution、それともDangerousか;
• 回収可能な容量を信頼する前にDry Runが必要か;
• プロファイルにワークフローのリスクがあるためGuided Preflightが必要か;
• まず確認すべきブロッカー、警告、または結果は何か？

この違いは、StorageRadarのDev Cleanupモデルに組み込まれています。これは任意の削除として動作しません。既知の開発者プロファイルとリスクポリシーから動作します。

例えば、現在のApple開発プロファイルは次のように分割されています。

• Xcode DerivedDataはSafe;
• Xcode ArchivesはCaution;
• CoreSimulator DataはCaution;
• iOS DeviceSupportはCaution;
• SwiftPM CacheはSafe。

これはクリーンアップの混乱の対極です。生成されたキャッシュを保持されたアーティファクトやシミュレータの状態とは異なる扱いにする、エコシステムを認識したワークフローです。

StorageRadarの役割

これが実用的なワークフローを変えます。

• Apple開発者領域全体が膨張している可能性がある場合、Developer Folderを使用;
• 通常のファイル削除ではなくプロファイルを認識したクリーンアップが必要な場合、Dev Cleanupを使用;
• DerivedDataのようなSafeプロファイルを、Archivesやシミュレータ関連ストレージのようなCautionプロファイルから分離して維持。

この区別こそが、開発者マシンにとっての全価値です。製品は単にフォルダが大きいことを伝えるだけではありません。それはどのような種類の開発者ストレージであり、どのようなクリーンアッププロセスに値するかを伝えています。

やってはいけないこと

これらの一般的な間違いを避けてください。

• DerivedDataが確認すべき唯一のXcodeフォルダだと想定しない;
• Archives、CoreSimulator、iOS DeviceSupportを同じリスクプロファイルであるかのようにワイプしない;
• リビルド時間が重要な期限の直前に完全なリセットを行わない;
• エコシステムコンテキストが必要な開発者アーティファクトに最大ファイルのロジックだけを使用しない;
• 生成されたビルド出力をプロジェクトデータ、成果物、または保持されたシミュレータの状態と混同しない。

Apple開発アーティファクトがSystem Dataを不自然に大きく見せている場合、関連ガイドのMacのSystem Dataが大きすぎる場合が次に読むべきものです。

まとめ

DerivedDataがMacの容量を圧迫している場合、安心できる点は、生成された出力であるため、通常はより安全なXcodeクリーンアップターゲットの一つであることです。あまり明らかでない点は、DerivedDataが全体像であることは稀だということです。

最善のクリーンアップ決定は、より広範な開発者フットプリントを確認し、SafeプロファイルとCautionプロファイルを分離し、パニックではなく現在のワークフローに基づいて選択的または完全なクリーンアップを選択することから生まれます。