2025年11月16日

ハードウェア

912 文字

ベアメタル・Docker・WSL2の環境差分｜AI開発基盤の比較と選定指針

AI開発で用いるベアメタル・Docker・WSL2を実測ベースで比較します。GPU推論性能の差は数%に収まる一方、WSL2のWindowsドライブ経由ファイルI/Oは10倍以上遅くなります。フェーズ別・用途別の選定指針を整理しました。

はじめに：環境選定がプロジェクトの成否を左右する

AI開発において「どの実行環境で構築するか」は、性能・開発効率・運用コストに直結する重要な判断です。GPU性能だけを見て選ぶと、ファイルI/Oや運用面で想定外のボトルネックに突き当たることが少なくありません。

本稿では、AI開発で広く使われる3つの実行環境を、DigitalBaseの検証データと構築実績に基づいて比較します。

ベアメタル（ネイティブLinux）：最高性能だが柔軟性に欠ける
Docker：移植性と再現性に優れるが、わずかなオーバーヘッドがある
WSL2：Windows上でのLinux開発を実現するが、独特の制約がある

技術的な特性だけでなく、実務での使い分けまで整理します。

3つの環境の基本特性

ベアメタル（ネイティブLinux）

OSがハードウェア上で直接動作する環境です。仮想化レイヤーを介さないため、ハードウェアリソースを最大限に活用できます。

代表的な構成

Ubuntu Server 24.04 LTS
NVIDIA Driver + CUDA を直接インストール
Python仮想環境（venv, uv, conda）

Docker

コンテナ技術による軽量な仮想化環境です。アプリケーションとその依存関係を「コンテナ」としてパッケージ化し、環境を問わず同一に動作させられます。

代表的な構成

Docker + Docker Compose
NVIDIA Container Toolkit（GPU対応）
公式イメージ（pytorch/pytorch, nvidia/cuda 等）

WSL2（Windows Subsystem for Linux）

Windows上でLinuxカーネルを動作させる仕組みです。Windows環境を維持しながら、Linuxツールチェーンを利用できます。

代表的な構成

WSL2 + Ubuntu 24.04
CUDA on WSL（Windows側のNVIDIA Driver経由）
VS Code Remote WSL連携

総合比較表

比較項目	ベアメタル	Docker	WSL2
パフォーマンス	◎ 最高性能	◯ ほぼネイティブ	△ GPUは良好、I/Oに難
セットアップ難易度	△ 手動設定が多い	◯ Dockerfileで自動化	◎ Windows環境なら最速
環境再現性	△ 手動管理	◎ コード化可能	◯ 一定程度可能
移植性	△ 環境依存	◎ どこでも動作	△ Windows限定
GPU対応	◎ 完全対応	◯ Container Toolkitで対応	◯ CUDA on WSLで対応
マルチプロジェクト	△ 依存衝突リスク	◎ 完全分離	◯ 仮想環境で対応
開発体験	◯ SSH経由が基本	◯ VS Code統合が良好	◎ Windowsツールと連携
本番運用	◎ 最も安定	◎ K8s等で自動化	△ 本番利用は非推奨

詳細比較：パフォーマンス

GPU推論速度

7Bクラスのモデルを batch_size=1 で推論した際の実測値です。同一GPU・同一モデル・同一量子化条件で計測しています。

ベアメタル（Ubuntu 24.04）

トークン生成速度：52 tok/s
GPU利用率：95〜98%
メモリ転送：最適

Docker（NVIDIA Container Toolkit）

トークン生成速度：50 tok/s（約4%減）
GPU利用率：93〜96%
オーバーヘッド：軽微

WSL2（CUDA on WSL）

トークン生成速度：48 tok/s（約8%減）
GPU利用率：90〜94%
Windows Driver経由のため若干の遅延

検証からの評価 GPU推論では3環境とも実用上の問題はありません。ベアメタルとDockerの差はほぼ誤差範囲です。WSL2も許容範囲ですが、大量バッチ処理では差が顕在化する場合があります。

ファイルI/O速度

最も大きな差が出るのがファイルI/Oです。

ベアメタル

ローカルSSD：最速
データローディング：基準値

Docker

バインドマウント：ほぼネイティブ並み
ボリューム：やや遅い（5〜10%）
Windows/macOS上のDocker Desktop：大幅に遅い（50%以上）

WSL2

WSL内ファイルシステム：ネイティブ並み
Windowsドライブ（/mnt/c/）：極端に遅い（10倍以上になる場合あり）

重要な注意点 WSL2では必ずLinux側のファイルシステム（/home/ 以下）で作業してください。Windowsドライブ経由は避けるべきです。大量の画像データやモデルファイルを扱う場合、この差は致命的になります。

詳細比較：セットアップと管理

初期セットアップの難易度

ベアメタル

# 手動設定が多い
sudo apt update && sudo apt upgrade -y
# NVIDIA Driver
sudo apt install -y nvidia-driver-570
# CUDA Toolkit（手順は後述）
# Python環境
sudo apt install -y python3.12 python3.12-venv python3-pip

所要時間：2〜4時間（初回）／難易度：中〜高（Linuxの知識が必要）

Docker

# Dockerfileで自動化
FROM nvidia/cuda:12.8.0-runtime-ubuntu24.04
RUN apt-get update && apt-get install -y python3.12
COPY requirements.txt .
RUN pip install -r requirements.txt

docker compose up -d

所要時間：30分〜1時間（初回ビルド）／難易度：低〜中（Dockerfileの知識が必要）

WSL2

# PowerShellで簡単インストール
wsl --install -d Ubuntu-24.04

# WSL内で通常のLinux操作
sudo apt update
sudo apt install -y python3.12

所要時間：30分程度／難易度：低（Windowsユーザーには最も簡単）

依存関係の管理

ベアメタル

利点：直接的で理解しやすい
欠点：複数プロジェクトで依存関係が衝突する
対策：Python仮想環境（venv, uv, conda）で分離

Docker

利点：完全に分離され、衝突がない
欠点：イメージサイズが大きくなりがち
対策：マルチステージビルドで最適化

WSL2

利点：Linuxツールがそのまま使える
欠点：Windows側との連携で混乱しやすい
対策：作業をWSL内で完結させる

詳細比較：開発体験（DX）

コーディング環境

ベアメタル

SSH + VS Code Remote SSH
ターミナル中心の作業、サーバーへの接続が前提
利点：安定した接続と高速性／欠点：ローカルとリモートの切り替えが煩雑

Docker

VS Code Dev Containers拡張
ローカルでコンテナ内開発、compose.yml で環境を定義
利点：環境切り替えが容易でチーム共有に向く／欠点：コンテナ再構築に時間がかかる

WSL2

VS Code Remote WSL
WindowsとLinuxのシームレスな統合、エクスプローラーからWSL内ファイルにアクセス可能
利点：Windows環境では最も快適／欠点：WSL固有の不具合に遭遇することがある

デバッグとトラブルシューティング

ベアメタル

システムログを直接確認でき、ハードウェアレベルの問題も把握しやすい
ただし環境が壊れると復旧の負荷が高い

Docker

コンテナのログが分離され、問題が起きてもコンテナを再作成すれば復旧できる
ただしネットワークやボリュームの問題は切り分けが複雑になりがち

WSL2

Windowsとの相互作用が絡むと切り分けが難しい
ネットワーク設定が扱いにくく、WSLの再起動で解決するケースも多い

ユースケース別の推奨環境

ケース1：プロトタイピング・PoC開発

推奨：WSL2 または Docker

素早く環境を構築でき、試行錯誤しやすく、環境を壊しても復旧が容易です。Windows PCで開発する個人開発者にはWSL2、チームで環境を共有する場合はDockerが適します。

ケース2：本番運用（オンプレミス）

推奨：ベアメタルまたは Docker（K8s）

最高性能と安定性を最優先し、長期運用を見据えます。単一サーバーのシンプルな構成ならベアメタル、複数サーバーやスケーラビリティ重視ならDockerが適します。

ケース3：AIモデルのトレーニング

推奨：ベアメタル

GPU性能を最大限に活用でき、長時間実行の安定性とファイルI/Oの高速性に優れます。大規模なトレーニングでは数%の性能差が積み重なり、無視できない差になります。

ケース4：推論API提供（FastAPI等）

推奨：Docker

環境の再現性が高く、スケーリングとCI/CD統合が容易で、複数バージョンの並行運用にも向きます。

構成例：FastAPI + Uvicorn / NVIDIA Container Toolkit / Docker Compose または Kubernetes

ケース5：Windows環境での個人開発

推奨：WSL2

Windowsツール（Office、ブラウザ等）と併用でき、VS Codeとの統合も良好で、セットアップが簡単です。本番展開時はDockerやベアメタルへの移行を検討します。

ケース6：クライアント先でのデモ・PoC

推奨：Docker

ノートPCにも容易にセットアップでき、環境差異によるトラブルが少なく、compose.yml を共有するだけで再現できます。

実務での注意点とTips

ベアメタルでの注意点

① システム更新によるCUDA破損

# apt upgradeでNVIDIA Driverが壊れることがある
# 対策：ドライバを固定し、カーネル更新は慎重に
sudo apt-mark hold nvidia-driver-570

② 環境が壊れた際の復旧コストが高い

定期的なスナップショット取得を推奨
重要な設定は /etc/ をバックアップ

③ マルチユーザー環境での権限管理

# GPU使用権限をグループで管理
sudo usermod -a -G video $USER

Dockerでの注意点

① GPUリソースの指定

services:
  ai-service:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

② ボリュームマウントの性能

Windows/macOS上のDocker Desktopでは、バインドマウントが極端に遅くなることがあります。

# 対策：名前付きボリュームを使う
volumes:
  model-cache:

services:
  ai-service:
    volumes:
      - model-cache:/app/models

③ メモリ制限の設定

services:
  ai-service:
    mem_limit: 16g
    memswap_limit: 16g

WSL2での注意点

① メモリ使用量の制限

WSL2はデフォルトでホストメモリの50%まで使用します。

# %USERPROFILE%\.wslconfig
[wsl2]
memory=16GB
processors=8

② ネットワークの扱い

WSL2は独自のネットワークを持つため、Windowsからのアクセスが複雑になることがあります。

# 通常は localhost:8000 でアクセス可能
# 不可の場合はWSLのIPを確認
ip addr show eth0

③ ファイルシステムの境界

# 避けるべき：Windowsドライブ上での作業（極端に遅い）
cd /mnt/c/Users/username/project
python train.py

# 推奨：WSL内のファイルシステム（高速）
cd ~/project
python train.py

④ GPU Driverの更新

WSL2のCUDAはWindows側のNVIDIA Driverに依存します。

# Windows側で最新のNVIDIA Driverをインストール
# WSL側でCUDAを確認
nvidia-smi

コスト比較

初期セットアップコスト

環境	時間	学習コスト	金銭コスト
ベアメタル	2〜4時間	中〜高（Linux知識）	なし（既存サーバー利用時）
Docker	1〜2時間	中（Docker知識）	なし
WSL2	30分〜1時間	低	なし

ランニングコスト

ベアメタル：性能は最高だが、手動管理が多くメンテナンス工数が高い
Docker：性能はほぼネイティブで、自動化しやすくメンテナンス工数が低い
WSL2：I/O面で性能はやや劣る。メンテナンス工数は低いが、Windows PCのリソース占有に注意

実務での組み合わせパターン

多くのプロジェクトでは、フェーズに応じて複数の環境を使い分けています。

パターン1：開発から本番への典型的な流れ

開発フェーズ：WSL2でローカル開発。素早いプロトタイピングとWindowsツール（Excel等）の併用
テスト・検証フェーズ：Dockerでコンテナ化。CI/CDで自動テストし、チームで環境を共有
本番運用フェーズ：ベアメタルまたはK8s上のDocker。最高性能と安定性を確保し、監視・ログ収集を整備

パターン2：チーム開発の標準構成

全員がDockerで統一し、compose.yml で環境を定義。「自分の環境では動く」問題を回避
本番もDocker（Kubernetes）とし、開発環境と本番環境の差を最小化

パターン3：個人開発者の実用パターン

WSL2で日常的な開発と軽量モデルの実験
大規模モデルのトレーニングは必要に応じてクラウドGPU（Colab、SageMaker等）へ

環境選定のフローチャート

最適な環境を選ぶための質問

Windows PCで開発するか？ → はい：WSL2 または Docker／いいえ：ベアメタルまたは Docker

チームで環境を共有する必要があるか？ → はい：Docker／いいえ：次へ

本番運用で最高性能が必要か？ → はい：ベアメタル／いいえ：Docker または WSL2

複数プロジェクトを並行するか？ → はい：Docker／いいえ：ベアメタルまたは WSL2

頻繁に環境を作り直すか？ → はい：Docker／いいえ：ベアメタル

選定の指針

迷ったらDocker

多くのケースでDockerが最もバランスの取れた選択肢です。性能差は実用上ほぼ無視できる範囲であり、環境管理の容易さが大きな利点になります。

ベアメタルを選ぶべきケース

大規模モデルの長期トレーニング
極限の性能が求められる用途
シンプルな単一サーバー構成

WSL2を選ぶべきケース

Windows環境が前提の個人開発
Windowsツールとの連携が必須
素早いプロトタイピングを最優先する場合

参考：各環境のセットアップ手順

ベアメタル（Ubuntu 24.04 + CUDA 12.8）

# システム更新
sudo apt update && sudo apt upgrade -y

# NVIDIA Driver
sudo apt install -y nvidia-driver-570

# CUDA Toolkit
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

# Python環境
sudo apt install -y python3.12 python3.12-venv python3-pip

# 動作確認
nvidia-smi
nvcc --version

Docker + GPU対応

# Docker インストール
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# NVIDIA Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 動作確認
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

compose.yml の例

services:
  ai-dev:
    image: pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel
    command: sleep infinity
    volumes:
      - ./workspace:/workspace
      - model-cache:/root/.cache
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    ports:
      - "8888:8888"
      - "8000:8000"
    working_dir: /workspace

volumes:
  model-cache:

WSL2 + CUDA

# PowerShell（管理者権限）
wsl --install -d Ubuntu-24.04

# WSL再起動後、Ubuntu内で
sudo apt update && sudo apt upgrade -y

# CUDA on WSL（Windows側にNVIDIA Driverがインストール済みであることが前提）
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

# Python環境
sudo apt install -y python3.12 python3.12-venv python3-pip

# 動作確認
nvidia-smi

VS Code設定

Remote - WSL拡張機能をインストール
WSL内のプロジェクトを開く
WSL内でPython拡張機能をインストール

プロジェクト事例

事例1：医療記録AI

環境構成：開発はDocker（FastAPI + LangChain）、本番はベアメタル（Ubuntu Server）

選択理由：開発時は複数バージョンを並行検証し、本番は単一サーバーで安定運用を重視。セキュリティ要件でクラウド利用が不可だったため。

結果：Docker化で開発環境の構築を30分程度に短縮。本番はベアメタルで推論速度が約20%向上。

事例2：建築図面解析（CAD連携）

環境構成：開発はWSL2（Windows環境が必須）、推論APIはDocker（K8s）

選択理由：CADソフト（AutoCAD等）がWindows専用で、Windowsツールとの連携が頻繁。APIとして提供するためコンテナ化が必要だったため。

結果：WSL2でWindows/Linux双方のツールを活用しつつ、Docker化でスケーラビリティを確保。

事例3：LLMファインチューニング

環境構成：トレーニングはベアメタル（GPU複数枚）、推論APIはDocker（K8s + GPU）

選択理由：数日間の連続トレーニングで最高性能が必要。推論側は複数バージョンの管理が必要だったため。

結果：ベアメタルで安定したトレーニングを実現し、Dockerで複数モデルバージョンを並行提供。

よくある質問（FAQ）

Q1: DockerとWSL2を同時に使ってよいか？

可能です。むしろWSL2上でDockerを動かす構成がベストプラクティスです。Windows上のDocker Desktopは内部でWSL2を利用しています。

Q2: Apple Silicon（M系）Macでの推奨環境は？

Apple SiliconではDockerが実用的です。ただしCUDA非対応のため、GPUを使う処理はクラウドサービス（Colab、AWS等）や、ローカルではMLX/Metal対応フレームワークとの併用を推奨します。

Q3: 本番環境をDockerにするリスクは？

適切に構成すれば問題ありません。Kubernetes等と組み合わせることで、ベアメタル単体より高い可用性を実現できる場合もあります。

Q4: WSL2のGPU性能は実用的か？

推論用途では十分実用的です。ただし、ファイルI/Oが絡む大規模トレーニングでは不利になることがあります。

Q5: 環境を移行する際の注意点は？

依存関係を明示的に管理することが重要です。requirements.txt や Dockerfile で環境を「コード化」しておくと、移行がスムーズになります。

まとめ

AI開発環境の選定は、プロジェクトのフェーズ・チーム構成・性能要件によって変わります。本稿の検証から導かれる要点は次のとおりです。

万能な環境は存在しない：トレードオフを理解して選択する
フェーズごとに使い分ける：開発と本番で異なる環境を使うのは合理的
環境の再現性を確保する：DockerやIaCで環境を「コード化」する
理論より実測で判断する：GPU推論の差は数%でも、I/Oでは10倍以上の差が生じうる

DigitalBaseでは、中小規模のAI導入において「開発はDocker（再現性とチーム共有）、本番はベアメタルまたはDocker（要件次第）、個人検証はWSL2」という組み合わせを基本に据えています。この構成により、開発効率と本番性能の両立を図っています。

2025年11月16日

ハードウェア

912 文字

ベアメタル・Docker・WSL2の環境差分｜AI開発基盤の比較と選定指針

はじめに：環境選定がプロジェクトの成否を左右する

本稿では、AI開発で広く使われる3つの実行環境を、DigitalBaseの検証データと構築実績に基づいて比較します。

ベアメタル（ネイティブLinux）：最高性能だが柔軟性に欠ける
Docker：移植性と再現性に優れるが、わずかなオーバーヘッドがある
WSL2：Windows上でのLinux開発を実現するが、独特の制約がある

技術的な特性だけでなく、実務での使い分けまで整理します。

3つの環境の基本特性

ベアメタル（ネイティブLinux）

OSがハードウェア上で直接動作する環境です。仮想化レイヤーを介さないため、ハードウェアリソースを最大限に活用できます。

代表的な構成

Ubuntu Server 24.04 LTS
NVIDIA Driver + CUDA を直接インストール
Python仮想環境（venv, uv, conda）

Docker

代表的な構成

Docker + Docker Compose
NVIDIA Container Toolkit（GPU対応）
公式イメージ（pytorch/pytorch, nvidia/cuda 等）

WSL2（Windows Subsystem for Linux）

Windows上でLinuxカーネルを動作させる仕組みです。Windows環境を維持しながら、Linuxツールチェーンを利用できます。

代表的な構成

WSL2 + Ubuntu 24.04
CUDA on WSL（Windows側のNVIDIA Driver経由）
VS Code Remote WSL連携

総合比較表

比較項目	ベアメタル	Docker	WSL2
パフォーマンス	◎ 最高性能	◯ ほぼネイティブ	△ GPUは良好、I/Oに難
セットアップ難易度	△ 手動設定が多い	◯ Dockerfileで自動化	◎ Windows環境なら最速
環境再現性	△ 手動管理	◎ コード化可能	◯ 一定程度可能
移植性	△ 環境依存	◎ どこでも動作	△ Windows限定
GPU対応	◎ 完全対応	◯ Container Toolkitで対応	◯ CUDA on WSLで対応
マルチプロジェクト	△ 依存衝突リスク	◎ 完全分離	◯ 仮想環境で対応
開発体験	◯ SSH経由が基本	◯ VS Code統合が良好	◎ Windowsツールと連携
本番運用	◎ 最も安定	◎ K8s等で自動化	△ 本番利用は非推奨

詳細比較：パフォーマンス

GPU推論速度

7Bクラスのモデルを batch_size=1 で推論した際の実測値です。同一GPU・同一モデル・同一量子化条件で計測しています。

ベアメタル（Ubuntu 24.04）

トークン生成速度：52 tok/s
GPU利用率：95〜98%
メモリ転送：最適

Docker（NVIDIA Container Toolkit）

トークン生成速度：50 tok/s（約4%減）
GPU利用率：93〜96%
オーバーヘッド：軽微

WSL2（CUDA on WSL）

トークン生成速度：48 tok/s（約8%減）
GPU利用率：90〜94%
Windows Driver経由のため若干の遅延

検証からの評価 GPU推論では3環境とも実用上の問題はありません。ベアメタルとDockerの差はほぼ誤差範囲です。WSL2も許容範囲ですが、大量バッチ処理では差が顕在化する場合があります。

ファイルI/O速度

最も大きな差が出るのがファイルI/Oです。

ベアメタル

ローカルSSD：最速
データローディング：基準値

Docker

バインドマウント：ほぼネイティブ並み
ボリューム：やや遅い（5〜10%）
Windows/macOS上のDocker Desktop：大幅に遅い（50%以上）

WSL2

WSL内ファイルシステム：ネイティブ並み
Windowsドライブ（/mnt/c/）：極端に遅い（10倍以上になる場合あり）

重要な注意点 WSL2では必ずLinux側のファイルシステム（/home/ 以下）で作業してください。Windowsドライブ経由は避けるべきです。大量の画像データやモデルファイルを扱う場合、この差は致命的になります。

詳細比較：セットアップと管理

初期セットアップの難易度

ベアメタル

# 手動設定が多い
sudo apt update && sudo apt upgrade -y
# NVIDIA Driver
sudo apt install -y nvidia-driver-570
# CUDA Toolkit（手順は後述）
# Python環境
sudo apt install -y python3.12 python3.12-venv python3-pip

所要時間：2〜4時間（初回）／難易度：中〜高（Linuxの知識が必要）

Docker

# Dockerfileで自動化
FROM nvidia/cuda:12.8.0-runtime-ubuntu24.04
RUN apt-get update && apt-get install -y python3.12
COPY requirements.txt .
RUN pip install -r requirements.txt

docker compose up -d

所要時間：30分〜1時間（初回ビルド）／難易度：低〜中（Dockerfileの知識が必要）

WSL2

# PowerShellで簡単インストール
wsl --install -d Ubuntu-24.04

# WSL内で通常のLinux操作
sudo apt update
sudo apt install -y python3.12

所要時間：30分程度／難易度：低（Windowsユーザーには最も簡単）

依存関係の管理

ベアメタル

利点：直接的で理解しやすい
欠点：複数プロジェクトで依存関係が衝突する
対策：Python仮想環境（venv, uv, conda）で分離

Docker

利点：完全に分離され、衝突がない
欠点：イメージサイズが大きくなりがち
対策：マルチステージビルドで最適化

WSL2

利点：Linuxツールがそのまま使える
欠点：Windows側との連携で混乱しやすい
対策：作業をWSL内で完結させる

詳細比較：開発体験（DX）

コーディング環境

ベアメタル

SSH + VS Code Remote SSH
ターミナル中心の作業、サーバーへの接続が前提
利点：安定した接続と高速性／欠点：ローカルとリモートの切り替えが煩雑

Docker

VS Code Dev Containers拡張
ローカルでコンテナ内開発、compose.yml で環境を定義
利点：環境切り替えが容易でチーム共有に向く／欠点：コンテナ再構築に時間がかかる

WSL2

VS Code Remote WSL
WindowsとLinuxのシームレスな統合、エクスプローラーからWSL内ファイルにアクセス可能
利点：Windows環境では最も快適／欠点：WSL固有の不具合に遭遇することがある

デバッグとトラブルシューティング

ベアメタル

システムログを直接確認でき、ハードウェアレベルの問題も把握しやすい
ただし環境が壊れると復旧の負荷が高い

Docker

コンテナのログが分離され、問題が起きてもコンテナを再作成すれば復旧できる
ただしネットワークやボリュームの問題は切り分けが複雑になりがち

WSL2

Windowsとの相互作用が絡むと切り分けが難しい
ネットワーク設定が扱いにくく、WSLの再起動で解決するケースも多い

ユースケース別の推奨環境

ケース1：プロトタイピング・PoC開発

推奨：WSL2 または Docker

ケース2：本番運用（オンプレミス）

推奨：ベアメタルまたは Docker（K8s）

ケース3：AIモデルのトレーニング

推奨：ベアメタル

ケース4：推論API提供（FastAPI等）

推奨：Docker

環境の再現性が高く、スケーリングとCI/CD統合が容易で、複数バージョンの並行運用にも向きます。

構成例：FastAPI + Uvicorn / NVIDIA Container Toolkit / Docker Compose または Kubernetes

ケース5：Windows環境での個人開発

推奨：WSL2

ケース6：クライアント先でのデモ・PoC

推奨：Docker

ノートPCにも容易にセットアップでき、環境差異によるトラブルが少なく、compose.yml を共有するだけで再現できます。

実務での注意点とTips

ベアメタルでの注意点

① システム更新によるCUDA破損

# apt upgradeでNVIDIA Driverが壊れることがある
# 対策：ドライバを固定し、カーネル更新は慎重に
sudo apt-mark hold nvidia-driver-570

② 環境が壊れた際の復旧コストが高い

定期的なスナップショット取得を推奨
重要な設定は /etc/ をバックアップ

③ マルチユーザー環境での権限管理

# GPU使用権限をグループで管理
sudo usermod -a -G video $USER

Dockerでの注意点

① GPUリソースの指定

services:
  ai-service:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

② ボリュームマウントの性能

Windows/macOS上のDocker Desktopでは、バインドマウントが極端に遅くなることがあります。

# 対策：名前付きボリュームを使う
volumes:
  model-cache:

services:
  ai-service:
    volumes:
      - model-cache:/app/models

③ メモリ制限の設定

services:
  ai-service:
    mem_limit: 16g
    memswap_limit: 16g

WSL2での注意点

① メモリ使用量の制限

WSL2はデフォルトでホストメモリの50%まで使用します。

# %USERPROFILE%\.wslconfig
[wsl2]
memory=16GB
processors=8

② ネットワークの扱い

WSL2は独自のネットワークを持つため、Windowsからのアクセスが複雑になることがあります。

# 通常は localhost:8000 でアクセス可能
# 不可の場合はWSLのIPを確認
ip addr show eth0

③ ファイルシステムの境界

# 避けるべき：Windowsドライブ上での作業（極端に遅い）
cd /mnt/c/Users/username/project
python train.py

# 推奨：WSL内のファイルシステム（高速）
cd ~/project
python train.py

④ GPU Driverの更新

WSL2のCUDAはWindows側のNVIDIA Driverに依存します。

# Windows側で最新のNVIDIA Driverをインストール
# WSL側でCUDAを確認
nvidia-smi

コスト比較

初期セットアップコスト

環境	時間	学習コスト	金銭コスト
ベアメタル	2〜4時間	中〜高（Linux知識）	なし（既存サーバー利用時）
Docker	1〜2時間	中（Docker知識）	なし
WSL2	30分〜1時間	低	なし

ランニングコスト

ベアメタル：性能は最高だが、手動管理が多くメンテナンス工数が高い
Docker：性能はほぼネイティブで、自動化しやすくメンテナンス工数が低い
WSL2：I/O面で性能はやや劣る。メンテナンス工数は低いが、Windows PCのリソース占有に注意

実務での組み合わせパターン

多くのプロジェクトでは、フェーズに応じて複数の環境を使い分けています。

パターン1：開発から本番への典型的な流れ

開発フェーズ：WSL2でローカル開発。素早いプロトタイピングとWindowsツール（Excel等）の併用
テスト・検証フェーズ：Dockerでコンテナ化。CI/CDで自動テストし、チームで環境を共有
本番運用フェーズ：ベアメタルまたはK8s上のDocker。最高性能と安定性を確保し、監視・ログ収集を整備

パターン2：チーム開発の標準構成

全員がDockerで統一し、compose.yml で環境を定義。「自分の環境では動く」問題を回避
本番もDocker（Kubernetes）とし、開発環境と本番環境の差を最小化

パターン3：個人開発者の実用パターン

WSL2で日常的な開発と軽量モデルの実験
大規模モデルのトレーニングは必要に応じてクラウドGPU（Colab、SageMaker等）へ

環境選定のフローチャート

最適な環境を選ぶための質問

Windows PCで開発するか？ → はい：WSL2 または Docker／いいえ：ベアメタルまたは Docker

チームで環境を共有する必要があるか？ → はい：Docker／いいえ：次へ

本番運用で最高性能が必要か？ → はい：ベアメタル／いいえ：Docker または WSL2

複数プロジェクトを並行するか？ → はい：Docker／いいえ：ベアメタルまたは WSL2

頻繁に環境を作り直すか？ → はい：Docker／いいえ：ベアメタル

選定の指針

迷ったらDocker

多くのケースでDockerが最もバランスの取れた選択肢です。性能差は実用上ほぼ無視できる範囲であり、環境管理の容易さが大きな利点になります。

ベアメタルを選ぶべきケース

大規模モデルの長期トレーニング
極限の性能が求められる用途
シンプルな単一サーバー構成

WSL2を選ぶべきケース

Windows環境が前提の個人開発
Windowsツールとの連携が必須
素早いプロトタイピングを最優先する場合

参考：各環境のセットアップ手順

ベアメタル（Ubuntu 24.04 + CUDA 12.8）

# システム更新
sudo apt update && sudo apt upgrade -y

# NVIDIA Driver
sudo apt install -y nvidia-driver-570

# CUDA Toolkit
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

# Python環境
sudo apt install -y python3.12 python3.12-venv python3-pip

# 動作確認
nvidia-smi
nvcc --version

Docker + GPU対応

# Docker インストール
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# NVIDIA Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# 動作確認
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

compose.yml の例

services:
  ai-dev:
    image: pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel
    command: sleep infinity
    volumes:
      - ./workspace:/workspace
      - model-cache:/root/.cache
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    ports:
      - "8888:8888"
      - "8000:8000"
    working_dir: /workspace

volumes:
  model-cache:

WSL2 + CUDA

# PowerShell（管理者権限）
wsl --install -d Ubuntu-24.04

# WSL再起動後、Ubuntu内で
sudo apt update && sudo apt upgrade -y

# CUDA on WSL（Windows側にNVIDIA Driverがインストール済みであることが前提）
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

# Python環境
sudo apt install -y python3.12 python3.12-venv python3-pip

# 動作確認
nvidia-smi

VS Code設定

Remote - WSL拡張機能をインストール
WSL内のプロジェクトを開く
WSL内でPython拡張機能をインストール

プロジェクト事例

事例1：医療記録AI

環境構成：開発はDocker（FastAPI + LangChain）、本番はベアメタル（Ubuntu Server）

選択理由：開発時は複数バージョンを並行検証し、本番は単一サーバーで安定運用を重視。セキュリティ要件でクラウド利用が不可だったため。

結果：Docker化で開発環境の構築を30分程度に短縮。本番はベアメタルで推論速度が約20%向上。

事例2：建築図面解析（CAD連携）

環境構成：開発はWSL2（Windows環境が必須）、推論APIはDocker（K8s）

選択理由：CADソフト（AutoCAD等）がWindows専用で、Windowsツールとの連携が頻繁。APIとして提供するためコンテナ化が必要だったため。

結果：WSL2でWindows/Linux双方のツールを活用しつつ、Docker化でスケーラビリティを確保。

事例3：LLMファインチューニング

環境構成：トレーニングはベアメタル（GPU複数枚）、推論APIはDocker（K8s + GPU）

選択理由：数日間の連続トレーニングで最高性能が必要。推論側は複数バージョンの管理が必要だったため。

結果：ベアメタルで安定したトレーニングを実現し、Dockerで複数モデルバージョンを並行提供。

よくある質問（FAQ）

Q1: DockerとWSL2を同時に使ってよいか？

可能です。むしろWSL2上でDockerを動かす構成がベストプラクティスです。Windows上のDocker Desktopは内部でWSL2を利用しています。

Q2: Apple Silicon（M系）Macでの推奨環境は？

Q3: 本番環境をDockerにするリスクは？

適切に構成すれば問題ありません。Kubernetes等と組み合わせることで、ベアメタル単体より高い可用性を実現できる場合もあります。

Q4: WSL2のGPU性能は実用的か？

推論用途では十分実用的です。ただし、ファイルI/Oが絡む大規模トレーニングでは不利になることがあります。

Q5: 環境を移行する際の注意点は？

依存関係を明示的に管理することが重要です。requirements.txt や Dockerfile で環境を「コード化」しておくと、移行がスムーズになります。

まとめ

AI開発環境の選定は、プロジェクトのフェーズ・チーム構成・性能要件によって変わります。本稿の検証から導かれる要点は次のとおりです。

万能な環境は存在しない：トレードオフを理解して選択する
フェーズごとに使い分ける：開発と本番で異なる環境を使うのは合理的
環境の再現性を確保する：DockerやIaCで環境を「コード化」する
理論より実測で判断する：GPU推論の差は数%でも、I/Oでは10倍以上の差が生じうる

ベアメタル・Docker・WSL2の環境差分｜AI開発基盤の比較と選定指針

はじめに：環境選定がプロジェクトの成否を左右する

3つの環境の基本特性

ベアメタル（ネイティブLinux）

Docker

WSL2（Windows Subsystem for Linux）

総合比較表

詳細比較：パフォーマンス

GPU推論速度

ファイルI/O速度

詳細比較：セットアップと管理

初期セットアップの難易度

依存関係の管理

詳細比較：開発体験（DX）

コーディング環境

デバッグとトラブルシューティング

ユースケース別の推奨環境

ケース1：プロトタイピング・PoC開発

ケース2：本番運用（オンプレミス）

ケース3：AIモデルのトレーニング

ケース4：推論API提供（FastAPI等）

ケース5：Windows環境での個人開発

ケース6：クライアント先でのデモ・PoC

実務での注意点とTips

ベアメタルでの注意点

Dockerでの注意点

WSL2での注意点

コスト比較

初期セットアップコスト

ランニングコスト

実務での組み合わせパターン

パターン1：開発から本番への典型的な流れ

パターン2：チーム開発の標準構成

パターン3：個人開発者の実用パターン

環境選定のフローチャート

選定の指針

参考：各環境のセットアップ手順

ベアメタル（Ubuntu 24.04 + CUDA 12.8）

Docker + GPU対応

WSL2 + CUDA

プロジェクト事例

事例1：医療記録AI

事例2：建築図面解析（CAD連携）

事例3：LLMファインチューニング

よくある質問（FAQ）

まとめ

社内データを、ネットワーク不要で“使えるAI”に。

ニュースリリース

ベアメタル・Docker・WSL2の環境差分｜AI開発基盤の比較と選定指針

はじめに：環境選定がプロジェクトの成否を左右する

3つの環境の基本特性

ベアメタル（ネイティブLinux）

Docker

WSL2（Windows Subsystem for Linux）

総合比較表

詳細比較：パフォーマンス

GPU推論速度

ファイルI/O速度

詳細比較：セットアップと管理

初期セットアップの難易度

依存関係の管理

詳細比較：開発体験（DX）

コーディング環境

デバッグとトラブルシューティング

ユースケース別の推奨環境

ケース1：プロトタイピング・PoC開発

ケース2：本番運用（オンプレミス）

ケース3：AIモデルのトレーニング

ケース4：推論API提供（FastAPI等）

ケース5：Windows環境での個人開発

ケース6：クライアント先でのデモ・PoC

実務での注意点とTips

ベアメタルでの注意点

Dockerでの注意点

WSL2での注意点

コスト比較

初期セットアップコスト

ランニングコスト

実務での組み合わせパターン

パターン1：開発から本番への典型的な流れ

社内データを、ネットワーク不要で
“使えるAI”に。

社内データを、ネットワーク不要で
“使えるAI”に。