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

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

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

症状から始める

アンインストール失敗の六つの症状、項目が開いているという警告、削除後にアプリが戻ってくる、何も起きない、管理者パスワードの要求、root で操作が許可されないエラー、設定でグレーアウトした項目が、それぞれ別々の原因に振り分けられる図。
拒否の文言そのものが診断の手がかりです。六つのうち二つはダイアログすら出さないので、それがツール自体の故障だと誤解されがちです。
  • 「開いているため、項目をゴミ箱に入れることができません」。 何かが動いています。多くの場合、あなたが終了させたそのアプリではありません。
  • 削除したのに戻ってきた。 launchd のジョブ、プロファイル、パッケージマネージャのどれかが元に戻しました。
  • Finder が管理者パスワードを求めてくる。 .pkg がバンドルを root 所有のまま残していました。正常です。
  • 何も起きない。ダイアログもエラーもない。 App 管理の権限が拒否されています。
  • root で rm すると「Operation not permitted」と出る。 System Integrity Protection です。
  • グレーアウトしている、または職場の 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 がない場合もあります。それらは Background Task Management に属していて、システム設定 > 一般 > ログイン項目と機能拡張（起動項目ガイド）で管理します。

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 では、管理サーバーのスケジュールに従ってアプリが押し戻されることがあり、プロファイルは削除不可としてマークされていることがあります。症状としては、削除しても数時間後に元に戻っている、コントロールがグレーアウトしている、あるいは再インストールがリモートから駆動されているので launchd を探しても何も見つからない、といったものがあります。システム設定 > 一般 > デバイス管理を確認してください。このセクションがなければ、その Mac は管理下になく、これはあなたの原因ではありません。

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 すら問答無用で拒否します。POSIX の拒否は EACCES を設定して Permission denied を出力します。SIP の拒否は EPERM を設定して Operation not permitted を出力します。前者は権限を得てもう一度試せという意味で、後者はもう一度試すための権限自体が存在しないという意味です。

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

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

systemextensionsctl list

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

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

Mac App Store のアプリ。 バンドルを削除しても購入自体は取り消されません。多くの人が引っかかるのは、Apple が「他の Mac コンピュータやデバイスで App Store から購入した App を自動でダウンロード」と表現している設定です。同じアカウントの別の 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 は成功の合計数ではなく、スキップした項目と失敗した項目をパス付きで報告します。App 管理が拒否されたために拒否された行や、パスが root 所有でガードが弾いた行があれば、それが上のどの原因に当たったのかが分かります。拒否された書き込みにチェックマークを付けてしまうツールこそが、メニューバーアイコンについて一晩悩む原因です。Mole の動作はすべてローカルで完結し、ファイル操作は ~/Library/Logs/mole/operations.log に追記されます。ターミナルでは Mole CLI が無料でオープンソースで、mo uninstall は --dry-run に対応しているので、先にパスのリストを読めます。

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

よくある質問

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

大まかに頻度の高い順で四つの原因があります。launchd のエージェントかデーモンがまだそれを指すジョブ定義を持っていて、アクティビティモニタでは見えないトリガーで再起動させています。brew uninstall --cask を実行する代わりにアプリをゴミ箱に入れたために、Homebrew の cask レコードが生き残っています。管理下の Mac では、MDM が押し戻しています。あるいは、他のデバイスで購入したアプリを自動でダウンロードする App Store の設定が、二台目の Mac から引っ張ってきています。

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

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

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

いいえ、何もおかしくありません。.pkg インストーラが root としてそのバンドルを置いたので、移動には認証が必要です。心配する価値があるのはその逆で、プロンプトもエラーもなく何も起きないことです。それはたいてい、システム設定 > プライバシーとセキュリティの下で App 管理が拒否されている状態で、sudo では直りません。このゲートはユーザーではなく、要求しているプログラムに紐づいているからです。

関連記事