Python環境構築の決定版【2026年】uv・pyenv・venv・condaの使い分けを徹底解説

2026年時点のPython環境構築のベストプラクティスを徹底解説。uvを軸に、pyenv・venv・condaとの違いと使い分け、プロジェクト管理(uv add/sync)、Mac向けインストール手順、旧環境pyenv+Anacondaからの移行手順までを一次情報ベースで詳しくまとめる。

14 min read

2026年7月 全面改稿: 本記事は2021年に「pyenv + Anaconda」でのPython環境構築を解説した記事だったが、当時の情報は現在ほぼ通用しない。2026年7月時点の一次情報（ uv公式ドキュメント 、Python公式のvenv、pyenv README、conda/Miniforge）に基づき、内容を全面的に書き直した。

Python開発における「環境構築」は、実はまったく異なる3つの問題を1語に押し込めてしまっている。どのPythonインタープリタを使うか（バージョン管理）、プロジェクトごとにライブラリをどう隔離するか（仮想環境）、依存関係をどう記録・再現するか（パッケージ/プロジェクト管理）である。2021年の旧記事では、この3つを pyenv（バージョン管理）と Anaconda（仮想環境 + パッケージ管理をまとめて提供するディストリビューション）の組み合わせで解決していた。

2026年現在、この構図は大きく変わった。uvという単一のRust製ツールが3つの問題すべてを高速にカバーするようになり、事実上の標準になりつつある。本記事では uv を軸に、pyenv・venv・conda それぞれの現在の役割と使い分け、そして旧記事の読者向けの移行手順までを、公式ドキュメントに基づいて解説する。

1. 2026年のPython環境構築の全体像

3つの問題を分けて考える

問題何を管理するか旧来の代表的ツール
①バージョン管理どのPythonインタープリタ（3.11、3.14など）を使うかpyenv
②仮想環境プロジェクトごとにライブラリを隔離する場所venv、virtualenv、conda
③パッケージ/プロジェクト管理依存関係の記録・解決・再現（ロック）pip、pip-tools、Poetry

Anacondaはこの3つのうち②と③をまとめて提供する「ディストリビューション」で、pyenvは①だけを担う「バージョン管理ツール」だった。2021年時点では、①をpyenvに任せ、②③をAnacondaに任せるという組み合わせが妥当な選択肢の一つだった。

何が変わったか

2024年2月、Rust製の高速ツール群（ Ruff など）で知られるAstral社が uv を発表した。当初はpipの高速な代替として登場したが、その後急速に機能を拡張し、2024年8月には統合ツールを目指していた Rye プロジェクト（Armin Ronacher氏が開発）がAstralの管理下に入り、2025年にはRyeの開発が終了してuvへの移行が正式に案内されるに至った（ Rye移行ガイド ）。この過程で uv は、pip・pip-tools・pipx・virtualenv・そしてpyenv相当のPythonバージョン管理までを1つのバイナリに統合した。

さらに、Anaconda社は2024年以降、Anaconda Distributionの商用利用ライセンスを強化し、従業員・契約者数200名以上の組織では有償契約が必要になった。これを受けて、BSDライセンスで無償の Miniforge（conda-forgeコミュニティが保守）への移行を勧める大学・企業が増えている。

結果として2026年現在のデファクトスタンダードは、**「特別な理由がない限りuvを使う。ネイティブ依存の強い科学計算・GPU環境ではconda系（Miniforge）を併用する」**という形に収斂している。以降、各ツールを順に見ていく。

2. uvとは — Astral製、Rust実装の統合ツール

uv は、Astral社が開発するRust製のPythonパッケージ・プロジェクトマネージャーである。公式ドキュメントでは「pip、pip-tools、pipx、poetry、pyenv、twine、virtualenvなどを置き換える」ツールと説明されており、実際に本記事執筆時点（2026年7月）の最新バージョンは 0.11.29（2026年7月15日リリース）である。

主な特徴は次の通り。

  • 速度: 依存関係解決やインストールが、従来のpipに対して大幅に高速（公式は「10-100倍高速」と謳う）
  • 単一バイナリ: Rust製の単一実行ファイルで動作し、Python自体がインストールされていない環境にも導入できる
  • 守備範囲の広さ: Pythonバージョン管理、仮想環境、pip互換のパッケージインストール、pyproject.tomlベースのプロジェクト管理、使い捨てスクリプト実行までを1ツールでカバー

インストール方法(macOS / Linux)

公式のスタンドアロンインストーラーを使うのが最も簡単である。

# 公式インストーラー(curl)
curl -LsSf https://astral.sh/uv/install.sh | sh

# 特定バージョンを指定する場合
curl -LsSf https://astral.sh/uv/0.11.29/install.sh | sh

# Homebrew経由
brew install uv

# pipx / pip経由(既存のPython環境がある場合)
pipx install uv

インストール後、uv --version でバージョンを確認できる。既存のプロジェクトに影響を与えず単体で動作するため、他のツールと共存させながら段階的に試すことも容易である。

3. uvでのPythonバージョン管理

pyenvが担っていた「複数のPythonバージョンを切り替える」役割は、uv python サブコマンドに統合されている。

# 特定バージョンのPythonをインストール
uv python install 3.12

# 複数バージョンを一度にインストール
uv python install 3.11 3.12 3.14

# インストール済み/インストール可能なバージョン一覧を表示
uv python list

# 現在のディレクトリに使用するPythonバージョンを固定(.python-versionを生成)
uv python pin 3.12

uv python pin は .python-version ファイルをカレントディレクトリに作成する。uvはコマンド実行時にカレントディレクトリとその親ディレクトリを遡って .python-version を探索し、見つからなければユーザー設定ディレクトリを参照する。この仕組みはpyenvの .python-version と互換性があるため、既存のpyenv運用からの移行が比較的スムーズである。

uvが管理するPython本体は ~/.local/share/uv/python/ 以下に、マイナーバージョンごとの実行ファイル（例: python3.12）は ~/.local/bin にインストールされる。pyenvのようにOS標準のPythonやHomebrew版Pythonを汚染しない設計になっている。

4. uvでのプロジェクト管理 — init / add / sync / run

uvのもう一つの柱が、pyproject.tomlとロックファイル（uv.lock）に基づくプロジェクト管理である。Poetryが担っていた役割にほぼ相当する。

# 新規プロジェクトを作成(専用ディレクトリを生成)
uv init my-project
cd my-project

# 依存関係を追加(pyproject.tomlとuv.lockを自動更新)
uv add requests
uv add "requests==2.31.0"        # バージョン指定
uv add "django>=5.0" --group dev  # 開発用グループへの追加

# 依存関係を削除
uv remove requests

# ロックファイルの内容通りに仮想環境を同期
uv sync

# プロジェクト環境でスクリプト/コマンドを実行(実行前にロックの整合性を検証)
uv run python main.py
uv run pytest

生成される pyproject.toml はプロジェクトのメタデータと依存関係の要求範囲を人間が編集する場所である。一方 uv.lock は、依存関係を厳密なバージョンまで解決した結果を記録するクロスプラットフォームのロックファイルで、手動編集はせずバージョン管理システム（Git）にコミットしておく。これにより、チームメンバーやCI環境で uv sync を実行するだけで、寸分違わぬ依存関係の環境が再現できる。

# pyproject.toml の例
[project]
name = "my-project"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "requests>=2.31.0",
]

[dependency-groups]
dev = [
    "pytest>=8.0.0",
]

uv run はコマンドを実行するたびにロックファイルとの整合性を検証し、必要なら自動的に環境を同期するため、source .venv/bin/activate を手動で叩く機会は大きく減る。

5. 従来ツールとの使い分け

uvが3つの問題をカバーするからといって、pyenv・venv・condaが不要になったわけではない。それぞれ今も使う場面が残っている。

pyenv — まだ使う場面

  • 会社やチームの標準ツールとして既にpyenvが定着しており、移行コストが見合わない場合
  • uvが未対応の特殊なPython実装・パッチ版を扱う必要がある場合
  • pyenvの.python-versionはuvとも互換性があるため、uv python installを使いつつ、バージョン切り替えの運用だけpyenv流を維持することも可能

venv + pip — 標準ライブラリで済ませたい場合

Pythonにはバージョン3.3以降、標準ライブラリとしてvenvモジュールが同梱されている。外部ツールを一切追加したくない、教育目的でPython標準の仕組みだけを使いたい、といった場合には依然として有効な選択肢である。

python3 -m venv .venv
source .venv/bin/activate
pip install requests

ただし依存関係のロック（再現性の担保）はpip freeze > requirements.txtという素朴な方法に頼ることになり、uvのロックファイルほど厳密ではない。

conda / Miniforge — ネイティブ依存・科学計算での役割

condaはPythonパッケージだけでなく、CUDAツールキットやMKL、各種コンパイル済みのCライブラリなど、Pythonパッケージの枠を超えたネイティブ依存関係をまとめて管理できる点がuvやpipにはない強みである。GPU利用の深層学習環境や、地理空間・数値計算系のライブラリ（GDAL等）を要するプロジェクトでは、condaのバイナリパッケージ管理が今なお実用的な解決策になる。

Anaconda Distributionは2024年以降、200名以上の組織での商用利用に有償ライセンスが必要になったため、2026年現在は BSDライセンスで無償の Miniforge（conda-forgeチャンネルを既定とする最小構成インストーラー）を選ぶのが安全である。

比較表

ツールバージョン管理仮想環境パッケージ管理主な用途(2026年)
uv○○○新規プロジェクトの第一選択
pyenv○××既存運用の維持、特殊実装の管理
venv (標準)×○×(pip併用)依存ゼロで完結させたい場合
conda / Miniforge○(python自体も配布)○○GPU/ネイティブ依存の強い科学計算
Poetry×○○既存プロジェクトの継続運用(新規は基本uv推奨)

6. ユースケース別の推奨構成

図2: ユースケース別のPython環境ツール選定フローチャート ユースケース別のPython環境ツール選定フローチャート。GPU/科学計算のネイティブ依存が中心ならconda/Miniforge、使い捨てスクリプトならuv run –script、既存のpip管理プロジェクトなら段階移行、それ以外は標準のuv init/add/sync/runを推奨する分岐図

新規プロジェクト

uv init から始めて uv add / uv sync / uv run で完結させる。pyproject.tomlとuv.lockをGitにコミットするだけで、チーム全員・CI環境が同一の依存関係を再現できる。

既存のpip管理プロジェクト（requirements.txt）

uvはpip互換インターフェースも提供しているため、いきなりpyproject.toml化しなくても移行できる。

uv venv
uv pip install -r requirements.txt

動作を確認したうえで、余裕があれば uv add ベースのプロジェクト管理に段階的に移行するとよい。

データ分析

純粋にPythonパッケージ（pandas、matplotlib等）だけで完結するならuvで十分高速に環境構築できる。GDALなどネイティブ依存の強いライブラリが必要になった時点でconda系の併用を検討する。

機械学習(GPU)

CUDA/cuDNNなどのネイティブ依存が絡む場合はconda/Miniforgeが今も有力な選択肢である。ただしuvもPyTorchのCUDAビルド向けインデックス指定（uv add torch --index ...）に対応しており、用途によってはuv単独で完結する場合もある。プロジェクトの依存関係の複雑さに応じて判断する。

使い捨てスクリプト

1ファイルで完結する検証用スクリプトには、 PEP 723 のインラインスクリプトメタデータとuv run --scriptの組み合わせが便利である。

# /// script
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich import print

print(requests.get("https://example.com").status_code)

uv run script.py

依存関係をスクリプト自身の冒頭に埋め込めるため、requirements.txtや仮想環境を別途作らなくても、uv run一発で必要な依存関係込みの隔離環境が自動的に用意される。依存関係の追記も専用コマンドで行える。

uv add --script script.py "requests<3" "rich"

7. pyenv + Anacondaからの移行手順

2021年の旧記事の読者、あるいは長年pyenv + Anaconda構成を使ってきた読者向けに、uvへの移行手順を示す。

  1. uvをインストールする（前述のcurlワンライナーまたはHomebrew）。既存のpyenv・Anacondaと共存可能なので、いきなり削除する必要はない。
  2. プロジェクトごとにuvへ切り替える。既存プロジェクトのルートで.python-versionがあればそのまま流用できる。uv venvで仮想環境を作り、uv pip install -r requirements.txt（またはPoetryのpyproject.tomlがあればuv addで依存関係を再登録）して動作確認する。
  3. 一定期間、両者を並行運用し、CI・本番環境も含めて問題がないことを確認する。
  4. Anacondaのアンインストールに注意する。Anaconda環境をpyenv経由でグローバル設定していた場合（pyenv global anaconda3-x.x.x）、シェルの初期化スクリプト（.zshrc等）に残ったPATH設定を必ず確認し、他のツールのパス解決に影響しないよう慎重に外す。Anacondaのアンインストーラーはconda環境下のbase環境を削除するだけでなく、.condarcや~/anaconda3ディレクトリ自体を手動で削除する必要がある場合が多い。
  5. pyenvを完全に廃止するかは任意である。pyenvの.python-versionとの互換性があるため、チームの移行状況に応じてpyenv自体は残しつつ、実際のバージョンインストール・切り替えをuv経由に寄せていく、という漸進的な移行も可能である。

8. まとめ

2026年のPython環境構築は、特別な理由がない限りuv一択という状況にほぼ収斂した。uvはバージョン管理・仮想環境・パッケージ/プロジェクト管理という3つの異なる問題を、Rust実装による高速な単一ツールでカバーする。

図1: Python環境構築の3レイヤーとツールの守備範囲 Python環境構築における「①インタープリタのバージョン管理」「②仮想環境」「③パッケージ/プロジェクト管理」の3層構造と、pyenv・venv/virtualenv・conda/Miniforge・Poetryなど従来ツールがそれぞれ1〜2層をカバーするのに対し、uvが単一ツールで3層すべてを横断してカバーする様子を示す概念図

一方で、pyenvは既存運用の維持や特殊なPython実装の管理に、venv+pipは依存ゼロで完結させたい場面に、conda/Miniforgeは科学計算・GPU用途のネイティブ依存管理に、それぞれ今も居場所がある。「万能ツールが1つ登場したから他は全廃」ではなく、uvを基本線としつつ、必要に応じて適材適所で従来ツールを組み合わせるのが2026年時点の現実的な結論である。

よくある質問(FAQ)

uvだけで全部済む?

多くのケースでは済む。バージョン管理・仮想環境・パッケージ/プロジェクト管理のすべてをuvがカバーしており、新規プロジェクトであればuv initからuv runまで一気通貫で完結する。ただしCUDAツールキットなどPythonパッケージの枠を超えたネイティブ依存が絡む場合は、conda/Miniforgeの併用を検討する余地が残る（第5章・第6章参照）。

Anacondaはもう不要?

一般的なPython開発では不要と考えてよい。データサイエンス・機械学習用途で条件付きの科学計算パッケージ群がまとめて欲しい場合でも、2024年以降のAnaconda商用ライセンス強化を踏まえると、BSDライセンスで無償のMiniforgeを選ぶ方が安全である（第1章・第5章参照）。

uvとpyenvは併用できる?

できる。uvの.python-versionファイルはpyenvと共通のフォーマットを踏襲しているため、既存のpyenv運用を残したまま、実際のバージョンインストールや切り替えだけをuv経由に寄せる、といった段階的な移行が可能である（第3章・第7章参照）。

requirements.txtはもう使わない?

新規プロジェクトではpyproject.toml + uv.lockを推奨する。ただしuvはpip互換インターフェース（uv pip install -r requirements.txt）を提供しているため、既存プロジェクトをrequirements.txtのまま当面運用することも可能である。余裕ができたタイミングでuv addベースの管理に段階移行するのが現実的である（第6章参照）。

参考文献

この記事に関連する無料ツール

DevToolBox Moving Average Calculator SMA/EMA/WMA をブラウザで即座に計算 DevToolBox JSON Formatter JSONを整形・圧縮・バリデーション DevToolBox Regex Tester 正規表現をリアルタイムテスト

関連記事