ソースからインストールしたソフトを安全に削除する｜管理外ソフトの後始末【2026年版】

パッケージ管理外のソフトが厄介な理由

aptやdnfでインストールしたソフトウェアは、パッケージマネージャが配置ファイルの一覧をデータベースで管理しています。そのため apt remove や dnf remove を実行すれば、インストール時に置かれたファイルを漏れなく回収できます。

一方、ソースコードから ./configure && make && make install でインストールしたソフトウェアは、OS のパッケージデータベースにまったく記録されません。どのファイルがどのディレクトリに配置されたかを知っているのは、インストール時に使用した Makefile だけです。

この「管理外」という状態が、削除を難しくする根本的な理由です。ファイルが /usr/local/bin、/usr/local/lib、/usr/local/share、/etc など複数の場所に散在している場合、手作業で全件を把握するのは容易ではありません。削除が中途半端になると、別バージョンをインストールした際に古いライブラリとの混在が起き、予期しない動作を引き起こします。

削除前に必ず確認すること――ソースツリーとMakefileの所在

ソースインストールの削除作業は、ビルド時に使ったソースディレクトリが残っていることが大前提です。まずは当時の作業ディレクトリを探します。

find /usr/local/src /opt /root /home -maxdepth 3 -name "Makefile" 2>/dev/null

ソースツリーが見つかったら、Makefile に uninstall ターゲットが定義されているか確認します。

grep -n "^uninstall" /path/to/source/Makefile

出力に uninstall: という行が現れれば、後述の make uninstall が使えます。何も出力されなければ、別の手段を検討する必要があります。

また、インストール時に DESTDIR や --prefix を指定していた場合は、そのパスも確認しておきます。デフォルトの /usr/local 以外に置いている場合、削除コマンドにも同じオプションを渡す必要があるためです。

make uninstall が使える場合の手順と確認

GNU Autotools で構成されたプロジェクトの多くは uninstall ターゲットを持っています。ソースディレクトリに移動して実行するだけです。

cd /path/to/source
sudo make uninstall

実行後は、主要なファイルが本当に消えているかを手動で確認します。

# バイナリが消えたか
which target-command 2>/dev/null || echo "削除済み"

# ライブラリが残っていないか
ls /usr/local/lib/libtarget* 2>/dev/null

make uninstall は Makefile に書かれたファイルリストを順に rm するだけです。インストール後に手動で追加した設定ファイルや、ソフトウェアが実行時に生成したデータファイルは削除対象に含まれないため、それらは別途確認して手動で削除します。

共有ライブラリを削除した場合は、ldconfigのキャッシュを更新することも忘れないようにします。

sudo ldconfig

uninstall ターゲットがない場合の対処法

歴史の古いソフトウェアや、小規模なプロジェクトでは uninstall ターゲットが存在しないことがあります。この場合、以下の3つのアプローチから状況に応じて選択します。

アプローチ1：install ターゲットの内容から削除リストを作る

Makefile の install: セクションを読み、コピー先を洗い出します。

grep -A 30 "^install:" Makefile | grep -E "cp|install" | less

出力から配置先のパスを一覧化し、rm コマンドで削除します。ディレクトリごと削除する際は、rm -rf でほかのソフトのファイルを巻き込まないよう、対象を一つずつ丁寧に確認してから実行します。

アプローチ2：インストール前後のファイル差分を利用する

再現環境（テストサーバーや仮想マシン）があれば、インストール直前と直後のファイルスナップショットを比較することで、インストールされたファイルの完全なリストを得られます。

# インストール前
find /usr/local -type f > before.txt

# make install 実行後
find /usr/local -type f > after.txt

diff before.txt after.txt | grep "^>" | sed 's/^> //'

このリストを本番環境での削除スクリプトとして活用できます。

アプローチ3：–prefix を /opt 以下に限定していた場合

インストール時に ./configure --prefix=/opt/appname のように専用ディレクトリを指定していれば、そのディレクトリごと削除できます。これが最も安全で確実な方法です。

sudo rm -rf /opt/appname
# PATH から除外されているか確認
echo $PATH

次回から困らないための予防策――checkinstall と GNU Stow

現場では「削除に困った経験」を契機に、ソースインストールの管理方法を見直すケースが多くあります。2026年現在、実績のある2つのアプローチを紹介します。

checkinstall：ソースインストールをパッケージとして登録する

checkinstall は make install の代わりに実行することで、インストールされるファイルを追跡し、deb または rpm パッケージを生成してシステムに登録するツールです。

# Debian/Ubuntu
sudo apt install checkinstall

# インストール時の使い方（make install の代わりに）
sudo checkinstall --pkgname=myapp --pkgversion=1.0 --backup=no --deldoc=yes make install

登録後は通常のパッケージと同様に削除できます。

sudo apt remove myapp   # Debian/Ubuntu の場合

checkinstall は活発なメンテナンスが続いているわけではないため、複雑な Makefile との相性で問題が出ることもあります。事前にテスト環境での動作確認を推奨します。

GNU Stow：シンボリックリンクで管理する

GNU Stow はインストール先を /usr/local/stow/appname のような専用ディレクトリにまとめ、そこから /usr/local/bin などへシンボリックリンクを張る手法を採ります。削除時はリンクを外すだけなので、ファイルの取り残しが起きません。

# インストール（prefix を stow ディレクトリ配下に向ける）
./configure --prefix=/usr/local/stow/appname-1.0
make
sudo make install

# stow でリンクを張る
cd /usr/local/stow
sudo stow appname-1.0

# 削除時はリンクを外す
sudo stow -D appname-1.0
sudo rm -rf /usr/local/stow/appname-1.0

複数バージョンの共存管理にも向いており、アップグレード時には旧バージョンの stow -D → 新バージョンの stow という手順で切り替えられます。

2026年現在の現場判断――コンテナ・仮想環境の活用

ソースインストールが必要になる場面自体が、2026年現在では以前より減っています。多くのソフトウェアは公式が AppImage、Snap、Flatpak、あるいは OCI コンテナイメージを提供しており、ホスト環境を汚さずに利用できます。

開発・検証目的でソースビルドが必要な場合は、systemd-nspawn や Podman のルートレスコンテナをビルド環境として使う手法が広まっています。ビルドと実行をコンテナ内で完結させれば、ホスト側にはいっさいファイルが散らばらず、「削除」はコンテナイメージの廃棄だけで済みます。

# Podman でビルド環境を使い捨てにする例
podman run --rm -v $(pwd):/build:Z -w /build \
  debian:bookworm bash -c "apt-get update && apt-get install -y build-essential && ./configure && make"

どうしてもホストに直接インストールしなければならない場合、前述の GNU Stow か checkinstall を組み合わせることが現行の標準的な対処法です。「ソースインストールは削除できない」という旧来の前提は、これらのツールと運用の工夫によって克服できます。

すでに管理外になったソフトウェアの整理は、上述の Makefile 解析やファイル差分による洗い出しを地道に行うことになります。作業前には必ず rsync などでシステム全体のバックアップを取得し、削除後に関連サービスの動作確認（systemd であれば systemctl status で依存関係を確認）まで行うことを強く推奨します。管理外ソフトの後始末は、次のインストール時の「記録する習慣」を始めることと同じくらい重要な作業です。