Devboxとは？Nixを使う開発環境構築ツールの仕組み・インストール・使い方【2026年版】

Devboxは、パッケージマネージャNixを内部で使い、プロジェクトごとに隔離された開発環境をdevbox.json一つで再現できるオープンソースツールです。開発元はJetify（旧Jetpack）で、利用は無料。Nix独自の記法を書かずに、devbox addのような直感的なコマンドだけでチーム全員が同じツールチェインを揃えられます。

この記事では、Devboxの仕組み（Nixとの関係）、macOS・Linux・Windowsへのインストール、基本コマンドと設定ファイル、Docker・Dev Container・devenvとの違い、つまずきやすい点、そして「採用すべき場面と避けるべき場面」までを公式ドキュメントの記述に沿って整理します。

まとめ：Devboxの要点

• 正体：Nixを裏側で動かし、JSON設定（devbox.json）で開発環境を定義・再現するラッパーツール。Nixの記法は不要。
• 再現性：devbox.jsonと自動生成されるdevbox.lockをGitに含めれば、別マシンやCIでも同一バージョンの環境が手に入る。
• 導入：macOS・Linuxはcurl -fsSL https://get.jetify.com/devbox | bashの1行。Nixが無ければDevboxが自動でインストールする。WindowsはWSL2上で同じ手順。
• 強み：コンテナを使わずローカルで直接動くため軽量。Nixpkgsの約8万パッケージ（40万を超えるバージョン）にアクセスできる。
• 向き不向き：環境差分やNixの学習コストに悩むチームに向く。本番デプロイの隔離やGUIを含む完全なOS分離が要るならDockerが適する。

以下、それぞれを仕組みから順に見ていきます。

Devboxとは何か：Nixをラップする開発環境ツール

Devboxは、開発に必要なコンパイラ・ランタイム・データベースなどを、プロジェクト単位でまとめて用意するためのツールです。中核にあるのはNixですが、Devboxはdevbox.jsonというJSONファイルにパッケージ名を並べる方式を採るため、利用者がNixの言語（.nixファイル）を書く必要はありません。npmやpipでライブラリを足す感覚で、システムレベルの依存まで管理できる点が特徴です。

開発元のJetifyは2024年にJetpackから社名・ブランドを変更し、GitHubのリポジトリもjetify-com/devboxへ移っています。古い記事やコマンド例で見かけるjetpack-io/devboxは旧URLです。Devbox本体はApache 2.0ライセンスのオープンソースで、利用に費用はかかりません。

Devboxが解決する課題：環境差分とNixの学習コスト

チーム開発では「自分のマシンでは動くのに他の人やCIでは落ちる」という環境差分が起きがちです。Dockerで環境を統一する方法は定番ですが、コンテナ上の開発はボリュームマウント経由のファイルI/Oが遅く、ビルドのたびにイメージを扱う重さがあります。一方、再現性に優れたNixは独自記法（derivationやflake）の学習コストが高く、チーム全員に強いるのは現実的でありません。Devboxは「Nixの再現性を、Nixを知らない人でも使える形で提供する」ことでこの二つの課題の間を埋めるツールです。

DevboxとNixの関係：内部の仕組みと単体Nixとの違い

Devboxを理解する鍵はNixとの関係です。「devbox nix」「nix devbox」で調べる人は多く、ここを押さえるとDevboxの挙動がほぼ説明できます。

内部でNixがどう動くか：/nix/store と .devbox

devbox addを実行すると、DevboxはNixに対象パッケージの解決とインストールを指示します。Nixはパッケージ本体をハッシュ付きで/nix/storeに格納し、Devboxはそこへのシンボリックリンクをプロジェクト直下の.devbox/nix/profileに作ります。devbox shellで環境に入ると、このプロファイルがPATHの先頭に差し込まれ、プロジェクト専用のツールだけが見える状態になります。シェルを抜ければPATHは元に戻り、ホスト環境は汚れません。パッケージ実体は/nix/storeに共有されるため、複数プロジェクトで同じ依存を使ってもディスクは一度しか消費しません。

取得元はNixの公式パッケージ集Nixpkgsです。Devbox独自のパッケージ形式はなく、Nixpkgsのどのバージョンを使うかをdevbox.lockに記録して再現性を担保します。公開バイナリキャッシュ（cache.nixos.org）が効くパッケージはビルドせずダウンロードで済むため、人気のあるツールは初回でも短時間で入ります。

nix-shell・flakes単体利用との違い

同じことはNix単体（shell.nix＋nix-shell、またはflakeとnix develop）でも実現できます。違いはインターフェースです。Devboxはdevbox add nodejsのような短いコマンドとJSONで完結し、Nixのderivation記法を覚える必要がありません。さらにDevboxはスクリプト実行（devbox run）やローカルサービス起動（devbox services）、コンテナ設定の生成といった、Nix純正にはない開発支援機能を持ちます。

逆に、カーネルモジュールやシステム全体の構成までNixで管理したい（NixOS的な使い方をしたい）なら、Devboxのラッパーはむしろ制約になります。チーム全員がNixに習熟しているならdevenvのようなNixネイティブのツールや素のflakeで十分です。Devboxが効くのは「Nixの知識が一部メンバーに偏っているチーム」です。

Devboxのインストール手順：macOS・Linux・Windows

DevboxはNixの上で動きますが、Nixが未導入でも自動でセットアップされるため、まずはDevboxのインストールスクリプトを実行すれば始められます。

macOS・Linuxへのインストール（公式スクリプトとNix）

非rootユーザーで次の1行を実行します。最新版のDevboxが入り、必要なら同時にNixもインストールされます。

curl -fsSL https://get.jetify.com/devbox | bash

スクリプトが自動で導入するNixは、Linuxではシングルユーザー構成です。複数人で共有するサーバなどでは、Jetifyが推奨するDeterminate Nix Installerを自分で先に入れておくとよいでしょう。マルチユーザー構成で導入され、/nix/nix-installer uninstallでのアンインストールにも対応します。インストール後はdevbox versionでバージョンを確認できます。Nixに既に慣れているなら、flake経由でも導入できます。

nix profile install github:jetify-com/devbox/latest

特定バージョンを固定したいときは末尾にバージョンを付け、nix profile install github:jetify-com/devbox/0.13.2のように指定します（0.13.2以降で利用可）。Homebrew経由のインストールも可能ですが、最新版への追従は公式スクリプトかflakeの方が確実です。

Windows（WSL2）での導入

WindowsネイティブではNix・Devboxとも直接は動かないため、WSL2上のLinux環境を使います。管理者権限のPowerShellでwsl --installを実行してUbuntu等を入れ、そのシェル内でmacOS・Linuxと同じインストールスクリプトを走らせるだけです。WSL内で完結するため、Windows側のツールとは混ざりません。WSL2の仕組みや前提はWSL2とは｜WSL1との違い・仕組み・インストール方法とメリット/デメリットを解説を参照してください。

バージョンの更新と固定（devbox version update / DEVBOX_USE_VERSION）

更新したいときは、Devbox本体はdevbox version updateで最新の安定版に上げられ、個別パッケージはdevbox update <パッケージ名>で指定したものだけを更新できます。逆に固定したいときは、チームでDevboxのバージョンを揃えるために環境変数DEVBOX_USE_VERSIONを設定すると、インストール済みより新しい版があっても指定バージョンで動作します。安定運用中のプロジェクトでは、不意の挙動変化を避けるためにこの固定が有効です。

Devboxの基本的な使い方：init・add・shell・run・services

導入後の流れは「初期化 → パッケージ追加 → シェル起動」の3ステップで、慣れればHomebrewでツールを足す感覚と大きく変わりません。

プロジェクト初期化からシェル起動まで（init / add / shell）

プロジェクトのディレクトリでdevbox initを実行すると、空のdevbox.jsonが生成されます。続けて必要なツールを追加し、シェルに入ります。

devbox init
devbox add [email protected] nodejs@20 postgresql@16
devbox shell

バージョンはパッケージ名@バージョンで指定でき、省略するとNixpkgsの既定版が入ります。devbox shellに入ると追加したツールだけがPATHに通り、python --versionなどで隔離環境のバージョンが返ります。exitでシェルを抜ければ元の環境に戻ります。

devbox.json と devbox.lock による環境の固定

devbox.jsonはパッケージ一覧・初期化処理・スクリプトをまとめた設定ファイルです。例えば次のようになります。

{
  "packages": ["nodejs@20", "postgresql@16"],
  "shell": {
    "init_hook": ["echo Setting up project"],
    "scripts": { "start": "node app.js" }
  }
}

devbox addやdevbox installを実行すると、Devboxは各パッケージの正確なバージョンとNixpkgsのコミットを記録したdevbox.lockを自動生成します。この2ファイルをGitにコミットしておけば、他の開発者やCIがdevbox installを実行したときに同一の環境が再現されます。かつてLockファイルは存在せずバージョン固定が課題でしたが、現在はdevbox.lockが標準で、これがDevboxの再現性の土台です。さらに固定度を上げたいパッケージは、devbox add [email protected]のようにバージョンを明示して追加します。

スクリプトとサービス（run / services / global）

devbox.jsonのscriptsに登録したコマンドはdevbox run startのように呼び出せ、ビルドやテストの手順を環境定義と一緒に共有できます。データベースなど周辺プロセスはdevbox services upでまとめて起動・停止でき、内部ではprocess-composeが使われます。エディタやgitなど全プロジェクトで使いたいツールは、プロジェクトに縛られないdevbox global addで入れておくと便利です。

他ツールとの比較：Docker・Dev Container・devenv・asdf

Devboxは役割の一部がDockerや言語バージョン管理ツールと重なります。隔離の仕組みと用途で整理すると違いが見えます。

Dockerとの違いとコンテナ出力（devbox generate）

Dockerはコンテナとしてホストからプロセスごと隔離するため、本番環境へそのまま配布できる一方、開発時はファイルI/Oの遅さや起動の重さが付きまといます。Devboxはホスト上で直接動くため軽快ですが、OSレベルの完全な隔離ではありません。両者は対立するものではなく、Devboxで開発した環境からdevbox generate dockerfileでDockerfileを生成し、本番用イメージへ橋渡しできます。Docker自体の基礎はDockerの基本的な概念と仕組みを理解する、生成されるDockerfileの読み方はDockerfileとは？書き方と主要命令・ベストプラクティスを実例で解説【入門〜実務】が参考になります。

Dev Container・devenvとの使い分け

VS CodeのDev Containerを使うチームなら、devbox generate devcontainerで.devcontainer/配下にDockerfileとdevcontainer.jsonを生成し、Devboxの定義をそのままエディタ統合環境へ持ち込めます。Dev Container単体の仕組みはDev Containerの概要と基本的な機能および利点についてで確認できます。devenvはDevboxと近い目的のNixツールですが、設定をdevenv.nixにNix言語で書く点が異なります。Nixを書けるチームはdevenv、書きたくないチームはDevbox、という線引きが実務的です。

導入時のつまずきと対処

Devbox特有というより、背後のNixに起因するつまずきが大半です。遭遇しやすい順に対処を挙げます。

Nixストアの肥大化：多くのバージョンを試すと/nix/storeが膨らみます。devbox run -- nix store gcで未参照パッケージを回収すれば容量が戻ります。プロジェクト側の環境は.devboxを消すだけで片付きます。

ヘッダファイルが見つからずビルドに失敗：Nixpkgsの多くのパッケージは実行部と開発部（ヘッダ・静的ライブラリ）が別出力に分かれています。openssl/ssl.h: No such fileのようなエラーなら、devbox add openssl --output devでdev出力を追加します。

glibc関連のエラー：GLIBC_x.yy not foundはランタイム間でCライブラリのバージョンが食い違うと起きます。対象パッケージを新しい版へ更新するか、Devbox／Nixを更新して環境全体を最新化すると解消することが多いです。

インストールが遅い：公開キャッシュに無いパッケージはソースからビルドされます。Jetifyが提供するクラウドキャッシュ（Jetify Cache）やGitHub Actions向けの公式アクション（devbox-install-action）を使うと、ビルド済みバイナリを共有して時間を抑えられます。direnvと組み合わせ、ディレクトリ移動時に自動でDevbox環境へ入る運用も定番です。

Devboxを採用すべき場面・避けるべき場面

万能ツールではありません。判断基準を明確にしておくと導入で失敗しません。

採用が効く場面は、複数言語・複数プロジェクトを1台で扱い環境が衝突しがちなとき、新人のオンボーディングに時間を取られているとき、そして「ローカルとCIの環境差でテストが不安定」なときです。devbox.jsonとdevbox.lockをCIでも使えば、開発とCIの環境を一致させられます。チーム内でNixを書けるのが一部だけ、という状況にも噛み合います。

逆に避けるべき・過剰な場面もはっきりしています。本番までコンテナで一貫させたい、GUIや特殊なシステムライブラリまで含めOSレベルで完全分離したい、という要件はDockerの領域で、Devboxを無理に当てるとかえって遠回りになります。チーム全員がNixに習熟しているなら、ラッパーを挟まずdevenvや素のflakeの方が小回りが利きます。また、Windowsネイティブ環境しか使えずWSL2を導入できない制約下では選択肢になりません。「開発環境の再現と軽さ」が主目的のときに最も力を発揮するツールだと割り切るのが、導入を成功させるコツです。

よくある質問

Devboxとは何ですか？

パッケージマネージャNixを内部で使い、devbox.jsonに書いたパッケージ一覧から、プロジェクトごとに隔離された開発環境を再現するオープンソースツールです。開発元はJetify（旧Jetpack）。Nixの記法を書かずに、コマンドとJSONだけで環境を定義できる点が特徴です。

Devboxのインストールはどうやりますか？

macOS・Linuxは、本文「インストール手順」で示した1行のインストールスクリプトを非rootで実行するだけです。Nixが未導入でもDevboxが自動でインストールします。WindowsはWSL2を有効化し、そのLinux環境内で同じスクリプトを実行します。

DevboxとDockerは何が違いますか？

DockerはOSレベルでコンテナとして隔離し本番配布まで担えますが、開発時はI/Oが遅くなりがちです。Devboxはホスト上で直接動くため軽快で、開発環境の再現に向きます。両立も可能で、devbox generate dockerfileでDevbox環境からDockerfileを生成できます。

Devboxは無料で使えますか？

Devbox本体はApache 2.0ライセンスのオープンソースで無料です。背後のNixも無料で、Nixpkgsの約8万パッケージを追加費用なく利用できます。任意でJetifyのクラウドキャッシュなど有料サービスもありますが、利用は必須ではありません。

Windowsでも使えますか？

Windowsネイティブでは直接動きませんが、WSL2上のLinux環境で利用できます。wsl --installでWSL2を導入し、その中でmacOS・Linuxと同じ手順を実行すれば動作します。操作はWSL内で完結します。

関連記事

• Dev Containerの概要と基本的な機能および利点について
• Dockerの基本的な概念と仕組みを理解する
• Dockerfileとは？書き方と主要命令・ベストプラクティスを実例で解説【入門〜実務】
• WSL2とは｜WSL1との違い・仕組み・インストール方法とメリット/デメリットを解説