CentOSからUbuntuに移行した当初、パッケージ管理システムに慣れるまで約1週間かかりました。aptが難しいからではなく、apt、apt-get、apt-cache、dpkg…といった似たようなコマンドが多すぎたからです。どれが「正式」で、どれがどれのエイリアスなのか、なかなか判断できませんでした。
この記事ではその疑問に直接答えます。初心者向けの「A〜Zガイド」ではなく、全体像を理解して適切なツールを適切なタイミングで使えるようになることを目的としています。
Ubuntuのパッケージ管理ツール比較
Ubuntuには主要なパッケージ管理ツールが4つあり、それぞれに存在する理由があります：
1. dpkg — すべての基盤
dpkgは最下層に位置し、.debファイルを直接操作します。パッケージのインストール、削除、照会を行います。最大の制限は依存関係を自動で解決しないことです。パッケージAのインストールにパッケージBが必要な場合、dpkgはエラーを出して停止するだけで、aptのように自動でBを取得しに行きません。
2. apt-get — 古くて信頼できるラッパー
apt-getはまさにその制限を解消するために生まれました——リポジトリから依存関係を自動でダウンロードします。今もスクリプトで使われ続ける理由は、outputフォーマットが非常に安定しており、Canonicalがバージョン間での変更をしないと保証しているからです。2015年のDockerfileでapt-getを使っているものは、今日でも問題なくビルドできます。
3. apt — 新しくて使いやすいインターフェース
Ubuntu 16.04から登場したaptは、日常操作でapt-getを置き換えるために設計されました。プログレスバーやカラー表示が改善され、apt-getとapt-cacheの多くのコマンドが一箇所に統合されています。手動操作には便利ですが、outputフォーマットの安定性が保証されていないため、スクリプトには向きません。
4. snap — まったく異なるアプローチ
snapはCanonical独自のシステムです。各パッケージはすべての依存関係を一つのバンドルにまとめ、サンドボックス内で動作し、自動更新されます。聞こえはよいのですが、代償としてサイズが大きくなります。snap版のchromiumは約170MBあるのに対し、aptでインストールすると約80MBで済みます。本番サーバーでは、サイズが大きいことと起動が明らかに遅いという2つの理由から、snapはなるべく避けています。
各ツールのメリット・デメリット
| ツール | メリット | デメリット |
|---|---|---|
dpkg |
ローカルの.debファイルを直接インストール、パッケージ情報を素早く照会 | 依存関係を処理しない、リポジトリから取得しない |
apt-get |
Output安定、後方互換性あり、スクリプト/CIに最適 | 手動操作では出力が読みにくい |
apt |
プログレスバーあり、コマンド統合、手動操作に便利 | Outputフォーマットの安定性が保証されていない |
snap |
サンドボックス、自動更新、複数のディストリビューションで動作 | パッケージが2倍重く、起動が遅い |
使い始めた頃、チュートリアルでapt-getを使っているのはaptが間違いだからだと思っていました。そうではありません——どちらも正しく、使う場面が違うだけです。
状況に応じたツールの選び方
私が実践しているシンプルな使い分けの原則です：
- ターミナルでの日常使用 →
apt：便利で見やすく、十分な機能がある。 - シェルスクリプト、cronジョブ、CI/CDの記述 →
apt-get：Outputが安定しており、Canonicalがフォーマットを変更する心配がない。 - 手動でダウンロードした
.debファイルのインストール →dpkg -i：必要に応じてapt-get install -fを実行して依存関係を修正する。 - GUIアプリのインストール、最新バージョンやサンドボックスが必要な場合 →
snap：ただしサーバーでは使わない。
よく使うaptコマンド実践ガイド
パッケージリストの更新
何かをインストールする前に、必ずこのコマンドを実行します：
sudo apt update注意：apt updateはリストの同期のみで、パッケージのアップグレードは行いません。アップグレードするには：
# インストール済みのすべてのパッケージをアップグレード
sudo apt upgrade
# アップグレード時に依存関係の追加・削除も自動で処理する
sudo apt full-upgradeパッケージのインストールと削除
# パッケージをインストール
sudo apt install nginx
# 複数のパッケージを一度にインストール
sudo apt install git curl wget build-essential
# パッケージを削除するが設定ファイルは残す
sudo apt remove nginx
# パッケージを削除して設定ファイルも消す — クリーンリセットしたい時に使う
sudo apt purge nginx
# 不要になった依存関係も削除する
sudo apt autoremovenginxやmysqlのようなサービスを削除する際は、removeよりpurgeをよく使います。理由は、後で再インストールする時に古い設定ファイルの影響を受けたくないからです。
パッケージの検索と情報確認
# 名前や説明でパッケージを検索
apt search "web server"
# パッケージの詳細情報を表示
apt show nginx
# 特定のファイル/コマンドを提供するパッケージを調べる
dpkg -S /usr/bin/curl
# インストール済みのすべてのパッケージを一覧表示
dpkg -l
# 特定のパッケージがインストール済みかどうか、バージョンを確認
dpkg -l | grep nginxローカルの.debファイルをインストール
Google Chrome、VS Code、Slackなど、公式サイトから.debファイルをダウンロードする際によく使います：
# .debファイルをインストール
sudo dpkg -i google-chrome-stable_current_amd64.deb
# 依存関係エラーが出た場合、このコマンドでaptが自動修正する
sudo apt-get install -fリポジトリの管理
# 使用中のリポジトリ一覧を表示
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/
# PPA（Personal Package Archive）を追加
sudo add-apt-repository ppa:ondrej/php
sudo apt update
# PPAを削除
sudo add-apt-repository --remove ppa:ondrej/phpその他のよく使うコマンド
# パッケージのインストール/削除履歴を表示
cat /var/log/apt/history.log
# バージョンを固定して自動アップグレードを防ぐ
sudo apt-mark hold nginx
# holdを解除する
sudo apt-mark unhold nginx
# holdされているパッケージを確認
apt-mark showhold
# aptキャッシュを削除 — 通常数百MBを解放できる
sudo apt clean実際の使用経験から得た実践的なメモ
サーバーと開発マシンの両方でUbuntuを使ってきた経験から、もっと早く知っておけばよかったことをまとめました：
apt installの前に必ずapt updateを実行する — このステップを省くと古いパッケージをインストールしてしまったり、実際にリポジトリに存在するパッケージでも「package not found」エラーが出ることがある。- 「The following packages were automatically installed and are no longer required」というメッセージが表示されたら？
sudo apt autoremoveを実行して整理しましょう。何も心配する必要はありません。 - 自動化スクリプトでは、
-yとDEBIAN_FRONTEND=noninteractiveを追加してすべての対話プロンプトを無効にします：
DEBIAN_FRONTEND=noninteractive sudo apt-get install -y nginx- 最もディスク容量を使っているパッケージを確認したい場合：
dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n | tail -20CentOS/RHELからUbuntuへの移行はそれほど難しくありません。一つのルールを覚えれば十分です：yum/dnf ≈ apt、rpm ≈ dpkg。ロジックは同じで、コマンド名が違うだけです。
