この記事の要点

Python の仮想環境はプロジェクトごとに独立したパッケージ環境を作る仕組み 標準は venv モジュール（Python 3.3+ 標準同梱、追加インストール不要） 基本: python3 -m venv venv で作成 → source venv/bin/activate で有効化 Mac / Linux と Windows でアクティベートコマンドが異なる: Mac は source ..., Windows は .\Scripts\activate 管理ツール選択肢: venv (標準) / virtualenv (旧) / pipenv / poetry (現代的) プロジェクト直下に venv/ を作り、.gitignore で除外するのが定石

Python 仮想環境とは

仮想環境とは、システム全体の Python とは分離したプロジェクト専用の Python 環境のことです。プロジェクトごとに別の venv を作ることで、以下のメリットがあります:

• パッケージのバージョン衝突を回避（A プロジェクトは Django 4、B プロジェクトは Django 5）
• システム Python を汚さない（macOS の組み込み Python を壊さない）
• 誰のマシンでも同じ環境を再現できる (requirements.txt)
• 不要になったらフォルダごと削除するだけでクリーンアップ完了

標準ツール: venv (推奨)

Python 3.3 以降に標準で組み込まれた venv モジュールが現在のスタンダードです。追加インストール不要で、Mac / Linux / Windows すべてで同じコマンドが使えます。

1. 仮想環境を作る

# プロジェクトディレクトリへ移動
cd ~/projects/myapp

# venv という名前の仮想環境を作成
python3 -m venv venv

# Python のバージョンを指定したい場合
python3.11 -m venv venv

これで ./venv/ ディレクトリが作られ、中に Python バイナリ・pip・ライブラリ用フォルダが入ります。

2. 仮想環境をアクティベート (Mac / Linux)

source venv/bin/activate

# プロンプトが (venv) で始まれば成功
(venv) $ python --version
Python 3.11.x

(venv) $ which python
/Users/you/projects/myapp/venv/bin/python

Windows のアクティベート (参考)

:: コマンドプロンプト
venv\Scripts\activate

:: PowerShell
venv\Scripts\Activate.ps1

3. パッケージをインストール

(venv) $ pip install requests django pandas
(venv) $ pip list

# 依存関係を requirements.txt に書き出す
(venv) $ pip freeze > requirements.txt

# 別マシンで同じ環境を再現
(venv) $ pip install -r requirements.txt

4. 仮想環境を抜ける

(venv) $ deactivate
$

5. 削除

# venv フォルダごと消すだけ
rm -rf venv

旧来のツール: virtualenv

Python 3.3 以前に主流だったサードパーティパッケージ。今は venv を使えば十分ですが、レガシーコードや Python 2 系で残っている場合は使うこともあります。

# インストール
pip install virtualenv

# バージョン確認
virtualenv --version

# 仮想環境作成（venv とほぼ同じ）
virtualenv venv
python -m venv venv  # 標準 venv との混在も可能

# 有効化（venv と共通）
source venv/bin/activate

# 無効化
deactivate

新規プロジェクトでは venv 標準モジュール推奨。virtualenv はPython 2 サポートが必要なときの選択肢と考えてOK。

Mac 特有の注意点

システム Python と Homebrew Python

パス	由来	使う？
/usr/bin/python3	macOS 同梱	× 触らない（OS が使う）
/opt/homebrew/bin/python3 (Apple Silicon)	Homebrew	○ 推奨
/usr/local/bin/python3 (Intel Mac)	Homebrew	○ 推奨
~/.pyenv/versions/...	pyenv	○ バージョン切替するならこれ

Homebrew で Python をインストール

# Homebrew が未導入なら先に入れる
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Python 最新版
brew install python

# 特定バージョン
brew install python@3.11

# 確認
python3 --version
which python3

pyenv でバージョン管理

# インストール
brew install pyenv

# シェル設定 (zsh)
echo 'eval "$(pyenv init -)"' >> ~/.zshrc
source ~/.zshrc

# 利用可能なバージョン
pyenv install --list

# インストール
pyenv install 3.11.7
pyenv install 3.12.0

# プロジェクトごとに指定
cd ~/projects/myapp
pyenv local 3.11.7   # .python-version ファイルが作られる

# その状態で venv 作成
python -m venv venv
source venv/bin/activate

現代的な代替: pipenv / poetry

仮想環境とパッケージ管理を統合したツールも人気があります。

ツール	特徴	使い方
venv	標準・シンプル	個人プロジェクト・学習
pipenv	Pipfile + 自動 venv 管理	中規模プロジェクト
poetry	pyproject.toml ベース、依存解決強力	パッケージ公開・現代的
uv	Rust 製・超高速 (2024〜)	新規プロジェクトで注目

poetry の基本

# インストール
curl -sSL https://install.python-poetry.org | python3 -

# 新規プロジェクト
poetry new myapp
cd myapp

# 既存に追加
poetry init

# パッケージ追加（venv も自動管理）
poetry add requests django

# シェル起動（仮想環境内）
poetry shell

# スクリプト実行
poetry run python main.py

VS Code との連携

1. VS Code でプロジェクトを開く
2. 右下のステータスバーの Python インタプリタをクリック
3. ./venv/bin/python を選択
4. 以降、ターミナルが自動で venv をアクティベート、デバッガもこの環境で動く

.gitignore 設定

# venv フォルダはコミットしない
venv/
.venv/
env/
ENV/

# パッケージ情報
__pycache__/
*.py[cod]
*$py.class
*.egg-info/

# IDE 設定
.idea/
.vscode/

requirements.txt や pyproject.toml はコミットして共有、venv/ 本体は各人が自分のマシンで再生成するのが定石です。

仮想環境を使わないと何が起きるか

Python の初学者がよく陥るパターンに「システム Python へ直接パッケージをインストールし続け、いつの間にか動かなくなる」というものがあります。複数プロジェクトを並行して進めていると、片方は古いバージョンの Django に依存し、もう片方は最新版を要求する、というようなバージョンの衝突は避けられません。仮想環境を使わずに pip install を繰り返すと、後からインストールしたバージョンが前のバージョンを上書きしてしまい、過去のプロジェクトが突然動かなくなる事故が頻発します。

macOS の場合はさらに事情が複雑です。OS 標準の Python は OS 自体の補助スクリプトに使われているため、これに対して pip install を実行すると OS の機能を壊す危険があります。Homebrew で別途インストールした Python を使うか、pyenv でユーザー専用の Python を入れ、その上に venv で仮想環境を作るのが、macOS 上での Python 開発における事実上の標準です。仮想環境は一見手間に見えますが、長期的にはトラブルを劇的に減らしてくれる投資です。

仮想環境とコンテナの使い分け

近年は Docker などのコンテナ技術が普及し、「仮想環境とコンテナはどう違うのか」という質問もよく聞かれます。両者は似た目的を持ちますが、抽象化のレベルが異なります。venv はPython のパッケージレベルの分離で、OS やシステムライブラリは共有します。一方、コンテナはOS ライブラリレベルまで含めた完全な分離環境を提供します。

個人の開発マシンで複数の Python プロジェクトを切り替えるだけなら venv で十分です。一方、本番環境にデプロイするときは、ホスト OS のライブラリバージョン差で動作が変わるリスクを避けるため、コンテナ化したうえで内部にも venv を併用する、という二段構えが一般的になっています。「ローカル開発は venv、デプロイは Docker、Docker 内部にも venv」という構成は、多くの Python チームが採用している王道パターンです。

仮想環境を運用するベストプラクティス

仮想環境の運用で気をつけたいのは、requirements.txt を必ずバージョン番号付きで管理することです。pip freeze でファイルに書き出すと、現在インストールされている全パッケージとその正確なバージョンが記録されます。これをチームで共有することで、誰がいつクローンしても完全に同じ環境を再現できます。一方、Django や requests のような直接依存だけを記録した「シンプル版 requirements.txt」も別途用意しておくと、ライブラリのアップグレード時にどれが本当に必要だったか把握しやすくなります。

また、長期運用のプロジェクトでは pip install を直接行わず、poetry や pipenv のような依存解決エンジンを使うのが安全です。これらのツールはパッケージ間のバージョン互換を自動で解決し、矛盾が出たら即座に教えてくれます。さらに、CI/CD パイプラインに組み込めば、プルリクエスト時点で依存関係の整合性をチェックでき、本番環境で初めて衝突に気付く事故を防げます。venv 自体はシンプルですが、それを取り巻く運用ツールチェインに少し投資するだけで、開発・運用の安心感は大きく向上します。

FAQ

Q: venv と virtualenv の違いは？
A: venv は Python 3.3+ 標準、virtualenv は古いサードパーティ製。機能的にはほぼ同等、現代は venv で OK。

Q: アクティベート後 (venv) が表示されない
A: シェルの PS1 設定が venv を反映しない場合がある。echo $VIRTUAL_ENV や which python で確認。

Q: 複数プロジェクトで venv が肥大化する
A: 1 プロジェクト 50MB 程度。問題なら poetry や pipenv で中央管理するか、不要プロジェクトを rm -rf venv。

Q: なぜ venv 名前は "venv" が定番？
A: 慣例。.venv も同じく一般的（隠しディレクトリにできる）。プロジェクト内部での名前はチームで統一すればOK。

Q: アクティベートせずに使いたい
A: 直接バイナリ呼び出し: ./venv/bin/python script.py や ./venv/bin/pip install xxx。CI で使いやすい。

関連記事

• 環境構築（Python）