WSLでのRails / Django 開発 完全ガイド：WindowsとLinuxの違い、VS Code連携、ネットワーク公開まで

章 1 — WSL の基礎と「ファイル配置」の最適解

WSL は Windows 上に「Linux 環境」を提供する仕組みで、Windows ファイル（C:\ 等）は /mnt/c/… として Linux 側から見えます。ただし、/mnt 以下に置いたプロジェクトでは I/O 遅延や権限問題（chmod/chown が効かない等）が発生しやすく、Ruby や Node のような大量ファイル操作を伴う開発ではパフォーマンス・安定性の観点から Linux 側（/home/ユーザー）に置くのが推奨されます。また、VS Code の Remote-WSL 機能を使えば、Windows の GUI（VS Code）で Linux 側のファイルを快適に編集でき、開発体験と安定性を両立できます。下段では具体的な移行手順、コマンド例、注意点を詳述します。

1.1 WSL の仕組み：/mnt と Linux ファイルシステムの違い

ポイント：Windows のドライブは WSL 側で自動的に /mnt/c, /mnt/d とマウントされます。これにより Windows ファイルに直接アクセスできますが、NTFS の権限体系が影響して Linux 側の標準的な権限操作が期待通りに働かない場合があります。大きな I/O を伴う開発作業は Linux 側（例：~/projects）に配置するのが速く安定します。 参考：Microsoft の Remote-WSL ドキュメント。:contentReference[oaicite:0]{index=0}

1.2 なぜ /mnt/c/… は遅い／権限エラーが起きるのか

理由：NTFS と Linux のファイル属性管理の差、翻訳層（WSL が Windows 側 I/O をブリッジする）によるオーバーヘッドが原因です。結果として、ファイル数が多い処理（bundle install、npm install、webpack ビルド等）で遅延や権限エラーが出やすくなります。対処としてはプロジェクト本体を Linux 側に移し、静的ファイルなど大きなファイルのみ /mnt に置く運用が一般的です。

1.3 実践コマンド（移行例）

 # Linux 側にプロジェクトを作成 mkdir -p ~/projects/myapp cd ~/projects/myapp
Windows 側から移動する例（Windows path -> WSL）
Windows 側のファイルをコピーする

cp -r /mnt/c/Users/matumoto-1025/project_rails3_251118/django_gateway ~/projects/myapp/

権限の調整

chown -R $(whoami):$(whoami) ~/projects/myapp/django_gateway

章 2 — VS Code と Remote-WSL を使った快適開発環境

WSL を使う際、Windows 側の VS Code（GUI）から Linux 側のプロジェクトを直接編集できる Remote-WSL 機能は非常に強力です。これにより、Linux ファイルシステム上で高速に動くツール群（Ruby, Python, Node, DB 等）を活用しつつ、Windows の使いやすいエディタと統合できます。セットアップ手順（拡張機能の導入、Remote-WSL 接続、拡張のインストール）は公式に丁寧に記載されており、それに従うだけでデバッグ・ターミナル・拡張機能すべてが WSL 側で動作します。開発体験とパフォーマンスを両立するための注意点と実践的な設定例を示します。

2.1 VS Code Remote-WSL の導入手順（簡易）

1. Windows に VS Code をインストール
2. Extensions で「Remote – WSL」をインストール
3. VS Code のコマンドパレットで「Remote-WSL: New Window」を選択
4. WSL 内のプロジェクトを開く（ファイルは /home/…）

詳細は公式ドキュメント参照。:contentReference[oaicite:1]{index=1}

2.2 開発時の便利な設定

• ターミナルのデフォルトを WSL にする（VS Code 設定）
• 拡張（Ruby、Python、ESLint、Prettier）を WSL 側にインストール
• デバッグ構成（launch.json）はプロジェクト内に置く

2.3 トラブルと対処例（拡張が効かない、権限エラー）

例：拡張が Windows 側に入っていて WSL 側で動かない → Remote-WSL 窓で拡張をインストールし直す。 例：アクセス許可エラー → プロジェクトを /home に移し chown/chmod を実行して解決。必要なら VS Code を再起動。

章 3 — Rails と Django を WSL で動かす比較

Rails（Ruby）も Django（Python）も WSL 上で問題なく動きますが、依存関係の扱いやパッケージビルドの違い、推奨されるワークフローに差があります。Rails はネイティブ拡張（gem のビルド）が入りやすく Windows 側ではエラーが出やすい一方、Django は Python 仮想環境（venv）を使えば比較的軽く導入できます。両者ともプロジェクト本体は Linux 側に置き、VS Code Remote-WSL で開発するのが最も実務的です。社内LAN での公開やポート設定、DB の配置（Linux 側 PostgreSQL 推奨）といった運用上のポイントも詳述します。

3.1 環境準備の違い（言語・パッケージ管理）

Rails: rbenv/rvm + Bundler（Gem のネイティブ拡張に注意）。 Django: python3 + venv/pip、requirements.txt や pipenv が中心。 どちらでも DB は PostgreSQL を Linux 側に入れると安定します。

3.2 開発サーバー起動とネットワーク（0.0.0.0 と localhost の違い）

開発サーバー起動例：
Rails: rails s -b 0.0.0.0 -p 3000
Django: python manage.py runserver 0.0.0.0:8000
0.0.0.0 は「全インターフェースで待ち受け」する意味で、社内 PC からアクセスする場合はこちらを使います。127.0.0.1 / localhost はローカル専用です（外部端末からは見えません）。参考：Django / runserver の挙動。:contentReference[oaicite:2]{index=2}

3.3 社内 LAN での公開（WSL2 の注意）

WSL2 は仮想化ネットワークを使うため Windows と IP が分かれるケースがありましたが、最近の Windows/WSL2 では localhost 共有などが強化されています。社内の別マシンからアクセスする場合は、Windows の実際の IP（ipconfig で確認）＋ポートを使うか、必要に応じてポートフォワーディングやファイアウォール設定の調整を行ってください。参考：ネットワーク共有に関するコミュニティ情報。:contentReference[oaicite:3]{index=3}

章 4 — 運用・セキュリティ・教育（子供ブログ含む）

開発環境とは別に、運用・セキュリティの基本を押さえることは重要です。子どもにブログを書かせる運用を想定する場合、親がサーバーとドメインを管理し、公開範囲を段階的に広げることが安全かつ教育的です。具体的には、個人情報非公開、コメント承認、プラグイン（Akismet、Wordfence 等）の導入、定期バックアップ、SSL（Let’s Encrypt）の導入などが基本。IPA 等の青少年向けネット安全教材も参考に、実践的なルールとチェックリストを作ることで学びと安全の両立が可能です。:contentReference[oaicite:4]{index=4}

4.1 子供ブログ運用の具体的手順（親管理）

1. 独自ドメイン or サブドメインを取る（親管理）
2. WordPress をインストール（Cocoon テーマ等）
3. 公開範囲は最初は限定公開→徐々に公開
4. 投稿は親が事前チェックしてから公開

4.2 セキュリティ／プラグイン推奨

• Akismet（スパム対策）
• Wordfence / iThemes Security（WAF・ログ監視）
• UpdraftPlus（定期バックアップ）
• Let’s Encrypt（無料 SSL）

4.3 教育カリキュラムの例（小学生向け）

1週目：投稿の書き方（3つのルール：個人情報を書かない、敬語・礼儀を守る、画像は親が管理）
2週目：目次/ページ内リンクの作り方（id と a href の基礎）
3週目：アクセス解析の見方（GA の基本指標）と簡単な収益化概念（広告・アフィリエイトの基本）

章 5 — トラブルシューティング集

実務で遭遇しやすいエラーとその迅速な切り分け方法をまとめます。systemd や Gunicorn のサービス化、権限エラー、ワーカー落ち（Python の SyntaxError やモジュール未検出）、systemctl の Bad message（サービスファイルの改行や不可視文字）、WSL 側でのファイルアクセス許可エラーなど、典型的な事象に対して「原因→診断コマンド→対処手順」を短く示します。問題解決の鍵はログ（journalctl / systemctl status）とエラーメッセージの一語一句を読むことです。以下に代表的な切り分け例を載せます。

5.1 systemd / Gunicorn の起動失敗の切り分け

診断：sudo systemctl status django_gateway.service と journalctl -u django_gateway.service -n 200 --no-pager を確認。
よくある原因：ExecStart のパス間違い、サービスファイルの改行・不可視文字、Python の SyntaxError（settings.py 等）。
対処：systemd-analyze verify、サービスファイルの改行チェック、手動で venv の gunicorn を起動してエラー確認。

5.2 権限エラー（Windows ↔ WSL のファイル移動時）

Windows の NTFS 側に置いたファイルでは chmod/chown が期待通りに動かないことがあり、これが権限エラーの原因になります。対処はプロジェクトを Linux 側に移動し、chown で正しい所有者にすることです。

5.3 I/O 性能問題（npm / bundle の遅さ）

/mnt に置いたまま実行すると数倍遅くなるケースがあるため、node_modules や vendor/bundle は Linux 側に置く、あるいは .dockerignore/.gitignore を適切に設定して I/O を減らす運用が効果的です。

主要コマンドと比較一覧