WindowsでPython仮想環境を使う前に確認したい実行環境と依存関係の整理

WindowsでPython仮想環境を使う前に確認したい実行環境と依存関係の整理を、実際にコマンドを打つ順番に沿ってまとめます。対象は、Windows上でPythonの自動化スクリプトやAI関連のライブラリをプロジェクトごとに動かしたい人です。

まず押さえるべきこと：仮想環境はPython本体の代わりではない

venvは、すでにインストールされているPythonを土台にして、プロジェクト専用のPython環境を作る標準ライブラリの機能です。仮想環境ごとに、使用するPythonインタープリターと追加パッケージを分離できます。

たとえば、プロジェクトAはあるライブラリの1.0系、プロジェクトBは2.0系を必要とする、といった依存関係の衝突を避けられます。Windowsのシステム全体へパッケージを入れる運用より、どのプロジェクトに何が入っているかを追いやすいのが利点です。

一方、仮想環境は万能な隔離機能ではありません。作成時に使ったPythonがベースになるため、まず公式版のPythonが利用できる状態が必要です。また、仮想環境のフォルダーはGitなどのバージョン管理へ含めず、削除・再作成できるものとして扱います。環境そのものを別の場所へコピーして使うのではなく、依存関係から作り直す設計が前提です。

Windowsで作成する手順

プロジェクト用フォルダーを作り、PowerShellでそのフォルダーへ移動します。仮想環境の名前は、プロジェクト内で分かりやすい.venvにしておくと扱いやすいでしょう。

mkdir my-python-app
cd my-python-app
py -m venv .venv

py -m venv .venvは、Pythonのvenvモジュールを実行し、.venvフォルダーへ環境を作成するコマンドです。既存のフォルダーを指定した場合は再利用されるため、意図せず既存環境へ変更を加えないよう、プロジェクトごとに名前を決めて運用します。

PowerShellで有効化する場合は次のコマンドです。

.venv\Scripts\Activate.ps1

コマンドプロンプトなら、次を使います。

.venv\Scripts\activate.bat

有効化できると、通常はプロンプトに環境名が表示されます。ただし、表示だけに頼らず、実際にどのPythonが呼ばれるかを調べる方が安全です。

where python
python --version

結果のパスに.venv\Scripts\pythonが含まれていれば、プロジェクト用のPythonを使っていると判断できます。PowerShellでActivate.ps1が実行できない場合は、ユーザー単位の実行ポリシーが原因の可能性があります。公式ドキュメントでは、次の設定例が示されています。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

組織の端末ではポリシー変更が許可されない場合もあるため、その場合はコマンドプロンプトでactivate.batを使うか、仮想環境内のPythonをフルパスで呼び出す方法に切り替えます。仮想環境は必ずしも有効化しなければならないわけではなく、.venv\Scripts\python.exeを直接指定して実行することもできます。

pipは「python -m」で呼び出す

環境を有効化した後は、パッケージのインストールにpython -m pipを使うのが切り分けしやすい方法です。pip単体を呼ぶより、今実行しているPythonに対応するpipを明示しやすくなります。

python -m pip install --upgrade pip
python -m pip --version
python -m pip install requests

特定のバージョンが必要なら、バージョン指定を加えます。

python -m pip install "requests==2.18.4"

ただし、このバージョンはあくまで指定方法の例です。実際のアプリケーションでは、対象ライブラリがサポートするPythonバージョンや他の依存関係との組み合わせを見て決めます。AIや自動化のライブラリでは、Pythonのバージョン、OS、CPU向け・GPU向けの配布物などが絡むため、最新版を無条件に入れるより、動作条件を先に固定する方がトラブルを減らせます。

インストール済みの内容は、次のコマンドで確認できます。

python -m pip list
python -m pip show requests
python -m pip freeze

requirements.txtで再作成できる状態にする

仮想環境は移動やコピーに向かないため、再現手順をファイルに残します。現在の環境を記録するなら、次のようにします。

python -m pip freeze > requirements.txt

別のフォルダーや別のWindows端末で再構築するときは、先に新しい仮想環境を作り、その中で次を実行します。

py -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt

requirements.txtはGitへ含め、.venvは含めない、という分け方が基本です。なお、pip freezeはその時点で環境に入っているパッケージ一覧を出力します。不要なパッケージまで入った状態で記録すると、再作成時にも不要な依存関係が増えるため、プロジェクト専用の環境で作るのが現実的です。

つまずいたときの切り分け

「インストールしたのにimportできない」場合は、まずwhere pythonとpython -m pip --versionを実行します。表示された場所が.venvではなければ、別のPythonへインストールしている可能性があります。

PowerShellの有効化で止まる場合は、実行ポリシー、シェルの種類、コマンドのパスを順番に切り分けます。有効化に固執せず、次のように直接実行する方法もあります。

.venv\Scripts\python.exe script.py
.venv\Scripts\python.exe -m pip install requests

また、仮想環境を作った後に親フォルダーを移動した、あるいは環境フォルダー自体をコピーした場合は、内部の絶対パスが問題になることがあります。その場合は古い環境を使い回さず、移動先で.venvを削除して再作成し、requirements.txtからパッケージを入れ直す方が確実です。

どの運用を選ぶべきか

複数のPythonプロジェクトを並行して動かす人、ライブラリのバージョンを固定したい人、将来同じ環境を再構築したい人には、venvとrequirements.txtの組み合わせが向いています。逆に、標準ライブラリだけの短いスクリプトで、追加パッケージを使わないなら、仮想環境が必須とは限りません。

ただし、AI、自動化、データ処理のように依存パッケージが増えやすい用途では、最初からプロジェクトごとに.venvを作る方が、後からシステム全体のPythonを整理するより手戻りが少なくなります。WindowsでのPython環境構築は、有効化できたかだけでなく、実行するPythonの場所、pipの紐付け、再作成手順まで含めて考えるのが実務的な実行環境と依存関係の整理です。

筆者の環境で実際に確認した結果

確認日：2026年10月14日／環境：Windows 11 Home（ビルド26300）、Windows PowerShell 5.1、Python 3.14

実際に新しいvenvを作って、グローバル環境との違いを確認しました。

> python -m venv .venv
> .venv\Scripts\python.exe -c "import sys; print(sys.prefix); print(sys.base_prefix)"
...\rin_verify\.venv
...\Programs\Python\Python314

> .venv\Scripts\python.exe -m pip list
Package Version
------- -------
pip     26.2.1

> .venv\Scripts\python.exe -c "import requests"
ModuleNotFoundError: No module named 'requests'

グローバルのPython 3.14には requests が入っていますが、作ったばかりのvenvには pip しかなく、同じ import requests が失敗しました。また where python を実行すると、最初に出てきたのは ...\Microsoft\WindowsApps\python.exe（Microsoft Storeのエイリアス。ファイルサイズは0バイト）で、インストールしたPythonは2番目でした。どのpython.exeが動いているかは sys.executable と sys.prefix で確認できます。