Mac アプリがアンインストールできないとき、七つの原因とそれぞれの症状

アンインストール公開日 更新日 約15分で読めます

macOS でアンインストールが失敗するとき、それは一つの問題ではありません。Finder がバンドルの移動を拒否することもあります。移動自体は成功しても、次のログインでアプリが戻ってくることもあります。バンドルは消えたのに、あなたを困らせていたヘルパーは動き続けていることもあります。それぞれ仕組みも直し方も違うので、あなたの Mac に実際に起きたことから始めてください。通常の手順は完全にアンインストールするにあります。以下は、それがすでに失敗したという前提で進めます。

症状から始める

アンインストール失敗の六つの症状、項目が開いているという警告、削除後にアプリが戻ってくる、何も起きない、管理者パスワードの要求、root で操作が許可されないエラー、設定でグレーアウトした項目が、それぞれ別々の原因に振り分けられる図。
拒否の文言そのものが診断の手がかりです。六つのうち二つはダイアログすら出さないので、それがツール自体の故障だと誤解されがちです。
  • 「開いているため、項目をゴミ箱に入れることができません」。 何かが動いています。多くの場合、あなたが終了させたそのアプリではありません。
  • 削除したのに戻ってきた。 残っていたヘルパーの再起動なのか、管理ソフトやパッケージマネージャによるアプリの再インストールなのかを分けて確認します。
  • Finder が管理者パスワードを求めてくる。 .pkg がバンドルを root 所有のまま残していました。正常です。
  • 何も起きない。ダイアログもエラーもない。 App 管理の権限は原因の一つですが、操作結果やファイルの権限も確認が必要です。
  • root で rm すると「Operation not permitted」と出る。 システム保護などの制限が考えられますが、この文言だけで SIP とは断定できません。
  • グレーアウトしている、または職場の Mac で再び現れる。 構成プロファイルか MDM が所有しています。

1. アプリか、そのヘルパーの一つがまだ動いている

Finder はファイルが開いたままのバンドルの移動を拒否します。目に見えるプロセスを終了させても、そのアプリが起動したものすべてを止めたことにはなりません。アクティビティモニタは、ウィンドウを持つものだけでなくすべてのプロセスを一覧表示します。ベンダー名で検索して結果を全部読んでください。Foo というアプリは、たいてい Foo Helper、FooUpdater、そして無関係な表示名を持つログイン項目バンドルを一緒に出荷します。Apple メニュー > 強制終了のウィンドウは代わりにはなりません。UI を持つアプリケーションしか表示しないからです。

pgrep -fl -i foo
lsof +D /Applications/Foo.app 2>/dev/null | awk '{print $1, $2}' | sort -u

pgrep -fl はコマンドライン全体にマッチするので、プロセス名にはベンダー名が入っていなくても実行ファイルのパスに入っているヘルパーを捕まえられます。lsof +D はバンドル内のファイルを開いているすべてのプロセスを報告します。

親プロセスを強制終了させても、確実にヘルパーを止められるとは限りません。ヘルパーは自分自身の PID を持つ独立したプロセスなので、親が終了時にきちんと後始末をしない限り、親を殺すとヘルパーは孤立するだけです。そして launchd がそのヘルパーを管理している場合、どちらを殺しても launchd にもう一度起動するよう伝えているだけです。それが次のセクションです。

Quick Look のプレビューや Spotlight のインデックス作成も、バンドル内のファイルを開いたままにすることがあり、再起動すればどちらも解消します。それでもメッセージが出るなら、Apple のアプリ削除ガイドはセーフモードを勧めています。

2. launchd エージェントかデーモンが元に戻す

これは「削除したのに戻ってきた」というケースで、最も誤診断されやすいものです。多くの人がアクティビティモニタを確認して何も見当たらず、アプリは動いていなかったと結論づけます。オンデマンドでの起動という仕組みは、それが証拠にならないことを意味します。

launchd はバックグラウンドジョブを監督しています。ジョブとは、Label、プログラム、実行条件を持つプロパティリストです。RunAtLoad はジョブが読み込まれたときに起動させ、KeepAlive は終了したときに再起動させます。どちらもないジョブでも戻ってきます。MachServices、Sockets、WatchPaths、QueueDirectories、StartInterval はどれも、何かがそれを求めた瞬間に launchd にプロセスを起動させるので、10 秒でアイドルになって Mach サービスで再起動するヘルパーは、確認するたびに存在しないように見えます。

定義は三つの場所にあります。~/Library/LaunchAgents はあなたのユーザーだけの、ログインセッションの中のもの。/Library/LaunchAgents はログイン時にすべてのユーザーに対して実行されるもの。そして /Library/LaunchDaemons は誰もログインする前に root としてシステム全体で実行されるもので、だからこそデーモンは手作業のアンインストールを生き延びやすく、エージェントはそうでないことが多いのです。/System/Library/Launch* は Apple のもので保護されています。

launchctl list | grep -i foo
launchctl print-disabled gui/$(id -u) | grep -i foo
grep -l -i foo ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist \
  /Library/LaunchDaemons/*.plist 2>/dev/null

launchctl list では、PID の付いたラベルは今動いていて、ダッシュの付いたラベルは読み込まれてトリガー待ちです。print-disabled は永続的な無効化状態データベースを読みますが、これは plist が存在するかどうかとは別の事実です。候補は plutil -p <path> で読み、Program か ProgramArguments が削除しようとしているアプリを指しているか確認してください。ベンダーは必ずしも、中にあるラベルどおりにファイルを名付けているとは限りません。

順序が重要

先にジョブを停止して無効化し、それから plist を削除し、最後にアプリを削除してください。

launchctl bootout gui/$(id -u)/com.vendor.foo.helper
sudo launchctl bootout system/com.vendor.foo.daemon
launchctl disable gui/$(id -u)/com.vendor.foo.helper

ジョブが読み込まれた状態で plist を削除すると、launchd はディスク上にもう定義が存在しないサービスを保持し続けます。次の再起動まで動き続け、無効化状態データベースに古いエントリを残すこともあります。先にアプリを削除するのはさらに悪く、ジョブは存在しない実行ファイルに対して再生成され、ループで失敗し続けます。「消えたのにログイン項目にはまだ表示される」の原因はここにあります。

macOS 13 以降では、アプリは SMAppService でバックグラウンドコンポーネントを登録できます。ヘルパーやその定義をアプリバンドルに含める構成もあるため、上の三つのフォルダに別の plist があるとは限りません。登録状態はシステムが管理するもので、バンドル内のファイルそのものとは区別します。確認や切り替えはシステム設定 › 一般 › ログイン項目と機能拡張から行えます（起動項目ガイド）。

3. SIP に保護されたシステムアプリ

System Integrity Protection は権限のビットではなく、カーネルレベルのポリシーです。Apple はこれを、重要なシステムファイルの書き込み可能性を制限するためにカーネルの権限を使うもので、「サンドボックス化されているか管理者権限で動いているかにかかわらず、システム上で動作するすべてのプロセスに」適用されると説明しています（Apple プラットフォームセキュリティ）。Big Sur 以降、システムのコンテンツは暗号学的に封印された別のボリュームにも置かれています。csrutil status は保護が有効かどうかを表示し、Apple は「Mac に必要なアプリは削除できません」とはっきり述べています。この集合には Mail、Music、Books、Notes、Podcasts、Maps、News、Stocks が含まれます。

一つのバンドルを消すために SIP をオフにするのは割に合わない取引です。それは Recovery から起動して、マシン全体のセキュリティポリシーを変更することを意味します。Intel Mac では、無効化すると物理ストレージデバイスのすべてのパーティションの保護が失われると Apple は指摘していて、Apple silicon では Mac が Full Security から外れます。得られるものも長続きしません。システムボリュームは次の macOS アップデートで丸ごと置き換えられ、使える容量が回収されるわけでもありません。

そうする代わりに、アイコンを Dock から引き抜き、システム設定 > 一般 > ログイン項目と機能拡張から取り除き、それがあなたのファイルを開き続けるなら、情報を見る > このアプリケーションで開く > すべてを変更でハンドラを変更してください。

4. MDM か構成プロファイルによってインストールされた

管理下の Mac では、管理サーバーの指示でアプリが再インストールされることがあり、プロファイルが削除不可に設定されている場合もあります。削除後にアプリが戻る、設定がグレーアウトするなどの症状があれば、システム設定 › 一般 › デバイス管理を確認してください。この項目が見当たらなくても、それだけで管理下ではないと断定せず、以下の登録情報を確認します。勤務先や学校の Mac なら IT 担当者にも確認してください。

profiles status -type enrollment
sudo profiles list

一つ目は Automated Device Enrollment 経由での登録状況とユーザー承認済みかどうかを報告し、二つ目はインストール済みのプロファイルを一覧表示しますが root が必要です。そのうえで IT に聞いてください。Apple のガイダンスは、削除できないプロファイルについてはそれを提供した相手に尋ねるようにというもので、プロファイルを削除するとそのプロファイルが構成したものすべてが削除されると警告しています。メールアカウントを運んでいるプロファイルなら、それも一緒に持っていかれます。

5. 所有権と、黙って失敗する権限

Finder が管理者パスワードを求めてくる。 正常です。.pkg インストーラは root として実行され、バンドルを root 所有のまま残すので、移動には認証が必要です。ls -ld /Applications/Foo.app で確認してください。ここでレシートについても知っておく価値があります。pkgutil --files <id> はパッケージが配置したパスを一覧表示し、sudo pkgutil --forget <id> はファイルを一つも削除せずに /private/var/db/receipts からそのレシートを取り除きます。

何も起きない。 プロンプトもエラーもなく、アプリは /Applications にまだあり、使ったツールは曖昧な失敗を報告するか何か別のものにフォールバックします。macOS 14 以降では、これはたいてい App 管理で、Apple はこれを「他の App を更新または削除することをアプリに許可」と説明しています。見分け方は、パスは POSIX 的に書き込み可能なのに、書き込み自体は失敗するというものです。

test -w /Applications/Foo.app && echo "posix says yes"

これはアプリのパスが書き込み可能かを調べるだけで、削除できる証明ではありません。削除には親フォルダの書き込み権限や検索権限なども関わります。権限を調べても原因が分からない場合は、システム設定 › プライバシーとセキュリティ › App 管理で削除を行うアプリが許可されているかを確認し、変更後にそのアプリを再起動してください。

仕組みを覗く、同じに見える三つの拒否

POSIX パーミッションが最初の関門です。バンドルは root が所有していて、あなたはそうではなく、sudo がそれを解決します。このチェックはどのユーザーであるかだけを見ているからです。System Settings の裏側にあるプライバシー層である TCC は、POSIX を通過したあとに判断します。App 管理は、他のアプリのバンドルを変更または削除するという一つの操作に対する TCC のゲートです。管理者であってもこれを満たせませんし、sudo も同様です。これはユーザーではなく要求しているプログラムに紐づいているからで、だからこそその拒否は、プロンプトすら出さない汎用エラーとして表面化することがあります。

SIP は root にも制限をかけますが、エラー文だけで原因を一つに決めることはできません。EACCES（Permission denied）は親フォルダの書き込み権限や検索権限でも起こり、EPERM（Operation not permitted）も SIP 専用のエラーではありません。条件は Apple のファイル削除の説明にあります。失敗したパスと権限を調べずに、権限を上げたりシステム保護を無効にしたりしないでください。

6. システム拡張かネットワークフィルタがまだ有効

セキュリティソフトウェア、VPN クライアント、仮想化製品はシステム拡張をインストールします。アプリバンドルは拡張機能を登録しますが、それ自体が拡張機能ではありません。拡張機能が有効な状態でコンテナを削除すると、登録情報だけが所有者を失ったまま残ります。これが、削除したはずのソフトウェアを通してトラフィックがフィルタされ続ける仕組みです。

systemextensionsctl list

出力にはチーム識別子、バンドル識別子、[activated enabled] のような状態が表示されます。無効化はそれを内包するアプリに属し、たいてい再起動が必要なので、まずベンダーのアンインストーラを実行してください。Mac でアンチウイルスをアンインストールするで、このクラスの解体の順序を扱っています。

7. App Store か Homebrew から入れたもの

Mac App Store のアプリ。 バンドルを削除しても購入履歴は消えません。App Store には、ほかの Mac やデバイスで購入したアプリを自動ダウンロードする設定があります。これは別のデバイスでの購入に対する設定で、別の Mac にインストール済みというだけで必ず再インストールされるわけではありません。自動ダウンロードが起きた場合は App Store › 設定で確認します。

Homebrew の cask。 brew install --cask foo でインストールした場合、アプリをゴミ箱に入れても Homebrew はインストール済みだと思い込んだままです。brew list --cask はまだそのトークンを表示していて、次の brew upgrade は今削除したばかりのアプリを再インストールすることがあります。launchd のジョブが一切関わらない、正真正銘の「戻ってきた」原因です。代わりに brew uninstall --cask foo を実行してください。Homebrew の man ページは --zap を「cask に関連付けられたすべてのファイル」を削除するものと説明していて、「アプリケーション間で共有されているファイルを削除する可能性がある」と警告しているので、これは意図を持って使ってください。

削除に成功したあと、それでも残るもの

ログイン項目と機能拡張にまだ表示されている。 存在しないパスを指す「ログイン時に開く」項目か、プログラムがなくなったサービスの Background Task Management のレコードのどちらかです。システム設定 > 一般 > ログイン項目と機能拡張でマイナスボタンを使って取り除いてください。macOS は再起動後に自分で消してくれることも多いです。

起動時にメニューバーアイコンが現れる。 何かがまだバイナリを読み込んでいます。たいていは削除しそこねた launch agent か、インストーラが ~/Library/Application Support/<vendor> にコピーしたヘルパーです。

特権ヘルパーが生き残る。 root を必要としたソフトウェアは、対になる /Library/LaunchDaemons/<label>.plist とともに /Library/PrivilegedHelperTools/<label> にインストールされます。どちらも root 所有でバンドルの外にあるので、アプリをゴミ箱に入れてもどちらにも触れません。

ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons \
  /Library/PrivilegedHelperTools 2>/dev/null

データ側については、アンインストール後に残ったファイルを参照してください。

この診断を Mole でやる

手動で調べるには、アクティビティモニタ、三つの launchd フォルダ、ログイン項目と機能拡張、プライバシーとセキュリティ、Finder を確認します。Mole では、検出した同じアプリの関連項目を一つの画面で確認できます。スキャンは無料なので、購入や削除をせずに調査だけでも使えます。

アプリを展開してバンドルと ~/Library/Application Support、~/Library/HTTPStorages の残渣項目をそれぞれサイズとチェックボックス付きで表示し、下部に削除ボタンがあるアンインストールのレビュー画面。
削除が触るすべての項目が、何かが動く前に正確なパスとサイズ付きで見えます。

Mole の Software タブを開いてください。ここには三つの区画があります。インストール済みアプリの一覧、利用可能なアップデート、起動項目です。最後の一つが、この記事が手作業で組み立てるよう案内してきた launchd とログイン項目の一覧で、だから「戻ってくる」原因は削除したあとではなく、削除する前に見えます。

アプリを選ぶと、Mole はそのバンドル識別子を解決し、その識別子が所有するものを見つけます。Application Support、Caches、Preferences、Containers、HTTPStorages、そして名前に同じ単語が入っているだけでなく実際に plist がそのアプリを参照している launch agent や daemon です。それぞれの候補にはパス、サイズ、それを結びつけた証拠が付き、確信度の低いものは未選択で届きます。

確定すると、この記事が推奨している順序が、覚えておく必要なく強制された形で実行されます。Mole はアプリとそのバンドル内に入れ子になったヘルパーを終了させ、ログイン項目のヘルパーを bootout し、承認済みの起動項目は plist が削除される前に launchctl 経由でアンロードし、削除の瞬間にすべてのパスをもう一度検証します。削除はゴミ箱送りなので、間違えても引っ張り出せます。

Mole は、スキップした項目と失敗した項目をパス付きで報告します。アプリ管理の権限、管理者の認証、その他の原因を調べる手がかりになるため、成功件数だけで判断しないでください。スキャンとクリーンアップはローカルで実行し、清掃操作を ~/Library/Logs/mole/operations.log に記録します。ただし、記録があってもファイルが今もゴミ箱に残っているとは限りません。ターミナルでは無料のオープンソース Mole CLI を使え、mo uninstall の --dry-run で先にパスを確認できます。

Mole は、勝てない三つの原因とは戦いません。SIP を無効化したり、封印されたボリュームから Apple 標準のアプリを削除したりはしません。管理下の Mac でソフトウェアを再インストールする構成プロファイルを上書きすることもできません。セキュリティエージェント、VPN クライアント、仮想化製品については、解体の順序を知っているベンダーのアンインストーラの代わりにはなりません。App 管理が拒否されたときは、Mole はその失敗を報告するだけで、権限を回避して昇格させたりはしません。

よくある質問

アプリを削除したのに戻ってくるのはなぜですか

戻ったものがヘルパーのプロセスなのか、アプリバンドルなのかを先に確認します。launchd は残っているヘルパーを再起動できますが、ジョブの定義だけで削除済みのアプリバンドルを復元するわけではありません。アプリが再インストールされた場合は、Homebrew の記録と brew uninstall --cask を使ったかどうか、MDM の配布設定、App Store の他デバイスでの購入を自動ダウンロードする設定を確認してください。

SIP をオフにすれば Apple 標準のアプリを削除できますか

技術的には可能ですが、割に合わない取引です。Recovery から行うマシン全体のセキュリティのダウングレードと引き換えに、封印されたシステムボリュームが置き換えられる次の macOS アップデートで戻ってくるバンドルを手に入れるだけです。代わりに Dock とログイン項目から取り除いてください。

Finder がアプリを削除するときにパスワードを求めてきます。何かおかしいのでしょうか

必ずしも異常ではありません。たとえば、.pkg インストーラが root として配置したアプリを移動するときは、認証が必要になる場合があります。確認画面もエラーも出ず、削除もされない場合は、アプリ管理の権限が拒否されている可能性がありますが、それだけで原因は断定できません。実際のエラー、フォルダの権限、プロセスの状態を確認してください。アプリ管理は要求元のプログラムに対する権限なので、sudo では回避できません。

関連記事