[AI基礎解説] 仮想環境ってなんだ？〜venv編〜

GeneLab

2025年11月2日 15:54

前回のあらすじ：conda編読んだ？

conda編で仮想環境の重要性を語った。覚えてるか？

プロジェクトごとに独立した環境
バージョン地獄からの解放
依存関係の競合を防ぐ

conda編では、AI・データサイエンス向けの重厚な環境管理ツールを紹介した。

でも、こんな声が聞こえてきそうだ：

「condaって重くね？」
「ディスク容量が...」
「シンプルなツールが欲しい」

そんな君に朗報だ。venvという選択肢がある。

venvって何者？

venvモジュールは、軽量な「仮想環境」の作成をサポートし、それぞれが独立したPythonパッケージのセットをsite directoriesにインストールできる。

簡単に言うと：

Python標準搭載：Python 3.3以降に最初から入ってる。インストール不要
軽量：必要最小限だけ。condaの数分の一の容量
シンプル：Python専用。他の言語とか考えない
高速：起動も作成も速い

conda vs venv：再確認

項目 venv conda インストール不要（Python標準）必要容量軽い（数MB〜数十MB）重い（数GB）対応言語 Python専用 Python、R、C++などパッケージソース PyPI（pip） conda repo + PyPI 起動速度速いやや遅い依存関係解決普通超強力学習コスト低いやや高い

どっち使うべき？

Webアプリ、APIサーバー、スクリプト → venv
AI・機械学習、データサイエンス → conda
シンプルに済ませたい → venv
複雑な依存関係 → conda

俺の使い分け：

Djangoアプリ → venv
ちょっとしたツール → venv
深層学習プロジェクト → conda
NumPy/SciPyゴリゴリ使う → conda

venvの哲学：使い捨て文化

仮想環境は、破棄可能なものと見なされる。削除してゼロから再作成するのが簡単であるべき。環境内にプロジェクトコードを置いてはいけない。

これ、マジで重要。

venvのルール：

環境はいつでも作り直せる
プロジェクトコードは環境の外に置く
環境をGitにコミットしない（.gitignoreに追加）
環境が壊れたら？ → 削除して作り直せ

condaと同じ思想だな。

基本操作：まずは触ってみろ

環境作成

# 基本形
python -m venv myenv

# よくある命名（.venvは隠しディレクトリ）
python -m venv .venv

# 別のディレクトリに作成
python -m venv /path/to/myenv

仮想環境の一般的なディレクトリの場所は.venvで、これによりディレクトリはシェルで通常隠され、邪魔にならない名前になる。

命名のベストプラクティス：

.venv：プロジェクト直下に作る場合（おすすめ）
venv：これも一般的
env：短くていい

俺は.venv派。理由：

隠しファイルだからlsで邪魔にならない
.gitignoreに書きやすい
「ここに仮想環境あるよ」って意味が明確

【Windows】環境の有効化

# コマンドプロンプト
.venv\Scripts\activate.bat

# PowerShell
.venv\Scripts\Activate.ps1

PowerShellで「スクリプトの実行が無効」エラーが出たら：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

これで解決。

【Mac/Linux】環境の有効化

# bash/zsh
source .venv/bin/activate

# fish
source .venv/bin/activate.fish

# csh/tcsh
source .venv/bin/activate.csh

有効化されたか確認

有効化すると、プロンプトの先頭に環境名が表示される：

# 有効化前
$ 

# 有効化後
(.venv) $

さらに確認したいなら：

# Pythonのパスを確認（Mac/Linux）
which python
# /path/to/project/.venv/bin/python

# Pythonのパスを確認（Windows）
where python
# C:\path\to\project\.venv\Scripts\python.exe

環境の無効化

deactivate

これだけ。プロンプトから(.venv)が消える。

環境の削除

使い捨て文化を体現するぞ。

# Mac/Linux
rm -rf .venv

# Windows（コマンドプロンプト）
rmdir /s .venv

# Windows（PowerShell）
Remove-Item -Recurse -Force .venv

ディレクトリ消すだけ。超簡単。

パッケージ管理：pipを使いこなせ

venvの中では、pipが自動的に仮想環境内にパッケージをインストールする。

パッケージインストール

# 環境を有効化してから
(.venv) $ pip install requests

# 複数まとめて
(.venv) $ pip install numpy pandas matplotlib

# バージョン指定
(.venv) $ pip install django==4.2.0

# 最新版にアップグレード
(.venv) $ pip install --upgrade requests

インストール済み一覧

(.venv) $ pip list

または、より詳細な情報：

(.venv) $ pip freeze
# requests==2.31.0
# numpy==1.24.3
# pandas==2.0.3

pip freezeは後で重要になる。覚えとけ。

パッケージアンインストール

(.venv) $ pip uninstall requests

requirements.txt：環境の設計図

これがvenvの真骨頂。

requirements.txtとは？

プロジェクトに必要なパッケージのリスト。チーム全員が同じ環境を再現できる神ファイル。

作り方

# 現在の環境を出力
(.venv) $ pip freeze > requirements.txt

requirements.txtの中身（例）：

Django==4.2.0
requests==2.31.0
numpy==1.24.3
pandas==2.0.3
Pillow==10.0.0

使い方

# 新しい環境でインストール
(.venv) $ pip install -r requirements.txt

一発で全パッケージがインストールされる。

実践シナリオ：チーム開発

# 開発者A（プロジェクト立ち上げ）
python -m venv .venv
source .venv/bin/activate
pip install django requests
pip freeze > requirements.txt
git add requirements.txt
git commit -m "Add requirements"
git push

# 開発者B（プロジェクトクローン）
git clone <repo>
cd <project>
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

これでチーム全員が同じ環境。美しい。

requirements.txtのバージョン指定テクニック

# 完全固定（推奨：本番環境）
Django==4.2.0

# 指定バージョン以上
Django>=4.2.0

# 指定バージョン未満
Django<5.0.0

# 範囲指定
Django>=4.2.0,<5.0.0

# 最新版（非推奨：再現性がない）
Django

ベストプラクティス：

開発中：バージョン範囲指定でOK
本番環境：pip freezeで完全固定

よく使うコマンド一覧：チートシート

# 環境作成
python -m venv .venv

# 環境有効化（Windows - cmd）
.venv\Scripts\activate.bat

# 環境有効化（Windows - PowerShell）
.venv\Scripts\Activate.ps1

# 環境有効化（Mac/Linux）
source .venv/bin/activate

# 環境無効化
deactivate

# パッケージインストール
pip install <package>

# バージョン指定インストール
pip install <package>==<version>

# アップグレード
pip install --upgrade <package>

# アンインストール
pip uninstall <package>

# インストール済み一覧
pip list

# requirements.txt作成
pip freeze > requirements.txt

# requirements.txtからインストール
pip install -r requirements.txt

# 環境削除（Mac/Linux）
rm -rf .venv

# 環境削除（Windows）
rmdir /s .venv

実践：Djangoプロジェクトを始める

リアルな使用例を見せてやる。

# 1. プロジェクトディレクトリ作成
mkdir myproject
cd myproject

# 2. 仮想環境作成
python -m venv .venv

# 3. 環境有効化
# Windows
.venv\Scripts\activate
# Mac/Linux
source .venv/bin/activate

# 4. pipアップグレード（お約束）
pip install --upgrade pip

# 5. 必要なパッケージインストール
pip install django
pip install python-decouple  # 設定管理
pip install psycopg2-binary  # PostgreSQL接続

# 6. Djangoプロジェクト作成
django-admin startproject config .

# 7. requirements.txt作成
pip freeze > requirements.txt

# 8. .gitignore作成（環境を除外）
echo ".venv/" >> .gitignore
echo "*.pyc" >> .gitignore
echo "__pycache__/" >> .gitignore
echo "db.sqlite3" >> .gitignore

# 9. Git初期化
git init
git add .
git commit -m "Initial commit"

完璧なスタート。

つまずきやすいポイントと対策

ケース1：「python: command not found」

Pythonがインストールされてない、またはPATHが通ってない。

対策：

# Python確認
python --version
# または
python3 --version

python3で動くなら、以降はpython3を使え：

python3 -m venv .venv

ケース2：有効化しても(venv)が表示されない

コマンドが間違ってるか、パスが違う。

対策：

# Windows - コマンドプロンプト
.venv\Scripts\activate.bat

# Windows - PowerShell
.venv\Scripts\Activate.ps1

# Mac/Linux
source .venv/bin/activate

source忘れるな（Mac/Linux）。

ケース3：「Activate.ps1 cannot be loaded」（Windows PowerShell）

スクリプト実行ポリシーの問題。

対策：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

ケース4：pipが古いって怒られる

WARNING: You are using pip version X.X.X; however, version Y.Y.Y is available.

対策：

pip install --upgrade pip

仮想環境内で実行すれば、その環境のpipだけアップグレードされる。

ケース5：グローバルにパッケージ入れちゃった

# 環境有効化してないのに
$ pip install django  # ← これヤバい

システム全体にインストールされる。

対策：

常に環境を有効化してからインストール
プロンプトに(venv)が表示されてるか確認
やらかしたら、グローバルからアンインストール：

# システムのpip
pip uninstall django

ケース6：requirements.txtからインストールが失敗

依存関係の問題、またはパッケージが見つからない。

対策1：一つずつ試す

# どこで失敗してるか確認
pip install -r requirements.txt -v

対策2：pip更新

pip install --upgrade pip

対策3：requirements.txt修正 古いバージョン指定があったら、範囲指定に変える：

# NG
numpy==1.19.5  # 古すぎて見つからない

# OK
numpy>=1.20.0,<2.0.0

ケース7：環境を別のマシンに移動したい

NG：環境ごとコピー 環境は本質的に移植不可能。環境を再作成する簡単な手段を常に持つべき。

OK：requirements.txtで再現

# 元のマシン
pip freeze > requirements.txt

# 新しいマシン
python -m venv .venv
source .venv/bin/activate  # または Windows用コマンド
pip install -r requirements.txt

.gitignore：環境をGitに入れるな

venvディレクトリはGitで管理しない。絶対に。

.gitignoreに追加：

# 仮想環境
.venv/
venv/
env/
ENV/

# Python関連
*.pyc
__pycache__/
*.pyo
*.pyd
.Python

# その他
.DS_Store
db.sqlite3
*.log

理由：

環境はデカい（数十〜数百MB）
再現可能（requirements.txtがあれば十分）
OS依存（WindowsとMacで中身が違う）

複数Pythonバージョンの扱い

システムに複数のPythonバージョンがインストールされてる場合。

特定バージョンで環境作成

# Python 3.11で作成
python3.11 -m venv .venv

# Python 3.9で作成
python3.9 -m venv .venv

# Windows（py launcherを使う）
py -3.11 -m venv .venv

環境のPythonバージョン確認

(.venv) $ python --version
Python 3.11.5

pip install -e：開発モードインストール

自分でパッケージ開発してる時に超便利。

# 通常インストール
pip install .

# 開発モード（editable）
pip install -e .

何が違う？

通常：パッケージがsite-packagesにコピーされる
開発モード：リンクだけ作られる。ソース編集が即反映

自作ライブラリ開発してる人は使え。

venvとvirtualenvの違い

たまに「virtualenv」って聞くだろ？混乱するよな。

venv：

Python 3.3+標準搭載
シンプル
Python専用

virtualenv：

サードパーティツール（pip install virtualenv）
古いPython（2.7とか）にも対応
高機能

結論： Python 3使ってるならvenv一択。わざわざvirtualenv入れる必要なし。

condaとvenvは共存できる？

できる。でも、同じプロジェクトで両方使うな。

NG：

# conda環境の中でvenv作る
conda activate myenv
python -m venv .venv  # やめろ

OK：

プロジェクトA：conda
プロジェクトB：venv

プロジェクトごとに決めろ。混ぜるな危険。

pipenvやPoetryは？

venv以外にも選択肢はある。

pipenv：

pip + venvを統合
Pipfileで管理
依存関係解決が賢い

Poetry：

モダンなパッケージマネージャー
pyproject.tomlで管理
パッケージ公開も簡単

どれ使うべき？

初心者 → venv（シンプルだから）
中級者 → venv or Poetry
大規模プロジェクト → Poetry
レガシープロジェクト → venv

俺の意見：venv覚えてから他を試せ。基礎が大事。

次のステップ

実際にvenv環境を作ってみる：読むだけじゃダメ
requirements.txtを作る習慣：全プロジェクトで
環境を壊してみる：rm -rf .venvして再作成。使い捨て文化を体感
チーム開発で使う：requireme nts.txt共有して環境統一
DjangoかFlaskでアプリ作る：venvの真価を知る

まとめ：venvマスターへの道

venvの基本操作、お疲れ様。これで君も：

✅ venvが何か説明できる ✅ venv環境を作成・管理できる ✅ pipでパッケージ管理できる ✅ requirements.txtで環境を再現できる ✅ condaとvenvを使い分けられる ✅ チーム開発で環境を共有できる

仮想環境使わないでPython開発するのは、安全帯なしで高所作業するようなもん。マジで危ない。

venvの3原則：

プロジェクトごとに環境作れ
環境は使い捨て
requirements.txtで再現しろ

この3つ守れば、環境問題で悩むことは99%なくなる。

最初は面倒に感じるかもしれない。でも慣れたら、環境作成〜有効化〜インストールが5秒で終わる。

「動いてたコードが動かない」「ライブラリのバージョンが合わない」「他の人のマシンで動かない」

こういう地獄から解放される。それがvenvだ。

Pythonやるなら、仮想環境は必須スキル。今日からvenv使え。

参考リンク：

Python公式 - venvドキュメント: https://docs.python.org/ja/3/library/venv.html
Python公式 - 仮想環境とパッケージ: https://docs.python.org/ja/3/tutorial/venv.html
PEP 405（venvの提案）: https://peps.python.org/pep-0405/
pip公式ドキュメント: https://pip.pypa.io/
Python Packaging User Guide: https://packaging.python.org/

[AI基礎解説] 仮想環境ってなんだ？ 〜venv編〜

前回のあらすじ：conda編読んだ？

venvって何者？

conda vs venv：再確認

venvの哲学：使い捨て文化

基本操作：まずは触ってみろ

環境作成

【Windows】環境の有効化

【Mac/Linux】環境の有効化

有効化されたか確認

環境の無効化

環境の削除

パッケージ管理：pipを使いこなせ

パッケージインストール

インストール済み一覧

パッケージアンインストール

requirements.txt：環境の設計図

requirements.txtとは？

作り方

使い方

実践シナリオ：チーム開発

requirements.txtのバージョン指定テクニック

よく使うコマンド一覧：チートシート

実践：Djangoプロジェクトを始める

つまずきやすいポイントと対策

ケース1：「python: command not found」

ケース2：有効化しても(venv)が表示されない

ケース3：「Activate.ps1 cannot be loaded」（Windows PowerShell）

ケース4：pipが古いって怒られる

ケース5：グローバルにパッケージ入れちゃった

ケース6：requirements.txtからインストールが失敗

ケース7：環境を別のマシンに移動したい

.gitignore：環境をGitに入れるな

複数Pythonバージョンの扱い

特定バージョンで環境作成

環境のPythonバージョン確認

pip install -e：開発モードインストール

venvとvirtualenvの違い

condaとvenvは共存できる？

pipenvやPoetryは？

次のステップ

まとめ：venvマスターへの道

いいなと思ったら応援しよう！

[AI基礎解説] 仮想環境ってなんだ？〜venv編〜