--- title: "Devboxとは？Nixで開発環境を再現する使い方とインストール手順【0.18.4対応】" url: "https://www.issoh.co.jp/tech/details/8323/" published: 2025-08-20 updated: 2026-10-25 categories: ["開発"] publisher: "株式会社一創" --- # Devboxとは？Nixで開発環境を再現する使い方とインストール手順【0.18.4対応】 Devboxは、パッケージマネージャ**Nix**を裏側で動かし、`devbox.json`と`devbox.lock`の2ファイルでプロジェクトごとの開発環境を再現するオープンソースのCLIです。開発元はJetify（旧Jetpack）で、ライセンスはApache 2.0。Nixの言語を書かずに、`devbox add nodejs@22`のようなコマンドだけでNode.jsやPostgreSQLの版をチームで揃えられます。 名前が似ている**Microsoft Dev Box**（Azureのクラウド開発PCサービス）とは別の製品です。この記事では、2026年10月25日時点の最新安定版0.18.4を公式Dockerイメージで動かした結果をもとに、仕組み・インストール・基本操作・0.18.0で消えた機能・他ツールとの使い分けを整理します。 ## まとめ：Devboxの要点 - **仕組み**：パッケージ本体はNixの`/nix/store`に入り、プロジェクトの`.devbox/nix/profile`から参照される。コンテナは使わない。 - **再現性**：`devbox.lock`にNixpkgsのコミットとOS・CPU別のstore pathが記録される。別のコンテナで`devbox install`しても、Node.js v22.23.3・Python 3.12.15が同じ版で入り、lockのハッシュも変わらなかった。 - **導入**：`curl -fsSL https://get.jetify.com/devbox | bash`の1行。Nixが無ければ最初のコマンド実行時に自動で入る。WindowsはWSL2上で同じ手順。 - **最新の変更**：0.18.0（2026年8月16日）でJetify Cloud機能を削除。`devbox cache`・`devbox secrets`・`devbox auth`は使えない。 - **向き不向き**：Nixを書けるのが一部の人だけのチームに向く。本番まで同じイメージで運ぶならDocker、ランタイムの版切り替えだけならmiseで足りる。 以下、仕組みから順に、実際のコマンド出力を添えて説明します。 ## DevboxとNixの関係：パッケージが置かれる場所 DevboxとNixの関係は、役割の分担で整理できます。Devboxは検索サービスを使ってパッケージ名と版をNixpkgsのコミットへ解決し（0.18.4から既定の検索先は[www.nixsearch.com](https://github.com/jetify-com/devbox/releases/tag/0.18.4)）、取得・ビルド・格納はNixが担います。その上でDevboxは`devbox.json`の管理とシェルの環境変数づくりを受け持ちます。Devbox独自のパッケージ形式は無く、通常のパッケージ検索ではNixpkgsを利用します。Nix flakeを指定すれば、独自パッケージや上書きしたパッケージも追加できます。Nixpkgs自体の構造は[Nixpkgsとは？Nixとの関係・パッケージの探し方とinstall・flake.nixでの使い方](/tech/details/10472/)で詳しく扱っています。 ### /nix/store と .devbox/nix/profile の実体 0.18.4で`devbox add nodejs@22`を実行し、`node`の場所をたどると次のようになりました。 ``` $ devbox run -- which node /home/devbox/proj/.devbox/nix/profile/default/bin/node $ readlink -f /home/devbox/proj/.devbox/nix/profile/default/bin/node /nix/store/y11g9g1pmig70hhb4ryfl0j0w0q1q35q-nodejs-slim-22.23.3/bin/node ``` プロジェクト側にあるのはシンボリックリンクだけで、実体はハッシュ付きのディレクトリとして`/nix/store`に置かれます。同じNixストア内で同じstore pathを参照するプロジェクト間では、パッケージの実体を共有します。同じ版番号でも依存関係やビルド条件が異なれば、別のstore pathになります。`devbox shell`に入るとこのprofileがPATHの先頭に入り、`exit`で抜ければ元のPATHに戻ります。`.devbox`ディレクトリには中身が`*`と`.*`だけの`.gitignore`が自動で置かれるため、自分で除外設定を書かなくてもGitには入りません。 ### Nix単体・devenvとの違い 同じことは`shell.nix`と`nix-shell`、またはflakeと`nix develop`でもできます。違いは設定の書き方です。Nix単体やdevenv（設定は`devenv.nix`）はNix言語で書くのに対し、DevboxはJSONとCLIで完結します。加えて、スクリプト実行（`devbox run`）、process-composeによるサービス起動、Dockerfileやdevcontainer.jsonの生成といった開発向けの機能を持ちます。 判断は単純で、チーム全員がNix言語を書けるならdevenvや素のflakeのほうが制約が少なく、書けない人が混じるならDevboxが合います。逆に、OS全体の構成までNixで管理したいNixOS的な使い方では、Devboxのラッパーは遠回りになります。 ## Devboxのインストール：macOS・Linux・WSL2 Devbox本体はGoで書かれた単一のバイナリで、Nixは後から自動で入ります。[公式のインストール手順](https://www.jetify.com/docs/devbox/installing-devbox)は、非rootユーザーで次の1行を実行する方法です。 ``` curl -fsSL https://get.jetify.com/devbox | bash devbox version ``` ### Nixの自動インストール：権限と取得先 Nixが入っていない状態で`devbox add`などを実行すると、「Nix is not installed. Devbox will attempt to install it.」と表示され、Enterで続行すると`sudo`のパスワードを求められます。公式ドキュメントは、LinuxとWSL2ではシングルユーザー、macOSではマルチユーザーの構成でNixを入れると説明しています。 取得するインストーラは版によって違います。0.16系まではDeterminate Systemsのインストーラでしたが、2025年9月16日のコミット「change builtin installer to upstream nix experimental」（[nix/install.go](https://github.com/jetify-com/devbox/blob/0.18.4/nix/install.go)）により、0.17.0以降は`artifacts.nixos.org`で配布されるNix公式の実験版インストーラを取得します。systemdの無いLinux（コンテナなど）では`--init none`を付けて実行します。[nix-installerのREADME](https://github.com/NixOS/nix-installer)によれば、この構成でNixを使えるのはrootかsudoできるユーザーに限られます。Nixを自分で先に入れたい場合、公式ドキュメントは引き続きDeterminate Nix Installerを推奨しています。 ### Nix flakeでの導入と版の固定 Nixに慣れているなら`nix profile install github:jetify-com/devbox/latest`でも入ります。版を指定する書き方は0.13.2以降で使えます。Nixpkgs版の`nixpkgs#devbox`もありますが、Nixpkgs側の更新を待つため新版の反映が遅れます。公式ドキュメントが案内する導入方法は、インストールスクリプト・Nixpkgs・Nix flakeの3つです。 スクリプトで導入した本体の更新は`devbox version update`です。Nix経由で導入した場合は、導入方式に応じてNixのプロファイルや構成定義を更新します。チームで版を揃えたいときは環境変数`DEVBOX_USE_VERSION`に版番号を設定すると、新しい版が入っていても指定した版で動きます（公式FAQの例は`export DEVBOX_USE_VERSION=0.8.0`）。この環境変数による切り替えはランチャー経由の導入が対象で、Nix経由の導入ではプロファイルやNixの構成定義で版を固定します。0.18.0のような破壊的変更を含む版が出る製品なので、CIでは固定しておくのが安全です。 ### Windows（WSL2）での導入 WindowsネイティブではNixもDevboxも動きません。管理者権限のPowerShellで`wsl --install`を実行してUbuntuを入れ、そのシェルの中で上の1行を実行します。WSL2の仕組みや前提条件は[WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】](/tech/details/3410/)を参照してください。 ## devbox initからshellまでの基本操作 以下は2026年10月25日に、Docker Hubの公式イメージ[jetpackio/devbox](https://hub.docker.com/r/jetpackio/devbox)（Devbox 0.18.4・Nix 2.35.2、x86\_64）で実行した結果です。 ### init・add・shell・runの流れ ``` mkdir my-app && cd my-app devbox init # 空のdevbox.jsonを作る devbox add nodejs@22 jq # 版を省いたjqは jq@latest として記録される devbox shell # 追加したツールにPATHが通ったシェルに入る exit # 元のシェルへ戻ってから次のコマンドを実行 devbox run -- node --version # シェルに入らず1コマンドだけ実行（v22.23.3） ``` `devbox add nodejs@22 jq`はバイナリキャッシュ（cache.nixos.org）から取得するだけで済み、10.2秒で終わりました。`devbox init`が作る`devbox.json`には、`packages`の空配列と、`shell.init_hook`・`shell.scripts`の雛形が入ります。`scripts`に登録したコマンドは`devbox run test`のように名前で呼べるため、ビルドやテストの手順を環境定義と一緒にリポジトリへ置けます。 ### devbox.lockに記録される内容と再現の確認 `devbox add`を実行すると`devbox.lock`が自動で作られます。jqの記録は次のとおりです（抜粋）。 ``` "jq@latest": { "last_modified": "2026-10-20T14:23:57Z", "resolved": "github:NixOS/nixpkgs/5adc50831c259f87faeb09ddf930d43597197473#jq", "source": "devbox-search", "version": "1.8.2", "systems": { "aarch64-darwin": { "outputs": [ ... ], "store_path": "/nix/store/vvp6grz676r5...-jq-1.8.2-bin" }, "aarch64-linux": { ... }, "x86_64-linux": { ... } ``` `resolved`がNixpkgsのコミットを指し、`systems`にOS・CPUごとのstore pathが入るため、MacとLinuxが混ざったチームでも同じ版を指せます。`devbox.json`と`devbox.lock`をGitに入れ、`.devbox`は入れない、が基本の運用です。 再現性を確かめるため、nodejs@22とpython@3.12を追加したプロジェクトから`devbox.json`と`devbox.lock`だけを新しいコンテナへ持ち込み、`devbox install`を実行しました。入った版はNode.js v22.23.3・Python 3.12.15で元と同じ、`devbox.lock`のSHA-256も一致しました。所要時間は2分39秒で、大半はNixpkgsの該当コミットを取得してGitキャッシュに展開する初回処理でした。CIで毎回この時間がかかるなら、[devbox-install-action](https://github.com/jetify-com/devbox-install-action)（最新はv0.15.0）の`enable-cache`を有効にする価値があります。 ### プラットフォーム別のパッケージと出力の指定 Linuxだけで使うツールや、ヘッダファイルが必要なライブラリは、オプション付きで追加します。 ``` devbox add ripgrep --exclude-platform aarch64-darwin # Apple Siliconでは入れない devbox add busybox --platform x86_64-linux,aarch64-linux devbox add openssl --outputs=dev # ヘッダ等の dev 出力を選ぶ ``` オプションを付けると`devbox.json`の`packages`は配列からオブジェクトに書き換わり、`"openssl": { "version": "latest", "outputs": ["dev"] }`のような形になります。旧来の記事にある`--output dev`は誤りで、0.18.4のフラグ名は`--outputs`（短縮形`-o`）です。 ### パッケージと版の探し方 入れられる版は`devbox search`で確認します。`devbox search postgresql`は「Found 50+ results」と返し、`postgresql`に18.6や17.10、`postgresql_14`に14.24などが並びました。省略された版は`--show-all`で全件出ます。版を省いて追加すると`@latest`になり、`devbox info nodejs`はその時点で26.12.0を示しました。チームで使うツールは`nodejs@22`のように版を書いて追加してください。[公式サイト](https://www.jetify.com/devbox)は、8万パッケージ・40万を超える版を検索できると説明しています。 ## servicesによるDB起動とglobalによる共通ツール管理 ### devbox servicesによるPostgreSQLの起動 `devbox add postgresql@17`を実行すると、プラグインが`.devbox/virtenv/postgresql/process-compose.yaml`を作り、`PGDATA`と`PGHOST`をプロジェクト配下に設定します。ホストの`/var/lib`などには書き込みません。 ``` devbox add postgresql@17 devbox run -- initdb devbox services up -b # バックグラウンドで process-compose を起動 devbox services ls # postgresql Running Ready devbox run -- 'psql -d postgres -tAc "select version()"' devbox services stop ``` 実行すると「PostgreSQL 17.10 on x86\_64-pc-linux-gnu」が返りました。[devbox services](https://www.jetify.com/docs/devbox/cli-reference/devbox-services)は内部でprocess-compose（今回取得されたのは1.116.0）を使い、`start`・`stop`・`restart`・`attach`などのサブコマンドを持ちます。`psql`にホストを指定しなくてもつながるのは、`PGHOST`がソケットのディレクトリを指しているためです。 ### devbox globalによる全プロジェクト共通のツール管理 gitやエディタのように全プロジェクトで使うツールは`devbox global add`で入れ、`eval "$(devbox global shellenv --init-hook)"`を`~/.zshrc`や`~/.bashrc`に書くと常に使えます。設定の共有に使う`devbox global push`・`pull`は、0.18.0から引数が必須になりました。pushにはGitリポジトリを指定し、pullにはGitリポジトリ、HTTP(S)アーカイブ、devbox.jsonのURL、またはローカルパスを指定します。 ## 0.18.0で削除されたJetify Cloud機能 2026年8月16日公開の[Devbox 0.18.0](https://github.com/jetify-com/devbox/releases/tag/0.18.0)は、「Remove jetify cloud functionality from devbox」としてJetifyのクラウド連携を外しました。2025年以前に書かれた解説記事の多くはこの変更を反映していないため、次のコマンドを勧める記事は古いと判断できます。 | 削除・変更されたもの | 0.18.0以降の扱い | | ------------------------------ | ------------------------ | | devbox cache（Jetify Nix cache） | 削除。参照先はcache.nixos.orgのみ | | devbox secrets（envsec） | 削除。.envファイルへ移す | | devbox auth login・logout | 削除 | | devbox global push・pull（引数なし） | 引数が必須に | | env\_from: jetify-cloud | 警告して読み飛ばす | 影響が大きいのは、Jetify CacheでCIのビルド時間を短縮していたプロジェクトと、`devbox.json`の`env_from`でJetify Cloudのシークレットを読んでいたプロジェクトです。後者はエラーで止まらず警告だけで起動するため、環境変数が空のまま動いて気づくのが遅れます。0.17系以前から上げる場合は、`env_from`の有無を先に確認してください。Devbox本体と`devbox generate`・`devbox services`などのローカル機能は今回の削除の対象外です。 ## Docker・Dev Container・miseとの使い分け | ツール | 隔離の方法 | 設定ファイル | 向く用途 | | ------------- | -------------- | ----------------------- | -------------- | | Devbox | Nix（ホスト上で直接実行） | devbox.json・devbox.lock | ローカル環境とCIの統一 | | Docker | コンテナ（OSレベル） | Dockerfile | 本番までの配布 | | Dev Container | Docker＋エディタ統合 | devcontainer.json | VS Code前提の統一環境 | | devenv | Nix（Nix言語で記述） | devenv.nix | Nixを書けるチーム | | mise | ランタイムの版切り替え | mise.toml | 言語の版と環境変数の管理 | Dockerとの違いは、隔離の深さと速さの交換です。DockerはOSのライブラリまで含めて隔離でき、そのまま本番へ運べますが、macOSでは通常Linux仮想マシンを使い、ファイル共有方式や処理内容によって性能が変わります。Devbox自体は仮想マシンを必要としませんが、カーネルやシステム設定は隔離しません。コンテナの仕組みは[Dockerの仕組みを図解｜コンテナ隔離・アーキテクチャ・VMとの違いを実機コマンドで確認](/tech/details/2661/)で確認できます。 ### devbox generateで作られるDockerfileとdevcontainer.json `devbox generate`には`dockerfile`・`devcontainer`・`direnv`・`alias`・`readme`の5つのサブコマンドがあります。`devbox generate dockerfile`が出力したDockerfileは次の内容でした。 ``` FROM docker.io/jetpackio/devbox:latest WORKDIR /code USER root:root RUN mkdir -p /code && chown ${DEVBOX_USER}:${DEVBOX_USER} /code USER ${DEVBOX_USER}:${DEVBOX_USER} COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.json devbox.json COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.lock devbox.lock RUN devbox run -- echo "Installed Packages." && nix-store --gc CMD ["devbox", "shell"] ``` ベースイメージが`latest`タグなので、本番用にはベースイメージを固定し、アプリのコピー・依存関係の導入・必要なビルド処理に加えて、CMDまたはENTRYPOINTをアプリの起動コマンドへ変更する必要があります。Dockerfileの命令ごとの意味は[Dockerfileとは｜書き方・主要命令・ベストプラクティスを解説【2026年版】](/tech/details/3315/)を参照してください。`devbox generate devcontainer`は`.devcontainer/`にDockerfileと`devcontainer.json`を作り、拡張機能`jetpack-io.devbox`と`remoteUser: devbox`を設定します。「nix devcontainer」で探している場合は、この生成機能を使えばNixの定義をそのままDev Containerへ持ち込めます。Dev Container側の書き方は[Dev Container（devcontainer）のメリットとは｜devcontainer.jsonの書き方・lockfile・Compose連携【2026年版】](/tech/details/3728/)にまとめています。 ### mise・asdfとの違い miseやasdfが扱うのは主に言語ランタイムの版で、Devboxはそれに加えてOpenSSLやPostgreSQLのようなシステムライブラリ・サーバーまで版を固定できます。Node.jsとPythonの版を揃えるだけならNixを入れずに済むmiseのほうが軽く、詳しくは[miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】](/tech/details/17621/)で比較できます。両方を同じマシンで使う場合は、次の章のPATH競合に注意してください。 ## 導入時のつまずきと対処 多いのは、Devbox以外のツールとのPATHの取り合いと、Nix由来の問題です。 ### devbox shellでのnode・goのPATH競合 Devboxはシェル起動時に自分のprofileをPATHの先頭へ入れます。検証では、ダミーの`node`を置いたディレクトリをPATHの先頭に足してから`devbox shell`に入っても、Devbox側のv22.23.3が使われました。それでもmiseやasdfの版が使われる場合、原因は`.zshrc`などに書いた`mise activate`がシェル起動後にPATHを書き換えていることです。対処は2つあります。 - `devbox shell --pure`で起動し、HOME・USER・DISPLAYなど少数を除いて既存の環境変数を引き継がない - グローバルに入れたmiseの版を外し、そのツールはDevbox側だけで管理する `--pure`は継承する環境変数を減らせますが、`devbox.json`に入れていないコマンドは使えなくなります。検証では`which`すら「command not found」になりました。常用するなら、2つ目の整理のほうが現実的です。 ### 開発用ヘッダの不足とNixストア容量への対処 `openssl/ssl.h: No such file or directory`のようなビルドエラーは、Nixpkgsのパッケージが実行ファイルとヘッダを別の出力に分けているために起きます。前述の`devbox add openssl --outputs=dev`で解消します。 版を試すたびに`/nix/store`は大きくなり、検証用のコンテナでは3.5GBに達しました。不要になったパッケージは`nix-store --gc`で回収でき、jqだけを入れた環境で実行すると773パス・378MiBが消えました。`nix store gc`は環境によっては「experimental Nix feature ‘nix-command’ is disabled」で止まるため、`devbox generate dockerfile`の出力と同じ`nix-store --gc`を使うのが確実です。 ### direnvによるディレクトリ移動時の環境切り替え `devbox generate direnv`を実行すると、`eval "$(devbox generate direnv --print-envrc)"`の1行を含む`.envrc`が作られます。`direnv allow`すれば、ディレクトリに入るだけでDevboxの環境が有効になります。direnv自体の設定は[direnvとは？.envrcでディレクトリ単位に環境変数を切り替える手順と運用](/tech/details/17741/)を参照してください。利用状況の送信を止めたい場合は、0.18.0のリリースノートでも扱いが変わっていない`DO_NOT_TRACK`環境変数を設定します。 ## Devboxをアンインストールする手順 [公式FAQ](https://www.jetify.com/docs/devbox/faq)にあるスクリプト導入版の手順は、次の3つを削除するものです。Nix経由で導入した場合は、導入時に使ったプロファイルやNixの構成定義からDevboxを削除します。 ``` rm /usr/local/bin/devbox # ランチャー rm -rf ~/.cache/devbox # Devboxのバイナリ rm -rf ~/.local/share/devbox # グローバル設定 ``` この手順ではNixは残ります。Nixも消す場合は、Nixを入れたインストーラのアンインストール手順に従ってください。各プロジェクトの`.devbox`ディレクトリは個別に削除します。 ## Devboxを採用すべき場面・避けるべき場面 採用が効くのは、MacとLinuxが混ざったチームで「ローカルでは通るがCIで落ちる」が起きているとき、新しく入った人の環境構築に毎回時間を取られているとき、そしてプロジェクトごとにPostgreSQLやRedisの版が違うときです。`devbox.lock`がOS・CPU別にstore pathを持つので、Apple SiliconのMacとx86\_64のCIで同じ版を指せます。チームの開発環境とCIを揃える仕組みづくりから相談したい場合は、[DevOps・CI/CD導入支援](/service/system/devops/)でも対応しています。 一方、次の条件に当てはまるならDevboxは選びません。本番まで同じコンテナイメージで運ぶ前提なら、Dockerで最初から書くほうが二重管理になりません。WSL2を導入できないWindows環境では動きません。全員がNix言語を書けるならdevenvやflakeで足ります。そして、Nixの導入にroot権限が要るため、管理者権限を持てない社用PCでは最初の一歩で止まります。導入前に、チームの端末でsudoが使えるかを確認してください。 ## よくある質問 ### Devboxとは何ですか？ Jetifyが開発するオープンソースのCLIで、Nixを裏側で使い、`devbox.json`に書いたパッケージからプロジェクト専用の開発環境を作ります。Nix言語を書く必要はなく、`devbox add`と`devbox shell`で使えます。 ### DevboxとMicrosoft Dev Boxは同じものですか？ 別の製品です。Microsoft Dev BoxはAzure上に開発用のWindows PCを用意するクラウドサービスで、JetifyのDevboxは手元のmacOS・Linux・WSL2で動くコマンドラインツールです。 ### Devboxは無料ですか？ Devbox本体はApache 2.0ライセンスで無料です。Nixと、Nixpkgsのバイナリキャッシュであるcache.nixos.orgも無料で使えます。Jetify Cacheなどのクラウド連携は0.18.0でDevboxから削除されました。 ### devbox.lockはGitにコミットすべきですか？ コミットしてください。`devbox.lock`にNixpkgsのコミットとstore pathが入っているため、他の人やCIが`devbox install`したときに同じ版が入ります。`.devbox`ディレクトリは自動で除外されます。 ### Devboxをアンインストールするには？ `/usr/local/bin/devbox`、`~/.cache/devbox`、`~/.local/share/devbox`の3つを削除します。Nixは残るので、不要ならNixのアンインストール手順を別に実行します。 ## 関連記事 - [Nixpkgsとは？Nixとの関係・パッケージの探し方とinstall・flake.nixでの使い方](/tech/details/10472/) - [miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】](/tech/details/17621/) - [Dev Container（devcontainer）のメリットとは｜devcontainer.jsonの書き方・lockfile・Compose連携【2026年版】](/tech/details/3728/) - [direnvとは？.envrcでディレクトリ単位に環境変数を切り替える手順と運用](/tech/details/17741/) - [WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】](/tech/details/3410/) --- 出典: [Devboxとは？Nixで開発環境を再現する使い方とインストール手順【0.18.4対応】]()（株式会社一創）