Node.jsのインストールとバージョン管理 — nvm・LTSの選び方

Node.jsのインストール自体は、公式サイトからダウンロードすれば数分で終わります。それでもこの章を1章分使って解説するのは、実務でのつまずきが「インストールできない」ではなく、**「プロジェクトごとに必要なNode.jsのバージョンが違う」**ことから起きるためです。

会社のプロジェクトはNode.js 18、個人開発は22、ちょっと触りたいOSSは20——こうした状況は普通にあります。この章では、バージョンの読み方、LTSの選び方、そしてバージョンを切り替え・固定する方法を学びます。

学習者

昨日まで動いていたプロジェクトをクローンし直したら npm install でエラーの山に…。コードは同じはずなのに、何が違うんですか？

先生

真っ先に疑うべきはNode.jsのバージョンだね。同じコードでも、実行するNode.jsが違えば結果は変わる。だから実務では「どのバージョンで動かすか」をプロジェクトごとに固定するのが基本なんだ。

バージョン番号の読み方とリリースサイクル

Node.jsのバージョンは 22.11.0 のように3つの数字で表されます（セマンティックバージョニング）。

そして各メジャーバージョンは、次のような段階を経て寿命を迎えます。

• Current — リリース直後の状態。新機能が入るが、まだ枯れていない
• Active LTS — Long Term Support（長期サポート）。安定していて、バグ修正・セキュリティ修正が約束されている
• Maintenance — 新機能は入らず、重要な修正のみ
• End of Life（EOL） — サポート終了。セキュリティ修正すら提供されない

LTSとCurrent、どちらを選ぶか

結論はシンプルです。

各バージョンが今どの段階にあるかは、公式のリリース一覧（章末の参考リンク）でいつでも確認できます。EOLを過ぎたバージョンを本番で使い続けるのはセキュリティリスクなので、実務ではLTSの移り変わりに合わせてアップグレードしていくことになります。

インストール方法は3系統ある

Node.jsをマシンに入れる方法は、大きく3つに分かれます。

複数プロジェクトを扱う開発者は、最初からバージョン管理ツールでインストールするのがおすすめです。後から公式インストーラ版と共存させると、「どのNode.jsが使われているのか分からない」というPATHの混乱が起きがちです。

nvmでインストールする

もっとも広く使われているバージョン管理ツールが nvm（Node Version Manager） です。macOS / Linux（WindowsならWSL内）で動作します。

インストール後、よく使うコマンドは次のとおりです。

# 最新LTSを入れて、デフォルトに設定する流れ
nvm install --lts
nvm alias default 'lts/*'
 
# 動作確認
node -v   # → v22.x.x のようにバージョンが表示されれば成功
npm -v    # → npmはNode.jsに同梱されている

プロジェクトにバージョンを固定する

バージョン管理ツールの真価は「切り替えられること」よりも、「このプロジェクトはこのバージョンで動かす」と宣言してチーム全員で揃えられることにあります。方法は主に2つあり、併用するのが実務の定番です。

方法1: .nvmrc ファイル

プロジェクトのルートに .nvmrc というファイルを置き、バージョンを書くだけです。

# .nvmrc の中身（これだけ）
22

# プロジェクトのディレクトリで実行すると、.nvmrcのバージョンに切り替わる
nvm use

リポジトリにコミットしておけば、クローンした人は nvm use を実行するだけで正しいバージョンに揃います。

方法2: package.jsonの engines フィールド

package.json に、動作対象のNode.jsバージョンを宣言できます。

{
  "engines": {
    "node": ">=22.0.0"
  }
}

engines は宣言だけではデフォルトで強制されませんが、プロジェクトに .npmrc ファイルを置いて engine-strict=true を設定すると、条件を満たさないNode.jsで npm install した際にエラーで止められます。「気づかずに違うバージョンで作業していた」を仕組みで防げるわけです。

学習者

.nvmrc と engines、両方書くんですか？どっちかでいい気がしますが…

先生

役割が少し違うんだ。.nvmrc は「開発者のローカルのバージョンを切り替える」ためのもの、engines は「間違ったバージョンでの実行を検出する」ためのもの。CIやデプロイ環境は .nvmrc を読まないことも多いから、両方あると防御が厚くなるよ。

よくあるハマりどころ

sudo npm install -g で権限エラー地獄に入る

公式インストーラやaptで入れたNode.jsは、グローバルインストール先がシステム領域になるため、npm install -g で権限エラーが出て sudo に頼りがちです。すると今度はファイルの所有者が混ざり、さらにエラーが増えます。nvmで入れたNode.jsはすべてホームディレクトリ配下に置かれるため、この問題ごと消えます。これもバージョン管理ツールを勧める理由の1つです。

複数の入れ方が混在して「どのnodeが動いているか」分からない

公式インストーラで入れた後にnvmも入れた、といった環境では、シェルによって参照されるNode.jsが変わることがあります。which node で実際に使われているパスを確認し、古い方はアンインストールして1系統に統一するのが安全です。

Nodeのバージョン違いによる「原因不明」エラー

冒頭の例のように、npm install 時のネイティブモジュールのビルド失敗や、node_modules を共有した際の謎の実行時エラーは、Node.jsバージョンの不一致が原因のことがよくあります。エラーメッセージを読み込む前に、まず node -v がプロジェクトの想定（.nvmrc や engines）と一致しているかを確認すると、調査時間を大幅に節約できます。

ちゃんと使うためのポイント

• バージョンは「最新のLTS（偶数バージョン）」が基本——CurrentやEOL版は理由がない限り選ばない
• インストールは最初からバージョン管理ツール（nvm / Volta / fnm）で。複数バージョンの共存と権限問題の回避がセットで手に入る
• プロジェクトには .nvmrc でバージョンを明示し、engines + engine-strict で誤ったバージョンでの実行を検出する
• 環境の不調を感じたら、まず node -v と which node——バージョンとパスの確認から始める

次章では、Node.jsと一緒にインストールされたnpmを使って、package.jsonの読み方と依存管理を学びます。

参考リンク

• Node.js ダウンロードページ — 公式のインストール手段まとめ（nvm等の手順も選択できる）
• Node.js 以前のリリース — 各バージョンのLTS状況とサポート期限の一覧
• nvm - GitHub — nvmのインストール手順と全コマンドのドキュメント（英語）
• Volta — Rust製のツールチェーン管理ツール（英語）

Node.jsクイズに挑戦するこの章で学んだNode.jsの知識を、4択クイズでアウトプットして定着させよう