Windows 直入れ・WSL2・Ubuntu 直入れ・Proxmox を比較して、自宅開発基盤を考える
先に結論
すぐに開発を始めたいなら、Windows 直入れや WSL2 は今でも強い選択肢です。
特に WSL2 は、Windows を普段使いしながら Linux の開発体験を得やすく、個人開発や軽量な検証には十分です。
一方で、AI コーディングで試行錯誤が増えるほど、開発環境には「壊しても戻せること」「用途ごとに分けられること」「長く使うサービスを手元 PC から切り離せること」が重要になります。
この条件を重視するなら、Proxmox 上に Ubuntu VM を置く構成は有力です。
ただし、Proxmox は初期構築、ストレージ、ネットワーク、backup / restore、更新作業を自分で見る必要があるため、誰にでも最初から勧める構成ではありません。
この記事では、Windows 直入れ、WSL2、Ubuntu 直入れ、Proxmox 上の Ubuntu VM を比較しながら、個人・小規模事業向けの開発基盤としてどこから始めるのがよさそうかを整理します。
前提
- 対象範囲: 個人開発者、小規模事業者、副業エンジニアが使う開発・検証基盤。
- 対象範囲: AI コーディングで、試行錯誤、生成物の確認、環境分離、復旧を重視する場面。
- 対象範囲: Windows PC、WSL2、Ubuntu、Proxmox VE、Docker、Dev Containers を使った開発環境。
- 対象外: 商用本番向けの SLA 設計、HA / cluster / Ceph、複雑な SDN、外部公開ネットワークの詳細設計。
- 対象外: Proxmox のインストール手順そのもの、個別アプリケーションの構築手順。
- 必要な知識: Windows と Linux の基本操作、VM と container の大まかな違い、backup が必要になる理由。
はじめに
AI コーディングを使うようになると、コードを書く速度だけでなく、試す速度も上がります。
これはとても便利ですが、同時に「環境を壊す速度」も上がります。
言い換えると、依存関係や設定ファイルを変更する頻度が増え、環境差分が積み上がる速度も上がります。
依存 package を入れる。
Docker Compose の構成を変える。
database を作り直す。
AI に設定ファイルを書き換えさせる。
検証用のサービスを一時的に立てる。
このあたりを日常的に行うなら、開発環境には「速く始められること」だけでなく、「壊して戻せること」も必要になります。
私はローカル開発基盤を考える中で、次の 4 つを比較しました。
- Windows に直接ツールチェーンを入れる。
- Windows 上の WSL2 を使う。
- PC に Ubuntu を直接入れる。
- Proxmox 上に Ubuntu VM を作る。
結論として、日常の軽い開発は WSL2 がかなり便利です。
ただ、長く使う開発基盤、検証環境、内部 Git や local LLM（ローカルLLM）まで見据えるなら、Proxmox 上の Ubuntu VM に分けていく方が扱いやすいと判断しました。
この記事は、Proxmox の細かな構築手順ではなく、その前段にある「どの開発環境を選ぶか」の比較記事です。
比較対象
この記事では、次の 4 つを比較します。
| 選択肢 | ここでの意味 |
|---|---|
| Windows 直入れ | Windows に Node.js、Python、Git、Docker 関連ツールなどを直接入れて開発する |
| WSL2 | Windows 上で Ubuntu などの Linux 環境を動かし、Linux ファイルシステム側で開発する |
| Ubuntu 直入れ | PC の OS として Ubuntu を直接入れ、その上で開発する |
| Proxmox 上の Ubuntu VM | Proxmox VE を host にし、用途別に Ubuntu VM を作って開発する |
なお、WSL2 は Windows 上で Linux 環境を扱える仕組みであり、内部的には軽量 VM 上で Linux カーネルを動かします。
そのため、単なる互換レイヤーではなく、Linux 向けのツールチェーンをかなり自然に使える一方、ネットワークやファイルシステムまわりでは WSL2 固有の癖もあります。
ここでいう Dev Containers は、VS Code から container 内の開発環境を開き、プロジェクトごとにツールチェーンや runtime を揃えるための仕組みです。
VM で OS レベルを分離し、その中で Dev Containers によってプロジェクト単位の開発環境を揃える、という二段構えで考えています。
どれが絶対に正しい、という話ではありません。
重視するものによって、向き不向きがかなり変わります。
比較表
| 観点 | Windows 直入れ | WSL2 | Ubuntu 直入れ | Proxmox 上の Ubuntu VM |
|---|---|---|---|---|
| 手軽さ | 高い。普段の PC にすぐ追加できる | 高い。Windows を残したまま Linux 開発へ寄せられる | 中。OS 入れ替えや dual boot の判断が必要 | 低め。host 構築と VM 設計が必要 |
| Linux 開発との相性 | プロジェクトによって差が出る | 高い。Linux ツールチェーンを使いやすい | 高い。Linux を素直に使える | 高い。Ubuntu VM を用途別に用意できる |
| 環境分離 | 低め。host にツールチェーンが混ざりやすい | 中。distro 単位では分けられる | 中。host そのものが開発環境になる | 高い。VM 単位で用途を分けやすい |
| 復旧性 | 低め。PC 全体の状態に引きずられる | 中。export や再作成で戻せる余地がある | 中。backup 設計次第 | 高い。snapshot や backup / restore 方針を考えやすい |
| 再現性 | 低め。手作業が増えると差分が残りやすい | 中。setup script や dotfiles で補える | 中。構成管理次第 | 高い。template、clone、runbook と相性がよい |
| 運用負荷 | 低い。PC 管理の延長で済む | 低から中。WSL 固有の癖はある | 中。OS 更新や driver も自分で見る | 高め。ストレージ、ネットワーク、backup / restore、host 更新を見る |
| 拡張性 | 低から中。PC の状態に依存する | 中。軽量な container 検証に向く | 中。1 台の Linux machine として強い | 高い。開発 VM、外部接続の入口、内部 Git、local LLM などを増やしやすい |
| 費用 | 低い。既存 PC で始めやすい | 低い。既存 Windows PC で始めやすい | 中。専用 PC 化するなら機会損失がある | 中から高。host、storage、電気代を考える必要がある |
| 持ち運び | 高い。PC だけで完結する | 高い。PC だけでかなり完結する | 中。Ubuntu PC を持ち歩くなら可能 | 低から中。自宅基盤への接続性に依存する |
ざっくり言うと、手軽さでは Windows 直入れと WSL2 が強いです。
Linux 開発体験だけなら、WSL2 や Ubuntu 直入れでも十分です。
Proxmox が効いてくるのは、単なる「Linux が使える環境」では足りなくなったときです。
用途別に環境を分けたい。
作業前に戻しやすい状態を用意したい。
VM ごとの backup / restore 方針を考えたい。
VPN / reverse proxy / bastion などの入口用 VM、内部 Git、local LLM 用 VM を役割ごとに分けたい。
そういう長期運用寄りの要求が出てくると、Proxmox を検討する価値が出てきます。
なお、snapshot、backup、restore test の具体的な運用は、今後実環境で確認しながら整理する予定です。
この記事では、あくまで開発基盤を選ぶときに重視した観点として扱います。
抽象化した構成
実際のホスト名やネットワーク値は出さず、開発基盤としての役割だけを抽象化すると次のようになります。
ポイントは、Proxmox に全部を寄せきらないことです。
Proxmox に接続できる日は、VM 群を常設寄りの開発基盤として使います。
接続できない日や軽い作業の日は、WSL2 で文書更新、検索、軽量な build / test を続けます。
ここでは VM 名やネットワークの実値ではなく、開発基盤として分けている役割だけを示しています。
つまり、WSL2 と Proxmox は競合というより、役割分担に近いです。
Proxmox が向くケース
Proxmox が向くのは、次のような場面です。
| ケース | 理由 |
|---|---|
| 開発環境と検証環境を分けたい | VM 単位で分けると、依存関係や設定の衝突を抑えやすい |
| AI に試行錯誤させる環境を分けたい | 失敗しても戻せる前提を作りやすい |
| snapshot や backup / restore 方針を分けて考えたい | 作業前の一時保険と、復旧用 backup を別物として扱いやすい |
| 長く動かすサービスを PC から切り離したい | 普段使い PC の再起動や環境変更から独立させやすい |
| 役割ごとに基盤を分けたい | 外部接続の入口、内部 Git、local LLM などを VM として分けやすい |
| 設計判断を文書化しながら運用したい | template、inventory、runbook と組み合わせやすい |
特に AI コーディングでは、「試せること」が増えるほど「戻せること」が大事になります。
AI が悪いという話ではなく、人間でも AI でも、試行錯誤が増えれば環境差分は増えます。
その差分を PC 本体に積み上げるのか、VM に閉じ込めるのか。
この違いは、長く使うほど効いてきます。
Proxmox が向かないケース
逆に、Proxmox が向かない場面もあります。
| ケース | 理由 |
|---|---|
| とにかく今日から開発したい | 初期構築、ストレージ、ネットワーク、backup / restore の準備が必要になる |
| PC 1 台だけで完結させたい | Proxmox host を別途管理する考え方になる |
| Linux ツールチェーンが少し使えれば十分 | WSL2 の方が軽く済むことが多い |
| backup / restore 運用まで考えたくない | Proxmox の強みを活かしにくい |
| ネットワーク設計に時間を使いたくない | VM 間通信や外部入口を考えるほど設計対象が増える |
| host の更新や障害対応を見たくない | 仮想化基盤そのものの面倒を見る必要がある |
Proxmox は、開発環境を「小さな基盤」として扱いたい人には合います。
一方で、開発環境を「PC に入っているツールの集合」として軽く扱いたいなら、過剰になることがあります。
私の判断
今回、私は Proxmox を採用する方向で整理しました。
ただし、最初から大きな構成にはしていません。
今回の目的は、家庭内に小さなデータセンターを作ることではありません。
AI コーディングや個人開発で安全に試行錯誤できる、説明可能な開発基盤を作ることです。
判断は次のようなものです。
| 判断 | 理由 |
|---|---|
| 単一 node から始める | まずは説明できて、壊れたときに自分で戻せる規模にする |
| 用途別に Ubuntu VM を分ける | 開発、外部接続の入口、内部 Git、local LLM を混ぜすぎない |
OS disk と /data disk を分ける |
OS と作業データ、Docker data、サービス data を分けて扱いやすくする |
Docker の永続データを /data 側へ寄せる |
VM の OS 領域と container data の責務を分ける |
| backup / restore を先に検討する | 本格利用前に backup と restore test の方針を決めてから使い込む |
| WSL2 継続モードを残す | Proxmox に触れない日も、文書更新や軽量検証を止めない |
| HA / cluster / Ceph は初期対象外にする | 初期構築では複雑さより、理解できる運用を優先する |
WSL2 は捨てない
Proxmox を使うといっても、WSL2 をやめるわけではありません。
WSL2 は、手元で素早く動く Linux 開発環境として強いです。
repository の検索、Markdown の編集、軽量な test、Dev Containers の確認などは、WSL2 で十分な場面が多いです。
一方で、次のような作業は Proxmox 側に寄せます。
- VM の作成や削除。
- ネットワーク、backup / restore 方針の確認。
- 常設寄りの Docker / Dev Containers 環境。
- VPN / reverse proxy / bastion など外部接続の入口や、内部 Git のような、PC 本体から切り離したいサービス。
- local LLM 検証。
普段使いの軽さは WSL2 に残し、長く残したい環境は Proxmox に寄せる。
このくらいの分担が、個人・小規模事業向けには扱いやすいと感じています。
まとめ
開発環境は、最初から Proxmox にする必要はありません。
すぐ始めたいなら Windows 直入れや WSL2 が強いです。
Linux 開発体験を重視するなら、WSL2 や Ubuntu 直入れで十分なことも多いです。
ただ、AI コーディングで試行錯誤を増やすなら、環境を壊して戻せること、用途ごとに分けられること、backup / restore 方針を事前に考えておくことが重要になります。
その条件を満たす開発基盤として、Proxmox 上の Ubuntu VM は有力な選択肢です。
ポイントは、最初から HA や cluster まで広げないことです。
まずは単一 node、用途別 VM、backup / restore 方針、WSL2 との役割分担くらいから始めるのがよさそうです。
次回以降は、次のような内容を整理していきます。
- Proxmox でつくる自宅開発基盤の全体設計。
- Proxmox 上の Ubuntu VM に Docker / Dev Containers 環境を作る。
- AI コーディング用に、壊して戻せる開発環境をどう運用するか。
この記事では技術的な比較を中心に書きました。
なぜ自宅開発基盤を整えるのか、AI 活用や小規模事業の視点からの考え方は note 側に整理しています。
Discussion