Nixpkgsとは？Nixとの関係・パッケージの探し方とinstall・flake.nixでの使い方

Nixpkgsは、パッケージマネージャ「Nix」で使うパッケージ定義を集めたリポジトリです。GitHubの NixOS/nixpkgs で開発されており、Linux ディストリビューション NixOS もここから組み立てられます。この記事では2026年10月時点のNix 2.35系とNixOS 26.05を前提に、Nix・NixOSとの違い、パッケージの探し方と入れ方、flake.nixでのコミット固定、対応プラットフォームを順に整理します。後半では、Nixpkgsの関数 symlinkJoin と wrapProgram の使用例として、Bashのテストツール Bats に拡張ライブラリを組み込む手順を示します。Batsのテストは実際に実行し、Nix式は構文解析で確かめたコードです。

まとめ：Nixpkgsの要点

• Nixpkgsとは：Nix言語で書かれたパッケージ定義（レシピ）の集まり。GitHubのREADMEは「140,000を超えるパッケージ」と説明している。NixOSの設定モジュールも同じリポジトリに入っている。
• Nix・NixOSとの違い：Nixはレシピを評価してビルドするツール、Nixpkgsはレシピ集、NixOSはNixpkgsで組み立てるLinuxディストリビューション。NixとNixpkgsだけならmacOSや既存のLinuxでも使える。
• 探し方と入れ方：search.nixos.org か nix search nixpkgs 名前 で属性名を確かめ、試すだけなら nix shell、常用するなら nix profile add（Nix 2.30で nix profile install から改名）。
• 固定の仕方：プロジェクトの開発環境は flake.nix に書き、使うコミットを flake.lock に記録する。<nixpkgs> を参照する shell.nix はマシンごとに中身が変わる。
• Intel Macの注意：Nixpkgs 26.05 が x86_64-darwin をサポートする最後の版で、2026年11月末に予定されている26.11からはこのプラットフォーム向けのパッケージがビルドされない。

Nixpkgsとは：Nix・NixOSとの関係

名前が似ているため混同されやすいのですが、3つは役割がはっきり分かれています。

版は nixos.org/download の「Current version」の表示です（2026年10月25日時点。GitHubには10月22日付けで2.35.4のタグも作られています）。

Nixpkgsの中身は、ソフトウェアごとに「どのソースを取ってきて、何に依存し、どうビルドするか」を書いたNix式のファイルです。Nixはこれを評価して、ビルド手順（derivation）に変換し、実行します。つまりNixpkgsは実行ファイルの置き場ではなく、レシピの置き場です。

ドキュメントやコードで見かける pkgs は、Nixpkgsを読み込んだ結果の属性セット（パッケージの一覧）に慣例で付ける名前です。pkgs.ripgrep と書けば、Nixpkgsに入っている ripgrep のパッケージを指します。

収録数は数え方で変わります。各リポジトリの収録状況を集計している Repology では、nixpkgs-unstable がパッケージ149,275件、ソフトウェア単位（プロジェクト）で119,197件でした（2026年10月25日時点）。公式のパッケージ検索の画面表示は「140 000 packages」です。

Nixpkgsの仕組み：/nix/storeとブランチ

/nix/storeとハッシュ付きのパス

Nixがビルドしたものは、すべて /nix/store/<ハッシュ>-ripgrep-<バージョン> のような読み取り専用のディレクトリに入ります。通常のパッケージでは、ハッシュはソースや依存パッケージ、ビルド手順といった入力から計算されるため、入力が1つでも違えば別のパスになります（ソースのダウンロードのように、出力の中身のハッシュで決まる固定出力derivationは例外です）。同じソフトの別バージョンが衝突せずに共存でき、前の状態へ戻す（ロールバックする）のも、参照先を切り替えるだけで済みます。

実際には毎回ソースからビルドするわけではありません。公式のビルドサーバー Hydra がビルドした結果が cache.nixos.org にあり、同じハッシュのものがあればそれをダウンロードします。

ブランチとチャネル

Nixpkgsは master ブランチで開発され、ビルドとテストを通過したコミットだけが利用者向けのブランチ（チャネル）に進みます。安定版は毎年5月と11月に切られ、2026年10月時点の最新は26.05です。次の26.11は、リリース計画で2026年11月末の公開が予定されています。

安定版には、主にセキュリティ修正とバグ修正だけが入ります。nixos- と nixpkgs- の違いは、ブランチを進める前に通すテストの範囲です。

Nixpkgsの対応プラットフォーム：Tierと26.11でのIntel Mac終了

Nixpkgsのマニュアルは、プラットフォームごとのサポートを7段階のTierで定めています。Tier 1はこのプラットフォームでの問題がチャネル更新を止める条件になり得て、ほとんどのパッケージが動く前提です。Tier 2は更新後も動く状態が保たれ、多くのパッケージがHydraでビルドされます。Tier 3は修正が入ることはあっても、更新でビルドが壊れる可能性があります。

Intel Macを使っている場合は、次の打ち切りを前提に計画します。Nixpkgs 26.05のリリースノートは、26.05を「x86_64-darwinをサポートする最後のリリース」とし、26.05のサポートが切れる2026年末まではビルドを続け、26.11ではこのプラットフォーム向けのパッケージをビルドせず、ソースからのビルドもサポートしないと書いています。26.05では警告が表示され、Nixpkgsの設定 allowDeprecatedx86_64Darwin = true で消せます。

実務上の判断は2つです。Intel Macで flake.nix を書いているなら、nixpkgs-26.05-darwin か nixos-26.05 に固定したまま2026年末までに移行先（Apple Silicon機、Linux機、Homebrewなど）を決めます。チームの flake.nix に x86_64-darwin を含めているなら、26.11へ上げるときに system の一覧からx86_64-darwinを外します。

Nixpkgsの中身：pkgs/by-nameのレシピとビルド関数

pkgs/by-nameのディレクトリ構成

新しいパッケージの多くは pkgs/by-name/<先頭2文字>/<属性名>/package.nix に置かれています。by-nameのREADMEによると、先頭2文字は属性名を小文字にした頭の2文字で、ここに置いたパッケージは all-packages.nix に書き足さなくても pkgs.<属性名> として自動で読み込まれます。たとえば bats の定義は pkgs/by-name/ba/bats/package.nix です。search.nixos.org の検索結果からも、GitHub上の定義ファイルへのリンクをたどれます。パッケージがどう組み立てられているかを知りたいときは、このファイルを読むのが早道です。

stdenv.mkDerivationとビルドヘルパー

package.nix の多くは、Nixpkgsの関数 stdenv.mkDerivation を呼んでいます。stdenv にはCコンパイラ（Linuxでは通常GCC、macOSではClang）・make・coreutilsなどの基本的なビルド環境が入っていて、./configure・make・make install で入るソフトなら、ほとんど設定を書かずにビルドできます。ソースの取得には fetchFromGitHub や fetchurl を使い、ダウンロードする中身のハッシュを hash に書きます。ハッシュが合わなければビルドは失敗します。

言語ごとのビルド関数もあります。Goなら buildGoModule、Rustなら rustPlatform.buildRustPackage、Pythonなら python3Packages.buildPythonApplication、コンテナイメージなら dockerTools.buildImage です。開発用シェルを作る mkShell や、後で使う symlinkJoin もNixpkgsが提供する関数です。これらの引数は Nixpkgs Reference Manual にまとまっています。

Nixpkgsのパッケージ検索とインストール

Nixのインストールと実験的機能の有効化

公式サイト nixos.org/download が案内しているコマンドは次のとおりです。Linuxでは、systemdが動いていてSELinuxが無効、かつsudoが使える環境ならマルチユーザーのインストールが推奨されています。macOS（14.0以降が必要）は --daemon を付けずに同じスクリプトを実行し、この場合もマルチユーザーのインストールになります。

curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install | sh -s -- --daemon

nix search、nix shell、flake.nix などの新しいコマンドは、Nix 2.35でも実験的機能の扱いです。使う前に ~/.config/nix/nix.conf へ次の1行を書いておきます。

experimental-features = nix-command flakes

パッケージ検索と属性名の確認

パッケージ名（属性名）は、ソフトの名前と一致しないことがあります。まず search.nixos.org か、次のコマンドで確認します。

nix search nixpkgs ripgrep

結果に出る legacyPackages.x86_64-linux.ripgrep の末尾（ripgrep）が、以降のコマンドで指定する属性名です。search.nixos.org では、画面上部の Channels でブランチを選べます。公開されたばかりのソフトは、unstable を選ばないと見つからないことがあります。Platforms 欄に自分の system 名（Apple Silicon Macなら aarch64-darwin）があるかも確認します。

一時利用と常用のコマンド

用途によってコマンドを使い分けます。

nix profile add は、Nix 2.30のリリースノートで nix profile install から改名されました。install も別名として残っているので、古い記事の手順もそのまま動きます。

従来の nix-env を使う場合は、-A（--attr）で属性名を指定します。Nixのマニュアルは、-A を付けたほうがパッケージ名で照合するより速く、指す対象も曖昧にならないと説明しています。-A なしの nix-env -i ripgrep は、同じ名前を持つパッケージ全体から候補を探すためです。

shell.nix・flake.nixによる開発環境の定義

shell.nixとmkShellによる開発用シェルの定義

プロジェクトの直下に次の shell.nix を置いて nix-shell を実行すると、指定したパッケージが入ったシェルに入れます。mkShell は開発用シェルを作るためのNixpkgsの関数です。

{ pkgs ? import <nixpkgs> { } }:
pkgs.mkShell {
  packages = [
    pkgs.jq
    pkgs.shellcheck
  ];
}

ただし <nixpkgs> は NIX_PATH などの検索パスから解決され、通常はそのマシンに登録されたチャネルを指します。チャネルを更新した時期が違えば、同じ shell.nix でも入るバージョンが変わります。チームで同じ環境を共有したいなら、次の flake.nix で固定します。

flake.nixとflake.lockによるコミット固定

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

  outputs = { self, nixpkgs }:
    let
      forAllSystems = nixpkgs.lib.genAttrs [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
    in
    {
      devShells = forAllSystems (system:
        let pkgs = nixpkgs.legacyPackages.${system};
        in {
          default = pkgs.mkShell {
            packages = [ pkgs.jq pkgs.shellcheck ];
          };
        });
    };
}

nix develop を初めて実行すると、その時点の nixos-26.05 ブランチのコミットが flake.lock に記録されます。flake.nix と flake.lock を一緒にGitへコミットすれば、誰がいつ実行しても同じコミットのNixpkgsが使われます。更新したいときは nix flake update で flake.lock を書き換えます。system の一覧に入れている x86_64-darwin は、前章のとおり26.11へ上げるときに外します。

URLへコミットを直接書いて固定することもできます。この場合も通常は flake.lock が作られるので、flake.nix と一緒に共有します。Nixのマニュアルは、github:NixOS/nixpkgs/<40桁のコミットハッシュ> を「特定のリビジョン」の書き方として載せています。不具合の再現やバグ報告で、ある時点のNixpkgsを指したいときに使います。

inputs.nixpkgs.url = "github:NixOS/nixpkgs/da6dc0e7b26060f2f71ce3ef7088fb56ee44fa36";

この例のハッシュは、2026年10月22日（UTC）に nixos-26.05 チャネルのリリース（nixos-26.05.12400）として公開されたコミットです。flakeは、Gitで管理されているディレクトリではGitに追跡されているファイルしか見えません。flake.nix を作った直後に「Path ‘flake.nix’ in the repository … is not tracked by Git.」と表示されたら、先に git add flake.nix を実行します。ディレクトリに入るだけで nix develop の環境を読み込ませたい場合は、direnv と nix-direnv を組み合わせ、.envrc に use flake と書きます。

symlinkJoin・wrapProgramの使用例：Batsへの拡張ライブラリ組み込み

ここでは、前述のビルド関数のうち symlinkJoin（複数のパッケージを1つのディレクトリにまとめる）と wrapProgram（実行ファイルを、環境変数を設定するラッパーに置き換える）が実際にどう使われているかを、Bashのテストツール Bats で見ます。

Bats（bats-core） は、シェルスクリプトを @test ブロックで検証するテストフレームワークです。アサーション用の bats-assert などは別リポジトリの拡張ライブラリになっていて、Batsは bats_load_library でそれらを読み込むときに環境変数 BATS_LIB_PATH を探します。

bats.withLibrariesの実装とライブラリ検索パス

Nixpkgsの bats パッケージ（pkgs/by-name/ba/bats/package.nix）には、拡張ライブラリを同梱した bats を作る withLibraries が定義されています。2026年10月25日時点で、収録されている Bats は nixos-26.05 が1.12.0、nixos-unstable が1.14.0 です（ライブラリは同じディレクトリの libraries.nix で、bats-assert が26.05は2.1.0・unstableは2.2.4、bats-support はどちらも0.3.0）。該当部分（masterの定義から meta の行を省略）は次のとおりです。

passthru.withLibraries =
  selector:
  symlinkJoin {
    name = "bats-with-libraries-${bats.version}";

    paths = [
      bats
    ]
    ++ selector bats.libraries;

    nativeBuildInputs = [
      makeWrapper
    ];

    postBuild = ''
      wrapProgram "$out/bin/bats" \
        --suffix BATS_LIB_PATH : "$out/share/bats"
    '';
  };

先頭の passthru は、パッケージに属性を付け足すための入れ物です。マニュアルによると、passthru の値はビルドを実行するプログラムには渡されないため、書き換えてもリビルドは起きません。それでいて pkgs.bats.withLibraries のように、パッケージの属性として呼び出せます。

処理は2段です。まず symlinkJoin が、bats 本体と選んだライブラリ（それぞれ share/bats/bats-assert などに入っている）を1つのディレクトリへシンボリックリンクでまとめます。次に wrapProgram が bin/bats をラッパーに差し替え、BATS_LIB_PATH の末尾にそのディレクトリを足します。Nixpkgsのマニュアルは、--prefix は依存先を固定してしまい、--suffix は実行時の値を優先してその後ろに補う、と使い分けを説明しています。ここで --suffix なのは、利用者が自分で設定した BATS_LIB_PATH を上書きしないためです。

wrapProgram を使うには、nativeBuildInputs に makeWrapper か makeBinaryWrapper を入れます。前者はシェルスクリプトのラッパーを、後者は小さなコンパイル済みのラッパーを作ります。マニュアルは後者を通常は推奨しています。macOSではシバン（#!）にスクリプトを指定できないため、ラッパー自体をインタプリタとして使う場合に必要になるからです。

devShellへのbats.withLibrariesの追加

先ほどの flake.nix の packages を次のように書き換えます。p には bats.libraries（bats-assert・bats-support・bats-file・bats-detik）が渡されるので、使うものだけを選びます。

packages = [
  (pkgs.bats.withLibraries (p: [
    p.bats-support
    p.bats-assert
  ]))
];

回文判定スクリプトのテストと実行結果

テスト対象は、引数が回文ならYESを出力して成功し、そうでなければNOを出力して終了コード1を返すスクリプトです。

#!/usr/bin/env bash
input="$1"
reversed="$(printf '%s' "$input" | rev)"
if [ "$input" = "$reversed" ]; then
  echo "YES"
else
  echo "NO"
  exit 1
fi

これを is_palindrome.sh として保存して実行権限を付け、test/is_palindrome.bats に次のテストを書きます。bats-assert は bats-support に依存するので、この順番で読み込みます。テスト名を英数字にしているのは、macOS標準のbash 3.2で実行したとき、UTF-8ロケールでは日本語のテスト名が「unknown test name」となり1件も実行されなかったためです（LC_ALL=C では日本語名でも通りました）。

setup() {
  bats_load_library bats-support
  bats_load_library bats-assert
  cd "$BATS_TEST_DIRNAME/.."
}

@test "palindrome prints YES and succeeds" {
  run ./is_palindrome.sh level
  assert_success
  assert_output "YES"
}

@test "non-palindrome prints NO and fails" {
  run ./is_palindrome.sh hello
  assert_failure
  assert_output "NO"
}

nix develop で入ったシェルから bats test/ を実行します。筆者の環境ではNixを使わず、nixos-26.05 と同じ版（Bats 1.12.0・bats-support 0.3.0・bats-assert 2.1.0）と nixos-unstable と同じ版（Bats 1.14.0・bats-assert 2.2.4）の両方を、withLibraries と同じくライブラリ名のディレクトリに置いて BATS_LIB_PATH を設定し、どちらでも次の結果を確認しました（端末ではなくパイプに出力したため、TAP形式で表示されています）。Nix上での評価とビルドは行っておらず、Nix式は構文のみを確認しています。

1..2
ok 1 palindrome prints YES and succeeds
ok 2 non-palindrome prints NO and fails

同じテストを BATS_LIB_PATH なしで実行すると、両方のテストが setup で止まり、次のメッセージが出ました。withLibraries を使わずに pkgs.bats だけを入れた場合に出るのがこのエラーです。

Could not find library 'bats-support' relative to test file or in BATS_LIB_PATH

Nixpkgs利用時のつまずきと対処

安定版に無い・古いパッケージの扱い

安定版のブランチには、公開後の新しいメジャー版がほとんど入りません。1つのパッケージだけ新しくしたいなら、unstable を2本目の入力として足し、そのパッケージだけをそちらから取ります。

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

  outputs = { self, nixpkgs, nixpkgs-unstable }:
    let
      system = "aarch64-darwin";
      pkgs = nixpkgs.legacyPackages.${system};
      unstable = nixpkgs-unstable.legacyPackages.${system};
    in
    {
      devShells.${system}.default = pkgs.mkShell {
        packages = [ pkgs.jq unstable.bats ];
      };
    };
}

この例ではjqは26.05から、Batsはunstable（2026年10月時点で1.14.0）から入ります。2つのブランチのコミットが両方とも flake.lock に記録されるので、固定が崩れることはありません。unstable にも無い版を使いたいときは、overrideAttrs で既存パッケージの version と src を差し替えます。overrideAttrs は stdenv.mkDerivation に渡す属性を上書きする関数で、Nixpkgsのほとんどのパッケージで使えます。Nixpkgsにそもそも無いソフトは、自分で package.nix を書くか、そのソフトだけHomebrewなど別の手段で入れます。Nix言語に慣れていないうちは、無理にレシピを書くより後者のほうが早く片付きます。

unfreeパッケージの許可設定

Nixpkgsは、ライセンスが自由ソフトウェアでないパッケージ（unfree）を既定では評価しません。検索にも出ません。チャネルなどflakeを使わない環境で常に許可するなら ~/.config/nixpkgs/config.nix に { allowUnfree = true; } と書きます。1回だけなら環境変数 NIXPKGS_ALLOW_UNFREE=1 を使えますが、flakeを使うコマンドは環境変数を読まないため --impure も付けます。flake.nix の中で許可するなら、legacyPackages の代わりに import nixpkgs { inherit system; config.allowUnfree = true; } で pkgs を作ります。

チャネルとflakeの参照先の違い

nix-shell -p や nix-env はチャネル（<nixpkgs>）を、nix shell nixpkgs#… はフレークのレジストリに登録された nixpkgs（既定は nixpkgs-unstable）を参照します。同じマシンでもコマンドによって入るバージョンが違うのはこのためです。プロジェクトでは flake.lock で固定し、手元の常用ツールは nix profile に寄せると混乱が減ります。

macOSのAPFSボリュームとシェル設定

macOSではインストーラが /nix 用のAPFSボリュームを作ります。OSのメジャーアップデート後に nix が見つからなくなった場合は、インストーラが /etc/zshrc などに追記した読み込み行が、残っているかを確認します。Nixを直接触らずに済ませたい場合は、Nixpkgsのパッケージを devbox.json で指定できる Devbox という選択肢もあります。

よくある質問

Nixpkgsとは何ですか？

パッケージマネージャNixで使うパッケージ定義（Nix式）を集めたリポジトリです。GitHubの NixOS/nixpkgs で開発されており、NixOSの設定モジュールも含みます。

NixとNixpkgsとNixOSの違いは何ですか？

Nixはパッケージをビルド・管理するツール、Nixpkgsはそのパッケージ定義の集まり、NixOSはNixpkgsを使って組み立てるLinuxディストリビューションです。NixとNixpkgsはmacOSや他のLinuxでも使えます。

Nixpkgsのパッケージ数はどれくらいですか？

GitHubのREADMEと公式のパッケージ検索は「140,000を超える」と表示しています。Repologyの集計では、2026年10月25日時点で nixpkgs-unstable がパッケージ149,275件でした。正確な件数はブランチと時期、数え方によって変わります。

Nixpkgsを更新（update）するにはどうすればよいですか？

flakeを使っているなら nix flake update で flake.lock を更新します。nix profile で入れたものは nix profile upgrade --all、チャネルを使っているなら nix-channel --update です。

flake.nixでNixpkgsのURLやコミットはどう書きますか？

inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05"; のように、GitHubのリポジトリとブランチ名を書きます。ローリング版なら末尾を nixos-unstable（macOSなら nixpkgs-unstable）にします。特定のコミットを指したいときは、ブランチ名の代わりに40桁のコミットハッシュを書きます。

関連記事

• Devboxとは？Nixで開発環境を再現する使い方とインストール手順【0.18.4対応】
• direnvとは？.envrcでディレクトリ単位に環境変数を切り替える手順と運用設計
• miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】
• Dev Container（devcontainer）のメリットとは｜devcontainer.jsonの書き方・lockfile・Compose連携【2026年版】
• Pixiとは？Python・conda対応のパッケージ管理ツールの使い方とuv・condaとの違い