Python を使うプロジェクトが増えてくると、「このスクリプトは 3.11、新しいツールは 3.13」のように、複数のバージョンを使い分ける場面が出てきます。そのときは、OS の Python には手を付けず、バージョン管理の道具で必要な版を入れ、プロジェクトごとに venv を作って依存パッケージを記録する、という3段の構成にすると混乱しにくくなります。この記事では、Windows の py ランチャー、macOS・Linux の pyenv、まとめて扱える uv を使った複数バージョンの入れ方と、venv を別のマシンやサーバーで同じ状態に作り直すための手順を説明します。OS ごとの最初のインストール手順や venv の基本操作は別記事で扱っているので、ここでは使い分けと再現性に絞ります。
OSのPythonを直接使わない理由
Linux や macOS には、最初から Python が入っていることがあります。Linux の場合、この Python はパッケージ管理やシステムのツールが使っているものです。ここに sudo pip install でパッケージを入れると、OS が依存しているライブラリを上書きし、システムのコマンドが動かなくなることがあります。
この事故を防ぐため、Debian 12 や Ubuntu 23.04 以降などでは、OS の Python に pip で直接入れようとすると externally-managed-environment というエラーで止まるようになっています（PEP 668 という仕様に基づく動作です）。このエラーは「venv を使ってください」という合図です。--break-system-packages というオプションで回避できますが、名前のとおり OS を壊す可能性がある操作なので使いません。
バージョンの選び方
Python は毎年1回、10月ごろに新しいマイナーバージョン（3.13、3.14 など）が公開され、それぞれ約5年間サポートされます。サポートが終わった版にはセキュリティ修正が出ません。どの版がサポート中かは python.org の「Status of Python versions」のページで確認できます（2026年10月現在）。
新しいプロジェクトでは、サポート期間が十分に残っていて、使いたいライブラリが対応している版を選びます。公開直後の版は、一部のライブラリがまだ対応していないことがあります。サーバーで動かすものは、サーバーで使える版に合わせるのが無難です。
Windows：py ランチャーで使い分ける
python.org のインストーラーで入れた Python は、py というランチャーから版を指定して起動できます。
py -0 # 入っている版の一覧
py -3.12 --version
py -3.12 -m venv .venv # 3.12 で venv を作る新しい版の Windows 向けには、複数の版のインストールと切り替えを担う「Python インストールマネージャー」が用意され、従来のインストーラーから移行が進んでいます。導入方法と使えるコマンドは版によって異なるため、python.org の Windows 向けのドキュメントで確認してください。どちらの方式でも、「版を指定して venv を作る」という考え方は同じです。
Microsoft Store から入れた Python や、python と打つとストアが開く設定（アプリ実行エイリアス）が混ざると、どの Python が動いているか分かりにくくなります。where python で検索された順番を確認し、意図しないものは Windows の設定のアプリ実行エイリアスで無効にします。
macOS・Linux：pyenvで使い分ける
pyenv は、複数の Python をユーザーのホームディレクトリにインストールし、ディレクトリごとに使う版を切り替える道具です。ソースからビルドするため、事前にコンパイラと開発用ライブラリが必要です。必要なパッケージの一覧は pyenv の README（Linux の場合は Wiki）に OS ごとに書かれているので、それに従って入れます。
pyenv install 3.12 # 3.12 系の最新を入れる
pyenv versions # 入っている版の一覧
cd ~/projects/report-tool
pyenv local 3.12 # このディレクトリでは 3.12 を使う
python -m venv .venvpyenv local を実行すると .python-version というファイルが作られ、そのディレクトリに入ると自動で指定の版が使われます。このファイルを Git に含めておけば、ほかの人も同じ版を使えます。ビルドの途中で ssl や sqlite3 に関する警告が出た場合は、対応する開発用ライブラリが足りていません。入れ直してからもう一度ビルドしてください。
uv：版の管理とパッケージの管理をまとめて行う
uv は Rust で書かれた Python 向けのツールで、Python 自体のインストール、venv の作成、パッケージのインストールを1つで行えます。動作が速く、ビルド済みの Python を取ってくるのでコンパイラが要りません。開発が活発で機能やコマンドの追加が多いため、手元の版の uv --help と公式ドキュメントで確認しながら使ってください。
uv python install 3.12
uv venv --python 3.12 # .venv を作る
uv pip install -r requirements.txtチームの中に pip だけを使う人がいても、作られる .venv と requirements.txt は通常の venv や pip と同じ形式なので、混在できます。uv 独自のプロジェクト管理（pyproject.toml と uv.lock を使う方式）もありますが、既存のプロジェクトでは、まずこの互換の使い方から始めると移行の負担が小さくなります。
venvは作り直すもの、移動するものではない
venv の中には、作成したときの Python のパスが書き込まれています。そのため、venv のフォルダーを別の場所にコピーしたり、別のマシンに持っていったりすると、動かなくなるか、元の場所の Python を参照してしまいます。Python の版を上げたときも同様です。
venv は「いつでも作り直せる使い捨てのもの」として扱い、記録するのは中身の一覧のほうにします。
.venvは Git に含めない（.gitignoreに追加する）- 依存パッケージは
requirements.txtなどに記録する - 環境が壊れたら、消して作り直す
rm -rf .venv
python -m venv .venv
. .venv/bin/activate # Windows は .venv\Scripts\activate
python -m pip install -r requirements.txt依存パッケージを固定して記録する
requirements.txt に requests とだけ書くと、インストールした日によって入る版が変わります。ある日から動かなくなる、という事態を避けるには、版を固定した一覧を作ります。
いちばん簡単なのは、動いている環境で pip freeze を使う方法です。
python -m pip freeze > requirements.txtただし、この方法では自分で入れたパッケージと、それに付いてきたパッケージの区別がつかなくなります。長く保守するプロジェクトでは、直接使うパッケージだけを書いたファイル（requirements.in）を用意し、そこから版を固定した一覧を自動生成する方法が扱いやすくなります。
# requirements.in には直接使うものだけを書く（例: requests, pandas）
uv pip compile requirements.in -o requirements.txt
# pip-tools を使う場合は pip-compile requirements.in更新したいときは、requirements.in を変えるか、更新用のオプションを付けて生成し直し、差分を確認してからコミットします。生成された一覧には、どのパッケージがどれから必要とされたかの注記も付くので、不要になったパッケージを見つけやすくなります。
インストール後は python -m pip check を実行すると、パッケージどうしの版の食い違いを確認できます。
サーバーで同じ環境を作る
本番サーバーでも、手元と同じ版の Python と、同じ requirements.txt で venv を作ります。手元の venv をアップロードするのではなく、サーバーの上で作り直すのがポイントです。
cd /opt/report-tool
python3.12 -m venv .venv
.venv/bin/python -m pip install --upgrade pip
.venv/bin/python -m pip install -r requirements.txtcron や systemd から動かす場合は、activate を使わず、venv の中の Python をフルパスで指定します。activate は対話用のシェルの設定を変えるもので、cron の中では効かないことがあります。
# crontab の例
15 3 * * * /opt/report-tool/.venv/bin/python /opt/report-tool/run.py >> /var/log/report-tool.log 2>&1Ubuntu や Debian で python3 -m venv が ensurepip is not available というエラーで止まる場合は、venv 用のパッケージ（python3-venv、版を指定する場合は python3.12-venv など）を入れます。既存の環境を入れ替えるときは、元の venv をすぐに消さず、新しい venv を別名で作って動作を確かめてから切り替えると、問題があったときに戻せます。
まとめ
- OS の Python には pip で直接入れず、
externally-managed-environmentのエラーは venv を使う合図と考える。 - 複数の版は、Windows なら py ランチャー、macOS・Linux なら pyenv、両方で使える uv で管理する。
- venv はコピーや移動をせず、
requirements.txtから作り直す。.venvは Git に含めない。 - 依存パッケージは版を固定して記録し、直接使うものだけを書いたファイルから一覧を生成すると保守しやすい。
- サーバーでは同じ版の Python で venv を作り直し、cron や systemd では venv の Python をフルパスで指定する。