python環境がぐちゃぐちゃになったら読む記事｜venv・pyenv・conda・Microsoft Store版混在を診断して直す復旧ガイド

「pip installしたはずなのにimportできない」「コマンドプロンプトでpythonと打ったらMicrosoft Storeが開いた」「condaとpipを両方使っていたらJupyterが起動しなくなった」――今まさにこんな状態で、この記事にたどり着いたのではないでしょうか。

先に、2つだけお伝えしておきたいことがあります。

• 今の環境は、全部消してやり直してかまいません。「壊してしまった」という罪悪感を抱く必要はまったくありません。
• OSの再インストールは基本的に不要です。「もう全部入れ直すしかない」という極端な解決策に頼らなくても、順序立てて整理すれば元に戻せます。

この記事では、次のことが分かります。

• 今の自分がどのパターン(venv混在/pyenv混乱/conda×pip混在/Microsoft Store版×公式インストーラー版混在)に近いかの見分け方
• pip list・pip freeze・where python(Windows)/which python3(Mac)・sys.executableを使った「今の状態」の正確な把握の仕方
• パターンごとの具体的な復旧手順(自分に該当する箇所だけ読めばよい設計です)
• 作り直す前に確認・バックアップしておくべきこと(requirements.txtなど)
• 二度と同じ状態に戻らないための習慣化のポイント

「ModuleNotFoundErrorって結局何?」「pipが認識されないのはなぜ?」というレベルの、基本的な原因から知りたい方は、python学習⑦(ModuleNotFoundErrorとpipが認識されない時の対処法)を先にご覧いただくことをおすすめします。本記事は、そこからさらに一歩進んで、すでに複数のpython環境が混ざり合ってしまった状態を、どう診断し、どう解きほぐすかに特化した実践編です。

中の人

「え、これ詰んだ…?」って思うかもしれないけど、大丈夫。壊れて見える環境も、ちゃんと直せるようになってるから安心してね。

python環境がぐちゃぐちゃになった人へ ― まず今の状況を4パターンで診断しよう

基本的なModuleNotFoundErrorの原因や、pipコマンドが認識されないときの対処法については、python学習⑦｜ModuleNotFoundErrorとpipが認識されない時の対処法で解説済みです。すでにそちらを試したうえで、「それでもまだ何かおかしい」「複数の環境が絡み合っている気がする」という状態であれば、この記事が対応する範囲です。

まずは、今の自分がどのパターンに近いか、ざっくりで構わないので確認してみてください。1つに絞れなくても大丈夫です。複数のパターンに同時に当てはまっている人も珍しくありません。

パターンA:venv混在

プロジェクトのフォルダのあちこちにvenvや.venvというフォルダが増えていて、「どれが今使っているものか」「そもそも何個あるのか」が分からなくなっている状態です。pip installしたはずのライブラリが見つからない、という症状が典型的です。

パターンB:pyenv混乱

pyenv globalやpyenv localでバージョンを切り替えたつもりなのに、python --versionで確認すると意図したバージョンになっていない状態です。「切り替えたのに反映されない」という声が最も多いパターンです。

パターンC:conda×pip混在

Anacondaやminicondaを使いつつ、途中からpip installも併用してしまい、base環境やconda環境の中身が複雑になっている状態です。Jupyter Notebookが急に起動しなくなった、ライブラリ同士が競合してエラーが出る、といった症状につながりやすいパターンです。

パターンD:Microsoft Store版×公式インストーラー版混在(Windows限定)

Windowsで、Microsoft Storeからインストールしたpythonと、python.orgの公式インストーラーからインストールしたpythonの両方が入っている状態です。「pythonと打つとMicrosoft Storeの画面が開いてしまう」という症状はこのパターンの典型例です。

「自分は複数のパターンに当てはまっている気がする」という方も心配いりません。この後の章でまず現在の状態を棚卸しし、そのうえでパターンごとに整理していきますので、併発していても1つずつ順番に対応すれば大丈夫です。

中の人

複数のパターンに当てはまってても焦らなくて平気だよ。順番に1個ずつ片付けていけば、ちゃんとゴールにたどり着けるから。

先に伝えたいこと ― 全部消してやり直していいし、OS再インストールは基本不要

本題の手順に入る前に、もう一段だけ安心材料を掘り下げておきます。環境が混在してしまうと、「自分が何か間違った操作をしたせいだ」「取り返しのつかないことをしてしまったのでは」と、必要以上に自分を責めてしまう方が少なくありません。

結論からお伝えすると、venvもconda環境も、そしてpythonそのものも、消してからもう一度作り直すことができます。データベースのように「二度と復元できない状態」になることはありません。仮想環境というのは、パッケージを詰め込んだ「箱」にすぎないので、箱ごと捨てて新しい箱を用意し直すことに何の問題もないのです。

中の人

「壊しちゃった…」って落ち込まなくていいんだよ。仮想環境なんて、しょせんただの箱だからね。何度でも作り直せる。

ただし、すべてのケースで「全部消して作り直す」が最短ルートとは限りません。パターンによっては、設定ファイルを1つ直すだけで済む部分復旧のケースもあれば、既存の環境を丸ごと作り直したほうが結果的に早い作り直しのケースもあります。どちらが自分に当てはまるかは、この後の「棚卸し」で今の状態を正確に把握してから、パターン別の章で判断していきます。まずは焦らず、次の棚卸しのステップから始めましょう。

まずは棚卸し:今のpython/pip環境を正確に把握する【最重要パート】

ここが、この記事の中でもっとも重要なパートです。パターン別の復旧手順を早く読みたい気持ちも分かりますが、このステップを飛ばしていきなり削除・再インストールに進むと、かえって状態が複雑になってしまうことがよくあります。「今、何がどこにどう入っているか」を正確に把握してから手を動かすことで、無駄な作業や事故を防げます。

まずは、今使っているpythonのバージョンを確認します。

python --version

実行すると、今使われているpythonのバージョンが「Python 3.11.4」のように表示されます。Windowsのコマンドプロンプト、Macのターミナルのどちらでも同じコマンドで確認できます。

次に、今の環境にどんなライブラリが入っているかを確認します。ここでよく混同されるのがpip listとpip freezeの違いです。pip listは「今入っているライブラリを人間が見やすい表形式で一覧表示する」コマンドで、依存関係として自動で入ったライブラリまで含めて表示されます。一方、pip freezeは「そのままrequirements.txtに書ける形式(ライブラリ名==バージョン番号)で出力する」コマンドで、後で環境を再現するためのバックアップ用途によく使われます。「今何が入っているか確認したいだけ」ならpip list、「後で同じ環境を再現できるように控えておきたい」ならpip freeze、という使い分けを覚えておくと便利です。

pip list

pip freeze

# pip list の出力イメージ(人が目で見るための一覧表、Windows/Mac共通)
Package    Version
---------- -------
pandas     2.2.2
requests   2.31.0

# pip freeze の出力イメージ(そのままrequirements.txtに保存できる「名前==バージョン」形式)
pandas==2.2.2
requests==2.31.0

pip listは見出し付きの一覧表、pip freezeは「パッケージ名==バージョン」形式のテキストを出力します。バックアップとして保存したいときはpip freezeの結果を使います。

続いて確認したいのが、「今実際に動いているpythonの実体パス」です。コマンド名としてのpythonやpython3は同じでも、実は違うフォルダにあるpythonを指していることがあります。これを確認できるのがsys.executableです。

python -c "import sys; print(sys.executable)"

コマンドプロンプトやターミナルにこのまま1行で入力して実行します。実行すると、今実際に呼び出されているpython.exe(Macの場合はpython3の実体ファイル)のフルパスが1行で表示されます。

Windowsを使っている場合は、pythonランチャーのpy --listおよびpy --list-pathsも合わせて確認しておくと、パソコンにインストールされている複数バージョンのpythonを一覧で把握できます。

REM インストールされているpythonのバージョン一覧を確認する(pythonランチャー)
py --list

REM 各バージョンの実際のインストール先パスまで一緒に確認する
py --list-paths

実行すると、パソコンにインストールされている複数のpythonバージョンの一覧が表示されます。py –list-pathsではバージョンごとの実際のインストール場所も確認できます。

Windowsでの確認コマンド(where python)

where pythonを実行すると、コマンドプロンプトから見えるpythonの場所が、優先順位が高い順に一覧で表示されます。複数のパスが表示された場合、一番上に表示されているものが、実際にpythonとだけ入力したときに使われるpythonです。2番目以降に表示されているパスは、PATHの設定上は認識されているものの、コマンド入力時には優先されないpythonということになります。

表示されたパスの見分け方としては、以下のポイントを押さえておくと判断しやすくなります。

• パスの中にWindowsAppsという文字列が含まれている場合は、Microsoft Store版のpythonです。
• パスの中にProgram FilesやAppDataLocalProgramsPythonといった文字列が含まれている場合は、python.orgの公式インストーラーからインストールしたpythonです。

where python

REM 実行結果のイメージ(2つのpythonが見つかった例)
C:Usersユーザー名AppDataLocalMicrosoftWindowsAppspython.exe
REM ↑Microsoft Store版(WindowsAppsフォルダ配下にある)

C:Usersユーザー名AppDataLocalProgramsPythonPython312python.exe
REM ↑公式インストーラー版(Program FilesまたはAppDataLocalPrograms配下にある)

一番上に表示されたパスが、実際にpythonコマンドを打ったときに使われます。WindowsAppsという文字列を含むパスが一番上にある場合、Microsoft Store版が優先して起動している状態です。

Mac/Linuxでの確認コマンド(which python3)

Mac/Linuxの場合は、which python3で今使われているpython3の場所を、type python3でそれがコマンドなのかエイリアスなのかを確認できます。pyenvを使っている場合は、pyenv versionsを実行するとインストール済みのバージョン一覧と、現在有効になっているバージョンが分かります。

パスの特徴から、どの経由でインストールされたpythonかをある程度見分けることができます。

• パスに/opt/homebrewや/usr/local/Cellarが含まれる場合は、Homebrewでインストールしたpythonです。
• パスに.pyenv/shimsや.pyenv/versionsが含まれる場合は、pyenvが管理しているpythonです。
• パスが/usr/bin/python3のようにシステム標準の場所を指している場合は、OSにあらかじめ入っているシステム標準のpythonです。

# 今使われているpython3コマンドの実体パスを確認する
which python3

# python3コマンドが何(エイリアスか実体ファイルか)を指しているか確認する
type python3

# pyenvで管理しているpythonのバージョン一覧を確認する(*が付いている行が現在有効なバージョン)
pyenv versions

# which python3 の出力イメージ(Homebrewでインストールした場合)
/opt/homebrew/bin/python3

# pyenv versions の出力イメージ(pyenv版が有効になっている場合)
  system
* 3.11.4 (set by /Users/ユーザー名/.pyenv/version)
  3.12.2

パスが/opt/homebrew配下ならHomebrewでインストールしたpython、/Users/ユーザー名/.pyenv配下ならpyenvが管理しているpythonです。pyenv versionsで先頭に*が付いている行が、現在実際に使われているバージョンです。

中の人

地味な作業に見えるかもしれないけど、この棚卸しが実は一番大事。ここをちゃんとやっておくと、後がグッと楽になるよ。

棚卸し結果をメモにまとめる

ここまでの確認結果を、以下の3項目としてメモに書き出しておくことをおすすめします。

• 今動いているpythonの実体パス(sys.executableやwhere python/which python3の結果)
• pip listで確認した、現在入っているライブラリの概要
• pyenv・conda・venvのうち、どれがこの環境に関与しているか

この3項目は、次の「作り直す前にやることチェックリスト」と、その後の「パターン別復旧手順」の両方で前提情報として使います。ここで正確に書き出しておくほど、後の作業がスムーズに進みます。

環境を作り直す前にやることチェックリスト

棚卸しで今の状態が見えてきたところで、実際に削除や作り直しの作業に入る前に、もう一度確認しておきたいことをまとめます。ここを飛ばして先に手を動かしてしまうと、後から「あのライブラリ、何を入れていたか思い出せない」という事態になりかねません。

まず、今入っているライブラリの一覧を、そのまま再現できる形式でファイルに書き出しておきます。

pip freeze > requirements.txt

実行すると、今いるフォルダにrequirements.txtというファイルが作成され、中に「パッケージ名==バージョン」の一覧が保存されます。環境を作り直す前に、必ずこの手順で控えておきましょう。

そのうえで、以下の項目を1つずつ確認していきましょう。

• □ requirements.txt(または相当するファイル)を、プロジェクトごとに書き出したか
• □ どのプロジェクトフォルダが、どのvenv・conda環境を使っているかを一覧化したか
• □ 今から削除しようとしている環境が、グローバル環境を巻き込んでいないか(グローバルにしか入っていないライブラリまで一緒に消してしまわないか)を確認したか
• □ 環境の中に、消すと困るデータ(Notebookの実行結果、設定ファイル、キャッシュされたモデルファイルなど)が紛れ込んでいないか最終確認したか

特に、グローバル環境と各プロジェクト用のvenvを混同したまま作業してしまうと、思わぬところで別のプロジェクトまで動かなくなることがあります。「これから触ろうとしている環境が、本当にそのプロジェクト専用のものか」を、削除する直前にもう一度確認する習慣をつけておくと安心です。

パターン別:python環境の復旧手順【最大差別化ポイント】

ここからは、冒頭で診断した4パターンごとに、具体的な復旧手順を見ていきます。複数のパターンに同時に当てはまっている場合は、上から順番に対応していけば問題ありません。自分に該当する見出しだけを読んでいただいて構いません。

中の人

自分に関係ないパターンは読み飛ばして全然オッケー。該当するところだけつまみ食いしていこう。

パターン1 venv混在の整理・作り直し手順

まずは、パソコンの中に散らばっているvenv・.venvフォルダの場所を特定します。プロジェクトフォルダを1つずつ開いて、直下や1階層内にそれらしいフォルダがないか確認しましょう。棚卸しでメモした「どのプロジェクトがどの環境を使っているか」の情報が、ここで役立ちます。使われていないことが確認できたvenvフォルダは、フォルダごと削除して問題ありません(venvフォルダはあくまで「箱」であり、プロジェクトのソースコード自体には影響しません)。

不要なvenvを片付けたら、そのプロジェクト用に新しい仮想環境を作り直します。

python -m venv venv

実行すると、今いるフォルダに「venv」という名前のフォルダが新規作成され、その中に専用のpython本体一式が用意されます。

作成した仮想環境は、そのままでは無効な状態です。有効化のコマンドは、WindowsとMacで異なります。

Windowsの場合:

REM Windowsで仮想環境を有効化する
venvScriptsactivate

実行後、コマンドプロンプトの行の先頭に(venv)と表示されれば、仮想環境が有効化された状態です。

Mac(およびLinux)の場合:

# Mac/Linuxで仮想環境を有効化する
source venv/bin/activate

実行後、ターミナルの行の先頭に(venv)と表示されれば、仮想環境が有効化された状態です。

有効化できたら、先ほど確認したrequirements.txtを使ってライブラリをまとめて復元します。

pip install -r requirements.txt

仮想環境を有効化した状態で実行すると、requirements.txtに記載された全ライブラリが一括でインストールされ、以前と同じ環境を再現できます。

これで、venvが乱立していた状態から、プロジェクトごとに1つのクリーンな仮想環境という状態に整理できます。

パターン2 pyenvのバージョン切り替えが反映されないときの整理手順

pyenvには、global(パソコン全体でのデフォルトバージョン)とlocal(特定のフォルダ内だけで有効になるバージョン)という2種類の設定があり、localの設定がglobalより優先されます。「globalを切り替えたのに反映されない」という場合、実はそのフォルダに.python-versionというファイルが残っていて、localの設定が優先されているケースがよくあります。

また、pyenvでインストールしたpythonは、いったん「shims」という仕組みを経由して呼び出されます。この仕組みがうまく機能していないと、切り替えたはずのバージョンが反映されないことがあります。まずは以下のコマンドで、現在の設定状況を確認しましょう。

# インストール済みのpythonバージョン一覧と、現在有効なバージョンを確認する
pyenv versions

# パソコン全体(グローバル)で使うデフォルトのpythonバージョンを指定する
pyenv global 3.11.4

# 今いるフォルダ(プロジェクト単位)だけで使うpythonバージョンを指定する
# 実行するとこのフォルダに.python-versionというファイルが作られ、globalより優先される
pyenv local 3.12.2

pyenvは、pyenv localで指定したバージョンをpyenv globalより優先して使います。特定のプロジェクトフォルダの中でpython –versionを実行し、pyenv localで指定した値になっているかを確認しましょう。

なお、pyenv自体のインストール方式とPATHの設定は、WindowsとMacで異なります。Windowsではpyenv-winという別プロジェクトが使われており、PowerShellやコマンドプロンプトの環境変数に手動でパスを追加する必要があります。一方、Macでは主にHomebrew経由、またはpyenv-installer(gitを使ったインストール方式)が使われ、シェルの設定ファイルにeval "$(pyenv init -)"のような初期化コマンドを追記する形になります。この初期化コマンドの記述が抜けていたり、想定と違うシェルの設定ファイルに書かれていたりすると、pyenvがインストールされているのにコマンドとして認識されない、という状態になります。

設定を見直しても状況が変わらない場合は、以下のようなリセット操作を試してみてください。

# pyenvが管理するコマンドの対応表(shims)を作り直す
# バージョンを切り替えたのにコマンドの挙動が変わらない時に実行する
pyenv rehash

実行すると、pyenvが内部で管理しているコマンドの参照情報が最新の状態に更新されます。バージョン切り替え後にコマンドがうまく反映されないときに試してみてください。

パターン3 conda×pip混在からの復旧手順

conda環境の中でも、特にbase環境(condaをインストールした直後から存在するデフォルトの環境)を直接いじってしまうと、あとから収拾がつかなくなりやすい傾向があります。base環境にはできるだけ手を加えず、プロジェクトごとにconda createで専用の環境を作り、そちらに移行していく方針をおすすめします。

# base環境を汚さないよう、プロジェクト専用のconda環境を新規に作る(Windows/Mac共通)
# 「myenv」の部分は好きな環境名、「python=3.11」の部分は使いたいバージョンに置き換える
conda create --name myenv python=3.11

実行するとmyenvという名前の専用環境が新規作成されます。base環境には手を加えないため、他のプロジェクトへの影響を避けられます。

# 作った環境を有効化する(Windows/Mac共通)
conda activate myenv

# 1. condaで配布されているライブラリは、先にconda installで入れる
conda install numpy pandas

# 2. condaに無い(またはcondaでは古い)ライブラリだけ、後からpip installで補う
pip install requests

condaとpipを併用する場合は「conda installを先に、pip installを後に」という順序を守ると、依存関係の競合が起きにくくなります。順序を逆にすると、condaが依存関係を正しく把握できなくなり、環境が壊れやすくなります。

それでもbase環境が複雑に汚染されてしまい、どこから手をつけていいか分からない場合の最終手段として、Anacondaそのものの再インストールや、anaconda-cleanコマンドによるクリーンアップという選択肢があります。ただし、これはあくまで最終手段です。base環境をいきなり丸ごと消去する前に、まずは専用のconda環境への切り出しで解決できないかを試すことをおすすめします。

# 実行前に、pip freeze > requirements.txt などで今の環境の情報を必ず控えておく(Windows/Mac共通)
# これはあくまで最終手段のコマンドです

# anaconda-cleanパッケージをインストールする
conda install anaconda-clean

# Anaconda関連の設定・環境をまとめてリセットする(実行前に確認プロンプトが表示される)
anaconda-clean

実行すると、ホームフォルダ内の.anaconda_backupフォルダに現在の設定がバックアップされたうえで、Anaconda関連の設定がリセットされます。base環境やconda自体がどうしようもなく壊れてしまった場合の最終手段として使ってください。

中の人

anaconda-cleanは正直、最終手段中の最終手段。先にrequirements.txtだけは絶対に控えておいてね。

パターン4【Windows限定・最重要】Microsoft Store版×公式インストーラー版混在からの復旧手順

このパターンはWindows固有の現象です。Macを使っている方は、このセクションは読み飛ばして次の章に進んでいただいて構いません。

まず、なぜ「pythonと打つとMicrosoft Storeが開いてしまう」のかを説明します。Windows 10/11には、標準の状態でpython.exeという名前の「ダミーの実行ファイル」がPATH上に登録されています。このダミーファイルは、実行されると中身のpythonを起動する代わりに、Microsoft Storeのpythonページを開くように仕込まれています。python.orgの公式インストーラーでpythonをインストールしていない、あるいはインストールしても優先順位が正しく設定されていない場合に、このダミーファイルが先に反応してしまい、Storeが開いてしまうのです。

この現象は、以下の手順で解消できます。

手順1:アプリ実行エイリアスをオフにする
「設定」を開き、「アプリ」→「アプリ実行エイリアス」(検索ボックスに「エイリアス」と入力しても見つかります)と進みます。一覧の中に「App Installer」提供のpython.exeおよびpython3.exeという項目があるはずなので、それぞれのトグルスイッチをオフに切り替えます。これだけで、コマンドプロンプトでpythonと打ったときにMicrosoft Storeが開く現象は解消します。

手順2:Microsoft Store版pythonをアンインストールする
Microsoft Store版のpythonを実際にインストールしてしまっている場合は、あわせてアンインストールしておくと混乱を防げます。「設定」→「アプリ」→「インストール済みのアプリ」(または「アプリと機能」)の一覧から、「Python 3.x」のようにMicrosoft Storeのアイコンが付いているものを探し、アンインストールを実行します。

手順3:python.org公式インストーラーを再インストールし、PATHの優先順位を確認する
python.orgから公式インストーラーをダウンロードし、インストール画面の「Add python.exe to PATH」にチェックを入れて実行します。インストール後、where pythonを実行して、公式インストール先のパスが一番上(最優先)に表示されているかを確認しましょう。

where python

REM 実行結果のイメージ(2つのパスが表示された例)
C:Usersユーザー名AppDataLocalMicrosoftWindowsAppspython.exe
C:Usersユーザー名AppDataLocalProgramsPythonPython312python.exe

REM 見分け方のポイント
REM 1. パスに「WindowsApps」が含まれる → Microsoft Store版
REM    実体はダミーのexeで、これを実行するとMicrosoft Storeのアプリページが開くだけのことが多い
REM 2. パスに「ProgramsPython」や「C:PythonXX」が含まれる → 公式インストーラー版
REM    python.org からダウンロードしてインストールした本体
REM 3. whereの結果は「上から順番に実行される優先順位」を表す
REM    1番上にStore版のパスが来ている場合、pythonコマンドを打つとStore版が優先して起動してしまう

where pythonで表示された一覧の一番上のパスが、実際にpythonコマンドで起動されるものです。WindowsAppsという文字列を含むパスが一番上にある場合は、Microsoft Store版が優先されている状態だと判断できます。

ここまでの整理ができたら、今後はpythonやpython3とだけ打つのではなく、pyランチャー(pyコマンド)を使って、意図したバージョンを明示的に呼び出す運用に切り替えることをおすすめします。pyコマンドは、複数バージョンのpythonがインストールされていても、バージョン番号を指定して確実に呼び出せる仕組みです。

REM pythonランチャーで、バージョンを明示して実行する(例:python 3.11を指定)
py -3.11

REM 利用可能なバージョン一覧を確認する(どちらの書き方でも同じ内容が確認できる)
py -0
py --list

py -3.11のようにバージョン番号を指定すると、インストール済みの複数バージョンの中から狙ったものだけを起動できます。py -0またはpy –listを実行すると、現在使えるバージョンの一覧が表示され、Microsoft Store版に頼らずバージョンを明示的に選ぶ運用に切り替えられます。

そもそもなぜ環境が混在するのか?pyenv・venv・pip・condaの役割の違い

ここまでの手順で目の前の混乱は解消できたはずですが、最後に「そもそもなぜこうなってしまうのか」を整理しておきます。手順を丸暗記するだけでなく、仕組みを理解しておくことで、次に似た状況になったときにも自力で対応しやすくなります。

混乱の大きな原因は、pyenv・venv・pip・condaという4つのツールが、実はそれぞれ別の役割(レイヤー)を担当しているのに、名前も使い方も似ているために「どれも同じようなもの」と捉えてしまいがちなことにあります。

• pyenv:pythonそのもののバージョンを切り替える(python 3.10を使うか3.12を使うかを選ぶ)ためのツール
• venv:プロジェクトごとに、インストールするライブラリを隔離する(他のプロジェクトに影響を与えない)ためのツール
• pip:ライブラリそのものをインストールする、パッケージインストーラー
• conda:上記3つの役割(バージョン管理・環境の隔離・パッケージのインストール)を、1つのエコシステムとしてまとめて行うツール

condaは、pyenv・venv・pipの役割をすべて内包しているという点が、混乱の一番の原因です。condaだけで完結させるつもりが、途中で「condaに無いライブラリだから」とpipを使ってしまったり、pyenvも別途インストールしてバージョン管理を二重に行ってしまったりすると、同じ役割を持つツールが複数同時に動いている状態になります。役割が重なった状態でそれぞれのツールが別々にファイルを書き換えようとするため、どちらの設定が優先されているのか分からなくなり、結果として「環境がぐちゃぐちゃになった」という状態に陥ってしまうのです。

一言でまとめると、「同じ役割を持つツールを複数同時に、しかもルールを決めずに使ってしまうこと」が、環境混在の根本的な原因だと言えます。

中の人

pyenv・venv・pip・condaがそれぞれ別の仕事してるって分かると、頭の中がスッキリしない?ここが分かればもう混乱しないはずだよ。

同じことを繰り返さないための習慣化:再発防止のポイント

復旧作業が終わったら、最後に、同じ状態を繰り返さないための習慣をいくつか身につけておきましょう。

• プロジェクトごとに新しいvenv(またはconda環境)を作る:既存の環境を使い回さず、新しいプロジェクトを始めるときは必ず専用の仮想環境を作る習慣をつけましょう。
• VS Codeのインタープリター選択を、プロジェクトを開くたびに確認する:別のプロジェクトのpythonが選択されたままになっていないか、画面右下の表示をひと目確認する癖をつけると事故を防げます。
• venvを有効化できているかを、作業を始める前に確認する:コマンドプロンプトやターミナルの先頭に(venv)のような表示が出ているかどうかで、有効化できているかを見分けられます。
• condaとpipを併用する場合は、インストール順序ルールを徹底する:condaで入るものは先にconda、その後にpip、という順序を毎回守りましょう。
• 月1回程度、環境の棚卸しを軽くルーティン化する:この記事の「棚卸し」章の手順を、忘れた頃に一度実行してみるだけでも、混在の芽を早めに摘み取れます。

まとめ:python環境の復旧は「棚卸し→整理→再発防止」の3ステップ

最後に、この記事の内容を振り返ります。python環境の復旧は、大きく分けると次の3ステップです。

1. 棚卸し:python --version・pip list/pip freeze・sys.executable・where python(Windows)/which python3(Mac)を使って、今の状態を正確に把握する
2. 整理:自分が該当するパターン(venv混在/pyenv混乱/conda×pip混在/Microsoft Store版×公式版混在)に沿って、必要な部分だけを作り直す
3. 再発防止:プロジェクトごとに新しい仮想環境を作る、インストール順序を守るといった習慣を身につける

最初の診断がまだあいまいだった方のために、あらためて4パターンを挙げておきます。自己診断用にご活用ください。

• □ プロジェクトのあちこちにvenv・.venvフォルダが散らばっていて、どれが有効か分からない(venv混在)
• □ pyenvで切り替えたはずのバージョンが反映されない(pyenv混乱)
• □ condaとpipを両方使っていて、Jupyterが起動しない・ライブラリが競合する(conda×pip混在)
• □ pythonと打つとMicrosoft Storeが開いてしまう(Microsoft Store版×公式版混在、Windowsのみ)

基本的なModuleNotFoundErrorやpipが認識されない問題そのものについて、もう一度理解を深めておきたい方は、python学習⑦｜ModuleNotFoundErrorとpipが認識されない時の対処法もあわせてご覧ください。

中の人

お疲れさま!ここまで読んで実際に手を動かしてくれたら、もう環境迷子にはならないはずだよ。一緒に頑張ろうね。

まずは、この記事の「棚卸し」の章のコマンドを実際に1つずつ打ってみることから始めてみてください。今の状態が正確に見えてくれば、そこから先の整理は、思っているよりずっとシンプルに進められるはずです。