「(base) が出ているのは壊れている？」壊れていないけど切るべき理由と、グローバルを汚さない4層のPATH

PowerShell を開くと、いつもこう表示されていました。

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

パーソナル プロファイルとシステム プロファイルの読み込みにかかった時間は 1174 ミリ秒です。
(base) PS C:\Windows\system32>

先頭の (base) が Anaconda の base 環境であることは分かっています。今までこれで特に困ってもいませんでした。

ただ、改めて Claude Code をインストールして PATH を通す、といった作業を始めたことで、次の3つを共存させたときに PATH がどういう形になっていれば正しいのか、あやふやだった理解を一度整理し直すことにしました。

グローバル環境は汚したくない。だから venv で開発すると決めている
一方で Anaconda（conda）も入っている
VSCode では claude と打って Claude Code を起動したい

この記事は、その整理の結果と、「グローバルが空で、プロンプトを見れば今どこにいるか分かる」状態にするまでの手順です。私自身の備忘録でもあるので、各コマンドが何をしているかを、エンジニアでない方にも分かるように書きます。

この記事でできるようになること

(base) が何者で、なぜ消したほうがよいかが分かる
PATH を「優先順位」ではなく「層」で考えられるようになる
conda を消さずに、普段は PATH からいなくなってもらう設定ができる
Python 本体に余計なものが入っていないかを数えて、掃除できる
起動時の「プロファイルの読み込み時間」が短くなる（私の環境では 1174 ミリ秒が 702 ミリ秒になりました）

前提条件・環境

OS：Windows（PowerShell を使います）
Anaconda がインストール済み（私の環境では C:\Users\hidek\anaconda3）
Python 本体（python.org 版）が別に入っている。私の環境では 3.13 と 3.10
Claude Code、Git、Node.js が入っている

この記事では Anaconda をアンインストールしません。conda は残したまま、普段は前に出てこないようにします。

(base) は壊れていない。でも切ったほうがいい

まず結論です。(base) は異常ではありません。

(base) は、Anaconda や Miniconda が「base という環境を自動で有効にしましたよ」と知らせている表示です。conda をインストールしたときの標準の動作なので、壊れているわけではありません。

ここで出てくる言葉を2つだけ押さえておきます。

環境（かんきょう） とは、「この Python と、この追加部品のセットで動かします」という箱のことです。箱を分けておくと、A の仕事で入れた部品が B の仕事を壊すことがなくなります。

base は、conda が自分自身を動かすために最初から持っている箱です。

それでも自動で有効にするのはやめたほうがいい。理由は3つあります。

理由1：python と pip がどれを指しているか分からなくなる

base の箱が常に PATH の先頭にいるので、プロジェクトの venv を有効化し忘れたまま pip install を打つと、部品が base の箱に入ります。 これが一番よくある事故です。

理由2：base が汚れると conda 本体が壊れやすくなる

base は conda 自身が動くための箱です。ここに部品を積み上げると、conda 本体が頼っている部品と衝突して、復旧が面倒になります。

理由3：起動が遅くなる

冒頭に出ていた「プロファイル読み込みにかかった時間は 1174 ミリ秒」の大半は、PowerShell が起動するたびに読む設定ファイル（$PROFILE）に書かれた conda の初期化処理です。自動有効化をやめると、ここが軽くなります。

なお、自動有効化を切っても conda コマンド自体は使えます。使うときに conda activate 環境名 と自分で打つ運用になるだけです。

あるべき形は「優先順位」ではなく「層」

ここが今回の要点です。

PATH とは、コマンドを打ったときに Windows が「どのフォルダから順に探すか」を並べた一覧です。python と打てば、この一覧を上から見ていって、最初に見つかった python.exe が動きます。

PATH を「どれを先にするか」の勝負だと考えると、必ず破綻します。層ごとに役割を決めて、下の層に上の層を混ぜない、と考えると整理できます。私の用途だと4層です。

層	中身	置き場所	汚していいか
① 単体CLI	claude, git, node, npm	ユーザーPATHに常駐	汚れる概念がない
② Python本体	Python 3.x（素の状態）	PATHに入れない（py ランチャー経由）	絶対に汚さない
③ プロジェクト環境	venv	`プロジェクト\.venv`	ここだけ汚す
④ conda	特殊な依存が要る時だけ	常駐させず、必要時に conda activate	個別envは汚してよい

いま (base) が出ている状態は、④が常時①②の位置に居座っている状態です。だから「グローバルを汚したくないのに、どこがグローバルなのか分からない」という感覚になっていました。

① 単体CLI層：ユーザーPATHに置くもの

claude はネイティブインストーラで入れると %USERPROFILE%\.local\bin\claude.exe に置かれます（%USERPROFILE% は C:\Users\自分のユーザー名 のことです）。Node にも conda にも依存しない単独のプログラムなので、Python 環境の話とは完全に切り離して考えて構いません。

ユーザー環境変数 Path に入れるのは、この4つで足ります。

%USERPROFILE%\.local\bin
C:\Program Files\nodejs\
%APPDATA%\npm
C:\Program Files\Git\cmd

ここに Python も Anaconda も入れない、というのが要点です。

補足として、claude は winget 版（%LOCALAPPDATA%\Microsoft\WinGet\Links\claude.exe）とネイティブ版（%USERPROFILE%\.local\bin\claude.exe）が二重に入る事故が知られています。片方に統一してください。

② Python本体層：PATHに出さない

Windows には py ランチャー（C:\Windows\py.exe）があります。「ランチャー」は起動係のことで、py -3.13 のように打つと、指定した版の Python を探して起動してくれます。

これは最初からシステム PATH に入っているので、python.org 版の Python を「Add python.exe to PATH」のチェックを外してインストールすれば、python という名前はグローバル PATH のどこにも存在しなくなります。

これで何が起きるか。venv を有効化していない状態で pip install を打つと、コマンドが見つからずエラーになります。事故が「静かに base を汚す」から「うるさく失敗する」に変わります。 これが一番効きます。

③ プロジェクト層：唯一汚していい場所

venv を有効化すると .venv\Scripts が PATH の先頭に挿入され、プロンプトが (.venv) になります。抜けるときは deactivate です。

「プロンプトに何か出ている＝汚していい場所にいる」 という一対一の対応ができます。いままでは (base) が常に出ていたので、この信号が死んでいました。

④ conda層：常駐させず、箱として呼ぶ

conda を消す必要はありません。PATH に常駐させるのをやめるだけです。

自動有効化を切っても、$PROFILE に書かれた conda の初期化処理は残るので、conda コマンドは使えます。base が有効化されないだけです。つまり、普段は conda の Python は PATH にいません。conda が要るプロジェクトでは conda activate 環境名 と自分で打ち、プロンプトが (環境名) になります。

これで③と④が同じ規律で並びます。

手順1：現在の conda の設定を確認する

まず、いまの設定がどこに書かれているかを見ます。

conda config --show-sources

conda config は conda の設定を読み書きするコマンドで、--show-sources は「設定がどのファイルから来ているかを、ファイルごとに見せて」という指定です。私の環境ではこう出ました。

==> C:\Users\hidek\anaconda3\.condarc <==
channels:
  - defaults

==> C:\Users\hidek\anaconda3\condarc.d\anaconda-auth.yml <==
channel_settings:
  - frozendict.frozendict({'channel': 'https://repo.anaconda.cloud/*', 'auth': 'anaconda-auth'})

==> envvars <==
allow_softlinks: False

.condarc が conda の設定ファイルです。channels は部品をどこから取ってくるかの指定で、今回は触りません。

見てほしいのは、どこにも auto_activate という行が無いことです。書かれていないので、標準の値（自動で有効化する）がそのまま効いています。だから (base) が出ていました。

手順2：base の自動有効化を切る

設定を1行追加します。

conda config --set auto_activate false

--set 項目名値 は「この項目をこの値にして、設定ファイルに書き込んで」という指定です。auto_activate が「起動時に自動で環境を有効化するか」の項目で、それを false（しない）にしています。

もし auto_activate is not a known configuration parameter のようなエラーが出た場合は、conda のバージョンが古いので、古い名前の項目を使ってください。

conda config --set auto_activate_base false

逆に新しい conda で古い名前を使うと、Key auto_activate_base is an alias of auto_activate; setting value with latter という警告が出ます。動作はしますが、公式ドキュメントでも auto_activate_base は auto_activate の別名という扱いなので、新しい名前に書き換えたほうが無難です。

設定は、いま開いている PowerShell には反映されません。 次の手順は必ず新しいウィンドウで行ってください。

手順3：新しい PowerShell を開いて確認する

新しいウィンドウを開きます。まず、冒頭の表示が変わっているはずです。

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

パーソナル プロファイルとシステム プロファイルの読み込みにかかった時間は 702 ミリ秒です。
PS C:\Users\hidek>

(base) が消え、読み込み時間が 1174 ミリ秒から 702 ミリ秒になりました。

設定が入ったことを確認します。

conda config --show auto_activate

--show 項目名 は「この項目の今の値を見せて」です。auto_activate: False と出れば成功です。

次に、python と pip がどこを指しているかを確認します。

where.exe python
where.exe pip

where.exe は「この名前のプログラムが PATH 上のどこにあるか」を全部並べてくれるコマンドです。where ではなく where.exe と打つのは、PowerShell には同名の別命令（Where-Object の省略形）があり、where だけだとそちらが動いてしまうからです。

私の環境ではこう出ました。

PS C:\Users\hidek> where.exe python
情報: 与えられたパターンのファイルが見つかりませんでした。

「見つからない」が正解です。 これが「グローバルに python がいない」という状態です。python.org 版だけを返す場合も成功です。

もし anaconda3 配下のパスが出てくるなら、ユーザー環境変数 Path に anaconda3 のパスが直接書かれています。その場合は削除してください。conda の初期化処理が面倒を見るので、PATH に直接書く必要はありません。

手順4：PATH を目で確認する

環境変数は、ユーザー用とシステム用（Machine）の2つに分かれています。それぞれを1行ずつ表示します。

[Environment]::GetEnvironmentVariable("Path","User") -split ';'

[Environment]::GetEnvironmentVariable("Path","Machine") -split ';'

[Environment]::GetEnvironmentVariable("Path","User") は「ユーザー用の Path の中身をそのまま取り出して」という命令です。Path は ;（セミコロン）でつながった1本の長い文字列なので、-split ';' で ; のところで切って、1行に1フォルダで表示させています。

ユーザー側に ① の4つだけが残る形が理想です。Python や Anaconda のパスがここに書かれていたら、それが「層が混ざっている」箇所です。

手順5：Python 本体が汚れていないか数える

ここで「グローバルは空」を本当に確かめます。python.org 版の Python 本体に、余計な部品が入っていないかを見ます。

Write-Host "=== 3.13 ==="; py -3.13 -m pip list; Write-Host "=== 3.10 ==="; py -3.10 -m pip list

長く見えますが、; で区切った4つの命令を順番に実行しているだけです。Write-Host は画面に見出しを出す命令、py -3.13 -m pip list は「py ランチャーで 3.13 を起動し、その Python に付属の pip で、入っている部品を一覧して」という意味です。

-m pip と書くのは、「この Python に付属している pip」を確実に呼ぶためです。pip とだけ打つと、PATH 上の別の pip が動くことがあります。どの Python の pip を動かしているかを、いつも py -3.x -m pip で指名するのが、この記事全体の考え方です。

私の環境の結果です。

=== 3.13 ===
Package Version
------- -------
pip     26.2.1
=== 3.10 ===
Package    Version
---------- -------
pip        23.0.1
PyYAML     6.0.3
setuptools 65.5.0

[notice] A new release of pip is available: 23.0.1 -> 26.2.1
[notice] To update, run: C:\Users\hidek\AppData\Local\Python\pythoncore-3.10-64\python.exe -m pip install --upgrade pip

判定はこうです。

Python	状態
3.13	きれい。pip のみ
3.10	ほぼきれい。PyYAML が1つだけ余分

setuptools は 3.10 時代の標準同梱品なので汚れではありません。汚れは PyYAML の1件だけでした。過去に venv の外で pip install pyyaml を打った痕跡です。複数のPython（5系統）が重なって入っていた割に、この程度で済んでいたのは運が良い方です。

[notice] の2行は pip 自身の更新案内です。venv を作れば新しい pip が入るので、本体側の pip は放置で構いません。

PyYAML を消す

消しても消さなくても実害はほぼありません。python が PATH から消えたため、この 3.10 を使う経路は py -3.10 と自分で打つ場合だけになったからです。

ただ「グローバルは空」という状態を作っておくと、次に何か入っていたときに「いつ・何が汚したか」がすぐ分かります。消しておくことを勧めます。

py -3.10 -m pip uninstall -y PyYAML

uninstall は取り除く命令、-y は「本当に消しますか？」の確認に自動で「はい」と答える指定です。

Found existing installation: PyYAML 6.0.3
Uninstalling PyYAML-6.0.3:
  Successfully uninstalled PyYAML-6.0.3

もし py -3.10 で直接動かしている、YAML を読むスクリプトがあれば、それは動かなくなります。心当たりがなければ実行して問題ありません。

VSCode 側は何もしなくてよい

VSCode の Python 拡張は、作業フォルダ直下の .venv を自動で見つけます。手動で指定するなら、Ctrl+Shift+P → Python: Select Interpreter → .\.venv\Scripts\python.exe です。

claude コマンドは、VSCode が OS の PATH をそのまま引き継ぐので、① の層に入っていれば統合ターミナルから動きます。Claude Code をローカルLLMにつないで使う話は、ローカルLLMでコーディング環境を確立するに書いています。

環境変数を変更した後は、VSCode を完全に終了して再起動しないと反映されません。 ウィンドウの再読み込みでは不十分です。

やってはいけないこと

$PROFILE（PowerShell が起動時に読む設定ファイル）の中身は、次のコマンドで開けます。

notepad $PROFILE

この中に #region conda initialize から #endregion までのブロックがあります。これが conda の初期化処理で、起動時間の大半を占めている部分です。

このブロックを手で消さないでください。 消すと conda のシェル統合ごと無効になり、conda activate が使えなくなります。設定コマンドで切るのが正解です。

もう1つ。自動有効化を切ったあと、環境を有効化せずに python を打つと、Windows の場合は Microsoft Store 版 Python やインストーラ版 Python が起動することがあります。意図した環境かどうか、where.exe python で確認する癖をつけると事故が減ります。

整理後の最終状態

確認項目	結果
`(base)` の自動起動	停止
venv 外の `python` / `pip`	見つからない
Python 本体の汚れ	なし
`py -3.13` / `py -3.10`	動く
`claude` / `conda` / `uv`	動く

以後、グローバルが汚れる経路は「py -3.x -m pip install と自分で明示的に打つ」だけです。これは間違って打てる形ではないので、事故はほぼ起きません。

まとめ

(base) は壊れているのではなく、conda が base 環境を自動で有効化した表示。ただし python と pip の指す先が分からなくなるので、conda config --set auto_activate false で切る
PATH は優先順位ではなく 4つの層 で考える。単体CLI（claude・git・node）はユーザーPATHに常駐、Python 本体は PATH に出さず py ランチャー経由、汚していいのは venv だけ、conda は必要なときだけ conda activate で呼ぶ
where.exe python が「見つからない」と返す状態が正解。プロンプトに (.venv) や (環境名) が出ているときだけ、汚していい場所にいる
$PROFILE の conda ブロックは手で消さない。Python 本体の汚れは py -3.x -m pip list で数えて、py -3.x -m pip uninstall で消す