概要（venvは「プロジェクトごとに独立したPython環境」を作る標準機能）
venvはPython標準の仮想環境機能で、各プロジェクトが別々のライブラリやバージョンを使えるように分離します。これにより、他プロジェクトの依存関係と干渉せず、再現性の高い開発・運用が可能になります。重要なポイントは、作成・有効化・パッケージ管理・依存関係の固定化・終了と削除の流れを「型」として覚えることです。
なぜ仮想環境が必要か（衝突回避・再現性・安全性）
仮想環境を使わないと、グローバルに入れたライブラリが全プロジェクトに影響してバージョン衝突を招きます。プロジェクト単位で環境を分ければ、必要なバージョンを自由に選べ、依存の更新も安心して試せます。さらに、環境の「輸出入」が容易になり、チームや本番で同じ環境を再現できます。
はじめ方の基本手順（作成→有効化→パッケージ導入→終了）
仮想環境の作成と有効化の最短ルート
プロジェクトフォルダへ移動して、任意名の仮想環境を作ります。名前は慣例的に「venv」をよく使います。作成後に有効化し、プロンプト先頭に環境名が出たら成功です。
# 作成（フォルダ直下で実行）
python -m venv venv
# macOS/Linux 有効化
source venv/bin/activate
# Windows 有効化（PowerShell）
venv\Scripts\Activate.ps1
# Windows 有効化（cmd）
venv\Scripts\activate.bat
パッケージ導入と動作確認
有効化した環境内でpipを使い、必要なライブラリを入れます。Pythonとpipの場所が仮想環境配下になっていることを確認します。
pip install requests
python -c "import sys,requests; print(sys.executable, requests.__version__)"
終了と削除の流れ
作業を終えたら環境を無効化します。不要になればフォルダごと削除すれば綺麗に消えます。
# 無効化（どのOSでも同じ）
deactivate
# 削除（仮想環境フォルダを消す）
rm -rf venv # macOS/Linux
rmdir /S /Q venv # Windows
依存関係の固定化（requirements.txtで再現性を担保）
依存の書き出しと再現インストール
ライブラリ構成をファイルに固定し、他環境で同じ環境を再現します。開発が進んだら定期的に更新します。
# 依存を書き出し
pip freeze > requirements.txt
# 別環境で同じ構成を再現
pip install -r requirements.txt
再現性をさらに強固にするなら、バージョンを明示し、不要な依存が混在しないように定期的に見直します。プロジェクト配布時はrequirements.txtを必ず同梱します。
.gitignoreとプロジェクト構成の要点
仮想環境フォルダは巨大でOS依存のため、Gitには入れません。代わりにrequirements.txtやpyproject.tomlをコミットして、環境は各自で再現します。
venv/
フォルダ構成は、プロジェクト直下に「venv」「srcやapp」「tests」「requirements.txt」などを置くと迷いません。エディタやCI設定からも参照しやすくなります。
エディタ連携と運用の勘所（VSCode・パス・複数環境）
VSCodeで仮想環境を選ぶ
VSCodeの左下のPythonインタープリタ選択から、プロジェクトのvenv配下のPythonを選択します。選択後にターミナルを開くと、pipやPythonが仮想環境のものになります。選び間違いが起きたら、再選択してターミナルを作り直すと解決します。
PATHとpipの取り違えに注意
有効化前のpipはグローバルを指すため、誤って外へインストールしがちです。必ず「有効化→pip install」の順番を守り、sys.executableのパスがvenv配下になっているかを確認します。プロンプト先頭の「(venv)」表示が頼りになります。
複数環境の使い分け
プロジェクトごとにvenvを作り、同時利用時はターミナルを分けます。混乱を避けるため、環境名を分かりやすく付けると良いです。長期プロジェクトでは「venv」「venv-py311」などPythonバージョンを名前に含めると管理しやすくなります。
よくあるつまずきと対処（権限・スクリプト・バージョン）
有効化スクリプトが実行できない
WindowsのPowerShellでは実行ポリシーで有効化が拒否されることがあります。管理者権限で実行ポリシーを緩めるか、cmd版activate.batを使います。
# 一時的に許可（現在のセッションのみ）
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
macOS/Linuxで権限エラーが出た場合は、シェルを変えるか、ファイル権限を確認します。
Pythonのバージョンを分けたい
venvは「作成時に使ったPython」をそのまま抱えます。Pythonバージョン自体を切り替えたい場合は、pyenvなどで複数バージョンを管理し、目的のバージョンのpythonコマンドでvenvを作成します。
# 例：特定バージョンのPythonで作成
python3.11 -m venv venv
これで仮想環境内のインタープリタが指定バージョンになります。
仮想環境内の実体を理解する
venvフォルダには、実行ファイル（bin/Scripts）とsite-packagesが入っています。有効化は「PATHを書き換えて仮想環境のPythonとpipを優先する」仕組みです。この理解があれば、トラブル時にパスを確認して原因へ最短で辿れます。
例題（Web/APIプロジェクトをゼロから立ち上げる）
プロジェクト開始から依存固定までの一連の流れ
まずフォルダを作り、venvを作成して有効化します。次に必要なライブラリを入れて動作検証し、依存を書き出して終了します。
# プロジェクト新規
mkdir myapi && cd myapi
# 仮想環境作成と有効化
python -m venv venv
source venv/bin/activate # Windowsは前述のコマンド
# 依存導入
pip install requests python-dotenv
# 動作確認
python - <<'PY'
import requests, os
print("Python:", __import__('sys').executable)
r = requests.get("https://httpbin.org/get", timeout=5)
print("Status:", r.status_code)
PY
# 依存を書き出し
pip freeze > requirements.txt
# 終了
deactivate
この型を毎回繰り返せば、どの環境でも同じ手順で安全に立ち上げられます。途中で追加した依存は忘れずにfreezeし直し、チーム共有時はrequirements.txtを配布します。
まとめ（venvは「分離・再現・安心」をもたらす標準の型）
venvはプロジェクトごとの分離によって依存衝突を防ぎ、requirements.txtで再現性を担保します。有効化の徹底とpipの利用順序を守れば、取り違えによる事故は起きません。エディタで仮想環境を選び、PATHとPythonの場所を常に意識し、不要になればフォルダごと削除できる手軽さも魅力です。この型を身につければ、初心者でも短い手順で「壊れない・再現できる・運用しやすい」Python環境を作れます。