Mac アプリ削除後の残骸ファイルを片付ける
同じアンインストール済みアプリでも、残留ファイルを調べるツールによって一覧が違うことがあります。必ずしもバグではなく、ファイルの関連付け、保護対象、使える権限の違いが関係します。大切なのは件数ではなく、ほかのアプリや個人のデータを誤って含めていないかです。
このガイドは、そのあとの状態についてです。アプリはすでに消えているか、いまちょうど ゴミ箱に入ったところ。本来アンインストーラーが持つべき丁寧さで、残留を見直したいとき向けです。 アプリがまだ動いているあいだの手順全体は、 完全なアンインストール を参照してください。製品選びは AppCleaner の先へ を参照してください。
アプリをゴミ箱にドラッグしても消えるのはバンドルだけで、データは ~/Library 以下の Application Support、Caches、Preferences、Containers に残ります。残留はサイズや名前ではなく bundle identifier で帰属させ、削除前に候補をひとつずつ確認するか、まさにそれを徹底するアンインストーラーを使ってください。
macOS で「アンインストール」が実際に意味すること
macOS は、アプリケーションを「削除ボタンがひとつある単一のオブジェクト」としては扱いません。少なくとも 三つの層があります。
| 層 | よくある場所 | 誰が消すべきか |
|---|---|---|
| App bundle | /Applications、~/Applications、Setapp など |
あなた、ゴミ箱、またはパッケージマネージャ |
| ユーザーサポート | ~/Library/… |
残留スキャナー、または丁寧な手作業レビュー |
| システム / 特権 | /Library、helpers、receipts、extensions |
まずベンダーのアンインストーラー |
ゴミ箱にドラッグして確実に消えるのは、いちばん上の層だけです。真ん中の層では汎用 ツールが役に立ちます。三番目の層では、よく「できたつもり」になって失敗します。ドライバー、 ネットワーク拡張、特権ヘルパー、ライセンス用デーモンです。だからこそ Apple も、その層では ベンダーの Uninstall アプリを優先するよう案内しています (Apple のアプリ削除ガイド)。
ユーザー残留が実際にいる場所
サードパーティの残留の多くは、ホームの Library 以下に集まります。
| 領域 | 多くの場合の中身 |
|---|---|
Application Support/<Name or ID> |
データベース、オフラインパック、プロジェクト状態 |
Caches/<bundle id> |
再生成できるキャッシュ |
Containers/ と Group Containers/ |
サンドボックスのホームと共有グループ |
Preferences/(+ ByHost) |
設定の plist |
Logs/、DiagnosticReports |
診断情報 |
Saved Application State/ |
ウィンドウ復元 |
HTTPStorages/、WebKit、cookies |
その identity のネットワーク状態 |
LaunchAgents/ |
plist を持つユーザーのログインヘルパー |
Application Scripts/ |
サンドボックス用スクリプトパッケージ |
/Library 以下のシステムパス(LaunchDaemons、PrivilegedHelperTools、/private/var/db/receipts の
receipts)は、よりリスクの高い層です。ベンダーの削除手段を優先し、汎用スキャナーは
そこではレビュー専用として扱ってください。
サンドボックス化されたアプリは、見た目がすっきりしていることがよくあります。主コンテナは
~/Library/Containers/<bundle id> です。それでも App Groups、Application Scripts、
共有キャッシュ、CloudKit、Keychain 項目を使うことがあります。サンドボックスは直接のファイルアクセスを
狭めますが、ディレクトリがひとつに収まる保証はありません。サンドボックスなしのアプリは
Application Support、Caches、Preferences、Logs、Saved Application State、WebKit、
Cookies に散らばります。散らばりが広いほど、ふたつのツールが食い違う余地も増えます。
どのアプリのファイルかを確認する
安全な残留検出の鍵は、マーケティング名ではなく identity(識別子) です。
Bundle identifier と表示名
com.example.widget は、改名やローカライズをまたいでも安定しています。表示名はそうではありません。
ふたつの製品が会社フォルダ(…/Application Support/Google)を共有していて、
アンインストールしたのは片方だけ、ということもあります。「Google」を文字列としてマッチさせるのは、
スキャナーが数 GB 規模の誤検出を作る典型パターンです。
識別子(bundle ID)でのマッチング は対象を絞りやすい方法ですが、共有コンテナや別のアプリによる利用は確認が必要です。 また、製品名で作られたフォルダを見落とす場合があります。
名前でのマッチング はそのフォルダを見つけますが、たまたま同じ語を共有しているものも拾います。 見つかる量は増え、誤る回数も増えます。
削除前の実務チェック:
mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null
その id を持つものがまだあれば、共有のサポートパスは live(稼働中) として扱ってください。
ヘルパーと埋め込み identity
最近のアプリは、関連 id を持つヘルパーを同梱します。com.example.widget.helper、
SMPrivilegedExecutables で宣言された名前、Contents/Library/LoginItems 以下のログイン項目などです。
丁寧なスキャナーは、アプリが消える 前に バンドルからそれらの id を集めます。バンドルが
なくなったあとに残るのは、記録しておいた情報か、正確な名前のままディスクに残っているものだけです。
Group containers
~/Library/Group Containers/ は、スイート共有データを意図的に置きます。
group.<bundle id><TeamID>.<bundle id>のような team-scoped 名- 複数アプリが使う共有の
group.*空間
自動関連付けの候補にしてよいのは、所有者スコープが正確に一致するパスだけです。共有グループ ツリーは、兄弟がひとつでも残っているならレビュー専用か、手を付けない方がよいです。ここが 「たくさん見つけた」ツールが実害を出す典型カテゴリです。
名前のバリアントとチャネルビルド
Foo Beta は Foo Beta、FooBeta、そしてまだインストールされているリリースチャネル用の
安定版 Foo フォルダを残すことがあります。チャネル名を剥がしたベース名は誤検出リスクが
高いです。安定版アプリが消えたと証明できない限り、レビュー専用に留めてください。
安全な入口は三つ
1. まずベンダーのアンインストーラー
セキュリティエージェント、VPN クライアント、オーディオドライバー、エンドポイントツールは、 自分の receipt と拡張機能の取り外し順を知っています。Library を歩く前に、それらを先に実行してください。 ファイル削除は、システム拡張やネットワーク拡張を確実に無効化する手順ではありません。macOS が それらを登録しています。
2. アプリがすでに消えたあとのレビュー
.app がなくなったあとは、その bundle id や正確な名前バリアントが付いたパスをスキャンします。
保守的な既定の扱い:
- 所有が明確なら多くの場合 OK: caches、logs、saved state、crash reports
- 慎重にレビュー: Application Support、Containers、Preferences(ライセンス、オフライン メール、プロジェクト DB)
- 通常は残す: 正確な所有権のない Group Containers、Library 外の Documents、 別の id がまだ必要とするもの
候補のサイズ確認:
du -sh ~/Library/Application\ Support/<Name> \
~/Library/Caches/<bundle.id> \
~/Library/Containers/<bundle.id> 2>/dev/null
権限エラーの多くは、フォルダが空という意味ではなく、Terminal にフルディスクアクセスがないことを 意味します。
3. アプリがゴミ箱に入った瞬間
多くの人は、まずゴミ箱に入れてから考えます。~/.Trash に新しい .app が来たことを検知し、
Info.plist の identity を読み、関連サポートファイルをスキャンして 確認パネル を開く
ウォッチャーは、宝探しなしに残留を拾えます。有用と有害を分ける設計上の制約:
- ゴミ箱に入れたアプリバンドル自体は絶対に自動削除しない(Put Back が動くこと)
- protected / AV / MDM クラスではポップしない
- クリーナー自身 がアンインストール中にそのアプリをゴミ箱へ入れた場合は、 一回限りの抑制を消費する(そうしないとパネルがアンインストール流れと競合する)
- フルディスクアクセスを前提にし、なければバックグラウンドから促さず静かに失敗する
Mole の残留スキャンは、インストール済みアプリ、bundle ID、receipt がまだ所有するパスを先に差し引き、確認できない候補は未選択のままにします。名前とサイズを表示し、戻せる削除はゴミ箱へ送ります。Library 内で大きいだけでは理由になりません。
孤児は「Library 内の大きいもの全部」ではない
残留ファイルの候補を調べるときは、まずサポートフォルダを列挙し、インストール済みのソフトが使うものを除外します。bundle ID、起動中のアプリ、Launch Services の登録、メーカーの共有フォルダなどが手がかりです。タイムアウトや読み取れない場所があり、確認が不完全なら、推測で候補を出さない方が安全です。
最終更新時刻も確認します。先週まで書き込まれていた設定は、アプリ一覧に出てこない CLI ツールのものかもしれません。.app が見つからないだけで不要とは判断できません。
具体例:ふたつのツール、ひとつのベンダー・スイート
同じ会社が Product B も出しており、そちらはまだインストールされている状態で、Product A を アンインストールしたとします。
- ツール 1(identifier 寄り):短い一覧。ほぼ
com.vendor.productA.*パス。 - ツール 2(name 寄り):
~/Library/Application Support/Vendor(4 GB)と、両製品が使う group container を追加。
ツール 2 の方が徹底しているように見えます。しかし提案している削除は、Product B を壊し得ます。 画面下端の合計は品質スコアではありません。その上にあるカテゴリが肝心です。
Homebrew の孤立した receipt
アプリが Homebrew Cask 由来なら、.app だけ消すと Caskroom の記録が残り、再インストールを
妨げることがあります。ファイル残留のあとに:
brew list --cask
token が残っていれば、brew uninstall --cask <token> で関連付けを切れます(brew 自身の
より広いクリーンアップが欲しいときだけ --zap を受け入れる)。アプリがすでに消えたあとの
「Cask is not installed」は stale association(古い関連付け) であり、Caskroom の
パスを適当に rm -rf する理由にはなりません。
名前が一致しても拒否すべきもの
- まだインストールされている兄弟やチャネルの双子
- 共有の group containers とベンダー親フォルダ
- 検証済みの削除手段がない receipts と privileged helpers
- Library 外のユーザー文書
- キャッシュパスの近くにある AI のチャット保存やモデルディレクトリ (AI ツールの残りファイル整理)
よくある誤り
見つかった一覧を最大化する。 候補が多いほど、帰属が悪いことが多いです。
Group Containers を既定で消す。 共有は意図的なものです。
VPN、AV、オーディオ、仮想化でベンダーのアンインストーラーを飛ばす。
フルディスクアクセスなしで計測し、「何も残っていない」と結論する。
まとめて残留を消した直後にゴミ箱を空にする。 重要なものが誤帰属していたかもしれないなら、 通常利用を一日ほど挟んでからにしてください。
確認
- 削除したパスを再計測する。
- その id のログイン項目や launch agent が残っていないことを確認する (ログイン項目の整理)。
- 同じベンダーの兄弟アプリを起動する。
- 削除を受け入れてからだけ、ゴミ箱を空にする。
作業の順番
- ドライバー、拡張、ヘルパーがあったアプリなら、ベンダーのアンインストーラーを探す。
- 必要なら、アプリがまだ動いているうちにエクスポートや認可解除をする。
- アプリと見えるヘルパーを終了する。
- バンドルを削除する(またはすでにゴミ箱にあることを確認する)。
- 残留を identity でレビューする。共有コンテナには手を付けない。
- 該当すれば Homebrew cask の receipt を処理する。
- Mac を普通に使っているあいだはゴミ箱に置き、そのあと空にする。
アンインストール後の一日目
アプリが消えた瞬間にゴミ箱を空にする人は多いです。少し遅らせても失うものはなく、 戻り道が残ります。
- 初日は、アプリバンドルと、再生成されると確認できた caches だけをゴミ箱に入れる。
- Application Support と Containers はそのままにして、一日ふつうに Mac を使う。
- 兄弟アプリや同じベンダーの他製品が問題なく起動するなら、二回目の分を削除する。
- まだ判断のつかないパスは
du -shでサイズを控え、一週間後に決める。
ゴミ箱は同じボリューム上にあるので、空にするまで容量は戻りません。待つことで手に入るのは 復元できる猶予です。ディスクが本当に足りないときは、再生成される caches を先に空けて 余裕を作り、判断のつかないパスは後回しにします。
権限と可視性
フルディスクアクセスがないと、Terminal も多くのスキャナーも Containers の中や Library の
一部を見られません。du は権限エラーを出しながら合計まで進みますが、その合計には開けなかった
ものが丸ごと抜けています。読み方は「何も残っていない」ではなく「見る権限がない」です。
- Terminal、またはスキャンを実行するツールにフルディスクアクセスを与えてから計測し直す
- 前後の数字を比べる。半分目隠しのまま判断すると、数 GB のコンテナが空として通ってしまう
- 使わなくなったツールからはフルディスクアクセスを回収する。Mac でいちばん広い読み取り権限で、 一度与えると与えた理由より長く残る
「完全なアンインストール」との分担
完全なアンインストール は、アプリがまだ 入っているあいだの順番を扱います。まずベンダーのアンインストーラー、必要ならエクスポートや 認可解除、終了、バンドルの削除、そのあとに残ったもののレビューです。この記事はバンドルが すでにない状態を前提にします。簡単な証拠が消えたあとの残り半分、つまりどのファイルがその アプリのもので、どれが共有されていただけかを判断することに紙面を使います。
参考リンク
- Apple: Mac のアプリ削除ガイド
- 関連記事:アプリを完全にアンインストールする方法、 AppCleaner の代替、 クリーナーが消してはいけないもの
残留クリーンアップは identity の整備です。スキルはギガバイトの最大化ではなく、 所有を証明し、共有状態を守り、削除を復元可能に保つことです。
よくある質問
自分で ~/Library 以下の残留を消して大丈夫ですか?
帰属が取れているときだけです。フォルダをアプリの bundle identifier に合わせ、サイズや似た名前には合わせず、送る前にひとつずつ確認してください。ひとつの誤りが、別アプリのデータや自分の文書を消すことがあります。
そもそもなぜアプリはファイルを残すのですか?
バンドルをゴミ箱へ移しても、Library に保存した設定やデータは通常そのまま残ります。専用アンインストーラ、パッケージマネージャ、システム拡張はそれぞれ扱いが異なるため、該当する場合はメーカーの手順に従ってください。
再インストールすれば、消したものは戻りますか?
キャッシュと一部の初期設定は通常再作成されますが、インストール記録が初回起動で戻るとは限りません。書類、チャット履歴、独自の設定は再インストールだけでは戻りません。ライセンスの再認証も製品とアカウント次第なので、削除前にそれぞれのバックアップと復元方法を確認してください。