NixOS本番採用の段階移行とパッケージ互換性・ロールバック設計

NixOSが本番採用の候補に上がる背景

NixOSは、システム構成全体を /etc/nixos/configuration.nix という単一ファイル（またはモジュール群）で宣言的に管理できるLinuxディストリビューションです。同一の設定ファイルをどの物理・仮想ホストに適用しても、理論上まったく同じ状態のシステムが再現できる点が、インフラのコード化（IaC）を推進する現場で注目を集めています。

従来のUbuntu/RHEL系では、パッケージのアップデートやシステム設定変更は原則として上書き操作であり、「なぜこの状態になったのか」を後から追跡するのが難しい場面があります。NixOSはすべての変更を「世代（generation）」として記録し、前世代への切り戻しをコマンド一本で実行できる設計になっています。この特性が、可用性と再現性を要求される本番環境での評価につながっています。

ただし、NixOSの採用は「Nixの思想を全スタックに持ち込む」作業であり、既存のシェルスクリプト・Ansible Playbook・Dockerfileとの共存方針を最初に整理しておかないと、移行中に摩擦が生じます。以下では段階移行・パッケージ互換性・ロールバック設計の3点を軸に、実際の移行フローを整理します。

段階移行の設計：フェーズを明確に区切る

本番採用を一度に行うのではなく、フェーズを区切ることが一般的です。以下の3段階が現場でよく取られるアプローチです。

フェーズ1：開発・ステージング環境への先行適用

まず非本番環境でNixOSを動かし、チームがNix言語の記述スタイルと nixos-rebuild switch の操作感に慣れる期間を設けます。ここではパッケージの依存解決やモジュールの書き方よりも、「宣言した状態とシステム実態の一致を確認する習慣」を定着させることが優先です。CI/CDでの自動ビルド（nixos-rebuild build をリモートで実行し、成功したら switch に進む）の仕組みもこの段階で整備します。

フェーズ2：非クリティカルな本番ワークロードへの適用

監視エージェント・バッチサーバー・内部ツールサーバーなど、サービス断の影響が限定的なノードから切り替えます。この段階でAnsibleやTerraformとの役割分担を確定させます。NixOSは「パッケージとサービス起動の管理」を担い、ネットワーク構成やDNS・ロードバランサーは既存ツールが引き続き管理する、という分担が現場では定着しやすいです。

フェーズ3：クリティカルサービスへの段階展開

Blue/Green構成でNixOSノードを並走させ、動作確認後にトラフィックを移す方法が安全です。NixOSではシステムの世代管理が独立しているため、アプリケーション側のデータ移行とシステム移行を分離しやすい利点があります。フェーズ3に入る前に、後述するロールバック手順をチーム全員で演習しておくことが推奨されます。

パッケージ互換性の確認と主な対処法

NixOSはFHSレイアウト（/usr/lib や /usr/bin 等の標準パス）を持たず、すべてのパッケージが /nix/store 以下の内容アドレス可能なパスに格納されます。この設計上の特性から、以下の互換性問題が頻出します。

• バイナリ配布ソフトウェア（独自RPM・DEB、商用エージェント）：ハードコードされた /lib64/ld-linux-x86-64.so.2 等のパスが見つからず起動しない。patchelf でインタープリタパスを書き換えるか、buildFHSEnv / steam-run でFHS互換の仮想ルートを用意する方法が使えます。
• Nixpkgsに存在しないソフトウェア：Nixpkgs（2026年9月時点で9万パッケージ超）に収録されていない場合は、独自の derivation を書くか、nix-shell / devShell で隔離環境を用意します。小規模なPythonアプリであれば poetry2nix や pip2nix 系のツールが変換を自動化します。
• 動的ライブラリのバージョン競合：Nixは同一ライブラリの複数バージョンを共存できるため、従来型ディストリで問題になるsoname競合はほぼ発生しません。ただし、外部プロセスが LD_LIBRARY_PATH を参照する構成では、Nix管理外のパスとの混在に注意が必要です。

移行前の互換性調査では、稼働中サービスが依存するバイナリ・共有ライブラリ・設定ファイルのパスを ldd と strace で洗い出し、Nixpkgsの対応状況を先に確認する作業が有効です。この調査を怠ると、フェーズ3で想定外の作業が発生します。

ロールバック設計：世代管理の仕組みと実務上の注意

NixOSの最大の特徴の一つが世代（generation）によるロールバックです。nixos-rebuild switch を実行するたびに新しい世代が作成され、ブートローダー（GRUB / systemd-boot）のメニューに追加されます。前世代に戻すには次のコマンドを実行します。

# 利用可能な世代を確認
nixos-rebuild list-generations

# 現行世代を前世代に切り替え（システム再起動不要）
nixos-rebuild switch --rollback

# または特定世代に切り替え
/nix/var/nix/profiles/system-<世代番号>-link/bin/switch-to-configuration switch

ロールバックが即時反映される範囲は「Nix管理下のパッケージとsystemdサービス定義」です。データベースのスキーマ変更・ファイルシステム上のデータ・外部APIへの変更は当然ながらロールバック対象外であり、この点は従来のディストリと変わりません。本番での変更手順書には「NixOSロールバックで戻せる範囲」と「アプリケーション層で別途切り戻しが必要な範囲」を明記しておくことが重要です。

また、世代を蓄積し続けると /nix/store のディスク使用量が増加します。定期的なガベージコレクションを設定ファイルで宣言しておくのが標準的です。

# configuration.nix の例
nix.gc = {
  automatic = true;
  dates = "weekly";
  options = "--delete-older-than 30d";
};

本番環境では古すぎる世代のGCを避け、少なくとも直近3〜5世代を残すポリシーをとる現場が多いです。世代の削除は元に戻せないため、GCポリシーは慎重に設計してください。

2026年現行環境での差分と留意事項

2026年9月時点のNixOS環境で特に留意すべき変化点を整理します。

• Nix 2.x系のFlakes安定化：Nix Flakesは2026年時点で実験的フラグなしでも広く利用されており、新規プロジェクトではFlakesベースの構成が事実上の標準になっています。既存の configuration.nix ベースのプロジェクトをFlakesに移行するかどうかは、チームの習熟度に合わせて判断します。FlakesはCIとの相性が良く、ロックファイル（flake.lock）による再現性がさらに高まります。
• NixOS on ARM（Raspberry Pi / AWS Graviton）の成熟：ARM64向けバイナリキャッシュの整備が進み、Graviton3ベースのEC2でNixOSを本番運用する事例が増えています。ただし一部パッケージはARM向けのバイナリキャッシュがなく、ローカルビルドが必要なケースがあります。
• Home Managerとの役割分担：ユーザー単位のドットファイル・シェル設定はHome Managerに委ね、システム全体の設定はNixOSモジュールで管理するパターンが定着しています。サーバー用途では不要ですが、開発者環境の整備を兼ねる場合は構成の分担を明確にしておきます。
• コンテナとの共存：NixOSをコンテナホストとして使い、アプリケーションをOCIコンテナで動かす構成は引き続き有力です。virtualisation.docker.enable や virtualisation.podman.enable をNixOS設定で宣言するだけでデーモンが立ち上がり、systemdによる起動管理も自動で構成されます。

NixOSの本番採用は「最初の学習コストが高い代わりに、運用が進むにつれて差分管理・環境再現・切り戻しのコストが下がる」という特性を持ちます。段階移行を丁寧に設計し、パッケージ互換性を事前に調査し、ロールバック手順をチームで共有しておくことが、安全な移行の鍵になります。