Debian 13「Trixie」安定版前に組む移行計画｜Bookwormとのパッケージ差分と本番切替手順

リリーススケジュールと保守期限の現在地

Debian 13「Trixie」は2025年8月12日に安定版（stable）としてリリースされました。Debian 12「Bookworm」が2023年6月にリリースされてから約2年での世代交代です。2026年8月時点でTrixieは安定版として1年以上の実績を積んでおり、本番環境への移行を検討する現場が増えています。

Debianのリリースポリシーでは、安定版は約3年間のセキュリティサポートを受け、その後LTSチームによってさらに2年間（合計5年）のサポートが提供されます。BookwormのLTSサポートは2028年6月まで続く見込みのため、移行に対する絶対的な期限は目前ではありません。しかし、TrixieがBookwormの後継として「現行の推奨版」となった以上、新規構築はTrixieベースで行い、既存環境も計画的に移行していくことが実務上の標準的な対応です。

移行を急ぐ必要はないものの、「いつかやる」と後回しにしていると、サポート期限に近づいたタイミングで大量のサーバーを一斉に更新せざるを得なくなります。現場では1〜2年かけて段階的に移行する計画を立て、テスト環境での検証を先行させるアプローチが定着しています。

主要パッケージの差分：何が変わったのか

移行計画を立てる前提として、BookwormとTrixieの間でどのコンポーネントが入れ替わったかを把握しておく必要があります。実運用で影響が出やすい主要パッケージの変化を以下に整理します。

カーネルとシステム基盤

LinuxカーネルはBookwormのLTS 6.1系からTrixieのLTS 6.12系へ移行しました。6.12はio_uring関連のパフォーマンス改善やBPFサブシステムの強化が含まれており、ネットワーク集約型ワークロードでの恩恵が報告されています。一方、ドライバの挙動が変化しているケースもあるため、物理サーバーや特殊なNICを搭載した環境では事前にカーネルブートの確認を済ませることが重要です。

systemdはBookwormの252系からTrixieの257系へ上がっています。257ではサービス定義の一部パラメータが非推奨になったものがあり、カスタム書きのユニットファイルを保有する環境では systemd-analyze verify で事前に警告を拾い出しておくことを推奨します。OpenSSLはBookwormの3.0.x系からTrixieの3.4.x系へ移行し、レガシー暗号スイート関連の非推奨APIが除去されています。TLS設定をカスタマイズしているnginxやApache環境ではサイファーリストの見直しが必要になる場合があります。

言語ランタイムとデータベース

PythonはBookwormの3.11からTrixieの3.13に変わります。3.12で削除されたAPIがいくつかあるため、社内ツールやスクリプトが distutils や非推奨importに依存していないか確認が必要です。仮想環境（venv）を使っている場合は移行後に再作成が求められます。

PHPはBookwormの8.2からTrixieの8.4に移行します。8.3・8.4で削除・変更された関数（ldap_connect() のシグネチャ変更など）が存在するため、PHPアプリケーションを運用している環境では php -l による静的チェックと動作確認テストが不可欠です。GCCは12系から14系へ更新されており、-Werror をデフォルトにしているビルドスクリプトでは事前確認が必要です。

PostgreSQLはBookwormの15からTrixieの17へ上がります。メジャーバージョンアップはデータの物理フォーマットが変わるため、pg_upgrade または論理レプリケーションによる移行が必要です。OSのアップグレードとは別工程として計画に組み込む必要があります。MariaDBはBookwormの10.11（LTS）からTrixieの11.4（LTS）へ移行しています。

本番環境への移行手順：in-placeアップグレードの実際

Debianの公式サポートするアップグレード経路はin-place（上書き）アップグレードです。本番環境に適用する前に、必ず同一構成のステージング環境で手順を通しておくことが大前提です。

ステップ1：現状の記録とバックアップ
アップグレード前に dpkg --get-selections > packages-bookworm.txt でインストール済みパッケージ一覧を保存します。仮想マシン上であればスナップショットを取得します。物理サーバーや専用インスタンスの場合は、設定ファイル（/etc）とデータディレクトリのバックアップを確認してから作業に入ります。

ステップ2：Bookwormを最新状態に更新
アップグレード作業は、まず現行のBookworm環境を最新の状態にしてから開始します。apt update && apt upgrade -y && apt full-upgrade -y を実行し、保留中のパッケージをすべて解消しておきます。

ステップ3：sources.list の書き換え
/etc/apt/sources.list および /etc/apt/sources.list.d/ 以下の設定ファイルで「bookworm」という文字列を「trixie」に置き換えます。MariaDB公式・PostgreSQL公式・NodeSourceなどのサードパーティリポジトリが存在する場合は、Trixie対応版のリポジトリURLに個別に差し替えが必要です。Trixie非対応のリポジトリはいったんコメントアウトしておくのが安全です。

ステップ4：最小アップグレードと完全アップグレード
apt update でパッケージ情報を更新した後、apt upgrade --without-new-pkgs を先に実行して依存関係が複雑になる前にコア部分を更新します。次いで apt full-upgrade を実行することで、不要なパッケージの除去と新規パッケージのインストールが行われます。この段階で設定ファイルについて「既存を残すか新版で上書きするか」のプロンプトが表示されます。/etc 以下のカスタマイズ内容を事前に diff で把握しておくと判断が速くなります。

ステップ5：再起動と初期確認
full-upgrade 完了後はシステムを再起動します。新カーネル（6.12系）での起動を確認した後、cat /etc/debian_version および uname -r でバージョンを目視確認します。

移行後の動作確認と検証ポイント

アップグレード直後は、システムが正常に動作しているかを段階的に確認します。最初に確認すべきはsystemdのユニット状態です。systemctl --failed を実行して、起動に失敗しているサービスがないかを確認します。失敗があれば journalctl -xe でログを追いながら原因を特定します。

次に、アプリケーション層の動作確認を行います。Webサービスであれば想定URLへのHTTPレスポンスが正常か、データベースへの接続・クエリが正常に完了するかを自動テストやヘルスチェックスクリプトで確認します。この段階でエラーが出た場合は、パッケージのバージョン差分（特にPHP・Python・OpenSSL）に原因があるケースが多いため、アプリケーションのエラーログと合わせて確認します。

サードパーティリポジトリをコメントアウトしていた場合は、Trixie対応版に更新してから再度有効化し、不足パッケージを補完します。dpkg -l | grep -i 'rc' で残存している設定ファイルを持つ削除済みパッケージを確認し、必要に応じて apt purge で整理しておくと以後の管理がクリーンになります。

needrestart パッケージを導入している環境では、ライブラリ更新後に再起動が必要なサービスのリストが表示されます。カーネルの再起動だけでなく、デーモンの再起動を漏れなく実施することで、古いライブラリを参照し続けるプロセスをなくすことができます。

切り戻し方針と見落としやすい注意点

Debianのin-placeアップグレードには、公式の「ダウングレード」経路が存在しません。スナップショットや物理バックアップからの復元が実質的な切り戻し手段となります。このため、仮想化環境ではアップグレード前のスナップショットを手動削除しないよう運用ルールを設けることが重要です。保持期間は最低でも本番への負荷試験が完了するまで（目安として2〜4週間）が現場の一般的な基準です。

見落とされやすいポイントの一つが、サードパーティ製aptリポジトリのTrixie対応状況です。ベンダー提供のリポジトリはdistributionが変わると別URLになるケースが多く、古いURLを残したままにすると apt update がエラーになったり、古いバージョンが混入したりします。移行前にすべてのサードパーティリポジトリについてTrixie対応版を確認し、一覧を作成しておくことを推奨します。

もう一つが、PostgreSQLのデータディレクトリの扱いです。apt full-upgrade を実行した際にPostgreSQLがバージョン15から17に更新されても、データディレクトリは自動では移行されません。結果としてサービスが起動しない状態になります。PostgreSQLを運用している環境では、pg_upgradecluster（Debianで利用可能）を使ったデータ移行を独立した工程として計画に組み込んでください。

また、カーネルバージョンに依存したDKMSモジュールを使用している環境では、カーネル更新後に該当モジュールの再ビルドが必要です。VirtualBox Guest AdditionsやZFS on Linuxなどを導入している場合は、Trixieのカーネルへの対応状況を移行前に確認しておきます。

2026年時点での環境別考慮事項

2026年8月現在、クラウドネイティブな運用環境では、OSを直接アップグレードするin-place手法よりも、Trixieベースの新規イメージを用意してコンテナやVMインスタンスをブルーグリーンデプロイで切り替えるアプローチが主流になっています。この場合、アプリケーション側の動作確認が主な関心事となり、OS移行リスクを大幅に下げられます。

Dockerを使ったコンテナ環境では、ベースイメージを debian:bookworm から debian:trixie に変更してビルドし直す作業が「Debian移行」の実態です。この場合も、PythonやPHPのバージョン差異によるアプリケーションの互換性チェックは同様に必要です。CI/CDパイプラインにtrixieベースのビルドを追加して並行検証する手法が現場では実践されています。

一方、物理サーバーや長期運用の仮想マシンではin-placeアップグレードが依然として現実的な選択です。Trixieが安定版として1年以上の実績を持つ2026年時点では、サポートポリシーや運用コストを理由にUbuntu LTSへの乗り換えを検討する現場も出てきています。ただし、Debianの保守的なパッケージポリシー（安定性優先・バックポート中心）を評価して使い続けている環境では、Trixieへの移行が引き続き合理的な選択肢です。

AnsibleやChefといった構成管理ツールを活用している環境では、ansible.builtin.apt のリポジトリ管理タスクにdistribution変数を組み込んでおくと、sources.listの一括更新を自動化できます。移行作業をプレイブック化しておくことで、複数台への横展開時の作業漏れを防ぐ効果があります。段階的なロールアウト（検証機→ステージング→本番の順）とプレイブック管理を組み合わせることが、2026年時点の現場標準に近いアプローチといえます。