# Unity の Library フォルダーは削除しても大丈夫？

> MangoDisk で古い Unity プロジェクトの Library の容量を比較し、パスを確認して削除。アセット、設定、メモリスナップショットを残す方法と、再インポートの影響を解説します。

**作業を保存して Unity プロジェクトを閉じ、元のアセットと設定が揃っていることを確認すれば、削除できます。** プロジェクト内の `Library` には、通常、Unity が生成した内部データが保存されています。削除すると、次にプロジェクトを開いたときにデータの再生成とアセットの再インポートが必要です。しばらく使わない古いプロジェクトの整理には役立ちますが、毎日削除する必要はありません。[Unity のアセットインポートの説明](https://docs.unity3d.com/6000.0/Documentation/Manual/ImportingAssets.html)

複数の Unity プロジェクトが残っているなら、[MangoDisk](/ja) のディープクリーンアップで、検出されたプロジェクトの生成物のパスと容量をまとめて確認できます。古いプロジェクトのどの `Library` を削除するか、容量を比較してから決められます。無料・オープンソースで、登録やログインは不要。ファイルのスキャンはローカルで行います。

## MangoDisk で古いプロジェクトの容量を比較する

プロジェクトが一つなら、手作業での整理は難しくありません。複数になると、それぞれのフォルダーを探して容量を調べ、今も使っているプロジェクトを見分ける手間がかかります。MangoDisk では検出された Unity の生成物を一か所で確認し、展開した一覧からパスごとに選択できます。すべてのプロジェクトをまとめて削除する必要はありません。

![Windows 版 MangoDisk のディープクリーンアップ画面で、分類ごとのパスと容量を確認して削除対象を選択](https://assets.mangodisk.app/images/screenshots/windows/ja/light-01-deep-cleanup.jpg)

*画像はディープクリーンアップ画面の例です。表示されるプロジェクトはスキャン結果によって異なります。*

[ディープクリーンアップ](/ja/docs/features/deep-clean)で**標準スキャン**を実行し、**プロジェクトのビルド成果物**にある **Unity ビルド成果物**を確認します。別のディスクに保存したプロジェクトも調べる場合は、スキャンボタン横の**ディスクを選択**から対象のディスクを追加してください。

削除するときは、次の順で確認します。

1. パスと容量を比較し、当面作業する予定のない古いプロジェクトを選びます。
2. シーンとコードを保存し、ビルドを停止して Unity Editor を終了します。重要なアセット、設定、自分で加えた変更をバックアップしてください。
3. **すべて解除**を選び、Unity の項目を展開して、確認済みの古いプロジェクトの `Library` パスだけを選択します。
4. 選択したパスと削除予定の容量を見直し、クリーンアップを確定します。

**Unity の項目には Temp、Obj、Logs、MemoryCaptures も含まれる場合があります。Library を削除したいだけなら、項目全体を選ばないでください。** ログやメモリスナップショットがまだ必要かどうかは、別に判断します。

Unity ビルド成果物はデフォルトでは選択されず、スキャンだけではファイルは削除されません。クリーンアップを確定すると、MangoDisk は選択した内容をゴミ箱を経由せずに完全削除します。復元の制限は[安全性ガイド](/ja/docs/safety)をご確認ください。画面の案内だけに頼らず、Unity が終了し、ビルドも停止していることを自分で確認してから実行しましょう。

## Library の場所と容量が増える理由

ここで扱う `Library` は、**Unity プロジェクトのルートフォルダー**にあり、`Assets`、`Packages`、`ProjectSettings` と同じ階層に並んでいます。Mac のユーザーフォルダーにある `~/Library` とは別物です。同じ名前という理由で、ほかの場所のフォルダーを削除しないでください。

Unity は元のアセットを、エディターや対象プラットフォームで使える内部データに変換し、プロジェクトの `Library` に保存します。このデータはプロジェクトごとに作られるため、コードがあまり増えていなくても、複数のプロジェクトに残ったキャッシュが容量を使っている場合があります。

`Library` が大きいだけで、問題があるとは限りません。毎日使うプロジェクトでは、保存済みのデータが再インポートの手間を減らしてくれます。削除すれば一時的に空き容量は増えますが、次に開くとまた生成されます。空けたい容量と、再インポートを待つ時間の両方を考えて判断しましょう。

<table>
<thead>
  <tr>
    <th>
      プロジェクトの状況
    </th>
    
    <th>
      整理の目安
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      長く開いていない練習用、デモ、旧バージョンのプロジェクト
    </td>
    
    <td>
      バックアップを確認し、Library の容量を調べる
    </td>
  </tr>
  
  <tr>
    <td>
      近いうちに開発、テスト、ビルドを続けるプロジェクト
    </td>
    
    <td>
      再インポートを繰り返さずに済むよう、通常はキャッシュを残す
    </td>
  </tr>
  
  <tr>
    <td>
      Library に自分のファイルを保存した、またはパッケージのコードを直接変更した
    </td>
    
    <td>
      自分のデータや変更を保存してから、削除できるか判断する
    </td>
  </tr>
</tbody>
</table>

## 残しておくフォルダーとファイル

`Library` を再生成できるからといって、プロジェクト内のほかのデータまで削除できるわけではありません。

<table>
<thead>
  <tr>
    <th>
      内容
    </th>
    
    <th>
      扱い方
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        Library
      </code>
    </td>
    
    <td>
      プロジェクトを閉じ、自分のデータを失わずに再生成できることを確認してから、必要に応じて削除
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        Assets
      </code>
      
       と対応する <code>
        .meta
      </code>
    </td>
    
    <td>
      アセット、スクリプト、アセットの識別情報などを含むため残す
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        Packages
      </code>
    </td>
    
    <td>
      依存関係の設定や埋め込みパッケージのソースを含むため残す
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        ProjectSettings
      </code>
    </td>
    
    <td>
      プロジェクトの設定を含むため残す
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        Temp
      </code>
      
      、<code>
        Obj
      </code>
    </td>
    
    <td>
      内容とプロジェクトの状態を個別に確認。Library と一緒に削除する必要はない
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        Logs
      </code>
    </td>
    
    <td>
      調査に使うログは残す。古いログにも必要な情報がある場合がある
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        MemoryCaptures
      </code>
    </td>
    
    <td>
      必要なメモリスナップショットを残す。自動で再生成できるキャッシュとして扱わない
    </td>
  </tr>
</tbody>
</table>

`.meta` は小さなファイルでも、アセットの識別情報やインポートに関する情報を保存しています。アセットと一緒に残してください。[Unity のアセットメタデータの説明](https://docs.unity3d.com/6000.0/Documentation/Manual/AssetMetadata.html)

見落としやすいのが、**Library/PackageCache 内のパッケージのソースを直接変更している場合**です。削除前に変更を保存してください。Unity が案内する URP の変更手順では、キャッシュからプロジェクトの `Packages` にパッケージをコピーし、埋め込んだソースを編集します。自分で加えた変更をキャッシュ内にだけ残さないようにしましょう。[URP ソースコードの変更手順](https://docs.unity3d.com/6000.0/Documentation/Manual/urp/customize/modify-urp-source-code.html)

`MemoryCaptures` は別の用途のフォルダーです。Unity Memory Profiler で取得またはインポートしたスナップショットを保存し、その時点のメモリ使用状況を分析、比較するために使います。プロジェクトを開き直しても、過去の同じ状態のスナップショットは再生成されません。[Memory Profiler のスナップショットの説明](https://docs.unity3d.com/Packages/com.unity.memoryprofiler@1.1/manual/snapshot-capture.html)

## 一つのプロジェクトを手作業で整理する

作業を保存して Unity を終了し、Windows のエクスプローラーまたは Mac の Finder でプロジェクトのルートフォルダーを開きます。同じ階層に `Assets`、`Packages`、`ProjectSettings` があることを確認し、`Library` のプロパティや「情報を見る」で容量を調べてください。

バックアップと内容の確認が済んだら、そのプロジェクトの `Library` だけを削除し、ほかのフォルダーは残します。元に戻す余地を残したい場合は、まずゴミ箱に移動できます。ただし、ゴミ箱内のデータも容量を使うため、空き容量を増やすには後でそのデータも削除する必要があります。

一つのプロジェクトなら、エクスプローラーや Finder で対応できます。複数の古いプロジェクトを比べたいときは、MangoDisk で候補のパスと容量をまとめて確認し、個別に選べます。

MangoDisk にプロジェクトが表示されなくても、生成データがないとは限りません。現在の Unity ルールは、`Assembly-CSharp.csproj`、`Assets`、`ProjectSettings` を手がかりにプロジェクトを識別します。これらがない場合や、フォルダーがスキャン範囲外にある場合は検出されないことがあります。ツールに認識させるためにプロジェクトを変更する必要はありません。まずディスク使用量分析で実際のフォルダーを調べてください。[MangoDisk の Unity クリーンアップルール](https://github.com/harry0703/MangoDisk/blob/v1.1.6/src-tauri/crates/mangodisk-core/rules/project-artifacts/unity.toml)

## 削除した Library がまた大きくなったら

プロジェクトを開き直すと、Unity は新しい `Library` を生成します。これは正常な動作です。以前のキャッシュを削除しても、プロジェクトに必要なデータまで不要になるわけではありません。

最初に開くときは、アセットのインポートに普段より時間がかかる場合があります。完了を待ってから、シーン、アセットの参照、ビルドを確認してください。フォルダーを小さく保つために何度も削除したり、Library の削除だけですべての Unity エラーが直ると考えたりしないようにしましょう。

それでもディスクがいっぱいなら、MangoDisk の[ディスク使用量分析](/ja/docs/features/disk-analysis)で、実際に容量を使っているフォルダーを探します。元の素材、古いインストーラー、ほかのツールのビルド成果物が大きい場合もあります。`Assets` が大きいときは、どの素材がプロジェクトで使われているかを確認し、キャッシュと同じ感覚で削除しないでください。

ほかの開発環境については、[Gradle キャッシュの削除方法](/ja/blog/clear-gradle-cache)や [Cargo キャッシュと target の違い](/ja/blog/cargo-cache-vs-target-folder)も参考にできます。データの用途はツールごとに異なるため、実際のパスと内容を確認して整理しましょう。

[MangoDisk をダウンロード](/ja)して古いプロジェクトの生成物の容量を比較し、整理する `Library` を選びましょう。開発中のプロジェクトのキャッシュや、必要な診断データは残せます。

関連記事：[開発者向けディスククリーンアップ](/ja/blog/topics/developer-cleanup)。