メインコンテンツへ移動
Mole
機能 検証 評判 価格 FAQ ブログ
EnglishEN 简体中文中 繁體中文繁 日本語日 한국어한 FrançaisFR DeutschDE ItalianoIT EspañolES
今すぐ購入購入 ダウンロード

    ヘルプ、ドキュメント、リリース、記事

    ホーム/ブログ

    Mac アプリ削除後の残骸ファイルを片付ける

    アンインストール公開日 2026年7月29日更新日 2026年9月25日約12分で読めます

    同じアンインストール済みアプリでも、残留ファイルを調べるツールによって一覧が違うことがあります。必ずしもバグではなく、ファイルの関連付け、保護対象、使える権限の違いが関係します。大切なのは件数ではなく、ほかのアプリや個人のデータを誤って含めていないかです。

    このガイドは、そのあとの状態についてです。アプリはすでに消えているか、いまちょうど ゴミ箱に入ったところ。本来アンインストーラーが持つべき丁寧さで、残留を見直したいとき向けです。 アプリがまだ動いているあいだの手順全体は、 完全なアンインストール を参照してください。製品選びは AppCleaner の先へ を参照してください。

    アプリをゴミ箱にドラッグしても消えるのはバンドルだけで、データは ~/Library 以下の Application Support、Caches、Preferences、Containers に残ります。残留はサイズや名前ではなく bundle identifier で帰属させ、削除前に候補をひとつずつ確認するか、まさにそれを徹底するアンインストーラーを使ってください。

    macOS で「アンインストール」が実際に意味すること

    macOS は、アプリケーションを「削除ボタンがひとつある単一のオブジェクト」としては扱いません。少なくとも 三つの層があります。

    層 よくある場所 誰が消すべきか
    App bundle /Applications、~/Applications、Setapp など あなた、ゴミ箱、またはパッケージマネージャ
    ユーザーサポート ~/Library/… 残留スキャナー、または丁寧な手作業レビュー
    システム / 特権 /Library、helpers、receipts、extensions まずベンダーのアンインストーラー

    ゴミ箱にドラッグして確実に消えるのは、いちばん上の層だけです。真ん中の層では汎用 ツールが役に立ちます。三番目の層では、よく「できたつもり」になって失敗します。ドライバー、 ネットワーク拡張、特権ヘルパー、ライセンス用デーモンです。だからこそ Apple も、その層では ベンダーの Uninstall アプリを優先するよう案内しています (Apple のアプリ削除ガイド)。

    アプリバンドル、ユーザのライブラリのサポートファイル、システムレベルのヘルパーの3層です
    アプリバンドルの削除は最上層だけです。ユーザー Library の残留とシステムヘルパーは、リスクの異なる別判断です。

    ユーザー残留が実際にいる場所

    サードパーティの残留の多くは、ホームの 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)でのマッチング は対象を絞りやすい方法ですが、共有コンテナや別のアプリによる利用は確認が必要です。 また、製品名で作られたフォルダを見落とす場合があります。

    名前でのマッチング はそのフォルダを見つけますが、たまたま同じ語を共有しているものも拾います。 見つかる量は増え、誤る回数も増えます。

    Bundle identifier の照合は所有パスを正確に見つけ、表示名の照合は候補も誤検出も多くなります
    識別子マッチは狭くて安全です。名前マッチは残留を多く見つけますが、製品がベンダーフォルダを共有していると誤ることが増えます。

    削除前の実務チェック:

    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 フォルダを残すことがあります。チャネル名を剥がしたベース名は誤検出リスクが 高いです。安定版アプリが消えたと証明できない限り、レビュー専用に留めてください。

    バンドルの同一性が残留候補へ流れ、共有ベンダーフォルダは保護されたままです
    帰属は bundle identity から所有パスへ辿るべきで、ほかのアプリがまだ使うベンダー全体フォルダへ広げてはいけません。

    安全な入口は三つ

    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、オーディオ、仮想化でベンダーのアンインストーラーを飛ばす。

    フルディスクアクセスなしで計測し、「何も残っていない」と結論する。

    まとめて残留を消した直後にゴミ箱を空にする。 重要なものが誤帰属していたかもしれないなら、 通常利用を一日ほど挟んでからにしてください。

    確認

    1. 削除したパスを再計測する。
    2. その id のログイン項目や launch agent が残っていないことを確認する (ログイン項目の整理)。
    3. 同じベンダーの兄弟アプリを起動する。
    4. 削除を受け入れてからだけ、ゴミ箱を空にする。

    作業の順番

    1. ドライバー、拡張、ヘルパーがあったアプリなら、ベンダーのアンインストーラーを探す。
    2. 必要なら、アプリがまだ動いているうちにエクスポートや認可解除をする。
    3. アプリと見えるヘルパーを終了する。
    4. バンドルを削除する(またはすでにゴミ箱にあることを確認する)。
    5. 残留を identity でレビューする。共有コンテナには手を付けない。
    6. 該当すれば Homebrew cask の receipt を処理する。
    7. Mac を普通に使っているあいだはゴミ箱に置き、そのあと空にする。

    アンインストール後の一日目

    アプリが消えた瞬間にゴミ箱を空にする人は多いです。少し遅らせても失うものはなく、 戻り道が残ります。

    1. 初日は、アプリバンドルと、再生成されると確認できた caches だけをゴミ箱に入れる。
    2. Application Support と Containers はそのままにして、一日ふつうに Mac を使う。
    3. 兄弟アプリや同じベンダーの他製品が問題なく起動するなら、二回目の分を削除する。
    4. まだ判断のつかないパスは du -sh でサイズを控え、一週間後に決める。

    ゴミ箱は同じボリューム上にあるので、空にするまで容量は戻りません。待つことで手に入るのは 復元できる猶予です。ディスクが本当に足りないときは、再生成される caches を先に空けて 余裕を作り、判断のつかないパスは後回しにします。

    権限と可視性

    フルディスクアクセスがないと、Terminal も多くのスキャナーも Containers の中や Library の 一部を見られません。du は権限エラーを出しながら合計まで進みますが、その合計には開けなかった ものが丸ごと抜けています。読み方は「何も残っていない」ではなく「見る権限がない」です。

    • Terminal、またはスキャンを実行するツールにフルディスクアクセスを与えてから計測し直す
    • 前後の数字を比べる。半分目隠しのまま判断すると、数 GB のコンテナが空として通ってしまう
    • 使わなくなったツールからはフルディスクアクセスを回収する。Mac でいちばん広い読み取り権限で、 一度与えると与えた理由より長く残る

    「完全なアンインストール」との分担

    完全なアンインストール は、アプリがまだ 入っているあいだの順番を扱います。まずベンダーのアンインストーラー、必要ならエクスポートや 認可解除、終了、バンドルの削除、そのあとに残ったもののレビューです。この記事はバンドルが すでにない状態を前提にします。簡単な証拠が消えたあとの残り半分、つまりどのファイルがその アプリのもので、どれが共有されていただけかを判断することに紙面を使います。

    参考リンク

    • Apple: Mac のアプリ削除ガイド
    • 関連記事:アプリを完全にアンインストールする方法、 AppCleaner の代替、 クリーナーが消してはいけないもの

    残留クリーンアップは identity の整備です。スキルはギガバイトの最大化ではなく、 所有を証明し、共有状態を守り、削除を復元可能に保つことです。

    よくある質問

    自分で ~/Library 以下の残留を消して大丈夫ですか?

    帰属が取れているときだけです。フォルダをアプリの bundle identifier に合わせ、サイズや似た名前には合わせず、送る前にひとつずつ確認してください。ひとつの誤りが、別アプリのデータや自分の文書を消すことがあります。

    そもそもなぜアプリはファイルを残すのですか?

    バンドルをゴミ箱へ移しても、Library に保存した設定やデータは通常そのまま残ります。専用アンインストーラ、パッケージマネージャ、システム拡張はそれぞれ扱いが異なるため、該当する場合はメーカーの手順に従ってください。

    再インストールすれば、消したものは戻りますか?

    キャッシュと一部の初期設定は通常再作成されますが、インストール記録が初回起動で戻るとは限りません。書類、チャット履歴、独自の設定は再インストールだけでは戻りません。ライセンスの再認証も製品とアカウント次第なので、削除前にそれぞれのバックアップと復元方法を確認してください。

    Mole でキャッシュやアプリの残存ファイルを整理。一度で 100 GB 以上空いたという声も届いています。

    Mole を試す

    続きを読む

    • アンインストールMacアプリを完全にアンインストールする方法|残骸も安全に削除約8分で読めます
    • アンインストールOutlook のメールを失わずに Mac の Office を削除する約5分で読めます
    • アンインストールボリュームを残してDocker Desktopを消す約5分で読めます

    Mole · 鼴

    Macの掃除・アプリ管理・状態確認をひとつに。

    v1.15.0 (291) · リリース

    製品

    Macクリーナー アプリアンインストーラ Macメンテナンス ディスク解析 システムモニター

    サポート

    ヘルプ ドキュメント リリース ブログ

    規約

    利用規約 プライバシーポリシー 返金ポリシー

    リソース

    CLIツール アフィリエイトプログラム

    つながる

    Twitter hi@mole.fit

    Moleの公式サイトはここだけ mole.fit · 提供元が不明なインストーラはダウンロードしないでください

    ターミナル向けのCLIは、これからも無料です。