DebianとUbuntuの違いとは？なぜ分かれたのか解説

DebianとUbuntuが分かれた理由

DebianとUbuntuが2004年に分かれたのは、コードの差異ではなくリリースカレンダーが理由です。Debianはリリースチームが準備完了と判断した時点で安定版をリリースします。一方、Ubuntuはあらかじめ決めた日付に6ヶ月ごとのリリースを約束しました。そのため、Debianの開発ブランチをコピーしてフリーズさせ、不具合を修正した上でリリースしています。

22年が経過した現在も、両者はパッケージ形式とその管理ツールを共有しており、その背後にあるパッケージング作業の大部分は一度の作業で完結します。共有していないのは、スケジュール、サポート契約、そしてデフォルトインストールに何を含めるべきかという方針です。サーバー用OSを選択する際、この違いは重要です。表面的な違いと、対応に午後を丸々費やすような実質的な違いを区別できるからです。

Ubuntu の起源

Ian Murdock は 1993 年 8 月 16 日に Debian Project を設立しました。2004 年の時点で、Debian はボランティア運営のディストリビューションとして最大規模でしたが、開発速度は緩慢でした。Debian 3.0 "woody" が 2002 年 7 月 19 日にリリースされた後、後継の Debian 3.1 "sarge" が登場したのは 2005 年 6 月 6 日のことです。2 つの安定版リリースの間に約 3 年もの歳月が経過しました。この期間中、Debian サーバーで最新のソフトウェアを利用したいユーザーに対し、Debian プロジェクト自体が提供できる公式な解決策はありませんでした。

2004 年 4 月、Mark Shuttleworth は約 12 名の Debian 開発者をロンドンの自宅に招き、固定スケジュールで開発する Debian ベースのシステムを計画しました。彼はその開発者を雇用するために Canonical Ltd を設立しました。最初のリリースである Ubuntu 4.10 "Warty Warthog" は、その 6 ヶ月後の 2004 年 10 月 20 日に公開されました。バージョン番号はリリース日を表しており、4.10 は 2004 年 10 月、26.04 は 2026 年 4 月を意味します。

Ubuntu は、一般的な意味でのフォークではありません。フォークとは、コードベースを一度コピーした後に元のプロジェクトから離脱するものを指します。Ubuntu は、サイクルごとに Debian を再コピーしています。パッケージは Debian の不安定版である sid から取得され、各 Ubuntu サイクルの初期数週間にわたって自動的に更新が反映されます。インポートの凍結期間以降は、Ubuntu の開発者が手動でパッケージを取り込み、凍結ルールに基づいた正当性を証明する必要があります。Linux ディストリビューションの広範な系譜には多くの真のフォークが存在しますが、Ubuntu はそれに該当しません。これは永続的なダウンストリームです。

両プロジェクトが依然として共有しているもの

共有部分は相違点よりもはるかに大きいです。両者とも .deb パッケージ形式を採用しており、その基盤には dpkg があり、その上に apt が構築されています。また、ファイルの配置場所やパッケージの依存関係の宣言方法については、どちらも Debian Policy に準拠しています。Ubuntu の開発者向けドキュメントによると、ソースパッケージの約 5 分の 4 は Debian から無修正でコピーされたものです。Debian でバグを修正するメンテナは、通常、双方が意識することなく Ubuntu ユーザーのためにも修正を行っていることになります。

Ubuntu がパッケージに変更を加えた場合、バージョン文字列にそれが示されます。Debian の 1.2.3-4 は 1.2.3-4ubuntu1 となり、このサフィックスがローカルでの変更（両プロジェクトで「デルタ」と呼ばれます）を示します。Ubuntu は変更を加えたすべてのパッケージについて完全なデルタを公開し、パッチを Debian のパッケージ追跡システムに転送しています。これにより、Debian のメンテナは下流での変更内容を確認し、必要に応じて取り込むことができます。

それが十分かどうかについては 2005 年から議論が続いていますが、どちらかの立場を取るのではなく、その論点を明確に述べる価値があります。Debian 側の不満は、労力の帰結点に関するものです。Canonical は下流で作業する人々に報酬を支払っており、その下流がユーザーと注目を集める一方で、修正を上流に送り返す作業は追加の労力であり、誰もそのための報酬を受け取っていないという点です。一方、Ubuntu 側の主張は、6 か月という期限があるため、期限のないプロジェクトである Debian を待つことが常に選択肢になるとは限らないというものです。どちらの主張も事実です。しかし、どちらの主張もパッケージの流れを止めることはありませんでした。

準備が整い次第リリースする、カレンダーの日付に縛られずに

Debian のリリース日は結果であり、約束ではありません。Debian 12 "bookworm" は 2023 年 6 月 10 日に、Debian 13 "trixie" は 2025 年 8 月 9 日にリリースされました。約 2 年の間隔がありますが、次回の間隔が同じになるとは限りません。現在の testing ブランチは "forky" と呼ばれており、リリース日は決まっていません。Debian はリリースに致命的なバグがなくなるまで、リリース日を公表しないためです。

Ubuntu の日付は約束です。6 か月ごとにリリースが行われ、4 回に 1 回、偶数年の 4 月に LTS (長期サポート) リリースが提供されます。Ubuntu 26.04 LTS "Resolute Raccoon" は予定通り 2026 年 4 月 23 日にリリースされました。その間のリリースは中間リリースと呼ばれ、アップデート期間は 9 か月間のみです。そのため、年に 2 回も再構築したくないサーバーには適していません。サーバーにおける Ubuntu LTS と中間リリースの選択は、この 9 か月という期間に集約されます。

このリリースサイクルがアップグレードのスケジュールを決定します。これが両者の違いによる最も実用的な影響です。Ubuntu LTS では、次のインプレースアップグレードが偶数年の 4 月に行われることが数年前から分かっているため、Ubuntu 24.04 から 26.04 へのアップグレードは 26.04 が存在しない段階から計画可能です。Debian では、フリーズの告知を監視し、実際にリリースが行われてから作業をスケジュールします。

LTSがもたらした変化

Ubuntu 6.06 LTS "Dapper Drake" は2006年6月1日にリリースされ、これが最初のLTSとなりました。それ以前のUbuntuは半年ごとにシステムが入れ替わる非常に速いペースで開発されており、企業が本番環境のサーバーを構築する基盤としては適していませんでした。LTSがもたらした重要な変化は、将来のサポート終了日を明確に定めたことです。これにより、長期的な計画を立てることが可能になりました。この変化こそがUbuntuを標準的なサーバーディストリビューションへと押し上げた要因であり、半年ごとのリリースサイクルがそれを支えています。各LTSは、その間のリリースで既に検証済みの成果を統合して構築されるためです。

Debianもまた、異なるアプローチから同じ到達点に達しました。Debianのstableリリースは元来、緩やかなペースで更新されてきましたが、Debian LTSプロジェクトが発足したことで、Debianのセキュリティチームによるサポート終了後も各リリースの寿命が延長されるようになりました。

サポートの提供元と期間

[
  {
    "label": "Debian stable",
    "support_duration": 3
  },
  {
    "label": "Debian LTS",
    "support_duration": 5
  },
  {
    "label": "Debian ELTS, paid",
    "support_duration": 10
  },
  {
    "label": "Ubuntu LTS",
    "support_duration": 5
  },
  {
    "label": "Ubuntu Pro ESM",
    "support_duration": 10
  },
  {
    "label": "Ubuntu Pro plus Legacy",
    "support_duration": 15
  }
]

Debian のセキュリティチームは、安定版リリースに対して 3 年間のサポートを提供します。その後は Debian LTS チームが引き継ぎます。Debian はこのチームを公式のセキュリティ・リリースチームではなく、ボランティアと企業のグループと位置づけており、サポート期間は 5 年まで延長されます。この引き継ぎの時期は現在の日付から確認できます。bookworm は 2026 年 6 月 11 日に LTS へ移行し 2028 年 6 月 30 日までカバーされます。bullseye は 2026 年 8 月 31 日に LTS 期間が終了します。それ以降は Freexian が Extended LTS (ELTS) を販売し、10 年までサポートを継続しますが、対象は支払い顧客が実際に使用しているパッケージのサブセットのみです。

Ubuntu LTS は、Canonical から 5 年間の標準的なセキュリティメンテナンスを受けられます。Ubuntu Pro を契約すると、ESM (Expanded Security Maintenance) を通じて main および universe リポジトリ全体で 10 年まで延長され、Legacy アドオンを追加すれば 15 年までとなります。2026 年 8 月現在、Ubuntu Pro は個人利用であれば最大 5 台まで無料であるため、単一の VPS であれば購入手続きなしで 10 年間のサポートが現実的な選択肢となります。また Pro には Livepatch サービスが含まれており、これはカーネルのセキュリティアップデートのたびに再起動することなく VPS 上でカーネルをライブパッチする ための公式な手段です。

これらの数字の背後にある構造は、数字そのものよりも重要です。Ubuntu の場合、ディストリビューションを構築している企業から直接サポートを購入します。Debian にはそのような企業が存在しないため、有償サポートは Freexian のようなサードパーティ、ホスティングプロバイダー、あるいは自社チームから提供されることになります。

Init システムと、議論に終止符を打った投票

技術的に最も鋭く対立したのは、カーネルが最初に起動するプロセスであり、その後の全サービスを管理する init システムでした。2006年10月26日にリリースされた Ubuntu 6.10 "Edgy Eft" は、Canonical が開発した Upstart を採用しました。Debian は議論が続く間、長年にわたり sysvinit を維持しました。Debian 技術委員会は 2014年2月11日に終了した投票によってこの問題を解決し、議長の決裁票により Debian 8 で systemd を採用することが決定しました。

Ubuntu も数日以内にこれに追随しました。Shuttleworth は「Losing graciously（潔く負けを認める）」と題した投稿で、その理由を簡潔に述べています。Ubuntu は Debian ファミリーの一員であるため、その決定に従うというものです。Ubuntu 15.04 は 2015年4月23日に systemd をデフォルトで採用し、Debian 8 "jessie" もその3日後の 2015年4月26日に同様の対応を行いました。

この収束こそが、ほとんどのサービス向けチュートリアルが両者の間で修正なしに通用する理由です。Unit ファイル、systemctl、および journalctl は、どちらの環境でも同じように動作します。Debian 13 は systemd 257 を、Ubuntu 26.04 LTS は systemd 259 を搭載しており、両者を隔てるものは設計の違いではなく、バージョン番号のみとなっています。

Snap と移植性の問題

Ubuntu 16.04 LTS は 2016 年に snap パッケージを導入し、18.04 では一部の標準アプリケーションが snap として提供されるようになりました。snap は依存関係を内包する自己完結型のバンドルです。そのため、アップストリームのプロジェクトは、アーカイブの更新を待つことなく、サポートされているすべての Ubuntu リリースに対して一度に新しいバージョンを配布できます。

他の主要なディストリビューションが snap を標準採用しなかった理由は、その形式にありません。snapd クライアントは Canonical が運営する単一のストアと通信しますが、そのストアのサーバー側はオープンソースではないためです。snap を採用するディストリビューションは、ソフトウェア配布の一部を他社に委ねることになります。Debian はこれを選択せず、デフォルトで snapd をインストールすることもしません。

ここで、アップストリームの指示が機能しなくなるケースが発生します。Certbot が最も明確な例です。Certbot の公式ドキュメントは snap からのインストールを推奨しており、ディストリビューションのパッケージは「LTS スタイルのディストリビューションでは急速に古くなる傾向がある」と警告しています。Ubuntu でその手順に従えば問題なく動作しますが、標準の Debian サーバーで実行すると、最初のステップから実行するものが何もありません。そのため、当サイトの Ubuntu 24.04 における Nginx 用 Certbot ガイド では、ディストリビューションのパッケージを使用しています。

カーネル、ファームウェア、および non-free に関する方針

Debian の社会契約と DFSG (Debian free software guidelines) は、main に含めることができるソフトウェアの基準を定めています。それ以外のものは contrib および non-free に分類されます。Debian の歴史の大半において、一般的なネットワーク機器やストレージハードウェアの動作に必要なバイナリファームウェアの blob は、この non-free に含まれていました。2022 年の一般決議を経て、Debian 12 では新たに non-free-firmware アーカイブ領域が追加され、公式インストーラーイメージにもファームウェアが同梱されるようになりました。

Ubuntu は当初から対照的な方針をとっています。Ubuntu のアーカイブは、Canonical がサポートしプロプライエタリなドライバーを含む main および restricted と、コミュニティが管理する universe および multiverse に分かれています。VPS 環境では仮想ハードウェアがほとんどファームウェアを必要としないため、この違いの影響は軽微です。しかし、物理サーバー（dedicated hardware）においては、ネットワークカードが認識されるかどうかの決定的な差となります。

カーネルについても同様の軸で方針が分かれています。2026 年 8 月現在、Ubuntu 26.04 LTS は Linux 7.0 を、Debian 13 は Linux 6.12 を採用しています。Ubuntu はハードウェア有効化スタック（HWE）を通じて、LTS リリースの期間中もカーネルを更新していきます。一方、Debian は安定版リリースの期間中、同一のカーネルシリーズを維持し、より新しいカーネルは backports を通じて提供します。新しいカーネルは最新の virtio デバイスやファイルシステムへの対応が優れています。古いカーネルは、1 月に検証した動作が 12 月になっても変わらないという安定性を提供します。

異なるディストリビューション向けの手順を実行した場合の不具合

多くの場合、一方のために書かれたガイドは他方でも機能します。不具合は特定の箇所に集中します。

• サードパーティの apt リポジトリは、ディストリビューションおよびコードネームごとに公開されます。noble と jammy をサポートするベンダーが trixie 用のパッケージを公開していない場合、その失敗はネットワーク障害のように見えますが、実際にはポリシー上の判断です。
• Launchpad PPA は特定の Ubuntu シリーズ向けにビルドされます。これを Debian に追加すると、Ubuntu のライブラリバージョンにリンクされたバイナリが取得されます。これが偶然動作することもありますが、Ubuntu のランタイムの大部分がシステムに引き込まれることになります。
• snapd、Ubuntu Pro サブスクリプション、Canonical の livepatch を前提とする手順には Debian 相当のステップが存在しません。そのため、ガイドの該当セクションは適応させるのではなく、置き換える必要があります。
• デフォルトイメージでは、ログインユーザーが異なります。Ubuntu イメージは通常 sudo 権限を持つ ubuntu ユーザーを提供し、root パスワードは設定されていません。Debian イメージは通常 debian ユーザーを提供しますが、プロバイダーのイメージによっても異なります。SSH に関する設定を変更する前に、自身の環境を確認してください。

リポジトリに自身のリリース用のスイートが存在しない場合、apt は以下のように明確なエラーを出力します。

E: The repository 'https://download.example.com/linux/debian forky Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

このメッセージは、ベンダーがそのコードネーム用のパッケージを公開していないことを意味します。ミラーサーバーが壊れているわけではなく、再試行しても解決しません。ベンダーがそのリリースをサポートしているかどうかの問題です。

では、どちらを選択すべきでしょうか？

数年先までカレンダーにアップグレード予定を書き込める安定性と、サポートを購入できる単一のベンダーを求めるなら Ubuntu LTS を選択してください。デフォルトのインストールサイズが小さく、特定の企業に依存せず、退屈なほどゆっくりと変化する基盤を求めるなら Debian stable を選択してください。

それ以外の要素は共通です。どちらも apt を使用し、Debian Policy に準拠しており、同じパッケージ形式から同じアプリケーションを実行するため、習得したスキルはそのまま活用できます。Red Hat や Fedora から移行する場合は、dnf と apt のコマンド対応表が双方の変換に役立ちます。また、デプロイ時に他のイメージと比較検討している場合は、VPS 用オペレーティングシステムの選択ガイドで他の選択肢と並べて比較しています。

FAQ

Ubuntu は Debian のフォークですか？

いいえ。フォークとはコードベースを一度コピーし、その後は別々に保守していくものを指します。Ubuntu は6か月ごとのリリースサイクルの開始時に Debian unstable からソースを取り込んでおり、開発者向けドキュメントによれば、無修正でコピーされるソースパッケージの割合は約5分の4に達します。Ubuntu は Debian の恒久的なダウンストリームであるため、Debian のパッケージ管理知識はそのまま Ubuntu に適用でき、Debian で行われた修正は通常、追加作業なしで Ubuntu ユーザーにも反映されます。

Ubuntu 向けのチュートリアルは Debian でも使えますか？

多くの場合使えますが、例外は予測可能です。両者とも apt を使用し、systemd を採用しており、Debian Policy に準拠しているため、パッケージ管理やサービス管理の手順は共通です。問題が発生するのは Canonical のインフラに依存する部分です。具体的には、snap ベースのインストール手順、Launchpad PPA、Ubuntu Pro コマンド、および Ubuntu のコードネーム向けにのみ公開されているサードパーティの apt リポジトリなどが該当します。リポジトリに自身のリリースに対応するスイートが存在しない場合、apt は "does not have a Release file" と報告しますが、これはベンダーがそのコードネーム向けにビルドを提供していないことを意味します。

Debian と Ubuntu のセキュリティアップデートはどのくらいの期間続きますか？

Ubuntu LTS は Canonical から 5 年間の標準セキュリティメンテナンスを受けられます。Ubuntu Pro サブスクリプションがあれば 10 年間、Legacy アドオンを追加すれば最大で 15 年間となります。Debian stable リリースは、Debian セキュリティチームから 3 年間、その後の LTS 期間を含めると合計 5 年間のサポートを受けられます。Freexian が提供する有償の Extended LTS は 10 年間まで延長されますが、これは顧客がリクエストしたパッケージのみが対象です。

サーバー用途には Debian と Ubuntu のどちらが良いですか？

どちらが優れているという一概な基準はなく、スケジュールとサポート体制で判断するのが誠実な回答です。アップグレード時期を予測可能にする必要があり、単一のベンダーからサポートを購入したい場合は Ubuntu LTS が適しています。デフォルトのインストールサイズが小さく、変更頻度が緩やかであることを重視する場合は Debian stable が適しています。両者とも同じパッケージ形式で同じソフトウェアを動作させるため、どちらを選んでもホストできる内容に制限はありません。