Windows の Node.js — ネイティブ vs WSL2、どちらを使うべきか？

Windows で Node.js を動かす際に最初に問うべきこと：「WSL2 Linux にインストールするか、Windows ネイティブにインストールするか？」どちらも動くが、パフォーマンス・ツール互換性・デバッグ体験は大きく異なる。このガイドは 2 つの環境を比較し、判断基準と両方のセットアップ手順を紹介する。

対象：Windows 11 で JavaScript / TypeScript を書く開発者。Windows 初期セットアップ 完了を前提とする。

TL;DR

経験則：本番は Linux がほとんど。WSL2 で開発すれば本番と一致する。強い理由がなければ WSL2 を選ぶ。

前提条件

• Windows 11 22H2 以上
• WSL2 + Ubuntu 24.04（Windows 初期セットアップ）
• Windows Terminal（オプション — windows-terminal-setup）

1. ネイティブ vs WSL2 — 根本的な違い

パフォーマンス

WSL2 の ext4 は Node が生成する「小さなファイルの大量読み取り」パターンで NTFS を圧倒する。注意：WSL2 内で Windows ファイル（/mnt/c/...）をマウントすると、ネイティブより遅くなる — §6.2 参照。

ツール互換性

デバッグ

2. 判断表

WSL2 を選ぶ場合

• 本番が Linux — Vercel / AWS / GCP / Heroku が 99% のケースをカバー
• node-gyp モジュールを多用 — sharp、canvas、@tensorflow/tfjs-node
• 高速な開発サーバー + HMR が欲しい — 日常で最も大きな差
• CI が Ubuntu / Alpine で動く — Linux でテストすれば CI が通る
• Mac ユーザーと協業 — ほぼ同一の（POSIX）環境

Windows ネイティブを選ぶ場合

• Electron デスクトップアプリのビルド — Windows バイナリを生成
• Tauri Windows ビルド — Rust + WebView2
• Windows 専用 API — COM、レジストリアクセス
• 単純な自動化スクリプト — メモ帳の自動化など
• スペックの低いマシンで VS Code Remote-WSL が遅すぎる

または両方使う

よくあるパターン：WSL2 で本業、ネイティブでサイドのデスクトップアプリ。競合なし — PATH が別々。

3. WSL2 Node.js セットアップ（推奨）

3.1 WSL Ubuntu に入る

wsl -d Ubuntu-24.04

3.2 mise で Node（推奨）

# mise（言語バージョンマネージャー）をインストール
curl https://mise.run | sh
echo 'eval "$(/home/$USER/.local/bin/mise activate bash)"' >> ~/.bashrc
exec bash
 
# Node をインストール
mise use --global node@22
node --version    # v22.x

mise の詳細：mac/dev-toolchain — Linux でも同様に動作。

3.3 または nvm

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
exec bash
nvm install --lts
nvm use --lts

3.4 または apt（システムパッケージ）

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

⚠️ apt ではバージョン切り替えが面倒で sudo に依存する。mise または nvm を推奨。

3.5 pnpm・yarn

npm install -g pnpm yarn

3.6 確認

node --version    # v22.x
npm --version
pnpm --version
which node        # ~/.local/share/mise/installs/node/22/bin/node（mise の場合）

4. WSL2 + VS Code 統合

4.1 Remote-WSL 拡張

VS Code 拡張：

• WSL（ms-vscode-remote.remote-wsl）

インストール後、コマンドパレット → WSL: Connect to WSL → Ubuntu を選択。

または WSL Ubuntu 内から：

cd ~/projects/myapp
code .

VS Code が Windows 上で開き、バックエンドが WSL2 内で動作する。

4.2 効果

• node / npm / pnpm が WSL2 内で実行される
• ファイルは WSL2 の ext4 上に存在（~/projects/myapp）
• ターミナルは WSL2 bash
• デバッガーと拡張が WSL2 側で動作

Windows ファイルシステム（C:\）以下では作業しないこと — パフォーマンスが激減する。

5. Windows ネイティブ Node.js セットアップ

5.1 winget でインストール

# 最新 LTS
winget install OpenJS.NodeJS.LTS
 
node --version    # v22.x

5.2 または fnm（バージョンマネージャー）

winget install Schniz.fnm
 
# PowerShell プロファイルから自動アクティベート
notepad $PROFILE
# 追加：
# fnm env --use-on-cd | Out-String | Invoke-Expression

.nvmrc / package.json#engines.node に基づいて自動切り替えする。

5.3 または NVM for Windows

winget install CoreyButler.NVMforWindows
 
nvm install lts
nvm use lts

nvm-windows は Unix の nvm とは別プロジェクト。コマンドは似ている。

5.4 ビルドツール（ネイティブモジュールのコンパイル用）

sharp / canvas / bcrypt などをビルドするには：

winget install Microsoft.VisualStudio.2022.BuildTools

または：

npm install -g windows-build-tools  # 非推奨 — Visual Studio Build Tools を推奨

5.5 確認

node --version
npm --version
pnpm --version

6. よくある落とし穴

6.1 両方インストール → どちらが動くか混乱

WSL2 に独自の node、Windows に独自の node — ターミナルごとにバージョンが異なる。修正方法：

• WSL bash 内では WSL の Node（which node → ~/.local/share/mise/...）
• PowerShell ではネイティブ Node（Get-Command node → C:\Program Files\nodejs\...）
• VS Code のターミナルのデフォルトを固定（terminal.integrated.defaultProfile.windows: Ubuntu (WSL)）

6.2 Windows ファイルシステムマウントが遅い

WSL2 内で /mnt/c/Users/me/projects/myapp から作業 → I/O が 5〜10 倍遅くなる。

# 遅い
cd /mnt/c/Users/me/projects/myapp
npm install
 
# 速い
cp -r /mnt/c/Users/me/projects/myapp ~/projects/
cd ~/projects/myapp
npm install

既存の Windows フォルダプロジェクトは一度 WSL2 に移行する。

6.3 改行コード（CRLF vs LF）

WSL2 で編集 → コミット → 同じファイルを Windows で開く → CRLF が注入される。修正方法：

git config --global core.autocrlf input    # WSL2 内

詳細：/multi-os/git-line-endings。

6.4 npm install -g で EACCES

# WSL2 内 — npm プレフィックスを変更
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH=$HOME/.npm-global/bin:$PATH' >> ~/.bashrc
exec bash

Windows ネイティブでは管理者 PowerShell を使う。

7. 確認（どちらの環境を選んでも）

# WSL2 または PowerShell
node --version
npm --version
 
# package.json 作成 + 依存関係インストール + 実行
mkdir hello-node && cd hello-node
npm init -y
npm install express
cat > index.js <<'EOF'
const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('hello'));
app.listen(3000, () => console.log('http://localhost:3000'));
EOF
node index.js
# → ブラウザで localhost:3000 → 「hello」

これが動けばセットアップ完了。

8. トラブルシューティング

Cannot find module 'sharp'（または別のネイティブモジュール）

• Windows ネイティブ：Visual Studio Build Tools をインストールして npm rebuild
• WSL2：sudo apt install build-essential して npm rebuild

開発サーバーに Windows ブラウザから接続できない（WSL2）

• アプリを 0.0.0.0 または :: にバインド（例：next dev -H 0.0.0.0）
• Windows 11 22H2 以上は自動転送；それ以前は localhost 経由でアクセス

pnpm コマンドが見つからない（PATH の問題）

• npm install -g がバイナリを置く場所を特定して PATH に追加
• ネイティブ：npm config get prefix → <prefix>\bin
• WSL2：$HOME/.npm-global/bin または mise のパス

node-gyp ビルドで「Python not found」

• Windows ネイティブ：winget install Python.Python.3.12
• WSL2：sudo apt install python3 python3-pip

WSL2 から Electron をビルドできるか？

可能だが複雑。Electron のパッケージングはホスト OS のアーティファクト（.exe / .app / .deb）を生成するため、Windows ビルドはネイティブ Windows に、Linux ビルドは WSL2 に属する。Electron にはネイティブ Windows を推奨。

Next.js の開発サーバーが再起動し続ける（WSL2）

/mnt/c/ 以下では作業しないこと（§6.2）。turbopack を使うか next.config.ts に webpackDevMiddleware オプションを設定する。

9. 次のステップ

• WSL2 で Docker — /windows/docker-wsl2
• WSL チューニング（メモリ・CPU・ネットワーク）— /windows/wsl-tuning
• Windows 初期セットアップ — /windows/initial-setup
• Mac での同様のセットアップ — /mac/dev-toolchain（mise は同じように動く）

参考リンク

• Node.js 公式
• mise 公式
• fnm on GitHub
• VS Code WSL ドキュメント

更新履歴

• 2026-05-16：初稿。WSL vs ネイティブ比較 + 両方のセットアップ手順 + 4 つの落とし穴 + 6 つのトラブルシューティング。