MENU
暮らしを少し便利にするアプリとサービスを作っています
  1. ホーム
  2. Androidアプリ
  3. 「ストレージが足りないかも」と出た開発者がやること｜Xcode・Android Studio・Flutter の容量整理

「ストレージが足りないかも」と出た開発者がやること｜Xcode・Android Studio・Flutter の容量整理

Androidアプリ Flutter iOSアプリ Macアプリ

私は Mac mini(メモリ32) と MacBook Air（メモリ16） の2つを併用して、普段仕事をしています。
(Mac mini がメイン機で、MacBook Air はサブ機でMACアプリの確認などに使っています。)
MacBook Air をアップデートしようとしたら、突然「ストレージが足りないかも」と表示されました。

512GB のモデルなのに、空きは約 92GB。開発に Xcode や Android Studio が欠かせないので、アプリ自体は消せません。「ノートPCの買い替えか…」とまで考えました。

結論から言うと、買い替えは不要でした。 開発環境のキャッシュ類を整理しただけで、空きが 90GB → 211GB になりました。

この記事では、実際にやった手順と、再発させないための習慣をまとめます。

目次

先に結果

場所整理前整理後
シミュレータのランタイム53.9GB（7個）14.8GB（1個）
CoreSimulator/Devices36GB3.3GB
iOS DeviceSupport20GB0
.gradle/caches約12GB0
Android エミュレータ（AVD）約12GB（2台）0
Xcode Archives4.6GB0
ディスクの空き約90GB約200GB

消したのは、どれも必要になれば自動で再生成・再ダウンロードされるものだけです。
なお、開発のメインにしている Mac mini（1TB）でも同じ整理をして、空きが 312GB → 540GB になりました（手順6を参照）。

大前提：まず「どこが大きいか」を調べる

闇雲に消さず、先に容量を測ります。ターミナルで次を実行してください。

du -sh ~/Library/Developer/Xcode/* 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null
du -sh ~/.gradle ~/.android ~/.pub-cache 2>/dev/null
du -sh ~/Library/Caches 2>/dev/null

私の場合の結果は、こうでした。

 20G  Xcode/iOS DeviceSupport
 36G  CoreSimulator
 12G  .gradle
 12G  .android
4.6G  Xcode/Archives
2.9G  Xcode/macOS DeviceSupport
2.5G  .pub-cache
361M  Xcode/DerivedData

意外なことに、定番の DerivedData は 361MB しかなく、犯人ではありませんでした。本当に大きかったのはシミュレータと実機シンボルです。「DerivedData を消せばいい」と思い込まず、まず測るのが大事です。

手順1：シミュレータのランタイムを整理する（効果：最大）

Xcode をアップデートするたびに、新しい iOS のシミュレータランタイムが増えていきます。古いものは自動では消えません。

まず一覧を見ます。

xcrun simctl runtime list

私の環境では、iOS 18.5 / 26.0 / 26.1（同じ版が2つ）/ 26.2 / 27.0 / 27.1 の 7個で 53.9GB ありました。

シミュレータで動作確認するなら、最新の1つだけあれば十分です。ほかは ID を指定して削除します。

xcrun simctl runtime delete <ランタイムのID>

ID は先ほどの一覧に出ている UUID です。残すものを間違えないよう、1つずつ実行して確認しながら進めてください。

そのあと、使えなくなったデバイスをまとめて削除します。

xcrun simctl delete unavailable

これで、Devices が 36GB → 3.3GB になりました。ランタイムを消したあとに、対応するデバイスが「unavailable」で残っていたためです。

削除したランタイムは、必要になれば Xcode の Settings → Components から再ダウンロードできます。

手順2：iOS DeviceSupport を消す（効果：大）

実機を接続してデバッグすると、iOS のバージョンごとに「デバッグ用シンボル」が ~/Library/Developer/Xcode/iOS DeviceSupport に溜まります。1バージョンで約5GBあり、私は4つで約20GBでした。

中身を確認します。

ls -la ~/Library/Developer/Xcode/iOS\ DeviceSupport/
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/* | sort -hr

古い iOS のものは不要です。次に実機をつなぐと、必要なものだけが自動で再作成されます（初回接続時にシンボル転送で少し待つだけです）。

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

zsh が「sure you want to delete all … files? [yn]」と確認してくるので、内容を確かめて y を入力します。

手順3：Gradle のキャッシュを消す（効果：中〜大）

Flutter で Android アプリを作っていると、~/.gradle が肥大化します。私は約 12GB でした。

rm -rf ~/.gradle/caches

次回の Android ビルドだけ、依存ライブラリの再ダウンロードで時間がかかります。それ以外の影響はありません。

手順4：Android エミュレータ（AVD）を整理する

~/.android は 12GB ありましたが、ほぼすべてが avd（エミュレータ本体）でした。

du -sh ~/.android/* 2>/dev/null | sort -hr

ここで注意点が2つあります。

  • ~/.android フォルダごとの削除は絶対にやらない。 debug.keystore（デバッグ署名）や adbkey（ADB認証）が入っています。
  • AVD の削除は Android Studio の Device Manager から行う。 .avd フォルダと .ini ファイルが対になっているため、フォルダだけ消すと不整合が起きます。

Apple Silicon の Mac では、x86 のエミュレータイメージは動きません。Intel Mac 時代に作った AVD が残っていたら、削除候補です。確認方法はこれです。

grep abi.type ~/.android/avd/*/config.ini

x86_64 と出たものは、M シリーズでは起動できません。arm64-v8a のものが使えます。

手順5：消すのを待つもの・慎重に扱うもの

場所扱い
Xcode/Archives公開済みアプリの最新版だけ残す。dSYM（クラッシュ解析用）が入っているため、全部消すのは避ける。Xcode の Organizer から整理する
macOS DeviceSupport古いバージョンのフォルダだけ消す
.pub-cache基本は残す。最後の手段
~/.android 全体消さない

手順6：「消したのに空きが増えない」ときは、スナップショットを疑う

Mac mini（1TB）でも同じ整理をしました。シミュレータのランタイムを7個から2個に、iOS DeviceSupport を13個から2個にして、CoreSimulator は 89GB → 210MB になりました。

ところが、df の空きは 312GB のまま、まったく変わりませんでした。 再起動しても同じです。

ここで確認したのが、Time Machine のローカルスナップショットです。

tmutil listlocalsnapshots /

前日の日付のスナップショットが1つ残っていました。これが、削除前のデータを保持していたようです。外付けのバックアップ本体とは別の、Mac 内に一時的に作られるものです。次のコマンドで削除しました。

sudo tmutil deletelocalsnapshots <日付の部分>

<日付の部分> は、一覧に出た名前の com.apple.TimeMachine. と .local の間の部分です（例：2026-11-07-125704）。

結果は、空きが 312GB → 540GB になりました。

外付けディスクや NAS にある Time Machine のバックアップ本体には、影響しません。消えるのは、Mac 内の一時的なスナップショットだけです。
スナップショットは、空きが足りなくなると macOS が自動で消すので、放っておいても実害はありません。ただ、df の数字を実際の空きとして見たいときは、手動で消すのが確実です。

「システム設定 → 一般 → ストレージ」の空きが先に増えて、df が変わらないときは、このパターンを疑ってください。

実行前のチェックリスト

  • Xcode と Android Studio を終了した
  • rm -rf のパスに余計なスペースが入っていない（iOS\ DeviceSupport/* の * の前にスペースがあると、別の場所を消すおそれがある）
  • 消すものが「再生成されるもの」だと確認した
  • 容量を du で測ってから消した

rm -rf は元に戻せません。不安なら1つずつ、ls で中身を見てから実行してください。

今後の習慣：再発させないために

溜まる原因は、次の3つです。

  1. Xcode のアップデートごとにシミュレータランタイムが増える
  2. 実機を接続するたびに DeviceSupport が増える
  3. ビルドのたびに Gradle や DerivedData のキャッシュが増える

そこで、次の習慣を作ります。

月1回（またはリリース作業の区切り）

# 使えなくなったシミュレータを削除
xcrun simctl delete unavailable

# DerivedData を削除
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# 各 Flutter プロジェクトで
flutter clean

Xcode をアップデートしたとき

xcrun simctl runtime list

古いランタイムが増えていないか確認し、使わないものを削除します。

実機の iOS を上げたあと

~/Library/Developer/Xcode/iOS DeviceSupport の古いバージョンのフォルダを削除します。

容量の確認

df -h / | tail -1

Avail の列が実際の空きです。

df -h / の Used が小さく見えるのは、macOS のシステム領域が別ボリュームになっているためです。見るのは Avail です。
また、「システム設定 → 一般 → ストレージ」の空き容量は、purgeable（必要に応じて自動で空けられる分）を含むため、df より大きめに表示されます。

まとめ

「ストレージが足りないかも」と出ても、開発マシンは、ビルドの副産物（再生成できるもの）が数十GB単位で溜まっていることがよくあります。

今回のポイントを振り返ります。

  • まず du で測る。 定番の DerivedData が犯人とは限らない
  • 一番大きかったのは、シミュレータのランタイムと DeviceSupport
  • 再生成できるものだけを消す。 ~/.android 全体は消さない
  • Xcode のアップデート後に、古いランタイムを消す習慣をつける

この記事が、同じ警告に驚いた開発者の役に立てば嬉しいです。

(2026年11月時点の環境：MacBook Air M4 / 16GB / 512GB、Xcode、Android Studio、Flutter)

Androidアプリ Flutter iOSアプリ Macアプリ
macOS
目次