みなさん、こんにちは。
先日、Linuxの世界が二層に分かれていることについてお話しました。
私自身はサーバー環境を構築する場合でも、Debian/Ubuntu系をベースにすることが多いです。理由は、安定性とサポートの長さ、そして何よりも「APT」というシンプルで信頼できるパッケージ管理システムがあるからです。
また、医療・介護IoTという分野で仕事をしている都合上、サーバーは未だにオンプレミス環境で構築することが多いです。そうなると、サポートの一番長いUbuntu Serverをベースに、PostgreSQLやTomcat、Nginxといった手堅いバックエンド構成で組み込みサーバーを構築・納品する――。
エンジニアとしては非常に王道で、手離れの良さを狙った設計ですよね。
しかし、近年のUbuntuには最大の地雷が埋め込まれています。それが「snap」による強制自動アップデートです。
実はやってしまっていた、現場のケアレスミス
先日、「PostgreSQL 14 ＋ Tomcat 9」で堅牢に構築していたシステムが、前触れもなく沈黙するという大惨事がありました。
原因を調べてみると、なんとAPTではなく「snap版のPostgreSQL」がインストールされていたのです……！作業中のどさくさや、他の手順書のコピペなどで、意識せずに sudo snap install postgresql を叩いてしまっていたという、完全に現場のケアレスミスでした。
これがAPTで管理していたPostgreSQLと同じバージョンだったため、snap側の全自動更新機能がマイナーアップデートを引き起こし、接続エラーを発生させてしまったのです。
「あなたの管理ミスでしょ」と言われればそれまでなのですが、サーバー環境におけるsnapの存在自体が、「体験しないとヤバさがわからない」悪夢であることは間違いありません。
この悪夢から決別するため、Ubuntuからsnapを徹底的にパージ（排除）し、平穏なサーバー運用を取り戻す方法を今回は解説します！
開発元の「理想」と、現場の「現実」の致命的なギャップ
CanonicalのCEOマーク・シャトルワース氏は、インタビューなどで「AIエージェント時代には、厳格に隔離され、インターネットの速度で全自動更新されるsnapこそが唯一の安全な手段だ」と熱弁しています。
参考：「Ubuntu 26.04はAIエージェント時代のOS」–カノニカルのCEOが語る、その理由 (ZDNET)
確かに、デスクトップアプリや、使い捨てができるステートレスなAIマイクロサービスであればその理論も一理あります。しかし、データを預かるDBや、業務ロジックを回すWebサーバーにおいて、この思想は胃に穴が空く仕様でしかありません。
開発元は「自動更新で失敗しても、直前のデータ状態に自動ロールバックする機能（snap revert）があるから安全！」と主張するかもしれません。しかし、本番環境のサービスが一時的にでも予期せず沈黙すること自体が、現場にとっては大問題ですよね。
snapがサーバー環境でもたらす3大悪夢
- 意図しない強制再起動
リクエストを処理中のミドルウェアが、snapdの都合で強制終了・再起動され、セッション消失やデータ不整合のリスクに晒されます。 - 厳格すぎるサンドボックスによる通信遮断
snapアプリ同士、あるいはシステムとの連携が、アップデートの拍子にパーミッションリセットされ、ローカルソケットや特定ポートへの通信が突然拒否されることがあります。 - アップデート制御の煩わしさ
近年、特定のパッケージを完全に固定するsudo snap refresh --hold <package>という無期限ホールド機能が追加されました。しかし、パッケージごとにいちいちホールドを管理するくらいなら、最初からシステム全体を使い慣れたAPTでシンプルに一元管理したい、というのが現場の本音です。
なぜDocker（マイクロサービス）ではなく「APT」なのか？
「Dockerを使えばバージョンは固定できる」――それは正攻法の解決策です。しかし、オンプレミスや組み込み系サーバーの納品においては、Dockerがもたらす複雑性がデメリットになる局面が多々あります。
- 運用の階層（レイヤー）が増えすぎる
Linux標準の systemd だけでなく、Dockerデーモン、コンテナネットワーク、ボリュームマウントの監視が必要になり、トラブルシューティングが複雑化します。 - 顧客の運用担当者のスキルセット
「/var/log/の中身を見てください」「systemctl statusで確認してください」という、Linux共通の標準的な作法で引き継げるAPTの世界の方が、納品後のサポートコストが圧倒的に低いです。
だからこそ、「手順が簡単で、システムがシンプルに収まるAPTですべてを揃えたい」 というのは、現場として極めて合理的で賢明な判断なのです。
Ubuntuから「snap」を完全にパージする３手順
昨今のAIブームも商まって、Linux環境で開発する場合、普段はUbuntu系ディストリビューションを使っているエンジニアが多いと思います。
「開発機がUbuntuだから、作法が違うRed Hat系（Rocky Linux等）は避けたい」「でもUbuntu Serverのまま普通に apt install すると、一部のパッケージ（FirefoxやChromiumなど）で裏で勝手にsnap版にすり替えられる罠がある……」
このジレンマを解決するのが、「OSはUbuntuの体裁を保ちつつ、snapの仕組み自体をOSから完全に削除・ブロックする」 という職人技です。
納品前のキッティング（構築スクリプト）に、以下の手順を組み込みましょう。以下はUbuntu 22.04 LTS Serverをベースにした手順です。
手順1 – 動いているsnapアプリをすべて削除
まずは現在入っているsnapパッケージをすべて洗い出し、依存関係の下流から順に削除します。
# インストールされている一覧を確認
snap list
Name Version Rev Tracking Publisher Notes
core20 20260105 2717 latest/stable canonical✓ base
lxd 5.0.6-e49d9f4 38331 5.0/stable/… canonical✓ -
snapd 2.73 25935 latest/stable canonical✓ snapd
# 各パッケージを削除（環境に合わせて削除してください）
sudo snap remove --purge lxd
sudo snap remove --purge core20
※Ubuntu Serverのバージョンによっては、LXDのAPT側ラッパーが残ることがあるので、事前に sudo apt purge lxd lxd-client を実行しておくとより確実です。
手順2 – snapdサービス（本体）の完全削除
snapを管理するデーモン自体をシステムから完全にパージします。
sudo apt purge -y snapd
sudo rm -rf /root/snap /snap /var/snap /var/lib/snapd
手順3 – APTによる「隠れsnap」の再侵入を物理的に禁止する
一部のパッケージを apt install したときに、勝手にsnap版をダウンロードしてくるギミック（フック）を防ぐために、APTの設定ファイルを作成してsnapdのインストールを「絶対禁止」に設定します。
/etc/apt/preferences.d/nosnap.pref を新規作成し、以下を書き込みます。
Package: snapd
Pin: release a=*
Pin-Priority: -10
これで、以後誤ってsnapを呼び出すコマンドを叩いたり、依存関係で引っかかったりしても、システムが確実に拒否するようになります。
本当の平和を取り戻すためのダメ押し対策
「これでsnapも消えたし、APTリポジトリから本物のミドルウェアを入れれば安心！」……と思うのは、実はまだちょっと早いんです。
Ubuntuには標準で unattended-upgrades（セキュリティ自動更新機能） が仕込まれています。snapを消し去っても、この機能が有効なままだと、APTで入れたPostgreSQLなどのミドルウェアが、バックグラウンドの自動更新によって予期せずマイナーアップデート（例：14.1 → 14.2）され、一瞬サービスが瞬断したり再起動したりするリスクが残ります。
特に医療・介護システムのような分野では、ガイドラインに基づき「検証済みの環境（バージョン）」を維持して運用することが強く求められます。OSの勝手な判断でマイナーバージョンが1つ上がっただけでも、それは現場にとって「未検証のシステム」になってしまうリスクを孕んでいるのです。
本当の意味で「自分が apt upgrade を叩しない限り絶対にバージョンが上がらない、クリーンで堅牢な環境」を作るために、以下のコマンドで大事なパッケージをホールド（バージョン固定）しておきましょう！
# PostgreSQLのバージョンをAPT側でもがっちり固定する
sudo apt-mark hold postgresql-14
これで自動更新の対象から完全に除外され、現場の完全なコントロール下に置くことができます。
【おまけ】snap完全去勢後の地味なメリット
ちなみに、snapを綺麗さっぱり削除すると、サーバー起動後に df -h コマンドを叩いたときに画面を埋め尽くしていた大量の /dev/loopX（snapの仮想マウント）がすっきりと消え去ります。
ディスク容量の監視スクリプトが誤検知するリスクも減りますし、何よりシステムの視認性が劇的に向上するので、運用保守フェーズで地味にストレスが減る嬉しい副産物です。
開発元の理想論には「現場の生存戦略」で対抗する
カノニカルが描く「最新のアプリが全自動で安全に配信される世界」は、教科書の上では美しいですが、ミッションクリティカルなオンプレミス環境を預かるエンジニアにとってはリスクでしかありません。
もし顧客から長期サポートを要求され、「Ubuntu Server」を選択しなければならなくなったとしたら、OSのガワはUbuntuのまま、中身からsnapを徹底的に排除することを検討してください。そして、APT側のバージョンホールドも忘れずに。
この少しの泥臭い仕込みだけで、オンプレミスサーバーの安定性は劇的に向上し、エンジニアとしての平穏な夜を取り戻すことができます。
開発元の「理想」に振り回されず、システムの「確実性」をとるために、ぜひこの #NoSnap 構成を試してみてください。
本日も最後までお読みいただきありがとうございました。
それでは、よいUbuntuライフを！
