SSD Nodes Learn 🎉 VPS $5.50/月〜
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-21

WSLとVPSの違いと開発での使い分け

WSLとVPSは稼働時間、公開IP、systemd、ファイル速度、バックアップが異なります。WSL 0.67.6で追加されたsystemd対応とSSH接続の使い分けを解説します。

開発では WSL と VPS のどちらを使うべきか

開発で WSL と VPS のどちらを使うかは、可用性という 1 つの特性で決まります。WSL (Windows Subsystem for Linux) は、Windows セッションとともに起動し、セッションの終了時に停止する仮想マシン内で Ubuntu を実行します。VPS (virtual private server) は、ノート PC を閉じている間も稼働し続けるパブリック IP アドレス上で、同じ Ubuntu を実行します。多くの開発者は最終的に両方を使い、常に到達可能なサーバーを中心的なマシンとして運用します。

両者は Ubuntu を使用するため、オペレーティングシステムは重要な違いではありません。違うのは、稼働時間、インターネットからの到達性、systemd が保証できること、ファイルアクセスの速度、ネットワークの動作、バックアップの管理者です。以下の各セクションでは、それぞれの違いを自分のマシンで実際に確認できます。

ノート PC を閉じると WSL が停止するのはなぜですか？

WSL 2 は、Windows が必要に応じて起動する軽量な仮想マシン内で、実際の Linux カーネルを実行します。この仮想マシンはディストリビューションの実行中だけ存在し、ディストリビューションは何かが使用している間だけ実行されます。PowerShell から状態を確認します。

wsl --version
wsl --list --running

すべての WSL ターミナルを閉じて 1 分待ち、もう一度 wsl --list --running を実行します。実行中のディストリビューションがないと表示された場合、起動したシェルは終了しており、そのシェルで実行していた処理もすべて終了しています。wsl --shutdown はこれをすぐに実行します。再起動後に環境がどのように動作するかを確認する方法として便利です。

スリープと休止状態にすると、仮想マシンも停止します。03:00 にデータベースをダンプするよう設定したタイマーは、蓋を閉じている間は実行されません。処理を実行するカーネルが動作していないためです。エラーも記録されないため、そのジョブは最初からスケジュールされていなかったように見えます。この動作が、別のマシンを用意するきっかけになります。ビルドキュー、チャットボット、夜間バックアップ、Webhook 受信処理はいずれも、電源が入ったままのコンピューターを必要とします。

systemd は WSL で動作しますか？

動作します。WSL 0.67.6 でサポートが追加されました。古いインストールでは、デフォルトで無効になっています。これを有効にしない場合、systemctl status ssh は次を出力します。

System has not been booted with systemd as init system (PID 1). Can't operate.

まず設定ファイルを確認してください。すでに設定が存在する場合があります。[boot] セクションがなければ追加します。存在する場合は、既存のセクション内に次の 1 行だけを追加します。

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

PowerShell で wsl --shutdown を実行し、新しい Ubuntu シェルを開いてから、systemctl list-units --type=service --state=running で確認します。ユニットの一覧が表示されれば、systemd が PID 1 として動作しています。その時点から journalctl -b が機能します。

注意すべきなのは、enable が各マシンで保証する内容です。VPS では、sudo systemctl enable --now caddy はサービスがブート時に起動することを意味します。そのため、誰もログインしていなくても、再起動後やカーネルのアップグレード後にサービスが起動します。WSL では、サービスはディストリビューションの起動時に起動します。そしてディストリビューションは、ターミナルを開いたときに起動します。つまり、サービスは作業中だけ起動します。これは、サービスが存在する理由とは逆です。コンテナーにも同じ制約があります。そのため、Docker Compose サービスをブート時に起動する設定は、WSL が要求されたときにだけ実行するブートに依存します。

WSL で実行しているサーバーに webhook から到達できますか？

そのままでは到達できません。原因はネットワーク構成にあります。デフォルトでは、WSL 2 は仮想マシンを専用の仮想アダプター上の NAT（network address translation）の背後に配置します。アドレスを確認します。

ip -4 addr show eth0
ip route show default

このアドレスはプライベートアドレスです。仮想マシンを起動するたびに再割り当てされるため、変わります。Windows 自体は WSL が localhost 接続をディストリビューションへ転送するため、localhost:3000 には到達できます。同じネットワーク上の別のマシンからは到達できません。Administrator PowerShell でプロキシルールを追加する必要があります。

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

このルールは 1 つのアドレスを指定するため、アドレスが変わると機能しなくなります。より適した方法は Mirrored networking です。ディストリビューションが Windows と同じインターフェイスとアドレスを取得します。2026 年 8 月時点では、Windows 11 22H2 以降が必要です。%UserProfile%\.wslconfig に次の内容を追加し、wsl --shutdown を実行します。

[wsl2]
networkingMode=mirrored

Mirrored mode により、ローカルネットワークの問題は解消します。ただし、パブリックアドレスが付与されるわけではありません。ルーターが再び NAT を行い、多くの家庭向け接続では、利用者が制御できる受信ポートがありません。さらに、多くの ISP はその上に別の NAT 層を追加します。そのため、GitHub はノート PC にイベントを POST できず、同僚もデモのリンクを開けません。トンネルサービスを使えば回避できますが、トンネルクライアントはノート PC 上で動作します。つまり、ノート PC を起動したままにする必要があります。

VPS は、この問題とは反対側から始まります。VPS にはパブリック IPv4 アドレスがあり、通常はパブリック IPv6 アドレスもあります。開放するポートだけを受信可能にできます。A レコードを VPS に向け、80 と 443 を許可すれば、どこからでも応答できます。これはパブリック証明書を取得するための条件でもあります。HTTP-01 チャレンジでは、Let's Encrypt がパブリック名の port 80 経由でファイルを取得するためです。Certbot と nginx で Let's Encrypt 証明書を取得する作業はサーバー上なら 5 分で完了しますが、WSL では不可能です。ローカル作業では、独自 CA を Ubuntu の trust store に追加することで、WSL 内でもブラウザーが信頼する HTTPS を利用できます。

/mnt/c で git が遅いのはなぜですか？

ファイルが Linux のファイルシステム上にないためです。WSL には、アクセスコストが大きく異なる 2 つのストレージ領域があります。ホームディレクトリは仮想ディスク内の ext4 ファイルシステム上にあり、通常の Linux ディスクと同じように動作します。/mnt/c は Windows 側のコンポーネントが 9P プロトコル（Plan 9 filesystem protocol）で提供する Windows ドライブです。そのため、すべての open と stat が境界を越えます。

1 つのファイルなら問題ありません。git status は大規模なリポジトリで数千回の stat 呼び出しを行うため、呼び出しごとに境界を越えるコストが発生します。誰かの数値を、たとえこのページの数値であっても鵜呑みにせず、実際に測定してください。

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

各コマンドを 2 回ずつ実行し、2 回目の結果を比較してください。これにより、両方ともキャッシュが温まった状態になります。Windows のリアルタイムウイルス対策スキャンは /mnt/c 側でさらにコストを発生させます。そのため、同じリポジトリでも個人用ノート PC より会社支給のノート PC のほうが遅く感じることがあります。

WSL 内での対策は、作業コピーを ~ 以下に置き、エディターの WSL remote mode で開くことです。このモードでは、境界を越えてアクセスするのではなく、ディストリビューション内でエディターサーバーを実行します。Explorer から \\wsl.localhost\Ubuntu\home\you にあるファイルを引き続き参照することもできます。VPS ではファイルシステムが 1 つで Linux なので、この問題は発生しません。VPS で発生するコストは、編集中のネットワーク遅延です。そのため、ターミナルマルチプレクサーまたはリモートエディターセッションを使って作業します。小規模サーバーでは CPU を共有する点が避けられない注意点です。負荷の高い隣接ユーザーによる steal time は top の st 列に表示されます。

WSL が明確に優れる点

  • 無料で、すでにマシン上にあります。有効化して Ubuntu をインストールすれば、支払いも公開面の防御も必要なく、1 分で作業を始められます。
  • サーバーにはない使い捨てやすさがあります。wsl --export Ubuntu D:\wsl-backups\ubuntu.tar はディストリビューション全体を 1 つのファイルに書き出し、wsl --import はそれを復元するか、別名で複製します。ここで新しい Ubuntu リリースを試す場合は、複製とロールバックで済みます。一方、VPS を 24.04 から 26.04 にアップグレードする場合は一方向の変更であり、すでに稼働しているサービスを考慮して予定を組む必要があります。
  • GPU の利用を直接行えます。最新の Windows GPU ドライバーがあれば、ディストリビューション内から GPU を利用できるため、すでに所有しているハードウェアで CUDA や ROCm のワークロードを実行できます。同等クラスの GPU を時間単位で借りるには、実際の費用がかかります。
  • 編集から確認までのサイクルが短くなります。ファイルとブラウザーがどちらもローカルにあるため、localhost:5173 上の開発サーバーを、すでにサインインしているブラウザーで開けます。

これらは実際の利点です。そのため、通常の答えは 1 台ではなく両方のマシンを使うことになります。

バックアップの所有者は誰ですか？

どちらのマシンでも、管理するのはあなたです。WSL では、この点に気付いていない人が多くいます。ディストリビューションは、Windows のユーザープロファイル内にある仮想ディスクファイル（ext4.vhdx）です。プロバイダーが自動でスナップショットを取得してくれるわけではありません。wsl --unregister Ubuntu を実行すると確認なしで削除され、元に戻せません。Windows を再インストールすると、他のデータとともにこのファイルも失われます。実際に継続できるスケジュールでエクスポートしてください。

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

VPS では、プロバイダーのスナップショットによってホスト障害から復旧できます。ただし、rm -rf を誤ったディレクトリで実行した場合の保護にはなりません。また、サーバーと同じアカウントに保存したスナップショットは、ログイン情報を盗まれるだけでサーバーと一緒に失われる可能性があります。ファイル単位のバックアップをサーバー外へ転送し、必要になる前に 1 つ復元して確認してください。どちらの場合も、責任はあなたにあります。実務上の違いは、サーバーなら、誰かがノートパソコンを開いたままにしておく必要なく、03:00 に自分でバックアップを転送できることです。

WSL から VPS へ SSH 接続する橋渡し

2 台目のマシンは、接続を適切に設定するまで手間に感じます。WSL 内で 1 度だけ設定してください。

Windows 側ではなくディストリビューション内で鍵を生成します。これにより、秘密鍵を ssh が受け入れる Unix 権限付きの ext4 ファイルシステム上に保持できます。

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ed25519 鍵は短く高速です。ssh-copy-id はサーバー上の ~/.ssh/authorized_keys に公開鍵を適切なモードで追加します。後で鍵をローテーションまたは失効させる方法については、SSH 鍵管理の基本を参照してください。

~/.ssh/config にサーバー名を設定します。

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

これで ssh dev が接続します。IdentitiesOnly yes は、保持しているすべての鍵をクライアントが提示する動作を停止します。agent に複数の鍵が読み込まれている場合に Too many authentication failures が発生するのを防げます。ServerAliveInterval 30 は、ホーム接続上のセッションがメッセージなしに切断されるのを防ぎます。

ForwardAgent yes が、この作業を簡単にする設定行です。ノート PC の agent に鍵を読み込んでおけば、秘密鍵をサーバーに置かずに git clone git@github.com:you/app.git でサーバー上の作業を実行できます。VPS から ssh -T git@github.com を実行して確認してください。Hi you! You've successfully authenticated と返れば正常です。接続中は、そのサーバーを信頼できる場合にだけ agent forwarding を使用してください。そのマシンの root は、接続中に agent socket を使用できるためです。他のユーザーと共有するサーバーでは、リポジトリ単位の deploy key のほうが安全です。

WSL はシェル間で agent を維持しないため、新しいターミナルを開くたびに鍵を再入力する必要があります。keychain で解決できます。

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

新しいシェルを開き、ssh-add -l を実行します。鍵のフィンガープリントが表示されます。Error connecting to agent と表示される場合は、その行が読み込まれていません。シェルが実際に ~/.bashrc を source していることを確認してください。

接続が切れても作業が終了しないように、サーバー上の作業は terminal multiplexer 内で実行します。

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

ノート PC を閉じても build は継続します。これが 2 台目のマシンを使う主な理由です。同じ方法で tmux で VPS 上の Claude Code を実行することができ、別のデバイスからセッションを再開できます。

何かを配置する前に、サーバーを強化してください。新しい VPS で最初の 10 分間に行うことでは、root 以外のユーザー、鍵のみを使用する SSH、firewall、自動 security update を、接続不能にならない順序で設定する方法を説明しています。

どの作業にどのマシンを使うか

作業が画面上で完結する場合は、WSL を使います。編集、テストスイートの実行、localhost 上の開発サーバー、ノートブック、GPU 実験など、起動してから自分で監視する作業が対象です。

作業を外部から到達可能にする必要がある場合や、セッション終了後も実行し続ける必要がある場合は、VPS を使います。クライアントが開けるステージング URL、webhook エンドポイント、実際の時刻に基づいて実行する cron ジョブ、bot、別のサービスが接続する小規模なデータベース、金曜日の午後に開始するインポート処理などが該当します。

2 台目のマシンの用途をまだ決めていない場合は、仕様の比較よりも実際に VPS で実行されているもののほうが有用な一覧です。仮想化の仕組みについては、VPS とは何かで説明しています。使用するツールが Windows でしか動作しない場合は別の判断が必要です。その場合は、Linux と Windows Server の比較を参照してください。

2 台のマシンが、設定が不完全な 2 台のマシンにならないようにする習慣があります。コードは git で管理し、両方のマシンをリポジトリのクライアントとして扱います。重要なものをどちらか一方だけに置かないでください。

FAQ

WSL から実ドメインで Web サイトをホストできますか？

安定して運用することはできません。WSL 2 はコンピューター内部で NAT の背後にあり、ルーターでもう一度 NAT が行われます。また、多くの家庭向け接続では、転送できる受信ポートが提供されません。トンネルサービスを使えばローカルポートを公開できますが、トンネルクライアントはラップトップ上で動作するため、ラップトップがスリープするとサイトも停止します。証明書の取得はさらに難しくなります。HTTP-01 チャレンジでは、Let's Encrypt が公開名の port 80 経由でファイルを取得する必要があるためです。公開 IP アドレスと A レコードを持つ VPS なら、回避策なしで両方の条件を満たせます。

systemctl enable は WSL で動作しますか？

systemd を有効にすれば動作します。つまり、/etc/wsl.conf の [boot] 配下に systemd=true を設定し、その後 wsl --shutdown を実行します。これを行わない場合、systemctl は System has not been booted with systemd as init system (PID 1). Can't operate. と返します。systemd が動作していても、enable はディストリビューションの起動時にサービスを開始します。ディストリビューションはシェルを開いたときに起動します。サーバーでは、同じコマンドにより、ログインしているユーザーがいなくても再起動後にサービスが復旧します。

WSL の IP アドレスが頻繁に変わるのはなぜですか？

デフォルトの NAT モードでは、仮想マシンが起動するたびに、WSL の仮想アダプターから新しいプライベートアドレスを受け取ります。そのため、netsh interface portproxy ルールやハードコードしたアドレスは wsl --shutdown 後に機能しなくなります。現在のアドレスは ip -4 addr show eth0 で確認します。Windows 11 のミラーリングネットワークモードでは、ディストリビューションに Windows と同じインターフェースを割り当てるため、個別のアドレスが不要になります。%UserProfile%\.wslconfig の [wsl2] 配下に networkingMode=mirrored を設定します。

/mnt/c は本当に遅いのですか。それとも迷信ですか？

実際に遅く、1 分のテストで自分の環境でも確認できます。~ 配下のファイルは ext4 の仮想ディスク上にあります。/mnt/c 配下のファイルは Windows 側のコンポーネントが 9P プロトコル経由で提供するため、各 stat 呼び出しが境界を越えます。また、大規模なツリーに対して git status を実行すると、数千回の呼び出しが発生します。リポジトリを ~ にコピーし、それぞれの場所で time git status を 2 回実行して、キャッシュが温まった状態の実行結果を比較します。作業コピーは ~ 配下に置き、エディターの WSL リモートモードを使用してください。

VPS があれば WSL はまだ必要ですか？

多くの人は両方を使い続けます。WSL は無料ですぐに起動するため、編集とテストの環境として使い続けられます。GPU を使う作業も WSL に適しています。サーバーは常時稼働するマシンです。公開名を保持し、ラップトップを閉じても継続する必要があるジョブを実行します。コードを git で管理し、両方をリポジトリのクライアントとして扱えば、環境間の作業移動に費用はかかりません。

#wsl#ubuntu#development#vps#workflow