Nixで開発環境を構築する（nix-shell / flakes 実践）

なぜNixで開発環境を作るのか

「自分のPCでは動くのに、他の人の環境では動かない」——チーム開発で何度も繰り返されるこの問題の根本原因は、環境の再現性が保証されていないことにある。

brew install nodeやapt install nodejsは「最新版を入れろ」という命令だ。先週インストールした人と今日インストールした人で、入るバージョンが違う可能性がある。READMEに「Node.js 18が必要」と書いてあっても、実際に18が入っている保証はどこにもない。

Nixはこの問題を、宣言型・純粋関数型の発想で解決する。詳しい設計思想は別記事「Nixとは？宣言型パッケージ管理で開発環境の「壊れた」をなくす方法」で解説しているが、ここで押さえておきたいのは次の3点だ。

• バージョンが共存できる: Node.js 18と20を同じマシンに入れても衝突しない。プロジェクトごとに違うバージョンを使い分けられる。
• 入力が同じなら結果も同じ: 設定ファイルが同じなら、いつ・どこで実行してもまったく同じ環境ができる。
• システムを汚さない: 開発環境を作っても、グローバルな/usr/binを書き換えたりしない。シェルを抜ければ元通り。

つまりNixで開発環境を構築するということは、「環境の作り方」をコードとしてGitに残すということだ。新しいメンバーが入っても、PCを買い替えても、コマンド一発で同じ環境が手に入る。

nix-shellで一時的な環境を作る

まず一番手軽な使い方から。nix-shellを使うと、特定のツールが入った一時的なシェル環境をその場で立ち上げられる。システムには何もインストールされない。

たとえば「いまだけNode.jsを使いたい」場合。

# Node.jsが入った一時シェルに入る
nix-shell -p nodejs_18

# このシェルの中ではnodeが使える
node --version

# exitすると、元のシェルに戻る（nodeは消える）
exit

-p（package）オプションで、必要なパッケージを並べるだけだ。複数指定もできる。

# Node.js・jq・curlをまとめて使える一時環境
nix-shell -p nodejs_18 jq curl

シェルを抜けた瞬間、これらのツールは見えなくなる。グローバル環境を汚さずに「ちょっと試す」ができるのがnix-shell -pの良さだ。

ただしnix-shell -pは、その場限りの使い捨て向きだ。プロジェクトの開発環境として毎回同じツール群を呼び出すなら、次に紹介するshell.nixを使う方がはるかに管理しやすい。

shell.nixで再現可能な環境を定義する

プロジェクトに必要なツールをファイルに書き出すのがshell.nixだ。プロジェクトのルートに置き、nix-shellと打つだけで、そのプロジェクト専用の環境が立ち上がる。

# shell.nix
{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  buildInputs = with pkgs; [
    nodejs_18
    python311
    git
    jq
  ];

  shellHook = ''
    echo "開発環境が準備できました"
    echo "Node.js: $(node --version)"
  '';
}

# プロジェクトディレクトリで実行するだけ
nix-shell

これでNode.js 18、Python 3.11、Git、jqが揃ったシェルが起動する。buildInputsに並べたものが、その環境で使えるツールだ。shellHookはシェルに入った瞬間に実行されるスクリプトで、環境変数の設定や起動メッセージの表示に使える。

ポイントは、このshell.nixをGitリポジトリにコミットすることだ。チームの誰もがgit cloneしてnix-shellと打つだけで、まったく同じツールが揃った環境を手に入れられる。「README手順を1個ずつ実行する」必要はもうない。

direnvで自動化する

毎回nix-shellと打つのが面倒なら、direnvと組み合わせると快適になる。プロジェクトディレクトリに入るだけで、自動的にNix環境が有効になる仕組みだ。

# .envrcを作成して許可する
echo "use nix" > .envrc
direnv allow

これで対象ディレクトリにcdするたびに環境が自動ロードされ、ディレクトリを出ると元の環境に戻る。shell.nixと.envrcをセットでコミットしておけば、クローンしてdirenv allowするだけで開発を始められる。

flakesによる現代的な環境管理

shell.nixには一つ弱点がある。冒頭のimport <nixpkgs> {}が指すnixpkgsのバージョンが環境によって違うかもしれない点だ。Aさんのマシンと、半年後に環境を作るBさんのマシンで、<nixpkgs>が別バージョンを指していれば、得られるNode.jsの細かいバージョンがズレる可能性がある。

これを解決するのが**Nix Flakes（フレイク）**だ。

Flakesは、依存しているnixpkgsのバージョンをflake.lockファイルで正確に固定する。npmのpackage-lock.jsonやRustのCargo.lockと同じ発想だと考えればわかりやすい。一度lockファイルができれば、いつ・どこで実行してもまったく同じ環境が再現される。

flake.nixの例

# flake.nix
{
  description = "My project development environment";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
      in
      {
        devShells.default = pkgs.mkShell {
          buildInputs = with pkgs; [
            nodejs_18
            python311
            git
          ];
        };
      }
    );
}

inputsで「どのnixpkgsを使うか」をGitのブランチやタグで指定し、devShells.defaultで開発環境の中身を定義している。flake-utilsを使っているのは、Linux（x86_64）でもmacOS（Apple Silicon）でも同じ定義が動くようにするためだ。

# Flakeベースの開発環境に入る
nix develop

# 初回実行時にflake.lockが自動生成される
git add flake.nix flake.lock

shell.nixではnix-shellだったが、Flakesではnix developで環境に入る。重要なのは生成されたflake.lockを必ずGitにコミットすることだ。このファイルが依存関係の正確なバージョン（Gitのコミットハッシュ）を記録しており、再現性の要になる。

Flakesを有効にする

Flakesは便利だが、2026年現在もNixでは「実験的機能」という位置づけのため、明示的に有効化する必要がある。

# ~/.config/nix/nix.conf に追記する
echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf

shell.nix と flakes の使い分け

2つの方法を整理しておこう。

ざっくり言えば、まずshell.nixで試し、本格的にチームで使うならflakesへという流れが自然だ。どちらもpkgs.mkShellとbuildInputsという同じ部品を使うので、shell.nixに慣れていればFlakesへの移行は難しくない。

Node.js開発環境の実例

具体的にNode.jsプロジェクトの環境を組んでみよう。よくあるのは「特定のNode.jsバージョン + よく使うCLIツール」の組み合わせだ。

# shell.nix（Node.jsプロジェクト向け）
{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  buildInputs = with pkgs; [
    nodejs_18
    nodePackages.pnpm
    nodePackages.typescript
    git
  ];

  shellHook = ''
    echo "Node.js: $(node --version)"
    echo "pnpm:    $(pnpm --version)"
  '';
}

このshell.nixがあれば、nix-shellに入った時点でNode.js 18、pnpm、TypeScript、Gitがすべて使える状態になる。チームメンバーがNode.jsを手動でインストールする必要はない。

# 環境に入る
nix-shell

# あとは普段どおり
pnpm install
pnpm run dev

ここで一つ注意点がある。node_modulesの中身はNixが管理しないということだ。Nixが揃えるのは「Node.js本体やpnpmといったツール」であり、pnpm installで入れるプロジェクト依存パッケージは、これまでどおりpnpm（やnpm）が管理する。Nixは「土台となるツールチェーンの再現性」を担保する役割だと考えるとわかりやすい。

別バージョンが必要になったら、buildInputsのnodejs_18をnodejs_20に書き換えるだけでいい。

buildInputs = with pkgs; [
  nodejs_20   # 18から20に変えるだけ
  nodePackages.pnpm
];

書き換えてもう一度nix-shellに入れば、今度はNode.js 20の環境が立ち上がる。グローバルなNode.jsを入れ替える必要も、バージョン管理ツールを別途用意する必要もない。プロジェクトごとに違うバージョンを使い分けるのが、設定ファイル1行の変更で済む。

Dockerとの使い分け

「環境を固定するならDockerでいいのでは？」とよく聞かれる。結論から言うと、両者は競合ではなく補完関係だ。

使い分けの目安はこうだ。

• 手元の開発作業をサクサク進めたいなら、ホスト上でネイティブに動くNixが軽快だ。エディタやデバッガとの相性もよい。
• 本番と同じOS・ミドルウェア構成で動かしたい、あるいはPostgreSQLなどのミドルウェアごと隔離したいなら、Dockerが向く。

そして両者は組み合わせられる。NixでDockerイメージをビルドするという使い方も人気で、「開発はNix、配布はDockerイメージ」というワークフローも成り立つ。Dockerの代替や軽量化を検討しているなら、「Docker Desktopの代替ツール」もあわせて参考にしてほしい。

よくある質問（FAQ）

まとめ：まずはshell.nixを1つ置いてみる

Nixで開発環境を構築する流れを振り返っておこう。

• nix-shell -p で、その場限りのツールをサッと使える。「ちょっと試す」用途に最適。
• shell.nix に必要なツールを書いてコミットすれば、チーム全員がnix-shell一発で同じ環境を再現できる。
• direnv と組み合わせれば、ディレクトリに入るだけで環境が自動で有効になる。
• flakes（flake.nix） ならflake.lockで依存を完全に固定でき、最も再現性が高い。
• Node.jsのような環境も、バージョン変更は設定ファイル1行の書き換えで済む。
• Dockerとは競合せず、開発はNix・配布はDockerのように補完し合える。

最初の一歩として難しいことは要らない。手元のプロジェクトにshell.nixを1つ置き、必要なツールを並べてnix-shellと打つ——それだけで「自分のPCでは動くのに」問題の多くから解放される。