Python の venv をわかりやすく解説 — セットアップから使い方・メリット・デメリットまで

そもそも venv とは何か

venv（Virtual ENVironment）は、Python に標準でついている「仮想環境」という仕組みです。

少し難しい言葉ですが、要は以下のようなことです。

プロジェクトごとに Python のパッケージ（ライブラリ）を独立して管理できる仕組み

なぜ必要なのか — 比喩で説明

venv を知らない人のために、身近な例えで説明します。

ケーキ屋さんを考えてみてください。

チョコレートケーキを作りたい → チョコ・卵・小麦粉を用意
イチゴケーキを作りたい → イチゴ・クリーム・小麦粉を用意

もしこれが「すべて同じ台所で、同じ道具を使って」作っていたら、チョコレートのカスがイチゴケーキに混じったり、道具が足りなかったりしますよね？

仮想環境 = 各ケーキ用の専用台所 と考えてください。

各プロジェクト（ケーキ）ごとに「このプロジェクトで使うパッケージ（材料）」を分けて管理することで、プロジェクト同士が干渉しなくなります。

なぜ「みんな」venv を使うのか

venv を使わないで Python を開発すると、以下のような問題が起きやすいです。

プロジェクト A で Flask 1.0 を使いたい
プロジェクト B で Flask 2.0 を使いたい

→ パッケージのバージョンが衝突して、どちらかが動かなくなる

venv を使えば、プロジェクト A 用の Flask 1.0 とプロジェクト B 用の Flask 2.0 を別々にインストールでき、共存できます。

仮想環境の仕組み

venv を使うと、指定したディレクトリに以下のものが作成されます。

myenv/
├── bin/          ← Python や pip の実行ファイル（ショートカットのようなもの）
├── lib/          ← パッケージがインストールされる場所
├── include/
└── pyvenv.cfg    ← 設定ファイル

ポイントは bin/ と lib/ の中身です。

bin/: システムの Python をコピーしたような実行ファイルが置かれる。venv を「有効に」すると、この bin/ が優先的に使われる
lib/: このプロジェクト専用のパッケージが入る。システム全体の Python パッケージとは完全に独立

実際のセットアップ手順

前提条件

Python 3.3 以降（venv は Python 3.3 から標準搭載）
Ubuntu なら python3 と python3-venv パッケージが必要

sudo apt update
sudo apt install python3 python3-venv -y

1. プロジェクトディレクトリを作成

mkdir myproject
cd myproject

2. 仮想環境を作成

python3 -m venv venv

python3 -m venv = venv モジュールを実行
最後の venv = 作成先のディレクトリ名（任意）

実行すると、以下のようなディレクトリ構成になります。

myproject/
└── venv/
    ├── bin/
    ├── lib/
    ├── include/
    └── pyvenv.cfg

3. 仮想環境を有効にする（activate）

source venv/bin/activate

有効になると、プロンプトの先頭に (venv) が表示されます。

(venv) user@server:~/myproject$

これで このターミナル内だけ 仮想環境が有効になった状態です。

4. パッケージのインストール

通常通り pip を使います。

pip install flask requests

インストールされたパッケージは venv/lib/ に格納され、システム全体の Python には影響しません。

5. 仮想環境を無効にする

deactivate

プロンプトの (venv) が消え、システムの Python に戻ります。

6. requirements.txt で依存関係を保存

プロジェクトのパッケージ一覧をファイルに書き出します。

pip freeze > requirements.txt

このファイルがあれば、同じ仮想環境を再現できます。

pip install -r requirements.txt

よく使うコマンド一覧

コマンド	意味
`python3 -m venv venv`	仮想環境を作成
`source venv/bin/activate`	仮想環境を有効にする
`deactivate`	仮想環境を無効にする
`pip install <パッケージ名>`	パッケージをインストール
`pip freeze`	インストール済みパッケージ一覧を表示
`pip freeze > requirements.txt`	パッケージ一覧をファイルに保存
`pip install -r requirements.txt`	ファイルからパッケージを一括インストール
`which python`	現在使っている Python のパスを確認

メリット

メリット	説明
パッケージの衝突を回避	プロジェクトごとに別々のバージョンのライブラリを使える
再現性の確保	`requirements.txt` で環境を記録し、誰でも同じ環境を作れる
システム Python を壊さない	`sudo pip install` でシステム全体を汚すリスクがない
不要になったら消せる	venv ディレクトリを削除するだけで完全に片付く
標準搭載	追加ツールのインストール不要（Python 3.3 以降）
軽量	Docker ほどリソースを使わず、手軽に使える

デメリット

デメリット	説明
OS パッケージは管理できない	`apt` で入れるシステムライブラリ（libmysqlclient など）は venv の外にあるため、問題が出ることがある
有一种の「覚えること」	activate / deactivate の手順を忘れる初心者が多い
IDE との連携が必要	VS Code などでは仮想環境のパスを指定しないと認識されない場合がある
本番環境とのズレ	開発用の venv と本番サーバーの環境が異なるケースがある
ディスク容量の増加	プロジェクトごとに venv を作ると、同じパッケージが複数存在する

便利なヒント

仮想環境の名前は「venv」にするのがおすすめ

名前は任意ですが、多くの開発者やツールが venv を標準として扱っています。

myproject/
├── venv/          ← 普通はこれ
├── .venv/         ← 非表示にする場合
└── env/           ← 過去の惯例（非推奨ではないが非推奨傾向）

.venv にすると隠しフォルダになり、ls で表示されなくなります。好みで選んでください。

VS Code で仮想環境を認識させる

VS Code を使い始めると、右下に「Python の選択」の通知が出ます。そこから venv の Python を選んでください。

または .vscode/settings.json で明示的に指定できます。

{
  "python.defaultInterpreterPath": "${workspaceFolder}/venv/bin/python"
}

本番環境でのvenv の使い道

本番サーバーでも venv は有効です。特に Docker を使わない環境では、venv でパッケージを分離するのが推奨されます。

cd /opt/myapp
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

venv と類似ツールの比較

ツール	特徴
venv	Python 標準。シンプルで軽量。小〜中規模に最適
virtualenv	venv の元ネタ。Python 2 にも対応（Python 3.3 以降は venv で十分）
conda	データ分析向け。Python 以外のライブラリも管理可能
poetry	パッケージ管理 + 仮想環境を統合。モダンなプロジェクト向け
pipenv	pip + venv を統合。精度の低い依存関係解決
Docker	OS レベルで完全分離。本番環境とのズレが最も小さい

まとめ

venv は Python 開発において「これがあると安心」する基盤です。

** larvae は Python に標準搭載**で追加ツール不要
パッケージの衝突を防ぎ、プロジェクトごとに独立した環境を構築
activate / deactivate の一言で切り替えが可能
不要になればディレクトリごと削除するだけで片付く

Python を本格的に扱い始めたら、まず最初に venv を使いましょう。後の自分（チームメンバー）が助かります。