仮想環境（virtual environment）は、独自にインストールされたパッケージを持つ隔離された Python 環境で、システムの Python や他のプロジェクトとは分離されています。これは依存関係の衝突を解決します。異なるプロジェクトが、同じパッケージの異なる（さらには互換性のない）バージョンを使えるのです。
Project A needs Django 3.2
Project B needs Django 4.2
→ Installing globally, they CONFLICT — you can't have both versions system-wide.
Virtual environments give each project its OWN isolated set of packages.
隔離なしにパッケージをグローバルにインストールすると、プロジェクト間でバージョンの衝突が起き、特定のバージョンに依存するシステムツールを壊す可能性があります。
# 1. create a virtual environment (a folder named .venv)
python -m venv .venv
# 2. ACTIVATE it (shell-specific)
source .venv/bin/activate # macOS/Linux
.venv\Scripts\activate # Windows
# 3. now pip installs go INTO this env, isolated from the system
pip install django requests
# 4. when done
deactivate
一度アクティベートすると、python と pip はその環境の隔離されたコピーを指すようになります。パッケージはシステム全体ではなく、そこだけにインストールされます。
pip freeze > requirements.txt # record exact installed versions
pip install -r requirements.txt # recreate the env elsewhere (teammate, CI, prod)
requirements.txt は環境を再現可能にします。誰でもまったく同じ依存関係を再現でき、「自分の環境では動くのに」という問題を防げます。
venv + pip → built-in, standard, widely used
poetry → dependency management + lockfile + packaging (popular)
pipenv → combines pip + venv with a lockfile
uv / pdm → newer, faster tools
conda → common in data science (manages Python versions + non-Python deps too)
より新しいツール（poetry、uv）はロックファイルやより優れた依存関係解決を追加しますが、中核となる概念 — プロジェクトごとに隔離された環境 — は同じです。
# .gitignore
.venv/ ← don't commit the environment; commit requirements.txt/lockfile instead
仮想環境は、あらゆる Python プロジェクトにとって不可欠な標準的慣行です。プロジェクト間、およびプロジェクトとシステムの Python の間での依存関係の衝突を防ぎ、（requirements.txt／ロックファイルとともに）マシン、チームメイト、CI、本番環境をまたいで環境を再現可能にします。
これを省くと、バージョンの衝突、システムツールの破損、再現不能なセットアップにつながります。
作成、アクティベート、依存関係の取得の方法 — そして現代的なツールの状況（poetry、uv） — を理解することは、プロフェッショナルな Python 開発の基本であり、あらゆる実際のプロジェクトで当然期待されることです。