WSL入門：WindowsでLinuxを動かす最短ルート（WSL1とWSL2の違いも解説）

Windows を主軸にしながら、Linux の力を必要とする場面は想像以上に多くあります。Web サーバの挙動を手元で再現したい、CLI での運用作業を練習したい、Python やNode、Go のツール群を Linux と同じ前提で整えたい――そうした現場の「すぐに試したい」「環境差を減らしたい」という要望に対して、WSL（Windows Subsystem for Linux）は最短距離で応えます。

仮想マシンのように重いテンプレートを用意する必要はありません。デュアルブートのように起動を切り替える手間もありません。Windows のログインセッションのまま、Linux のシェルとパッケージ管理、ファイルパス、プロセス管理の流儀にそのまま触れられる――この“距離の近さ”が、継続的な学習と日々の実務に直結します。

WSL よりも手軽にBash環境を使いたい場合には Git Bash についてまとめたページや、Bashについて網羅している Bashとは も参照ください。

なぜWSLを使うのか

学び始めの人にとっては、「まずは触る」までの障壁が一気に下がります。wsl --install の一行で、必要なカーネルとディストリビューションが整い、数分後には apt update を叩いている。そこで得た慣れは、サーバ運用やクラウドの基礎体力になります。
一方で実務の開発者や管理者にとっても、WSL は“Windows デスクトップの快適さ”と“Linux ツールチェーンの互換性”を両取りできる実用解です。IDE、ブラウザ、Office、チャットはそのまま使い、裏で Linux のビルドやスクリプトを回す。ワークフローを分断しないことが、生産性の底上げにつながります。

とはいえ、選択肢は常に一つではありません。仮想マシンやデュアルブートが適する場面もあります。そこで最初に押さえておきたいのは、「何を優先したいのか」という基準です。下はよくある判断材料を一枚にまとめたものです。迷いそうなときの物差しとして手元に置いてください。

Bash道として重視するのは、「実務で迷わない土台を、最小の手間で築く」ことです。
WSL はそのための強力な入口であり、学習フェーズでも運用フェーズでも“今すぐ手を動かす”を助けます。

この先では、最短ルートで WSL を導入し、日々の「環境＆ワークフロー」に違和感なく溶け込ませるための要点を、手順と考え方の両面から整理していきます。

WSLとは

WSL（Windows Subsystem for Linux）は、Windows 上で Linux 環境をほぼそのまま扱えるようにする仕組みです。Linux のユーザー空間を Windows に載せるという発想自体は初期からありましたが、現在の主役は WSL2 です。WSL2 は軽量な仮想マシン上で本物の Linux カーネルを動かす方式を採用し、互換性の高さと実用速度の両立を実現しています。ターミナルを開けば Bash が立ち上がり、apt でパッケージを入れ、systemd 前提のツールも動く。Windows 側のエディタやブラウザをそのまま使いながら、裏は Linux という二重生活が自然に回り始めます。

初期の WSL1 は、Linux のシステムコールを Windows の呼び出しに翻訳するユーザーモードのレイヤーで構成されていました。軽さは魅力でしたが、カーネル機能に依存するツールやコンテナ周りで「動かない」「挙動が違う」に悩むことがありました。対して WSL2 は Hyper-V テクノロジに基づく軽量 VM 上で Linux カーネルを直接動かすため、互換性面の壁が一気に低くなります。Docker などのコンテナ、inotify を多用する開発ツール、ネットワーク挙動の再現性など、実務で効く違いが積み上がります。

選択の基準は難しくありません。よほどの事情がない限り、WSL2 を選びます。Bash道の観点では、学習でも運用でも「できないことが少ない」選択が最終的な近道です。翻訳レイヤーで頑張るより、最初からネイティブカーネルに寄せる。これがワークフローの詰まりを減らし、記事やドキュメントどおりの手順が通る確率を上げます。

違いを短く整理しておきます。判断に迷ったときの確認用にどうぞ。

WSL の本質は「Windows を捨てずに Linux を手に入れる」点にあります。IDE、Teams、ブラウザ、Office――日常の道具はそのまま。必要なときだけ Linux の殻に手を入れて、ビルドやスクリプト、検証を即座に走らせる。分断の少ない作業動線が、疲れを増やさずアウトプットを増やします。Bash道では、この“近さ”を最大限に活かす設計を前提に、以降の手順や整備のポイントを積み重ねていきます。

導入の前提条件と準備

WSL は「入れてすぐ動く」ことが魅力ですが、はじめの数分でつまずかないために、土台を整えておくと後の体験が変わります。ここでは、対応バージョンの確認、仮想化機能の有効化、初期の設定方針という三つの観点で準備を済ませます。どれも難しくはなく、作業としては Windows の再起動が一度挟まる程度です。

まずは Windows の対応状況です。Windows 11 は基本的にそのまま対象、Windows 10 はバージョンとビルド番号の条件があります。確認はスタートメニューで「winver」と入力して表示されるダイアログが一番手早いでしょう。企業管理下の PC では更新ポリシーで止まっていることもあるので、必要なら IT 管理者に相談します。

次に、仮想化の前提です。WSL2 は軽量 VM 上で Linux カーネルを動かすため、「仮想マシンプラットフォーム」機能が必要になります。家庭用 PC なら多くが既定で使えますが、BIOS/UEFI で仮想化支援（Intel VT-x / AMD-V）が無効だと起動しません。タスクマネージャーの［パフォーマンス］→［CPU］に「仮想化：有効」と表示されていればクリア。無効であれば一度再起動して BIOS/UEFI 設定から有効化します。Windows の機能自体は「Windows の機能の有効化または無効化」からチェックを入れる方法のほか、管理者ターミナルでコマンド一発でも設定できます。

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

ここまで済んだら、WSL の既定バージョンを 2 に寄せておくと後が楽です。管理者としてターミナルを開き、次の一行を実行しておきます。

wsl --set-default-version 2

環境の準備でもう一つ意識しておきたいのは、ストレージとネットワークの前提です。ディストリビューション本体の容量は大きくありませんが、パッケージやビルド成果物を置き始めると数 GB 単位で膨らみます。C ドライブの空き容量は 20GB 程度を目安に確保し、Windows と WSL 間で大きなファイルを頻繁に行き来させる計画なら、後述の「配置方針」に備えておきます。ネットワークは通常の Windows の接続がそのまま使われますが、社内プロキシや VPN を通す場合は /etc/apt/apt.conf.d/ や環境変数の設定が必要になることが多いので、利用形態を頭の片隅に置いてください。

最後に、権限と再起動の扱いです。インストールや機能の有効化では管理者権限のターミナルが求められる場面があります。スタートボタンを右クリックして「ターミナル（管理者）」を選ぶやり方に慣れておくと、迷いが減ります。機能有効化の直後は再起動をはさむのが安全で、ここを惜しまないことが安定への近道です。準備が整ったら、いよいよ導入の最短ルートに進みます。

インストール手順（最短ルート）

前提条件が整ったら、いよいよ実際のインストールに進みます。方法は大きく分けて二つあります。ひとつはコマンドラインからの一括導入、もうひとつは Microsoft Store を経由する導入です。どちらも最終的に入るものは同じですが、作業の感覚は少し異なります。最短で環境を立ち上げたいならコマンドライン、ストアアプリから手順を追って進めたいなら Store を選ぶと良いでしょう。

最も簡単なのは、管理者権限でターミナルを開き、次の一行を実行する方法です。

wsl --install

これだけで WSL2 と Ubuntu が同時に導入されます。処理の途中でユーザーアカウント制御（UAC）のダイアログが表示されるので「はい」を選び、Windows が再起動を促してきたら素直に再起動します。再起動後は自動的に Ubuntu のダウンロードと初期設定が始まり、数分の待機で Linux のログイン画面にたどり着けます。

もう一つの方法は、Microsoft Store から導入するやり方です。ブラウザで https://aka.ms/wslstorepage にアクセスすると、Store アプリが「Windows Subsystem for Linux」のページを開きます。そこで［入手］または［インストール］を押せば、数分で WSL 本体が導入されます。この時点ではまだ Linux ディストリビューションが入っていないので、続けて「Ubuntu」などを検索してインストールします。こちらも最初の起動でユーザー名とパスワードの設定が求められます。

どちらの手順を選んでも、既定で入るのは Ubuntu です。Ubuntu は情報量が多く、パッケージの整備も進んでいるため、初学者から実務利用まで幅広く安心して使えます。とはいえ、他のディストリビューションを選びたい場合もあるでしょう。セキュリティツールが豊富な Kali Linux、企業利用で注目される AlmaLinux、軽快さを求める Debian など、多彩な選択肢があります。コマンドラインから導入する際は wsl --install -d ディストリビューション名 として明示的に指定できますし、Store なら検索ボックスから目的のものを探すことができます。

表にすると、次のような関係になります。

Bash道としての推奨は、まずはコマンドラインで Ubuntu を入れてしまうことです。理由は単純で、少ない入力で一気に環境が整い、記事や教材との整合性も高いからです。その上で必要に応じて他のディストリビューションを追加していけば、迷走せずに広げられます。インストールが終われば、いよいよ初期設定に移ります。

初期設定と基本操作

インストールが完了すると、最初に Ubuntu が立ち上がり、ユーザー名とパスワードの入力を求められます。ここで設定するのは Windows のアカウントとは別の Linux 用アカウントです。見慣れない挙動として、パスワード入力時に何も表示されない点がありますが、これは仕様であり正常です。入力して Enter を押せば登録されます。このアカウントは以後、Ubuntu 内での標準ユーザーとなり、sudo を使うときに入力を求められるパスワードにもなります。

初期化が終われば、いよいよシェルが使える状態になります。まず確認したいのは WSL のバージョンとインストールされているディストリビューションです。ターミナルで次のように打ち込むと一覧が出ます。

wsl -l -v

ここに「VERSION」が表示され、2 であれば WSL2 が有効になっています。複数のディストリビューションを入れている場合は、この表で状態を整理できます。既定のディストリビューションを変えたいときは、次のように指定します。

wsl --set-default <ディストリビューション名>

また、もし意図せず WSL1 で動いているディストリビューションがあれば、次のコマンドでバージョンを切り替えることができます。

wsl --set-version <ディストリビューション名> 2

ここまで整うと、Windows と Linux の間でのファイル操作も試してみたくなります。WSL 上では、Windows のドライブが /mnt/c/ や /mnt/d/ としてマウントされています。たとえば cd /mnt/c/Users/ と移動すれば、エクスプローラで見ている C ドライブのユーザーフォルダにアクセスできます。逆に、Windows 側からはエクスプローラのアドレスバーに \\wsl$\Ubuntu と入力すれば、Linux 側のファイルシステムを直接参照できます。開発中のプロジェクトをどちらに置くかは後のパフォーマンスに影響するため、用途に応じて整理しておくと良いでしょう。

表にすると、よく使う初期コマンドは次のようにまとまります。

初期設定を済ませ、基本操作に慣れておくことで、学習や実務の立ち上がりがぐっと滑らかになります。余計な戸惑いをなくし、使いたいツールやコマンドにすぐ移れるようにしておくことが、WSL を長く活かす第一歩です。

使い始めの整備（最小セット）

環境が起動してすぐにコマンドを叩けるようになったとしても、そのままでは古いパッケージが混ざった状態であることが多いです。まず最初に実行すべきは、パッケージリストの更新とインストール済みソフトウェアのアップグレードです。Ubuntu であれば以下の一行を実行するのが定石です。

sudo apt update && sudo apt upgrade

最初に入力を求められるのは Ubuntu 用に設定したパスワードで、正しく入力すると更新が始まります。途中で「続けますか？」と尋ねられるので y を押せば処理が進みます。これにより、セキュリティ修正や不具合改善が反映された最新の状態に整えることができます。

次に触れておきたいのは、よく使うコマンドの確認です。ls や cat など基本的なファイル操作のコマンドがどのように動くかを確かめるのも良いですが、実務や学習で効率を高めるためには少しずつ自分の環境を整えることが有効です。たとえば、履歴検索を強化する fzf、表示を見やすくする bat、あるいはカラー表示をサポートする ls --color の設定などを導入するだけでも快適さが増します。設定は .bashrc や .zshrc に追加して、毎回の作業が自分仕様で始まるようにすると習慣化しやすくなります。

エディタや統合開発環境との連携もここで整えておくとスムーズです。特に Visual Studio Code は「Remote – WSL」という拡張を提供しており、WSL 内のファイルを Windows 側の VSCode から直接開いて編集できます。これにより、Linux 側のパスやライブラリをそのまま利用しながら、普段の Windows デスクトップと同じ編集体験が得られます。初学者が最初につまづきやすい「Windows と Linux のどちらで作業するのか」という問題も、この仕組みを導入すれば大きく軽減されます。

さらに整備を進めるなら、プロンプトにユーザー名やディストリビューション名、カレントディレクトリを分かりやすく表示するように設定すると安心です。複数のシェルを開いた際にも、今どこで作業しているかを一目で把握できます。これも .bashrc のカスタマイズで簡単に行えます。

最小セットの整備は、見栄えや遊びではなく「学習を滞らせないための地ならし」と捉えてください。パッケージを最新にして、よく使う道具を手元に置き、エディタとつなげて迷いをなくす。この基本を押さえることで、次のステップであるワークフローへの組み込みが自然に進むようになります。

実務ワークフローへの組み込み

環境が整ったら、次は日常の作業の流れにどう組み込むかを考える段階です。WSL は「動いた」で終わりではなく、Windows と Linux の役割をうまく切り分けることで真価を発揮します。ここではプロジェクトの配置、秘密情報の管理、そして運用の最小パターンについて整理します。

まず意識しておきたいのは、プロジェクトの置き場所です。Windows 側の C:\Users\... にソースコードを置き、それを /mnt/c/Users/... 経由で編集することも可能ですが、I/O の多いビルドやテストでは速度低下が目立ちます。安定性と速度を優先するなら、Linux 側のホームディレクトリ（~/projects など）に配置し、VSCode の Remote-WSL で開くのが基本です。どうしても Windows のアプリと直接やり取りする必要があるファイルだけを共有フォルダに置く、という整理が無駄を減らします。

次に、Git や SSH 鍵、環境変数といった秘密情報の扱いです。Windows と Linux で別々に鍵を管理すると混乱のもとになるため、どちらかに寄せて統一するのが良いでしょう。多くの場合は WSL 側に .ssh ディレクトリを置き、リモートリポジトリやサーバー接続は Linux から行うのがスムーズです。その上で、Windows 側のアプリからも同じ設定を参照させたい場合はシンボリックリンクや VSCode の設定で橋渡しをすれば十分対応できます。環境変数も .bashrc などで定義して、常に同じ値が呼ばれる状態を維持することが重要です。

実務に近い運用では、タスクの自動化やログの扱いも欠かせません。WSL 上では cron を動かすことも可能ですが、Windows 側のタスクスケジューラとどちらを使うかを考える必要があります。日常的に Linux サーバで運用する作業を再現したいなら cron を、Windows 環境に統合したいならタスクスケジューラを使う。選択基準をはっきりさせておくと、後で混乱せずに済みます。また、ログ出力は Linux 側の標準的な場所（/var/log や専用ディレクトリ）に集約させておくと、サーバ移行時にも知識が活きやすいです。

まとめると、次の三点がワークフロー統合の基本軸になります。

このように、WSL を「どこにどう位置づけるか」を早い段階で決めておくと、学習から実務への橋渡しが滑らかになります。環境の重複やファイルの散逸を防ぎ、Windows と Linux の両面を無理なく使える流れができれば、日常の作業そのものがストレスなく進むようになります。

トラブルシューティング

どんなに手順を守っても、環境構築の場面では思わぬエラーに遭遇します。WSL も例外ではありません。むしろ Windows 側と Linux 側の仕組みが絡み合う分、慣れないと原因が見えづらいことがあります。ここでは代表的なつまずきと、そのときにどう考え、どう動けばよいかを整理します。

最初に多いのは「インストールそのものが失敗する」ケースです。仮想化支援機能が無効になっていると、wsl --install を実行しても進みません。この場合は、タスクマネージャーで「仮想化：有効」になっているかを確認し、無効であれば BIOS/UEFI から有効にするのが解決策です。もうひとつは、管理者権限でターミナルを開いていない場合。機能の有効化やディストリビューション導入は管理者モードが必須なので、スタートボタン右クリックから「ターミナル（管理者）」を選ぶ習慣をつけると回避できます。

次に遭遇しやすいのは「ネットワーク関連の不具合」です。WSL 内から apt update をすると接続エラーが出る場合、企業ネットワークのプロキシ設定や VPN が影響していることが少なくありません。Linux 側で /etc/apt/apt.conf.d/proxy.conf に環境変数を設定したり、.bashrc に http_proxy を追加したりすることで解決できます。また、DNS 解決がうまくいかないときは、/etc/resolv.conf の内容を手動で書き換えることで改善する場合があります。再起動や wsl --shutdown でのリセットを試すことも基本的な対応です。

時間が経ってから現れる問題としては、「古い Ubuntu がそのまま残っている」ことがあります。サポートが切れたバージョンを使い続けるのはリスクなので、アップグレードを実行するのが安全です。具体的には以下の手順です。

sudo apt update && sudo apt upgrade
sudo apt dist-upgrade && sudo apt install update-manager-core
sudo do-release-upgrade

これで段階的に LTS の新しいバージョンへ移行できます。もし Prompt=never が原因でアップグレードが始まらない場合は、設定ファイルを書き換えて LTS アップグレードを許可する必要があります。

さらに押さえておきたいのは「どうしても直らないときのリセット」です。WSL はディストリビューション単位でアンインストール・再インストールが可能なので、破損してしまった環境は潔く作り直した方が速い場合があります。重要なデータや設定は /home 以下をバックアップしておき、新しい環境に戻せば被害は最小限にできます。wsl --unregister <ディストリビューション名> で削除し、再度インストールし直すのが基本です。

このように、トラブルに遭遇したときは「機能が有効か」「権限は十分か」「ネットワークは通っているか」「バージョンは古すぎないか」という四つの視点で切り分けると、原因にたどり着きやすくなります。Bash道の観点では、エラーを単なる壁ではなく「環境理解を深めるきっかけ」と捉えることが重要です。仕組みを知れば、次に同じ問題に出会ったときは自分で切り抜けられるようになります。

発展活用（必要に応じて）

基礎を固めてワークフローに組み込めるようになったら、次の一歩として「発展的な活用」に進むことができます。これは必須ではありませんが、利用の幅を広げることで WSL がより実用的な武器になります。ここでは代表的な三つの方向性を紹介します。

ひとつ目は GUI アプリケーションの利用 です。従来の WSL は CUI（コマンドライン）中心でしたが、WSLg という仕組みの登場で Linux の GUI アプリも Windows 上でそのまま動かせるようになりました。例えば Linux 版のブラウザや軽量エディタ、画像ビューアなどを直接起動できます。Ubuntu 内で gedit を立ち上げ、Windows のウィンドウとして扱える体験は、仮想マシンとは違う自然さを持っています。グラフィカルツールとシェルを組み合わせて学習や検証を進めたい人には特に有効です。

ふたつ目は GPU 活用 です。AI や機械学習の分野では、GPU を用いた処理が欠かせません。WSL2 は GPU のパススルーに対応しており、NVIDIA の CUDA を利用した演算や、PyTorch・TensorFlow などのフレームワークを Linux 環境でそのまま動かすことができます。Windows デスクトップを維持しながら、学習や推論を Linux で実行できるのは、研究や検証を行う開発者にとって大きな利点です。

三つ目は 複数ディストリビューションの併用 です。WSL では Ubuntu だけでなく、Debian、Kali Linux、AlmaLinux などもインストールできます。開発用途とセキュリティ検証用途を分けたい、最新の実験的な環境と安定した LTS 環境を同時に持ちたいといったニーズに対応できます。wsl -l -v でインストール済みの環境を一覧でき、wsl --set-default <名前> で既定の環境を切り替えることも可能です。状況に応じて使い分けることで、柔軟な検証環境が手元に整います。

このような発展的な利用は「必ずやるべきこと」ではありません。しかし、学びを深める過程で自然に関心が向かう領域でもあります。WSL を導入した段階では基礎的な操作を習慣にすることを優先し、その後で GUI や GPU、複数環境といった広がりを試すと、負担なくステップアップできます。Bash道としては、「一歩進んだら戻って基礎を確認する」姿勢を忘れずに、必要に応じて発展活用を取り入れることを勧めます。

まとめと次の一歩

WSL は「Windows を捨てずに Linux を使う」ための、いちばん摩擦の少ない入口です。インストールは一行、起動は一瞬、そして学びや実務に必要な互換性が揃っています。Bash道の観点で重要なのは、導入それ自体ではなく、日々の環境＆ワークフローに“自然に溶け込むか”です。最短ルートで入れ、最小セットで整え、配置方針と秘密情報の扱いを早めに決めておく――これだけで、学習も検証も失敗しづらくなります。

ここまでの内容を、実践の踏み台として短い点検表にまとめます。迷ったときは立ち戻り、詰まったら原因切り分けの観点（機能・権限・ネットワーク・バージョン）で静かにほどいてください。

次の一歩は、小さくても“完了が見える”タスクに置きましょう。たとえば、~/projects に練習用のリポジトリを作り、git clone からビルド、テスト、ログ確認までを一息で通す。あるいは VSCode 連携を整え、拡張機能の設定を自分仕様にまとめる。こうした短距離の成功体験が、WSL を道具ではなく“身体の一部”に変えていきます。

学びの導線としては、コマンドの基本を抑える「学習ハブ」に戻って反復し、詰まりが出たら具体的な作業に落とした「実務レシピ」で手を動かし続けるのが効率的です。WSL の良さは、思い立ったその場で検証できる即応性にあります。今日の作業に、明日の学びに、迷わず取り入れてください。

参照リンク

• WSL のインストール | Microsoft Learn
  公式のインストール手順やコマンド一覧。常に最新情報を確認できる一次情報源です。
• Windows Subsystem for Linux ドキュメント | Microsoft Learn
  WSL の概要、機能解説、設定オプションがまとまっているドキュメント。
• Qiita: Windows に WSL2 環境を構築する手順
  日本語での導入例や VSCode との連携を含んだ実践的な記事。
• Wikipedia: Windows Subsystem for Linux
  歴史的な経緯や WSL1 / WSL2 の違いを整理する参考情報。
• WSLg (GUI アプリサポート) | Microsoft Dev Blogs
  Linux GUI アプリを Windows 上で動かす仕組みの紹介。
• WSL Community GitHub リポジトリ
  開発元である Microsoft によるソースコードと Issue トラッカー。最新の動向や既知の不具合を確認できます。