Mac空き容量ゼロ事件をClaudeと一緒に解剖した話 - 60GB空けても一瞬で埋まる謎を追う

#macOS #DiskSpace #Claude #Troubleshooting #iPhone #Backup

Mac空き容量ゼロ事件をClaudeと一緒に解剖した話 - 60GB空けても一瞬で埋まる謎を追う

Zoom中にメールが受信できなくなった。原因を辿ると、Macの空き容量が 400MB まで減っていた。60GB 空けたはずなのに、気づいたらゼロに戻っている。

この「気づいたら空き容量ゼロ」問題、Claudeと一緒に半日かけて解剖した記録を残す。最後には 39GB の自分自身の孤児化した iPhone バックアップが出てきて、思わず笑ってしまった。

症状

「空き容量が 20GB 切ると macOS が書き込みを抑制し始める」という挙動は有名だが、実感として初めてハマった。Zoomのレコーディング先も、メールの一時ファイルも、ブラウザのキャッシュも全部書けなくなる。これは怖い。

診断コマンド5連発

まずは何が大きいのか特定する。いきなり消そうとしないのが大事。

1. ホーム配下の TOP 20

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

結果（抜粋）：

118G  ~/Library
 35G  ~/Documents
 33G  ~/Development
 23G  ~/Music
 11G  ~/.ollama

~/Library が 118GB。普通じゃない数字。ここを掘る。

2. APFSローカルスナップショット

Time Machineを使ってなくても、macOS は勝手にスナップショットを作る。放置されると容量を食う常連。

tmutil listlocalsnapshots /

結果：0件。これは珍しいが朗報。スナップショット問題は除外。

3. Docker確認

Dify/n8n/Ollama を Docker で回していると Docker.raw が肥大している可能性。

find ~/Library -name "Docker.raw" -exec ls -lh {} \;

結果：ヒットなし。Docker Desktop は使っていなかった（過去にリセット済み）。仮説ハズレ。

4. Library のドリルダウン

du -h -d 1 ~/Library 2>/dev/null | sort -hr | head -15

ここでハマったのが macOS の du のクセ。

落とし穴: du -sh -d 1 は macOS の BSD du ではエラーで終了する（-s と -d は排他）。GNU du（Linuxなど）は通るが、macOS では -h -d 1 を使うのが正解。

結果（抜粋）：

132G  ~/Library
 78G  ~/Library/Application Support
 24G  ~/Library/Caches
 14G  ~/Library/Developer

Application Support 78GB。ここに犯人がいる。

5. Application Support の中身

du -h -d 1 ~/Library/Application\ Support | sort -hr | head -15

結果：

39G  iMobie               ← ？？？
9.5G Claude
8.1G VoiceInk
3.9G Dia

iMobie 39GB。記憶にない。

iMobie の正体を探る

iMobie は中国の Eltima 系ソフトウェア会社が作る AnyTrans / PhoneRescue / DroidKit などのブランド。iPhone / Android のデータ転送・バックアップツール。

まず /Applications にアプリ本体があるか確認：

ls /Applications/ | grep -i -E "anytrans|phonerescue|droidkit|iMobie"

→ ヒットなし。アプリは既に消されているのに、データだけ 39GB 残っている孤児状態。

バックアップディレクトリを開く

ls -la ~/Library/Application\ Support/iMobie/Backups/

00008110-000459D92106201E という 40 桁の英数字のディレクトリがあった。これは iPhone の UDID フォーマット。

Info.plist で端末情報を読む

plutil -p ~/Library/Application\ Support/iMobie/Backups/<UDID>/Info.plist | \
  grep -E "Device Name|Product Type|Product Version|Phone Number|Last Backup"

結果：

"Device Name"       => "Vongole Bianco"
"Product Type"      => "iPhone14,6"   (iPhone SE 3rd gen)
"Product Version"   => "18.6.2"
"Phone Number"      => "+81 70 XXXX XXXX"
"Last Backup Date"  => 2026-02-01

"Vongole Bianco"（白アサリ、伊）。

……自分の iPhone の名前だった。完全に忘れていた。

さらに衝撃：バックアップは壊れていた

Status.plist を確認：

plutil -p ~/Library/Application\ Support/iMobie/Backups/<UDID>/Status.plist

結果：

"BackupState"    => "empty"
"SnapshotState"  => "uploading"
"IsFullBackup"   => 1

"empty"。"uploading" のまま止まっている。

さらに決定的な証拠：

ls ~/Library/Application\ Support/iMobie/Backups/<UDID>/Manifest*
# → zsh: no matches found

Manifest.db が存在しない。

iPhone バックアップにおいて Manifest.db はインデックスファイル。これが無いと、どのファイルが何なのか解釈する手段がない。つまり：

2 月 1 日にバックアップを取ろうとして、途中で止まって、そのまま放置されていた 39GB のゴミ、という結論。

思わず笑ってしまった。

何が学びか

1. ツールを悪者にしない

最初「中国製アプリが勝手にデータを残していた」と言いたくなったが、違う。自分がインストールして、自分で使って、自分で忘れただけ。AnyTrans に悪意はない。むしろ、正常終了していれば復元に使えたはずのバックアップだった。

ツールの出身国や運営会社で警戒するのは合理的な場面もある（特に業務データを扱うなら）。でも今回のケースは完全に自分の管理責任。「見えない資産は資産ではない」 が正しい学び。

2. iPhone バックアップの健全性チェック

Info.plist と Status.plist と Manifest.db の有無を見れば、バックアップが生きているかすぐ分かる。

# 生きている条件
# - Info.plist 存在
# - Status.plist で BackupState != "empty"
# - Manifest.db または Manifest.mbdb が存在

これはサードパーティ製でも iTunes/Finder 製でも共通。知っていれば一瞬で判定できる。

3. 60GB埋まる謎は別にあった

iMobie は 2 月 1 日に生成されて以来ずっと 39GB のまま。つまりストック型のゴミであって、「60GB が一瞬で埋まる」フロー型の増殖の犯人ではない。

これを切り分けたのは意外と大きかった。対処法も違う：

種別 特徴 対策
ストック型 過去の残骸、放置されてる 削除すれば終わり
フロー型 継続的に増殖している 根本原因の特定と運用改善が必要

解放できた容量

合計 44.6 GB 解放（空き 400MB → 45GB）。

再起動すればさらに VM ボリュームの 22GB が解放される見込み。ただし現在作業中のため、夜に実施予定。

削除前に必ずやること

壊れたバックアップでも、勢いで消すのは危険。順番はこう：

  1. Info.plist で端末・所有者を特定（UDID、端末名、電話番号など）
  2. 所有者が他人（親族・パートナー・同僚など）なら本人確認必須
  3. 自分のものなら、最新の iPhone の iCloud 設定を確認（iCloud 写真・メッセージなどが ON なら、バックアップの中身の多くは iCloud 側にも存在している）
  4. 判断に迷うなら外付け SSD/HDD に退避。消してしまえば戻らないが、残しておけばいつでも判断し直せる

今回は Foresthill 自身の iPhone（現役稼働中）の古いバックアップ、かつ破損していて復元不能、という条件が揃っていたので削除で確定。

次の一手：診断を自動化したい

この「du 打ってドリルダウン、個別にplutil で正体確認、判定」の流れ、再現性はあるけど時間がかかる。しかも 200 個のプロジェクトを抱えたインディー開発者には現実的じゃない。

「既知のパターンを AI で判定して、削除の可否を人間に提案する」OSS ツールを作ったら需要ありそう、という話はまた別の記事で。

まとめ

60GB が一瞬で埋まる謎については、結論が出たら別記事で。

関連記事