【Windows Server入門 第5回】WSL2とWindows Terminal。Windows上でLinuxを飼い慣らすハイブリッド開発環境

「WindowsでLinuxコマンドが打てたらいいのに」が、現実になった。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、Windows Server標準のWebサーバー「IIS」について解説しました。
IISがカーネルモードで動作する高性能なサーバーであることは理解できたと思います。

でも、やっぱり開発や運用の現場ではこう思いませんか？
「grep や sed でログを解析したい」
「PythonやNode.jsの環境構築は、WindowsよりLinuxの方が100倍楽だ」
「GitのコマンドはBashで打ちたい」

本記事では、WSL2のアーキテクチャ、導入手順、ファイルシステムのパフォーマンス問題と回避策、そして最強の相棒「Windows Terminal」のカスタマイズまでを徹底解説します。

---

第1章：WSL2とは何か？ 「エミュレータ」ではない革命

WSLには「WSL1」と「WSL2」があります。
名前は似ていますが、中身は別物です。

WSL1：システムコール変換方式

Linuxのシステムコールを、Windowsカーネルが理解できるAPIにリアルタイムで変換して実行する方式です。
Wineの逆バージョンと言えます。
メリット： Windowsファイルシステムへのアクセスが高速。
デメリット： 完全な互換性がなく、Dockerなどが動かない。

WSL2：軽量仮想マシン方式（現在の主流）

Hyper-Vの技術を応用した「軽量ユーティリティVM」の中で、本物のLinuxカーネルを動かす方式です。
VMと言っても、起動は1秒足らず。メモリも動的に確保・解放されます。
メリット： Linuxと100%互換（Dockerも動く）。Linux内部のファイルシステムが爆速。
デメリット： Windowsファイルシステム（/mnt/c）へのアクセスが遅い。

---

第2章：WSL2のインストールとセットアップ

Windows 10 バージョン2004以降、またはWindows 11、Windows Server 2022であれば、インストールは驚くほど簡単です。

コマンド一発でインストール

PowerShellを「管理者として実行」し、以下のコマンドを入力します。

wsl --install

これだけで、必要な機能（仮想マシンプラットフォームなど）が有効化され、Linuxカーネルがダウンロードされ、デフォルトのディストリビューション（通常はUbuntu）がインストールされます。
完了したらPCを再起動してください。

ディストリビューションの選択

「UbuntuじゃなくてAlmaLinuxがいい！」という方は、Microsoft Storeから好きなディストリビューションを入手できます。
または、コマンドで一覧を確認・インストールも可能です。

# インストール可能なリストを表示
wsl --list --online

# 特定のディストリビューションをインストール
wsl --install -d Debian

【重要】systemdの有効化

以前のWSL2では systemctl コマンドが使えないのが弱点でしたが、最新版ではサポートされています。
もし使えない場合は、WSL内の /etc/wsl.conf に以下を追記してWSLを再起動（wsl --shutdown）してください。

[boot]
systemd=true

これで、systemctl start nginx などのコマンドが実機同様に使えるようになります。

---

第3章：Windows Terminal。最強のターミナルエミュレータ

WSL2を入れても、昔ながらの「コマンドプロンプトのウィンドウ」で操作するのは苦痛です。
Microsoftが開発したオープンソースのターミナル、「Windows Terminal」を使いましょう。
（Windows 11では標準搭載されています）

Windows Terminalのここが凄い

• タブ機能： PowerShell、WSL(Ubuntu)、Command Prompt、Azure Cloud Shellを1つのウィンドウでタブ切り替え可能。
• ペイン分割： 画面を左右上下に分割して、ログを見ながらコマンドを打てる（tmux要らず）。
• GPUアクセラレーション： 高速描画で、大量のログが流れても重くならない。
• フルカスタマイズ： JSONファイルでキーバインドや配色を細かく設定可能。

プロの設定術：Nerd FontsとOh My Posh

ターミナルを「カッコよく」するのはモチベーション維持に重要です。
アイコン付きフォント「Nerd Fonts」をインストールし、PowerShellやWSLのプロンプトを「Oh My Posh」で装飾するのが今のトレンドです。

1. フォントインストール： 「Cica」や「MesloLGS NF」などのNerd FontをWindowsにインストール。
2. Terminal設定： 設定（Ctrl+,）→ プロファイル → 外観 → フォントフェイスを変更。
3. プロンプト装飾： WSL側でStarshipやOh My Poshを導入。

これで、Gitのブランチ名やステータスがアイコン付きで表示される、モダンなターミナル環境が完成します。

---

第4章：ファイルシステムの相互アクセス（/mnt/c の罠）

WSL2を使う上で、絶対に知っておかなければならないのが「ファイルシステムのパフォーマンス問題」です。
ここを間違えると、「WSL2ってなんか遅いな…」と誤解することになります。

2つのファイルシステム

1. Windows側 (NTFS): Cドライブなど。WSLからは /mnt/c/ として見える。
2. Linux側 (Ext4): WSLの仮想ディスク内。/home/user/ など。

【鉄則】クロスアクセスは最小限に！

• NGパターン： ソースコードをWindows側（C:\Users\User\Project）に置き、WSL側のコマンド（git, npm, python）で操作する。
  → 激遅です。 ファイルシステム間の変換オーバーヘッドがかかるため、ビルド時間が数倍〜数十倍になります。
• OKパターン： ソースコードはLinux側（~/Project）に置く。
  → 爆速です。 Linux本来のパフォーマンスが出ます。

WindowsからLinuxファイルへのアクセス

「でもLinux側にファイルを置いたら、エクスプローラーで編集できないじゃん」
いいえ、できます。
エクスプローラーのアドレスバーに \\wsl$ と入力してください。
起動中のディストリビューションがネットワークドライブのように表示され、Linux内のファイルを直接読み書きできます。

VS Code Remote – WSL の活用

これが最強のソリューションです。
VS Codeに「WSL」拡張機能を入れると、VS Code自体はWindowsで動いていながら、バックエンドの処理（ファイル操作、ターミナル、デバッガ）だけをWSL内で行うことができます。
WSL内のディレクトリで code . と打つだけで、Windows側のVS Codeが立ち上がります。
これにより、「ファイルはLinux内（高速）、エディタはWindows（快適）」という理想的な環境が実現します。

---

第5章：実践！Windows Serverでのコンテナホスト活用

WSL2はWindows 10/11だけの機能ではありません。
Windows Server 2022でも利用可能です。

Docker Desktop vs Docker Engine

開発機（Windows 10/11）では「Docker Desktop」を入れるのが簡単ですが、商用利用でのライセンス変更（有料化）が話題になりました。
また、サーバーOS上でGUIアプリであるDocker Desktopを常駐させるのはリソースの無駄です。

そこで、プロは以下の構成をとります。

1. WSL2 (Ubuntu) をインストール。
2. そのUbuntuの中に、普通のLinuxと同じようにDocker Engineをインストール。
3. systemdでDockerを自動起動。

これならライセンスの心配もなく、純粋なLinux上のDockerとして運用できます。
Windows Serverが「LinuxコンテナもWindowsコンテナも動かせるハイブリッドなコンテナホスト」に変貌するのです。

メモリ消費の制限 (.wslconfig)

WSL2は、放っておくとホストのメモリを喰らい尽くすことがあります（Linuxのページキャッシュのため）。
サーバー用途で安定稼働させるために、メモリ制限を設定しましょう。

Windows側のユーザーフォルダ直下（C:\Users\Administrator\.wslconfig）に以下のファイルを作成します。

[wsl2]
memory=4GB
processors=2
swap=2GB

これでWSL2が使うリソースにキャップをはめることができます。

---

第6章：Gitの改行コード問題（CRLF vs LF）

WindowsとLinuxを行き来する開発で必ずハマるのが「改行コード」です。
WindowsはCRLF、LinuxはLF。
Gitの設定を間違えると、コミットするたびに全行変更扱いになったり、シェルスクリプトが動かなくなったりします。

推奨設定 (autocrlf = false)

WSL2をメインにするなら、「Windows側でも改行コードはLFで統一する」のがトラブルが少ないです。

# Windows側、WSL側両方で設定推奨
git config --global core.autocrlf false

「チェックアウト時はCRLF、コミット時はLF」にする input や true 設定は、WSL2環境では混乱の元です。
エディタ（VS Code）の設定も「デフォルトの改行コード：LF」にしておきましょう。

---

まとめ：WindowsとLinuxは「対立」から「融合」へ

お疲れ様でした！
第5回は、WSL2とWindows Terminalを使ったハイブリッド開発環境について解説しました。

今回の重要ポイント：

• WSL2は軽量VM上の本物のLinux。Dockerもネイティブに動く。
• ソースコードは必ずWSL側のファイルシステム（~/）に置く。
• Windows Terminal + VS Code Remote は現代の最強開発セット。
• .wslconfig でリソース制限をかけ、メモリ枯渇を防ぐ。

さて、開発環境が整ったところで、次は運用における最大の頭痛の種、「Windows Update」の話をしましょう。
「勝手に再起動してサービスが止まった！」「全台手動でアップデートするのが辛い…」
そんな悩みから解放されるための仕組みが、Windows Serverには用意されています。

次回、第6回は「更新プログラムとの戦い。WSUS構築とWindows Updateの完全制御」です。
社内LANにアップデート配信サーバー（WSUS）を立て、パッチの適用タイミングを完全にコントロールする方法を解説します。お楽しみに！