NixOSとは？再現可能な環境構築・ロールバック・学習コストから選び方を解説

NixOSは、OSのパッケージやサービス、ユーザー、ネットワーク設定までコードとして宣言し、同じ構成を再構築したい人に向くLinuxディストリビューションです。複数PCや開発環境、サーバー構成の統一に強く、更新失敗時のロールバックも行えます。一方、Nix言語、Nixpkgs、モジュール、Flakesなど独自概念が多いため、一般的なLinux操作をそのまま使いたい人や、短期間で保守担当者を増やしたい組織には向かない場合があります。

30秒要約

NixOSは、OS全体の構成を宣言的な設定ファイルで管理するLinuxディストリビューション
パッケージを分離して保存するため、複数バージョンの共存、原子的な更新、世代単位のロールバックが可能
開発PC、複数端末、検証環境、構成をコードレビューしたいサーバー運用と相性がよい
Nix言語、Nixpkgs、モジュール、Flakesなど独自概念が多く、学習コストは高い
2026年7月11日時点の現行安定版はNixOS 26.05で、公式発表上のサポート期限は2026年12月31日

NixOSの基本情報

項目	内容
名称	NixOS
読み方	ニックスオーエス、ニックス・オーエス
種別	独立系Linuxディストリビューション
系統・ベース	NixパッケージマネージャーとNixpkgsを基盤とする独立系
パッケージ管理	Nix
パッケージ集合	Nixpkgs
システム設定	NixOSモジュールによる宣言的構成
initシステム	systemd
主なリリース系列	安定版、nixos-unstable
現行安定版	NixOS 26.05「Yarara」
現行安定版の公開日	2026年5月30日
26.05のサポート期限	2026年12月31日
主な用途	開発環境、個人PC、サーバー、検証環境、複数端末の構成統一
費用	無料
ライセンス	NixOS、Nix、Nixpkgsおよび各パッケージのライセンスによる
公式サイト	https://nixos.org/
ダウンロード	https://nixos.org/download/
NixOSマニュアル	https://nixos.org/manual/nixos/stable/
Nixマニュアル	https://nix.dev/manual/nix/latest/
Nixpkgsマニュアル	https://nixos.org/manual/nixpkgs/stable/
パッケージ・オプション検索	https://search.nixos.org/
公式Wiki	https://wiki.nixos.org/
ソースコード	https://github.com/NixOS/nixpkgs

確認日：2026年7月11日

NixOS公式ダウンロードページでは、2026年7月11日時点の現行安定版としてNixOS 26.05が案内されています。

https://nixos.org/download/ NixOS 26.05の公式リリース発表では、バグ修正およびセキュリティ更新の提供期限が2026年12月31日とされています。

https://nixos.org/blog/announcements/2026/nixos-2605/

NixOSとは

NixOSは、Nixパッケージマネージャーを中心に構築されたLinuxディストリビューションです。

一般的なLinuxディストリビューションでは、管理者がパッケージを順番にインストールし、/etc以下の設定ファイルを直接編集し、サービスを個別に有効化します。

NixOSでは、必要なパッケージ、ユーザー、サービス、ファイアウォール、ブートローダーなどを設定ファイルに記述し、その宣言からシステム構成を生成します。

たとえば、SSHサーバーを有効にし、nginxを導入し、ファイアウォールでHTTPとHTTPSを許可する構成を、1つのNix設定として管理できます。

{
  services.openssh.enable = true;

  services.nginx.enable = true;

  networking.firewall.allowedTCPPorts = [ 80 443 ];
}

設定を反映する際は、通常、次のコマンドを実行します。

sudo nixos-rebuild switch

この仕組みにより、手作業で変更した内容が分からなくなる「構成ドリフト」を抑えやすくなります。

NixOS、Nix、Nixpkgsの違い

NixOSを理解するには、NixOS、Nix、Nixpkgsを分けて考える必要があります。

名称	役割
NixOS	Nixを基盤にしたLinuxディストリビューション
Nix	パッケージのビルド、取得、保存、環境構築を行うパッケージマネージャー
Nixpkgs	Nixで利用できるパッケージ定義とNixOSモジュールの大規模な集合
Nix言語	パッケージやシステム構成を記述するための式言語
Nix store	ビルド成果物や依存関係を保存する領域
NixOSモジュール	OSの設定項目を宣言的に組み合わせる仕組み

NixOS

OS全体です。Linuxカーネル、systemd、ユーザー、ファイルシステム、サービスなどをNixの仕組みで構成します。

Nix

パッケージマネージャーです。NixOS以外のLinuxやmacOSにも導入できます。

UbuntuやmacOSを維持したまま、開発環境だけNixで管理することも可能です。

Nixpkgs

パッケージ定義のリポジトリです。

Firefox、nginx、Python、Node.js、Gitなどのパッケージ定義に加え、NixOSの設定項目を提供するモジュールも含まれています。

Nixpkgsのソースは次のリポジトリで公開されています。

https://github.com/NixOS/nixpkgs

NixOSが再現可能といわれる理由

NixOSの代表的な特徴は、同じ設定から同じ構成を再現しやすいことです。

ただし、「どの環境でも完全に同一の結果が必ず得られる」という意味ではありません。CPUアーキテクチャ、外部データ、ビルド時の非決定性、秘密情報、ハードウェア差などは別途管理する必要があります。

NixOSが再現性を高められる主な理由は次のとおりです。

システム構成をコードとして記述する

パッケージやサービスの状態を設定ファイルへ記録できます。

{
  environment.systemPackages = with pkgs; [
    git
    curl
    vim
    ripgrep
  ];

  services.openssh.enable = true;
}

この設定をGitで管理すれば、変更履歴を確認し、別の端末へ移植できます。

パッケージを固有のパスへ保存する

Nixは、パッケージを通常の/usr/binや/usr/libへ直接上書きするのではなく、原則として/nix/store以下へ保存します。

概念的には次のようなパスになります。

/nix/store/ハッシュ-パッケージ名-バージョン

ハッシュには、パッケージの入力情報や依存関係が反映されます。

異なるバージョンや異なるビルド設定のパッケージを別のパスへ保存できるため、既存環境を上書きしにくい設計です。

世代を作成する

システム構成を更新すると、新しい世代が作成されます。

以前の構成をすぐに削除せず、過去の世代として保持できるため、問題が起きたときに戻しやすくなります。

入力リビジョンを固定できる

Flakesやロックファイルを使う構成では、利用するNixpkgsなどの入力リビジョンを固定できます。

これにより、同じ設定ファイルを後日評価したときに、参照先が意図せず変わる問題を減らせます。

宣言的なシステム管理とは

宣言的管理では、「どのコマンドをどの順番で実行するか」ではなく、「最終的にどのような状態にしたいか」を記述します。

Ubuntuなどでnginxを導入する場合、一般的には次のような操作を行います。

sudo apt update
sudo apt install nginx
sudo systemctl enable nginx
sudo systemctl start nginx
sudo ufw allow 80/tcp

NixOSでは、設定ファイルに最終状態を記述します。

{
  services.nginx.enable = true;
  networking.firewall.allowedTCPPorts = [ 80 ];
}

反映コマンドは次のとおりです。

sudo nixos-rebuild switch

宣言的管理には、次の利点があります。

現在の構成を設定ファイルから把握しやすい
Gitで差分を確認できる
コードレビューを行える
別端末へ構成を移植しやすい
手作業による設定漏れを減らしやすい
自動構築へ発展させやすい

一方、設定外で行った操作が永続的な構成として残らないことや、NixOSモジュールの書き方を理解する必要がある点には注意が必要です。

configuration.nixの基本

従来型のNixOS構成では、主に次のファイルを利用します。

/etc/nixos/configuration.nix
/etc/nixos/hardware-configuration.nix

configuration.nixには、ユーザーが管理するシステム設定を記述します。

hardware-configuration.nixには、インストール時に検出されたファイルシステム、デバイス、カーネルモジュールなどが記録されます。

基本的な例は次のとおりです。

{ config, pkgs, ... }:

{
  imports = [
    ./hardware-configuration.nix
  ];

  networking.hostName = "nixos-pc";

  time.timeZone = "Asia/Tokyo";

  i18n.defaultLocale = "ja_JP.UTF-8";

  users.users.example = {
    isNormalUser = true;
    extraGroups = [ "wheel" "networkmanager" ];
  };

  environment.systemPackages = with pkgs; [
    git
    curl
    vim
  ];

  services.openssh.enable = true;

  system.stateVersion = "26.05";
}

設定を検証し、一時的に起動する場合は次を使用できます。

sudo nixos-rebuild test

現在のシステムへ反映し、次回起動時の既定構成にもする場合は次を使います。

sudo nixos-rebuild switch

次回起動用の構成を作成するものの、現在の実行環境は切り替えない場合は次のとおりです。

sudo nixos-rebuild boot

具体例1：開発用パッケージをまとめて導入する

Git、Visual Studio Code、Node.js、Python、Dockerを利用する開発PCの一例です。

{ config, pkgs, ... }:

{
  environment.systemPackages = with pkgs; [
    git
    curl
    wget
    ripgrep
    jq
    nodejs
    python3
    vscode
  ];

  virtualisation.docker.enable = true;

  users.users.example = {
    isNormalUser = true;
    extraGroups = [
      "wheel"
      "networkmanager"
      "docker"
    ];
  };

  networking.networkmanager.enable = true;
}

設定後に反映します。

sudo nixos-rebuild switch

Dockerグループへの追加は、Dockerデーモンを実質的に管理できる強い権限をユーザーへ与えます。共有端末や厳格な権限管理が必要な環境では、rootless構成やPodmanなども比較してください。

具体例2：nginxを使ったWebサーバーを宣言する

nginxを有効にし、HTTPとHTTPSを許可する例です。

{ config, pkgs, ... }:

{
  services.nginx = {
    enable = true;

    virtualHosts."example.invalid" = {
      root = "/var/www/example";

      locations."/" = {
        tryFiles = "$uri $uri/ =404";
      };
    };
  };

  networking.firewall.allowedTCPPorts = [
    80
    443
  ];
}

example.invalidは説明用の予約ドメインです。実際の公開時には、自分が管理するドメインへ置き換えます。

TLS証明書を自動取得する場合は、ACME関連オプションも利用できます。

{
  security.acme = {
    acceptTerms = true;
    defaults.email = "admin@example.invalid";
  };

  services.nginx.virtualHosts."example.invalid" = {
    enableACME = true;
    forceSSL = true;
    root = "/var/www/example";
  };
}

実際に使用する際は、DNS、メールアドレス、ファイアウォール、公開ディレクトリの権限を確認してください。

具体例3：一時的な開発環境を作る

Nixは、OS全体へ永続的に追加せず、一時的な開発シェルを作る用途にも使えます。

Flakesを使わない簡単な例では、次のようなdefault.nixを用意します。

{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  packages = with pkgs; [
    nodejs
    git
    jq
  ];

  shellHook = ''
    echo "Node.js development environment"
    node --version
  '';
}

開発環境へ入ります。

nix-shell

シェルを終了すれば、そのプロジェクト用環境から離れられます。

プロジェクトごとにNode.jsやPythonなどのバージョンを分けたい場合に利用できます。

原子的な更新とロールバック

NixOSでは、新しい構成を作る際に、既存環境のファイルを直接上書きするのではなく、新しいシステム世代を生成します。

構成の切り替えは、完成した世代を単位として行われます。この性質から、更新途中で新旧ファイルが混在する問題を抑えやすくなります。

一時的に設定を試す

sudo nixos-rebuild test

testでは現在のシステムへ一時的に構成を適用しますが、通常はブートローダーの既定世代を変更しません。

再起動後に元へ戻る前提で設定を確認したい場合に便利です。

現在の構成へ切り替える

sudo nixos-rebuild switch

新しい構成を現在の環境へ反映し、起動時の既定世代にも設定します。

直前の世代へ戻す

sudo nixos-rebuild switch --rollback

起動不能などで現在のシステムから戻せない場合は、ブートローダーのメニューから以前のNixOS世代を選択できる構成があります。

利用できる方法はブートローダー設定によって異なるため、導入時に復旧手順を実機または仮想マシンで確認してください。

ロールバックで戻らないもの

NixOSのロールバックは強力ですが、システム上のすべてのデータを過去へ戻す機能ではありません。

通常、次のようなデータは別途保護が必要です。

データベースの内容
ユーザーのホームディレクトリ
/var以下のアプリケーションデータ
外部ストレージのデータ
Secretや認証情報
アプリケーションが変更した状態
ファイルシステム上で削除された一般ファイル

OS構成のロールバックと、データのバックアップやスナップショットは分けて設計します。

Flakesとは

Flakesは、Nixプロジェクトの入力と出力を一定の形式で定義し、依存するNixpkgsなどのリビジョンをロックファイルで固定する仕組みです。

主に次のファイルを使います。

flake.nix
flake.lock

簡略化したNixOS用Flakeの例は次のとおりです。

{
  description = "My NixOS configuration";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
  };

  outputs = { self, nixpkgs, ... }: {
    nixosConfigurations.my-pc = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";

      modules = [
        ./configuration.nix
      ];
    };
  };
}

この構成を反映する例です。

sudo nixos-rebuild switch --flake .#my-pc

flake.lockには、実際に参照したNixpkgsのリビジョンなどが記録されます。

これにより、ブランチ名だけを参照し続けるよりも、入力を固定しやすくなります。

Flakesは2026年時点でも実験的機能

2026年7月11日時点で、Flakesと新しいnixコマンドの一部は、Nixの仕組み上「experimental feature」として扱われています。

Nix公式マニュアルでは、実験的機能は変更または削除される可能性があり、明示的な有効化が必要と説明されています。

https://nix.dev/manual/nix/latest/development/experimental-features NixOSで有効化する設定例は次のとおりです。

{
  nix.settings.experimental-features = [
    "nix-command"
    "flakes"
  ];
}

Flakesは実務や個人構成で広く利用されていますが、正式な安定仕様として確定した機能と同じ扱いにはできません。

企業で採用する場合は、次を確認してください。

使用するNixバージョン
FlakeスキーマやCLIの変更影響
ロックファイルの更新手順
Flakesに依存しない代替手順
チーム内での互換性方針
関連ツールがFlakesを前提としているか

ChannelsとFlakesの違い

NixOSの構成入力を管理する代表的な方法として、ChannelsとFlakesがあります。

比較項目	Channels	Flakes
歴史	従来から利用されている	後から導入された
入力の固定	世代やチャンネル状態に依存	`flake.lock`で固定しやすい
プロジェクト構造	自由度が高い	入出力形式が一定
Gitとの相性	管理可能	ロックファイルを含め管理しやすい
実験的機能	基本機能として利用可能	2026年7月時点で実験的
情報量	古い手順を含めて多い	新しい構成例で多用される
初心者の混乱	Channels固有概念がある	Nix言語に加えてFlake概念が増える

新規構成でFlakesを採用する例は増えていますが、古い記事、公式マニュアル、既存環境にはChannelsを使う手順も残っています。

検索して見つけたコマンドを混在させると、入力元や更新方法が分からなくなるため、1つの構成では管理方式を明確に決めることが重要です。

system.stateVersionとは

NixOS設定には、次のような項目があります。

{
  system.stateVersion = "26.05";
}

この値は、現在インストールしているNixOSのバージョンを指定するための一般的なバージョン固定欄ではありません。

system.stateVersionは、過去のNixOSとの互換性に関係する既定値を維持するための設定です。

NixOSを新しいリリースへアップグレードしても、理由を確認せずに毎回この値を変更するべきではありません。

値を変更すると、データ保存場所、サービスの既定値、データベース形式などに影響する可能性があります。

変更前には、対象バージョンのリリースノートと、設定項目の説明を確認してください。

NixOSのオプションは、公式検索で確認できます。

https://search.nixos.org/options

NixOSのリリースとサポート方針

NixOSでは、通常、年2回の安定版リリースが行われています。

バージョン番号は、原則として年と月を表します。

26.05

これは2026年5月系列のリリースを意味します。

2026年7月11日時点の現行安定版はNixOS 26.05です。

公式発表では、NixOS 26.05は2026年12月31日までバグ修正とセキュリティ更新を受け取る予定です。

NixOS 25.11は2026年6月30日にサポート終了となっています。

確認先：

https://nixos.org/blog/announcements/2026/nixos-2605/

安定版

特定のNixpkgsブランチを基準に、一定期間のバグ修正とセキュリティ更新が提供されます。

デスクトップやサーバーの標準構成では、まず安定版を検討しやすいでしょう。

nixos-unstable

Nixpkgsの開発ブランチから、一定の評価やビルドを通過した状態が提供されます。

新しいパッケージを利用しやすい反面、安定版より変更頻度が高く、アップデート時の差分も大きくなりやすい特徴があります。

unstableは、すべてのパッケージが常に壊れているという意味ではありませんが、長期間固定される安定版と同じ保守方針ではありません。

長期サポートを前提にしない

NixOSのコミュニティ版安定リリースは、Ubuntu LTSやRHEL系の長期サポートと比べると短い更新周期です。

本番サーバーへ導入する場合は、半年程度の間隔で新しい系列へのアップグレードを検証する運用が必要になります。

複数年にわたり同じメジャー系列を維持したい場合は、Ubuntu LTS、Debian、RHEL、Rocky Linux、AlmaLinuxなども比較してください。

NixOSのメリット

複数端末の構成を統一しやすい

ノートPC、デスクトップ、検証機などで共通モジュールを利用できます。

nixos-config/
├── flake.nix
├── flake.lock
├── hosts/
│   ├── laptop/
│   │   └── configuration.nix
│   └── desktop/
│       └── configuration.nix
└── modules/
    ├── common.nix
    ├── development.nix
    └── desktop.nix

共通設定と端末固有設定を分けることで、同じツールやセキュリティ方針を複数端末へ適用できます。

設定変更をレビューできる

NixOS設定をGitで管理すれば、変更内容をPull Requestとしてレビューできます。

たとえば、SSHの設定変更、ポート開放、ユーザー追加、パッケージ更新を差分として確認できます。

依存関係の衝突を減らしやすい

パッケージを/nix/store上の個別パスへ配置するため、異なるバージョンを共存させやすい設計です。

従来のパッケージ管理で起こりやすい、共有ライブラリの上書きによる影響を抑えられます。

更新失敗から戻しやすい

世代単位でシステム構成を保持するため、設定変更後に問題が発生したとき、以前の構成へ戻しやすくなります。

ただし、データベースやユーザーデータは別途バックアップが必要です。

開発環境をプロジェクト単位で管理できる

OS全体のパッケージと、プロジェクト固有の開発ツールを分けられます。

Node.js、Python、Go、Rustなどの開発ツールをプロジェクトごとに指定しやすくなります。

同じ仕組みをLinuxとmacOSへ広げられる

NixパッケージマネージャーはNixOS以外のLinuxやmacOSでも利用できます。

macOSのシステム設定管理には、コミュニティプロジェクトのnix-darwinが利用されることがあります。

ユーザー環境の管理にはHome Managerも広く利用されています。

ただし、NixOS、Home Manager、nix-darwinは別プロジェクト・別レイヤーです。導入範囲を明確にしてください。

NixOSのデメリット

学習コストが高い

NixOSでは、一般的なLinux知識に加えて、次の概念を理解する必要があります。

Nix言語
Nix式の評価
derivation
Nix store
profile
generation
Nixpkgs
NixOSモジュール
Channels
Flakes
overlays
fixed-output derivation
garbage collection

最初からすべてを理解する必要はありませんが、エラー発生時には複数レイヤーを切り分ける必要があります。

検索結果の世代差が大きい

NixOSでは、古いChannels中心の手順、新しいFlakes中心の手順、Home Managerを組み合わせた手順が混在しています。

同じ目的でも複数の実現方法があります。

nix-env
nix profile
environment.systemPackages
home.packages
nix-shell
nix develop

これらを理解せずに混在させると、どの設定がパッケージを導入しているのか分からなくなります。

一般的なLinuxのファイル配置と異なる

実行ファイルや共有ライブラリは/nix/storeへ保存されます。

/usr/binや/usr/libにファイルがあることを前提とするソフトウェア、インストーラー、シェルスクリプトは動かない場合があります。

たとえば、次のような固定パスを前提とするプログラムは調整が必要です。

/usr/bin/python
/usr/local/bin/node
/usr/lib/libexample.so

配布済みバイナリの実行に調整が必要な場合がある

一般的なLinux向けに配布されたバイナリは、FHS準拠のパスや標準的な動的リンカー位置を前提としている場合があります。

NixOS上では、次の対応が必要になることがあります。

Nixpkgsのパッケージを使う
autoPatchelfHookで調整する
FHS互換環境を用意する
コンテナ内で実行する
upstreamからソースビルドする
steam-runなど用途別の互換環境を使う

ベンダーがNixOSを正式サポートしていない場合、問題発生時のサポート対象外になる可能性があります。

ディスク使用量が増えやすい

複数世代や複数バージョンを保持できることは利点ですが、古いパッケージやビルド成果物が残るため、/nix/storeが大きくなることがあります。

不要な世代や到達不能なストアパスを削除するには、ガベージコレクションを使用します。

sudo nix-collect-garbage

古い世代も削除する例です。

sudo nix-collect-garbage -d

-dを付けるとロールバックに使える過去世代も削除されるため、実行前に復旧要件を確認してください。

リリース更新の頻度が高い

安定版でもサポート期間は長期固定ではありません。

本番利用では、新系列のリリースごとに設定、サービス、データ形式、廃止オプションを検証する必要があります。

NixOSが向く用途

開発者のワークステーション

複数の開発ツールや言語環境を管理し、設定をGitで保存したい人に向きます。

OS再インストール後も、設定リポジトリから環境を再構築しやすくなります。

複数PCの構成管理

自宅PC、ノートPC、作業用端末などの設定を共通化したい場合に適しています。

共通モジュールと端末固有モジュールを分ける設計が可能です。

検証環境

設定変更を世代として残し、問題があれば以前の構成へ戻せます。

新しいデスクトップ環境、カーネル、サービス設定などを試す環境と相性があります。

宣言的に管理するサーバー

Webサーバー、VPN、監視サーバー、CIランナーなど、構成をコードレビューしたい用途に利用できます。

ただし、短い安定版サポート期間に合わせた更新体制が必要です。

再現可能な開発シェル

プロジェクトごとにコンパイラやツールを定義できます。

NixOSを採用せず、既存のUbuntuやmacOSへNixだけ導入する方法もあります。

NixOSを避けた方がよい条件

次の条件では、Ubuntu、Debian、Fedora、Arch Linuxなども比較してください。

Linux初心者が短期間で日常用PCを完成させたい
一般的なLinux向け手順をそのまま実行したい
ベンダーの正式サポート対象OSが必要
/usr/localへ直接インストールする製品を多用する
商用エージェントや独自バイナリが多い
半年ごとのアップグレード検証が難しい
Nix言語を学ぶ担当者を確保できない
障害時に一般的なLinux技術者へすぐ引き継ぐ必要がある
複数年の長期サポートを最優先する
宣言的構成やロールバックに大きな価値を感じない
ディスク容量が厳しく、世代管理やストア運用が負担になる

NixOSの強みを必要としない環境では、一般的なディストリビューションを利用する方が簡単です。

他のLinuxディストリビューションとの比較

比較項目	NixOS	Ubuntu LTS	Arch Linux	Fedora
系統	独立系	Debian系	独立系	Red Hat系
パッケージ管理	Nix	APT	pacman	DNF
システム設定	宣言的管理が中心	手動設定と自動化ツール	手動設定中心	手動設定と自動化ツール
更新方式	安定版、unstable	固定リリース	ローリング	固定リリース
ロールバック	世代管理を標準利用可能	標準では限定的	標準では限定的	標準では限定的
複数バージョン共存	得意	通常は工夫が必要	通常は工夫が必要	通常は工夫が必要
一般的なLinuxとの互換性	パス構造に注意	高い	高い	高い
学習情報	独自概念が多い	非常に多い	多い	多い
導入難度	高め	低〜中	中〜高	中
長期サポート	短め	LTSあり	ローリング	比較的短い
向く人	再現性と構成管理を重視	汎用性とサポート重視	最新環境と手動構築を重視	新技術と標準Linux環境を重視

NixOSとArch Linuxの違い

NixOSとArch Linuxは、どちらも利用者が構成を選びやすいディストリビューションですが、設計思想は大きく異なります。

Arch Linuxは、パッケージを通常のファイルシステムへ配置し、利用者が設定ファイルを直接編集する運用が中心です。

NixOSは、システム状態をNix設定として宣言し、生成された世代へ切り替えます。

判断軸	NixOS	Arch Linux
環境再現	設定コードで管理しやすい	構築手順を別途記録する必要がある
パッケージの新しさ	unstableで新しくできる	ローリングで新しい
ロールバック	標準設計に含まれる	スナップショットなどを別途設計
学習対象	Nix独自概念	一般的なLinux構成
ファイル配置	`/nix/store`中心	一般的なFHS構成
トラブル情報	Nix固有情報が必要	ArchWikiが充実

一般的なLinuxの内部構成を手作業で学びたいならArch Linux、構成をコード化して再現したいならNixOSが候補になります。

NixOSとUbuntuの違い

Ubuntuは、導入のしやすさ、ハードウェア対応、ベンダーサポート、情報量に強みがあります。

NixOSは、宣言的構成、世代管理、依存関係の分離に強みがあります。

企業PCや一般ユーザー向けPCではUbuntuが導入しやすい一方、開発者自身が環境をコード管理する場合はNixOSが魅力的です。

NixOSの仕組みだけを試したい場合は、UbuntuへNixパッケージマネージャーを導入する方法もあります。

OS全体を移行する前に、既存OS上でNixによる開発環境管理を検証すると、移行リスクを抑えられます。

用途別の選定表

用途	NixOSの適性	判断理由
個人開発PC	高い	設定と開発ツールをGit管理しやすい
複数の開発端末	高い	共通モジュールで構成を統一できる
検証用仮想マシン	高い	再構築とロールバックを試しやすい
小規模Webサーバー	中〜高	宣言的に管理できるが更新体制が必要
大規模企業サーバー	要検討	人材、サポート、更新周期を評価する必要がある
一般家庭用PC	中	構築後は使えるが初期学習が必要
Linux初心者用PC	低〜中	一般的な入門情報との差が大きい
商用アプリ中心のPC	低〜中	ベンダー対応とバイナリ互換性を確認
ゲームPC	中	Steamなどは利用できるが個別調整が発生し得る
GPU・機械学習	中	再現性は有利だがドライバーとCUDAの検証が必要
長期固定サーバー	低〜中	半年単位のアップグレード計画が必要
再現可能なCI環境	高い	入力固定と開発環境定義を活用できる

Home Managerとは

Home Managerは、ユーザー単位のパッケージや設定ファイルをNixで管理するコミュニティプロジェクトです。

例として、Git、シェル、エディター、ユーザー用パッケージなどを管理できます。

{
  home.username = "example";
  home.homeDirectory = "/home/example";

  home.packages = with pkgs; [
    ripgrep
    jq
    fd
  ];

  programs.git = {
    enable = true;
    userName = "Example User";
    userEmail = "user@example.invalid";
  };

  programs.bash.enable = true;

  home.stateVersion = "26.05";
}

Home ManagerはNixOS本体の標準機能そのものではありません。

NixOSモジュールとして統合する方法と、ユーザー単位で独立して利用する方法があります。

導入すると管理範囲が広がる反面、NixOS本体、Flakes、Home Managerの更新互換性を確認する必要があります。

公式リポジトリ：

https://github.com/nix-community/home-manager

セキュリティ運用で確認すること

NixOSも、導入しただけで安全になるわけではありません。

サポート中の系列を利用する

安定版のサポート期限を確認し、期限前に次の系列へ移行します。

2026年7月11日時点では、NixOS 26.05が現行安定版で、公式サポート期限は2026年12月31日です。

入力リビジョンを更新する

Flakesで入力を固定すると再現性は高まりますが、固定しただけではセキュリティ更新を取得できません。

ロックファイルを定期的に更新し、変更後のシステムを再ビルドする必要があります。

nix flake update
sudo nixos-rebuild switch --flake .#my-host

更新前には差分確認、テスト、ロールバック手順の確認を行います。

SecretをNix storeへ平文で保存しない

Nix式へ直接書いた文字列や、ビルド入力として扱ったファイルは、/nix/storeへ保存される可能性があります。

Nix storeは、ローカルユーザーから読み取り可能な構成になることがあります。

次の情報を設定へ直接書かないようにします。

APIキー
データベースパスワード
秘密鍵
アクセストークン
Cookie署名鍵
バックアップ暗号化鍵

Secret管理には、sops-nixやagenixなどのコミュニティツールが利用されることがあります。ただし、ツールの脅威モデル、鍵管理、復旧方法を確認して採用してください。

sops-nix：

https://github.com/Mic92/sops-nix agenix：

https://github.com/ryantm/agenix

設定ファイルだけをバックアップ対象にしない

設定コードからOS構成を再現できても、アプリケーションデータは戻りません。

次を別途バックアップします。

データベース
ユーザーデータ
Secretの復号鍵
ホームディレクトリ
アップロードファイル
外部サービスの設定
復旧に必要なFlake入力やGitリポジトリ

導入前に試す方法

いきなりメインPCへ導入するより、仮想マシンで試す方が安全です。

確認項目は次のとおりです。

インストーラーを起動できるか
ネットワークへ接続できるか
configuration.nixを編集できるか
nixos-rebuild testとswitchの違いを確認できるか
設定エラーを修正できるか
過去世代へロールバックできるか
Flakesを使うかChannelsを使うか決められるか
不要な世代を整理できるか
必要なアプリケーションが動作するか
バックアップから復旧できるか

物理PCへ導入する場合は、Wi-Fi、GPU、Bluetooth、音声、サスペンド、外部ディスプレイなども確認します。

NixOS導入時の学習順序

NixOSは、最初から複雑なFlake構成を作ると理解しにくくなります。

次の順番で学ぶと整理しやすくなります。

1. configuration.nixを理解する

パッケージ追加、ユーザー作成、サービス有効化を試します。

2. nixos-rebuildを理解する

test、boot、switch、buildの違いを確認します。

3. 世代とロールバックを試す

意図的に小さな設定変更を行い、以前の世代へ戻します。

4. Nix言語の基本を学ぶ

属性セット、リスト、関数、let、with、inherit、モジュール引数を理解します。

5. Nixpkgsとオプション検索を使う

パッケージ検索：

https://search.nixos.org/packages オプション検索：

https://search.nixos.org/options

6. 構成を複数ファイルへ分割する

デスクトップ、開発ツール、ユーザー、サービスなどをモジュール化します。

7. Flakesを検討する

入力固定と複数ホスト管理が必要になってから導入すると、目的を理解しやすくなります。

8. Home ManagerやSecret管理を追加する

OS構成を安定して管理できるようになってから、ユーザー設定や秘密情報管理へ範囲を広げます。

本番サーバーでの選定チェックリスト

技術面

必要なソフトウェアがNixpkgsにあるか
独自バイナリがNixOS上で動作するか
systemdサービスとして定義できるか
データ保存先を明確にできるか
SecretをNix storeへ保存せず管理できるか
ロールバック時のデータ互換性を確認できるか
バックアップと復旧手順があるか

運用面

約半年ごとのリリース更新を検証できるか
NixOSを理解する担当者が複数いるか
設定変更をコードレビューできるか
Flake入力やChannelsの更新責任者がいるか
監視、ログ、障害対応手順を用意できるか
利用サービスの正式サポート対象に含まれるか

組織面

特定担当者だけが理解する状態にならないか
採用・引き継ぎコストを許容できるか
UbuntuやRHEL系よりNixOSを選ぶ明確な理由があるか
再現性やロールバックが実際の課題解決につながるか

NixOSの選び方

NixOSを選ぶべきかは、単に「再現可能で便利そう」という印象ではなく、次の順番で判断します。

1. 再現したい対象を決める

OS全体、開発環境、ユーザー設定、サーバー構成のどこまでを管理したいか整理します。

開発環境だけでよければ、既存OSへNixを導入する方法でも目的を達成できる場合があります。

2. 必要なソフトウェアの互換性を確認する

Nixpkgsにパッケージがあるか、公式バイナリが動くか、ベンダーサポートを受けられるか確認します。

3. 更新周期を受け入れられるか確認する

安定版のサポート期間に合わせて、継続的にアップグレードできる体制が必要です。

4. 学習コストを評価する

NixOSは、構築後の再現性を高める代わりに、初期学習と問題解決のコストが増えます。

1台だけの端末で構成変更も少ない場合、学習コストを回収できない可能性があります。

5. 仮想マシンでロールバックまで試す

インストールできることだけでなく、設定エラー、世代管理、復旧まで確認します。

結論

NixOSは、Linuxのパッケージやサービス、ユーザー、ネットワーク設定を宣言的なコードとして管理し、同じ構成を再構築したい人に適したディストリビューションです。

特に、次の用途では大きな利点があります。

開発PCの設定をGitで管理する
複数端末へ共通構成を展開する
サーバー変更をコードレビューする
プロジェクトごとに開発環境を分離する
更新後に以前のシステム世代へ戻す
環境構築手順を手作業から宣言へ置き換える

一方、Nix言語、Nixpkgs、NixOSモジュール、世代、Flakesなど、一般的なLinuxとは異なる概念を学ぶ必要があります。

また、NixOSの安定版は長期固定型ではありません。2026年7月11日時点の現行安定版NixOS 26.05も、公式サポート期限は2026年12月31日です。本番運用では、約半年単位でアップグレードを検証する体制が求められます。

NixOSを選ぶ前には、次の4点を確認してください。

再現可能にしたい対象が明確か
必要なソフトウェアがNixOS上で動作するか
安定版の更新周期へ対応できるか
独自概念の学習と引き継ぎに必要な時間を確保できるか

これらを満たし、環境の再現性や構成レビューに価値があるなら、NixOSは非常に強力な選択肢です。

反対に、一般的なLinux手順との互換性、ベンダーサポート、長期保守、担当者確保を優先する場合は、Ubuntu LTSやDebianなどを選ぶ方が運用しやすい可能性があります。

参考リンク

NixOS公式サイト https://nixos.org/
NixOSダウンロード https://nixos.org/download/
NixOS 26.05リリース発表 https://nixos.org/blog/announcements/2026/nixos-2605/
NixOS Manual https://nixos.org/manual/nixos/stable/
NixOS Release Notes https://nixos.org/manual/nixos/stable/release-notes
Nix Reference Manual https://nix.dev/manual/nix/latest/
Nix Experimental Features https://nix.dev/manual/nix/latest/development/experimental-features
Nixpkgs Manual https://nixos.org/manual/nixpkgs/stable/
NixOS Packages Search https://search.nixos.org/packages
NixOS Options Search https://search.nixos.org/options
NixOS公式Wiki https://wiki.nixos.org/
Flakes - NixOS Wiki https://wiki.nixos.org/wiki/Flakes
nixos-rebuild - NixOS Wiki https://wiki.nixos.org/wiki/Nixos-rebuild
NixOS/nixpkgs https://github.com/NixOS/nixpkgs
Home Manager https://github.com/nix-community/home-manager
sops-nix https://github.com/Mic92/sops-nix
agenix https://github.com/ryantm/agenix

2026年7月の調査追補

NixOSは、パッケージ、サービス、ユーザー、ネットワーク、ブート構成をNix言語で宣言し、OS全体を構成する独立系Linuxです。

2026年7月22日時点の現行安定版はNixOS 26.05で、2026年12月31日までバグ修正とセキュリティ更新を受けます。長期固定型LTSではなく、半年単位で新系列へ追従する運用が必要です。

基本情報

項目	内容
名称	NixOS
系統	独立系
主な用途	開発PC、複数端末、宣言的サーバー、検証環境
パッケージ管理	Nix
パッケージ集合	Nixpkgs
init	systemd
現行安定版	NixOS 26.05
サポート終了	2026-12-31
状態	現役
公式サイト	https://nixos.org/
確認日	2026-07-22

先に結論

環境をGitで管理し、複数PCやサーバーへ同じ構成を展開し、更新後に世代単位で戻したい人には強力です。

一般的なLinux手順をそのまま使いたい人、ベンダー製バイナリを多用する人、半年ごとのアップグレード検証が難しい組織にはUbuntu LTSやDebian stableが扱いやすい場合があります。

宣言的構成

一般的なLinuxでは、パッケージ導入と設定変更を順番に行います。NixOSでは最終状態を設定へ記述します。

{
  services.openssh.enable = true;
  services.nginx.enable = true;
  networking.firewall.allowedTCPPorts = [ 80 443 ];
}

sudo nixos-rebuild switch

設定をGit管理すれば、変更差分をレビューできます。

Nix storeと世代

パッケージは/nix/storeへ固有パスで保存されます。異なるバージョンや構成を共存させやすく、更新時に新しいシステム世代を作ります。

sudo nixos-rebuild test
sudo nixos-rebuild switch
sudo nixos-rebuild switch --rollback

ロールバックはOS構成を戻しますが、データベース、ホーム、/varのアプリデータを戻すものではありません。

Flakes

Flakesは入力と出力を標準化し、flake.lockでNixpkgsのリビジョンを固定します。

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
}

2026年時点でもFlakesと一部新CLIはexperimental featureとして扱われます。実務採用時はNixバージョンと更新方針を固定します。

system.stateVersion

system.stateVersionは現在のNixOS版を示す一般的な更新番号ではありません。過去の既定値との互換性を維持する設定です。

メジャーアップグレードのたびに理由なく変更しないでください。

インストール

グラフィカルISOまたは最小ISOから導入します。

UEFI / BIOS
パーティション
暗号化
ネットワーク
hardware-configuration.nix
configuration.nix
ブートローダー
デスクトップ
復旧世代

最初は仮想環境でtest、switch、ロールバックまで試します。

バイナリ互換性

NixOSは一般的なFHSのパス構成と異なります。/usr/binや標準的な動的リンカー位置を前提にした配布バイナリは調整が必要です。

選択肢:

Nixpkgsのパッケージ
autoPatchelfHook
FHS互換環境
コンテナ
upstreamからビルド

ベンダーの正式サポート対象か確認します。

Secret管理

Nix式へ秘密情報を直接書くと、/nix/storeへ平文で保存される可能性があります。

APIキー
秘密鍵
DBパスワード
トークン

sops-nixやagenixなどを使う場合も、鍵のバックアップと復旧方法を設計します。

更新と復旧

安定版でも約半年ごとに次系列へ移ります。

更新前:

Release Notes
Git差分
Flake入力更新
nixos-rebuild test
以前の起動世代
データバックアップ
Secret復号鍵

不要世代の削除はロールバック可能性を失うため、確認して実行します。

Arch LinuxやUbuntuとの比較

観点	NixOS	Arch Linux	Ubuntu LTS
構成	宣言的	手動設定	手動＋管理ツール
更新	半年安定版 / unstable	ローリング	2年ごとLTS
ロールバック	世代管理	自前設計	標準では限定
一般バイナリ	調整が必要	高い	高い
学習	Nix独自概念	一般Linux構成	情報量が多い

選ぶべき人

NixOSは、再現したい対象が明確で、Nix言語と短いリリース周期を学習・運用できる人に向きます。開発環境だけが目的なら、既存OSへNixを導入する方法も先に検証してください。

公式情報

正本DBの基本情報と参照元

NixOSについて、正本DBに保存された値と、その値に紐づく参照URLをまとめます。この表示は項目のevidence methodを「公式直接確認済み」とするものではありません。版や配布物で変わる項目は、導入前に参照元で対象を照合してください。

項目	DB登録内容
標準デスクトップ候補（DB登録値・根拠未確定）	任意（GNOME、KDE Plasma等を宣言的に選択）
ドキュメント候補（DB登録値・根拠未確定）	https://nixos.org/manual/nixos/stable/
ダウンロード候補（DB登録値・根拠未確定）	https://nixos.org/download/
公式URL候補（DB登録値・公式性未確認）	https://nixos.org/
パッケージ形式候補（DB登録値・根拠未確定）	Nix derivation / NARバイナリキャッシュ
ソースコード候補（DB登録値・根拠未確定）	https://github.com/NixOS/nixpkgs

参照元とDB記録日

ソースコード候補（DB登録値・根拠未確定）の参照元（DB記録日: 2026-07-16）

選ぶ前に確認すること

この表にない仕様は推測で補っていません。用途、対応アーキテクチャ、配布物、サポート状況を参照元で照合してから判断してください。