Linuxで不要な常駐サービスを止めて安全に軽量化する運用手順【2026年版】

なぜ不要なサービスを止めるのか：セキュリティとリソースの両面から

Linuxサーバーは、ディストリビューションのインストール直後から、用途を問わず多くのサービスが起動状態になっています。Webサーバーとして使う予定のホストにBluetoothデーモンやAvahiが動いていても意味はなく、むしろポートやソケットが余分に開放されることでセキュリティ上の露出面（アタックサーフェス）を広げるリスクがあります。

現場では「稼働させていたサービスを把握していなかった」という状況が問題の起点になるケースが少なくありません。脆弱性スキャンで検出された問題が、そもそも不要なサービスに起因していた——という事例も実際の運用でたびたび見られます。不要サービスの整理は、セキュリティ対策の第一歩として、サーバー構築フローに組み込んでおくべき定番作業です。

リソース面でも、常駐プロセスはCPUやメモリを継続的に消費し、監視ツールのアラートノイズにも繋がります。一見小さな差でも、10〜20のサービスを整理するとメモリ使用量が数百MB単位で変わるケースがあります。軽量化とセキュリティ強化は、同一の作業で同時に達成できる点が、このタスクの実用的な価値です。

まず現状把握：稼働中サービスの一覧確認

現行の主要ディストリビューション（Ubuntu 22.04/24.04、Debian 12、RHEL 9系、Rocky Linux 9など）はすべてsystemdをinitシステムとして採用しています。かつて広く使われた chkconfig や service コマンドは、systemdへの薄いラッパーとして残っている場合がありますが、2026年現在の運用では systemctl を直接使うのが標準です。旧来の手順を引き継いだまま運用している環境では、この段階で切り替えを検討してください。

まず、現在アクティブに起動しているサービスを確認します。

systemctl list-units --type=service --state=running

次に、起動時に有効化されているサービスを一覧表示します。現在は起動していなくても、再起動後に自動起動するサービスを把握するために必要な確認です。

systemctl list-unit-files --type=service --state=enabled

「runningではないがenabledになっているサービス」は見落とされがちです。再起動後に突然有効化されて問題になるケースがあるため、両方の確認をセットで行う習慣をつけておくことを推奨します。

止める対象の見極め方：役割とリスクで判断する

どのサービスを止めるべきかは、サーバーの用途によって異なります。「このサービスは絶対に停止すべき」とは一概に言えませんが、以下の観点を組み合わせて判断するのが現場的なアプローチです。

• そのサーバーの役割に無関係なサービスか：WebサーバーにBluetoothや印刷スプーラは不要です。
• 外部からアクセス可能なポートを開くサービスか：ss -tlnp でリッスン状態を確認し、不要な公開ポートを洗い出します。
• 停止しても他のサービスに依存されていないか：systemctl list-dependencies --reverse サービス名 で依存関係を確認してから判断します。

停止候補としてよく挙がるのは、avahi-daemon（mDNS/Bonjour）、cups（印刷スプーラ）、ModemManager（モバイルブロードバンド管理）、bluetooth などです。ただし、クラウド環境では cloud-init のように見た目には不要に見えても停止してはいけないサービスも存在します。サービスの役割を調べる際は systemctl cat サービス名 や man サービス名 で内容を確認するのが確実です。

systemctlで安全に停止・無効化する手順

サービスの停止と自動起動の無効化は、2つの操作をセットで行います。stop だけでは再起動後に復活し、disable だけでは現在のセッションでまだ動き続けます。それぞれの役割を意識して使い分けることが重要です。

# avahi-daemonを停止・無効化する例
sudo systemctl stop avahi-daemon
sudo systemctl disable avahi-daemon

1コマンドで停止と無効化を同時に行いたい場合は、--now フラグを使います。

sudo systemctl disable --now avahi-daemon

--now は disable と同時に stop も実行するオプションです。設定変更と即時停止を一度に行えるため、複数サービスをまとめて整理する場面で作業効率が上がります。

さらに確実に無効化したい場合は mask を使います。maskはサービスファイルを /dev/null へのシンボリックリンクに置き換えることで、systemctl start による手動起動も含めて完全に封じます。

sudo systemctl mask avahi-daemon

maskは強力な操作です。将来的に再度使う可能性があるサービスには disable にとどめ、明確に不要と判断したサービスにのみ mask を使うのが適切な使い分けです。

停止後の検証と切り戻し手順

サービスを停止したら、意図した通りの状態になっているかを確認します。

systemctl status avahi-daemon

出力に Active: inactive (dead) と表示され、Loaded 行に disabled と記載されていれば、停止と無効化の両方が正しく適用されています。maskを適用した場合は Loaded 行に masked と表示されます。

再起動後も状態が維持されているかを確認するには、sudo reboot 後に systemctl is-enabled サービス名 と systemctl is-active サービス名 をそれぞれ実行して確認します。本番環境では、メンテナンスウィンドウ内でこの確認まで含めた手順をチェックリスト化しておくと、作業の抜け漏れを防げます。

切り戻しが必要になった場合は、以下の手順で元の状態に戻せます。

# maskを解除してから再有効化・起動する場合
sudo systemctl unmask avahi-daemon
sudo systemctl enable --now avahi-daemon

maskを使わず disable のみの場合は unmask のステップは不要です。systemctl enable --now サービス名 だけで復旧できます。切り戻し手順を事前に手順書に記載しておくことで、万一の際の対応時間を短縮できます。

2026年環境での注意点：ソケット起動とディストリビューション差異

2026年現在の運用環境では、systemdのソケットアクティベーション（socket activation）に注意が必要です。一部のサービスは .service ユニットがdisabledになっていても、対応する .socket ユニットが有効なままだと、接続要求が来た時点でサービスが自動起動します。

# 関連するsocketユニットも確認する
systemctl list-units --type=socket --state=active

例えば cups.socket が残っていると、cups.service をdisableにしても印刷要求時に自動起動します。完全に無効化するには .socket ユニットも合わせてdisableまたはmaskしてください。サービスを止めたのにプロセスが再び現れる場合は、まずこのソケットユニットの存在を疑うのが定石です。

ディストリビューション間の差異も把握しておく必要があります。Ubuntu/Debianでは apt によるパッケージインストール時にサービスが自動起動するため、インストール直後の確認タイミングが重要です。一方、RHEL/Rocky/AlmaLinuxでは、インストール時点では自動起動しないサービスもあり、デフォルトの挙動が異なります。マルチディストリビューション環境を管理している場合は、この差異を意識した手順書を用意しておくと混乱を防げます。

クラウドVM（AWS EC2、GCP Compute Engineなど）では、amazon-ssm-agent や google-guest-agent のようにクラウドプロバイダーが提供するエージェントサービスを誤って停止すると、SSHアクセスや監視・パッチ管理に支障が出ます。停止前にサービスの役割を必ず確認する手順を省略しないことが、クラウド環境での運用では特に重要です。

不要サービスの整理は一度やって終わりではありません。パッケージの追加・更新時に新しいサービスが有効化されていないかを定期的に確認する運用習慣が、長期的なセキュリティ維持の土台になります。構築時の一回限りの作業ではなく、運用サイクルに組み込むことを検討してください。