Linuxのパッケージ管理の実務まとめ｜dnf/aptでの導入・更新・削除と安全な運用【2026年版】

パッケージ管理が運用の土台になる理由

Linux サーバーで何かをインストールするとき、単にバイナリをコピーするだけでは済まないのが現実です。Web サーバーひとつ立ち上げるにしても、依存ライブラリ・設定ファイルのデフォルト配置・systemd サービスユニットの登録まで、一連の作業がパッケージとして束になっています。パッケージマネージャはその束を整合的に展開し、将来の更新や削除も追跡可能な状態に保ちます。

セキュリティパッチを手作業で管理していた時代と比べると、現代の運用は「リポジトリに公開されたパッケージを正しく使いこなす」能力で差がつきます。dnf や apt を体系的に理解しておけば、依存関係の衝突・部分アップデートの危険・ロールバックの手順といった問題に対して、場当たり的でなく再現性のある対処ができるようになります。

2026年版ディストリビューション別の標準ツール対応

まず前提として、対象サーバーのディストリビューションと標準ツールの組み合わせを整理しておきます。

• RHEL 9 / CentOS Stream 9 / Fedora 40：dnf（バージョン4系）が標準です。
• Fedora 41 以降 / RHEL 10 / CentOS Stream 10：dnf5 への移行が進んでいます。コマンド体系は互換性が保たれていますが、カスタムプラグインを使っている環境では動作確認が必要です。
• Ubuntu 24.04 LTS / Debian 12（Bookworm）：apt が標準です。対話操作には apt、スクリプトには apt-get を使い分ける運用が公式ドキュメントでも推奨されています。
• Fedora CoreOS / RHEL for Edge など：イミュータブル OS 系では rpm-ostree や bootc を使います。通常の dnf では操作できないため、対象サーバーの OS 種別の確認が先決です。

rpm コマンドや dpkg は低レベルのツールであり、依存関係を自動解決する dnf・apt を上位ツールとして使えば、直接操作する機会はほぼありません。旧来の rpm -ivh スタイルの手順は、現在の運用では推奨されていません。

パッケージの調査・導入・削除の基本フロー

インストール前に「何が手に入るか」「何が引き込まれるか」を確認する習慣が、後のトラブルを防ぎます。

パッケージの検索と詳細確認

名前が曖昧なときはまず検索します。

# RHEL 系
dnf search nginx

# Debian/Ubuntu 系
apt search nginx

候補が絞れたら詳細情報を確認します。バージョン・ライセンス・依存パッケージが確認できます。

# RHEL 系
dnf info nginx

# Debian/Ubuntu 系
apt show nginx

特定のコマンド（例：/usr/bin/dig）がどのパッケージに含まれるかを調べたいケースも現場ではよくあります。

# RHEL 系（未インストールのパッケージも検索可能）
dnf provides /usr/bin/dig

# Debian/Ubuntu 系（インストール済みのみ）
dpkg -S /usr/bin/dig
# 未インストール含めて検索する場合は apt-file を使用
sudo apt install apt-file && sudo apt-file update
apt-file search dig

インストールと依存関係の解決

インストールは以下のコマンドで実行します。-y オプションで確認プロンプトをスキップできますが、本番環境では意図しないパッケージが引き込まれる場合があるため、初回は省略して変更内容を一覧確認してから進める運用が安全です。

# RHEL 系
sudo dnf install nginx

# Debian/Ubuntu 系
sudo apt install nginx

複数のパッケージを同時に指定するにはスペース区切りで並べます。dnf はトランザクション全体を一括処理するため、依存関係に衝突があれば実行前に警告が表示されます。

削除と残存設定ファイルの扱い

# RHEL 系：バイナリを削除（依存パッケージは残る）
sudo dnf remove nginx

# Debian/Ubuntu 系：バイナリのみ削除（設定ファイルは残る）
sudo apt remove nginx

# Debian/Ubuntu 系：設定ファイルごと削除
sudo apt purge nginx

インストール時に自動で引き込まれた依存パッケージを一括削除するには autoremove を使います。

# RHEL 系
sudo dnf autoremove

# Debian/Ubuntu 系
sudo apt autoremove --purge

autoremove はディスクの整理に有効ですが、手動でインストールしたパッケージが「不要」と誤判定されるリスクがゼロではありません。削除対象のリストを必ず事前に確認してから実行する習慣が重要です。

システム全体の更新を安全に進める実践手順

パッケージの一括更新はセキュリティ維持に欠かせませんが、計画なく実行するとサービス停止につながることがあります。現場で定着している手順を示します。

更新前の差分確認

まず更新可能なパッケージの一覧を取得します。この段階では何も変更されません。

# RHEL 系：更新対象とバージョン差分の一覧
dnf check-update

# Debian/Ubuntu 系：ローカルキャッシュを更新してから一覧表示
sudo apt update
apt list --upgradable

カーネルの更新が含まれている場合は、適用後に再起動が必要です。サービス影響を考慮したメンテナンスウィンドウを確保してから実行します。

本番環境での段階的な適用

# RHEL 系（全パッケージ更新）
sudo dnf upgrade

# Debian/Ubuntu 系（依存関係の変化を許容しない更新）
sudo apt upgrade

# Debian/Ubuntu 系（依存関係の変化を許容した上での全更新）
sudo apt full-upgrade

セキュリティ修正のみを対象にしたい場合は、以下の方法が利用できます。

# RHEL 系：セキュリティ修正のみ適用
sudo dnf upgrade --security

# Debian/Ubuntu 系：unattended-upgrades のドライランで対象を確認
sudo unattended-upgrades --dry-run --debug

ステージング環境で同じ手順を先行実施し、問題がなければ本番に適用するフローが理想です。特定のパッケージバージョンを固定したい場合は、dnf では versionlock プラグイン、apt では apt-mark hold を使います。

更新失敗時の切り戻しとトランザクション確認

dnf には更新履歴をトランザクション単位で管理する仕組みがあります。これが RHEL 系の大きな強みです。

# トランザクション履歴の一覧
dnf history

# 特定トランザクションの詳細（ID が 5 の場合）
dnf history info 5

# トランザクション 5 の取り消し（ロールバック）
sudo dnf history undo 5

Debian/Ubuntu 系には apt に同等のロールバック機能がありません。更新後に問題が発生した場合は、/var/log/dpkg.log で変更内容を確認し、必要なら手動で旧バージョンを指定してダウングレードします。

# 利用可能なバージョン一覧の確認
apt-cache policy nginx

# 特定バージョンへのダウングレード
sudo apt install nginx=1.24.0-2ubuntu3

ただし、パッケージレベルのロールバックだけでは、設定ファイルや実行中サービスの状態まで完全に元に戻せるとは限りません。本番環境では LVM スナップショット・ZFS スナップショット・クラウドのディスクスナップショットといったストレージレベルのバックアップと組み合わせておくことが、最も確実な切り戻し手段です。

2026年の現行環境で押さえておくべき差分

dnf5 の普及とスクリプトへの影響

Fedora 41 以降と RHEL 10 では dnf5 がデフォルトになっており、dnf コマンドは互換シムとして動作します。日常的なインストール・更新・削除の操作は従来どおり動作しますが、プラグインのインターフェースが変わっているため、dnf-plugins-core 以外のサードパーティプラグインを使っている環境では動作確認が必要です。バージョンを確認するには dnf --version を実行します。

Ubuntu の snap との混在問題

Ubuntu では一部のアプリケーションで、apt install を実行しても内部的に snap パッケージがインストールされる挙動が続いています。firefox がその代表例です。自動化スクリプトやアンサーブルでパッケージ管理を行う際は、インストール後のパスやサービス起動方法が apt ネイティブのものと異なる場合があるため、事前の動作確認が欠かせません。snap を避けたい場合は、公式リポジトリを直接追加して apt ネイティブのパッケージを取得する方法があります。

セキュリティアップデートの自動化が事実上の標準に

RHEL 系では dnf-automatic、Debian/Ubuntu 系では unattended-upgrades を使ったセキュリティパッチの自動適用が、2026年時点では多くの組織で標準運用になっています。手動更新のみに頼る体制では、脆弱性公開からパッチ適用までのリードタイムが長くなり、セキュリティリスクに直結します。

ただし自動適用はカーネル更新を伴う場合に再起動が必要となります。再起動タイミングの制御（メンテナンスウィンドウとの連携・reboot-guard の設定）と組み合わせて設計しないと、意図しない時間帯にサーバーが再起動するリスクがあります。自動化の範囲をセキュリティパッチのみに限定し、メジャーな更新は手動で管理するという使い分けが、現場での主流のアプローチです。