AI構築ノウハウ: Docker, ベアメタル, WSLの環境差分を比較してみた

はじめに：環境選択がプロジェクトの成否を分ける

AI開発において「どの環境で構築するか」は、パフォーマンス、開発効率、運用コストに直結する重要な判断です。

本記事では、AI開発でよく使われる3つの実行環境を実務経験に基づいて徹底比較します：

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

技術的な観点だけでなく、実際のビジネスシーンでの使い分けまで解説します。

---

3つの環境の基本特性

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

概要

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

代表的な構成

• Ubuntu Server 22.04/24.04
• NVIDIA Driver + CUDA直インストール
• Python仮想環境（venv, conda）

Docker

概要

コンテナ技術を使った軽量な仮想化環境。アプリケーションとその依存関係を「コンテナ」としてパッケージ化し、どこでも同じように動作させられます。

代表的な構成

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

WSL2（Windows Subsystem for Linux）

概要

Windows上でLinuxカーネルを動かす技術。Windows環境を維持しながら、Linuxツールチェーンを利用できます。

代表的な構成

• WSL2 + Ubuntu 22.04
• CUDA on WSL（Windows NVIDIA Driver経由）
• VS Code Remote WSL連携

---

総合比較表

---

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

GPU推論速度

実測値（Llama2 7B、batch_size=1での推論）：

ベアメタル（Ubuntu 22.04）

• トークン生成速度：52 tokens/sec
• GPU利用率：95-98%
• メモリ転送：最適

Docker（nvidia-docker）

• トークン生成速度：50 tokens/sec（▲4%）
• GPU利用率：93-96%
• オーバーヘッド：わずか

WSL2（CUDA on WSL）

• トークン生成速度：48 tokens/sec（▲8%）
• GPU利用率：90-94%
• Windows Driver経由のため若干遅延

💡 実務での体感
GPU推論では、3環境とも実用上は問題なし。ベアメタルとDockerの差はほぼ誤差範囲。WSLも許容範囲内ですが、大量バッチ処理では差が出ることがあります。

ファイルI/O速度

大きな差が出るポイント：

ベアメタル

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

Docker

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

WSL2

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

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

---

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

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

ベアメタル

# 手動での設定が多い
sudo apt update && sudo apt upgrade
# NVIDIA Driverインストール
sudo apt install nvidia-driver-535
# CUDAインストール
wget 
https://developer.download.nvidia.com/
...
# Pythonセットアップ
sudo apt install python3.11
# 各種ライブラリ...

所要時間：2-4時間（初回）

難易度：中～高（Linuxの知識必要）

Docker

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

docker-compose up -d

所要時間：30分-1時間（初回ビルド）

難易度：低～中（Dockerfileの知識必要）

WSL2

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

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

所要時間：30分程度

難易度：低（Windowsユーザーには最も簡単）

依存関係の管理

ベアメタル

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

Docker

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

WSL2

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

---

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

コーディング環境

ベアメタル

• SSH + VS Code Remote SSH
• ターミナルベースの作業
• サーバーマシンへの接続必須

利点：安定した接続、高速

欠点：ローカルとリモートの切り替えが面倒

Docker

• VS Code Dev Containers拡張
• ローカルでコンテナ内開発
• docker-compose.ymlで環境定義

利点：環境の切り替えが容易、チーム共有しやすい

欠点：コンテナ再構築時に時間がかかる

WSL2

• VS Code Remote WSL
• WindowsとLinuxのシームレスな統合
• エクスプローラーからWSL内ファイルにアクセス可能

利点：最も快適な開発体験（Windows環境の場合）

欠点：WSL特有のバグに遭遇することがある

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

ベアメタル

• システムログが直接確認できる
• ハードウェアレベルのトラブルも把握しやすい
• ただし、環境が壊れると復旧が大変

Docker

• コンテナのログが分離されている
• 問題が起きてもコンテナを再作成すればOK
• ただし、ネットワークやボリュームの問題は複雑

WSL2

• Windowsとの相互作用が絡むと複雑
• ネットワーク設定がトリッキー
• WSLの再起動で解決することも多い

---

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

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

推奨：WSL2 または Docker

理由

• 素早く環境構築できる
• 試行錯誤しやすい
• 環境を壊しても復旧が簡単

WSL2を選ぶ場合：Windows PCで開発する個人開発者

Dockerを選ぶ場合：チームで環境を共有したい

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

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

理由

• 最高のパフォーマンス
• 安定性が最優先
• 長期運用を見据えた構成

ベアメタルを選ぶ場合：シンプルな構成、単一サーバー

Dockerを選ぶ場合：複数サーバー、スケーラビリティ重視

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

推奨：ベアメタル

理由

• GPU性能を最大限に活用
• 長時間実行の安定性
• ファイルI/Oが高速

注意点：大規模なトレーニングでは、数%の性能差が積み重なって大きな差になります。

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

推奨：Docker

理由

• 環境の再現性が高い
• スケーリングしやすい
• CI/CDとの統合が容易
• 複数バージョンの並行運用が可能

構成例：

• FastAPI + Uvicorn
• NVIDIA Container Toolkit
• Docker Compose or Kubernetes

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

推奨：WSL2

理由

• Windowsツール（Office、ブラウザ等）と併用できる
• VS Codeとの統合が最高
• セットアップが簡単

注意点：本番環境への展開時はDockerやベアメタルに移行を検討

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

推奨：Docker

理由

• ノートPCにも簡単にセットアップ可能
• 環境差異によるトラブルが少ない
• docker-compose.ymlを渡すだけで再現可能

---

実際の開発での注意点とTips

ベアメタルでの注意点

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

# apt upgradeでNVIDIA Driverが壊れることがある
# 対策：カーネル更新は慎重に
sudo apt-mark hold nvidia-driver-535

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

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

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

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

Dockerでの注意点

① GPUリソースの指定

# docker-compose.yml
services:
  ai-service:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

② ボリュームマウントのパフォーマンス

Windows/Mac上の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からのアクセスが複雑になることがあります。

# WSL内のサービスを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の更新

WSLの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、PowerPoint等）と併用

テスト・検証フェーズ

• Dockerでコンテナ化
• CI/CDで自動テスト
• チームメンバーと環境共有

本番運用フェーズ

• ベアメタルまたはK8s上のDocker
• 最高性能と安定性を確保
• 監視・ログ収集の仕組みを整備

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

全員がDockerで統一

• docker-compose.ymlで環境定義
• 全員が同じ環境で開発
• 「私の環境では動く」問題を回避

本番環境もDocker

• Kubernetesでオーケストレーション
• 開発環境と本番環境の差を最小化

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

WSL2で開発

• 日常的な開発作業
• 軽量なモデルでの実験

必要に応じてクラウドGPUへ

• Google Colab、AWS SageMaker等
• 大規模モデルのトレーニング
• ベアメタルLinuxと同等の環境

---

まとめ：環境選択のフローチャート

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

1. Windows PCで開発しますか？

• はい → WSL2 または Docker

• いいえ → ベアメタル または Docker

1. チームで環境を共有する必要がありますか？

• はい → Docker

• いいえ → 次へ

1. 本番運用で最高性能が必要ですか？

• はい → ベアメタル

• いいえ → Docker または WSL2

1. 複数のプロジェクトを並行していますか？

• はい → Docker

• いいえ → ベアメタル または WSL2

1. 頻繁に環境を作り直しますか？

• はい → Docker

• いいえ → ベアメタル

最終的な推奨

迷ったらDocker

ほとんどのケースでDockerが最もバランスの取れた選択肢です。パフォーマンスの差は実用上無視できる範囲で、環境管理の容易さが圧倒的なメリットになります。

例外的にベアメタルを選ぶべきケース

• 大規模モデルの長期トレーニング
• 極限のパフォーマンスが求められるケース
• シンプルな単一サーバー構成

例外的にWSL2を選ぶべきケース

• Windows環境に縛られている個人開発
• Windowsツールとの連携が必須
• 素早いプロトタイピングが最優先

---

参考：各環境の具体的なセットアップ手順

ベアメタル（Ubuntu 22.04 + CUDA）

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

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

# CUDA Toolkit
wget 
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.0-1_all.deb

sudo dpkg -i cuda-keyring_1.0-1_all.deb
sudo apt update
sudo apt install -y cuda-12-1

# Python環境
sudo apt install -y python3.11 python3.11-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
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L 
https://nvidia.github.io/nvidia-docker/gpgkey
 | sudo apt-key add -
curl -s -L 
https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list
 | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo systemctl restart docker

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

docker-compose.yml 例

version: '3.8'

services:
  ai-dev:
    image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-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-22.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.0-1_all.deb

sudo dpkg -i cuda-keyring_1.0-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-1

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

# 動作確認
nvidia-smi

VS Code設定

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

---

実際のプロジェクト事例

事例1：医療記録AI（Digital Base実績）

環境構成

• 開発：Docker（FastAPI + LangChain）
• 本番：ベアメタル（Ubuntu Server）

選択理由

• 開発時は複数バージョンを並行テスト
• 本番は単一サーバーで安定運用重視
• セキュリティ要件でクラウド不可

結果

• 開発効率：Docker化で環境構築を30分に短縮
• 本番性能：ベアメタルで推論速度20%向上

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

環境構成

• 開発：WSL2（Windows環境必須）
• 推論API：Docker（K8s）

選択理由

• CADソフト（AutoCAD等）がWindows専用
• Windowsツールとの連携が頻繁
• APIとして提供するためDocker化

結果

• WSLでWindows/Linux両方のツールを活用
• Docker化でスケーラビリティ確保

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

環境構成

• トレーニング：ベアメタル（A100 x 4）
• 推論API：Docker（K8s + GPU）

選択理由

• 数日間の連続トレーニング
• 最高性能が必要
• 推論は複数バージョン管理が必要

結果

• ベアメタルで安定したトレーニング
• Dockerで複数モデルバージョンを並行提供

---

よくある質問（FAQ）

Q1: DockerとWSL2を同時に使うのは？

A: 可能ですが、WSL2上でDockerを動かすのがベストプラクティスです。Windows上のDocker Desktopは内部でWSL2を使用しています。

Q2: Mac（M1/M2）での推奨環境は？

A: M1/M2 MacではDockerが最も実用的です。ただし、CUDA非対応なのでGPUを使うクラウドサービス（Colab、AWS等）との併用を推奨します。

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

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

Q4: WSL2のGPU性能は本当に実用的？

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

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

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

---

結論

AI開発環境の選択は、プロジェクトのフェーズ、チーム構成、性能要件によって変わります。

最も重要なポイント

1. 完璧な環境は存在しない：トレードオフを理解して選択する
2. フェーズごとに使い分ける：開発と本番で異なる環境を使うのも合理的
3. 環境の再現性を確保する：特にDockerやIaCで環境を「コード化」
4. 実測して判断する：理論より実際のパフォーマンスで評価

Digital Baseの推奨アプローチ

中小企業のAI導入では、以下の組み合わせが最も現実的です：

• 開発フェーズ：Docker（チーム共有と再現性）
• 本番フェーズ：ベアメタルまたはDocker（要件次第）
• 個人検証：WSL2（Windowsユーザーの場合）

このアプローチにより、開発効率と本番性能の両方を最大化できます。