この件に関して、当社には実質的に何の利害関係もありません。当社は Geonode であり、プロキシを販売していますが、これは Python ライブラリのインストールとは一切関係がありません。 両者が重なる点が1つだけあり、それについては一言触れておく価値があります。企業環境で pip install が応答しなくなる場合、それは通常、ネットワークで必要とされるプロキシであり、pip はその存在を認識していません。その対処法は、pip install --proxy または標準的な環境変数の設定です。このケースについては最後に説明します。それ以外のすべてについては、インフラも購入も一切必要ありません。
簡単な答え
python -m venv sklearn-env
source sklearn-env/bin/activate # Windows: sklearn-env\Scripts\activate
pip install -U scikit-learn
または conda を使用する場合:
conda create -n sklearn-env -c conda-forge scikit-learn
conda activate sklearn-env
公式ドキュメント には両方の方法が記載されており、環境については次のように強調されています。「仮想環境はオプションですが、他のパッケージとの潜在的な競合を避けるために強く推奨されます」。
さらに、多くの人が見落としがちな注意点として次のように付け加えられています。「新しいターミナルセッションを開始する際は、Pythonコマンドを実行する前に、必ず選択した環境をアクティブ化することを忘れないでください。」「昨日は動いていたのに」という報告の多くは、環境がアクティブ化されていない新しいターミナルが原因です。
「pip install sklearn」が失敗する理由
この分野で最もよく寄せられる質問ですが、その答えは「意図的な設計」にあります。
sklearn は import 名です。scikit-learn は パッケージ 名です。前者を pip に入力すると、ユーザーを阻止することだけを目的としたプレースホルダーがインストールされてしまいます。
PyPI上のそのプレースホルダー自体の説明は明確です。「非推奨のsklearnパッケージ。代わりにscikit-learnを使用してください」とあり、「pip install sklearnの代わりにpip install scikit-learnを使用してください」および「pipの要件ファイル内でsklearnをscikit-learnに置き換えてください」というガイダンスが示されています。
これが存在する理由はサプライチェーン上の問題によるものであり、そのドキュメントには次のように明記されています:
PyPI上の
sklearnパッケージは、悪意のある者がsklearnパッケージを使用することを防ぐために存在します。これは、sklearn(インポート名)とscikit-learn(プロジェクト名)が、時折混同されて使用されることがあるためです。
つまり、メンテナーたちは、他者が使用できないように、混同されやすいこの名前を先に確保したのです。これほど多くの人が誤って入力してしまうことを考えれば、それは賢明な判断でした。
このパッケージのドキュメントには、遭遇した際に知っておくべき3つのエッジケースが記載されています:
- 「
pip install sklearn==1.1.3とすると、バージョン 1.1.3 が存在しないと表示され、混乱を招く」 — プレースホルダーには、それ自身のバージョン番号しか含まれていません。 - 「
pip uninstall sklearnと実行しても、実際にはscikit-learnはアンインストールされません。その後でもimport sklearnを実行できます」。 pip listに両方が存在するのは混乱を招きますが、誤って両方をインストールしてしまった場合にはよくあることです。
回避策として、SKLEARN_ALLOW_DEPRECATED_SKLEARN_PACKAGE_INSTALL=Trueを設定する方法がありますが、これは「最後の手段」と説明されています。もしこの手段に頼らざるを得ない状況になった場合、真の解決策は、ほぼ例外なく、依存パッケージの要件に sklearn を明記することです。placeholder 自身のアドバイスに従う価値があります。「どのパッケージが scikit-learn ではなく sklearn を使用しているかを追跡し、そのパッケージのイシュートラッカーに報告してください」。
自身のファイルでは、常に scikit-learn と記述してください。 コード内では、常に import sklearn と記述してください。この非対称性は恒久的なものです。
要件
2026年9月に確認した、現在のリリースのパッケージメタデータに基づく。
scikit-learn 1.9.0 は2026年6月2日に公開され、Python 3.11以降 が必要です。
その実行時依存関係は以下の通りです:
| 依存関係 | 最小バージョン |
|---|---|
| NumPy | 1.24.1 |
| SciPy | 1.10.0 |
| joblib | 1.4.0 |
| threadpoolctl | 3.5.0 |
| narwhals | 2.0.1 |
この表について2点注意があります。
narwhalsは比較的最近追加されたもので、古いドキュメントや以前のリリースを対象に書かれたチュートリアルには記載されていません。pipに依存関係の解決を任せるのではなく、手動で依存関係を固定している場合、この依存関係を見落としやすいでしょう。
Pythonの最低要件は変動します。 インストールページの依存関係表は、そのページで説明されているリリース版を反映しており、要件は最近のバージョンで引き上げられています。古いバージョンのPythonを使用している場合、pipはエラーを出すのではなく、古いバージョンのscikit-learnをインストールします。これは通常問題ありませんが、時折、文献で目にする機能の欠落の理由となっていることもあります。
ベンチマーク、ドキュメント、サンプル、テスト用に、matplotlib、pandas、polars、pyarrow などがオプションとして宣言されています。ライブラリを使用するために、これらはいずれも必要ありません。
仮想環境を使用しないインストール
場合によっては、システム全体へのインストールを本当に希望することもありますが、その際には警告が表示されます。
ドキュメントでは、特にLinuxについて次のように明言しています。「特にLinuxでは、ディストリビューションのパッケージマネージャー(apt、dnf、pacmanなど)によって管理されるパッケージと並行してpipパッケージをインストールすることは推奨されません。」
その理由は、pipとディストリビューションのパッケージ管理ツールの両方が、システム上のPythonのsite-packagesディレクトリ内のファイルを「自分たちのもの」だと認識しており、両者の認識が食い違うと、原因を特定するのが困難なほど奇妙な挙動を示すPython環境になってしまうからです。 最近のディストリビューションでは、pipは「externally managed environment」エラーを返してインストールを完全に拒否します。これは、まさにこのような事態を防ぐためのパッケージングエコシステムの仕組みによるものです。
このエラーが発生した場合、優先順位の高い順に以下の選択肢があります:仮想環境を使用する、コマンドラインツールには pipx を使用する、ディストリビューション独自の python3-sklearn パッケージがある場合はそれを使用する、あるいは(自分が何をしているかを理解している場合に限り)--break-system-packages フラグで上書きする(このフラグ名は、ユーザーにこの操作を控えるよう促すために付けられています)。
macOS や Windows ではその必要性はそれほど高くないですが、アドバイス自体は変わりません。プロジェクトごとに仮想環境を設定するのにかかる時間は 10 秒程度で、それだけで一連の問題を未然に防ぐことができます。
インストールの確認
ドキュメントにはコマンドが記載されており、30秒ほどかけて実行してみる価値は十分にあります。
python -m pip show scikit-learn # version and install location
python -m pip freeze # everything in the environment
python -c "import sklearn; sklearn.show_versions()"
condaを使用する場合は:
conda list scikit-learn
conda list
問題報告の際は、
sklearn.show_versions()
を使用してください。このコマンドを実行すると、scikit-learnのバージョン、Pythonのバージョンとビルド情報、および基盤となる数値計算スタックのバージョンが表示されます。これらはまさに、メンテナンス担当者が真っ先に尋ねてくる情報そのものです。
何か奇妙な動作が見られる場合は、pip show
内のインストール場所を確認する価値があります。もし、自分が現在いると思っている環境とは異なる場所を指している場合、その原因がわかります。import sklearn
を実行すると、パス上で最初に検出されたインストールが優先されますが、それはあなたが今インストールしたものではない可能性があります。
conda 対 pip
どちらも機能します。どちらを選ぶかは、主に両者を混在させて使用する場合に重要になりますが、安易に混在させるべきではありません。
conda を使用すべき場合:すでに conda 環境がある場合、特定のコンパイル済み数値ライブラリが必要な場合、あるいはソースからのビルドが必須となるプラットフォームを使用している場合です。公式の指示通り、チャンネルとしては conda-forge を優先してください。
pip を使用すべき場合:一般的な Python 仮想環境を使用している場合です。これはほとんどのプロジェクトに該当します。 Wheelsは一般的なプラットフォーム向けに公開されているため、コンパイルは不要で、インストールは数秒で完了します。
安易に1つの環境でこれらを混在させないでください。 condaでパッケージをインストールした後、pipで依存関係をアップグレードすると、condaのメタデータが実際の状態を反映しなくなる環境が生まれ、その結果生じる不具合の診断は困難です。 やむを得ない場合は、まずcondaでインストール可能なものはすべてインストールし、condaにないものについてのみpipを使用してください。
現在どの環境にいるかを確認する実用的な方法があります。which pythonがconda環境のディレクトリ内を指している場合は、その環境ではcondaを使用してください。
インストール後のよくあるエラー
インストールが正常に完了した後、ModuleNotFoundError: No module named 'sklearn' というエラーが発生することがあります。ほとんどの場合、環境の設定が間違っていることが原因です。たとえば、異なるターミナルやインタープリターを使用していたり、ノートブックのカーネルが別の場所を指していたりします。 以下のコマンドで確認してください:
import sys; print(sys.executable)
そして、インストール先の環境と比較してください。特にJupyterの場合、カーネルはターミナル環境とは別個に選択されるため、一方にインストールしても他方には影響しません。ノートブック内で%pip install scikit-learnを実行すると、カーネルの環境にインストールされるため、これが確実な解決策となります。
ImportError で、NumPyやバイナリの非互換性が指摘される場合。 通常、コンパイルされたバージョンの不一致が原因であり、多くの場合、NumPyを個別にアップグレードしたことが原因です。両方を同時に再インストールすることで解決します:
pip install --force-reinstall --no-cache-dir numpy scipy scikit-learn
ソースからコンパイルしようとするビルド。 これは、お使いのプラットフォームとPythonのバージョンに一致するwheelが見つからなかったことを意味します。一般的に、wheelが公開される前の非常に新しいPythonリリースや、珍しいアーキテクチャの場合に発生します。 ビルドツールチェーンをセットアップするよりも、数週間待つか、少し古いバージョンのPythonを使用するほうが簡単です。
pip list ディレクトリ内の sklearn と scikit-learn の両方。 これらは、ある時点でプレースホルダーとしてインストールされたものです。これらを削除しても問題ありません:pip uninstall sklearn。ドキュメントにも記載されている通り、これを行っても「実際には scikit-learn はアンインストールされません」。
スレッドやthreadpoolctlに関する警告。 scikit-learnは、基盤となるBLASライブラリのスレッドプールを管理するためにこれを使用しています。OMP_NUM_THREADSを明示的に設定することで、これらの問題のほとんどは解決されます。また、制限のないライブラリはCPU制限に関係なくホストCPUごとに1つのスレッドを気兼ねなく作成してしまうため、コンテナ環境ではとにかくこの設定を行う価値があります。
再現性のためのバージョン固定
インストール自体は一度きりの作業ですが、来月も同じ環境を維持し続けることはより難しい問題であり、必要になる前に設定を済ませておく価値があります。
頭の中で覚えておくのではなく、要件ファイルに明記しましょう。 今日「pip install scikit-learn
」とだけ実行した場合と、6か月後に同じコマンドを実行した場合では、異なるバージョンがインストールされます。また、scikit-learnのAPIはマイナーリリース間で変更されます。推定関数にパラメータが追加されたり、デフォルト値が変更されたり、非推奨期間を経て機能が削除されたりすることもあります:
scikit-learn==1.9.0
numpy==2.3.1
scipy==1.16.0
scikit-learnだけでなく、数値計算スタックも固定してください。 このエコシステムにおける再現性の失敗の多くは、固定されたscikit-learnの下でNumPyやSciPyが変更されたことに起因します。なぜなら、それらの間のコンパイル済みインターフェースは、バージョン指定が示唆するよりも密接に結びついているからです。ツリーの最上位を固定し、残りを流動的にしておくという構成は、最も破綻しやすいものです。
ファイルを手動で記述するのではなく、動作する環境から生成してください:
pip freeze > requirements.txt
これにより、推移的依存関係を含むすべてが捕捉されます。これはアプリケーションにとって望ましいことです。公開するライブラリの場合は、代わりにバージョン範囲を指定し、利用者に解決を任せてください。正確なバージョンを固定するライブラリは、他のものと組み合わせることが不可能になってしまいます。
結果とともにバージョンも記録してください。 モデルの出力はライブラリのバージョンに依存しており、保存されたモデルは任意のバージョン間で移植可能ではありません。異なるリリースで保存された推定器をアンピックルすると、警告が出たり、失敗したり、あるいは黙って異なる動作をしたりする可能性があります。sklearn.show_versions()
の出力を永続化されたモデルの隣に保存しておけば、将来発生する謎を簡単に調べることができます。
また、保存形式としてのピクルス化されたモデルには懐疑的であるべきです。 それらは作成時のバージョンのクラス構造を埋め込んでいるため、アップグレード時に破損します。さらに、読み込み時にコードを実行するため、信頼できないソースからのピクルスは、単なるデータファイルではなく、任意のコード実行となります。 長期的に保存するものは、データ交換用に設計された形式を優先するか、少なくともモデルを再構築できるよう、トレーニング用のコードとデータを保持しておくようにしてください。
企業のプロキシ経由でのインストール
ここで初めて、本稿のテーマが直接関係し、その症状も特徴的になります。
pip install
が応答しなくなり、タイムアウトしてしまう場合(名前解決エラーですぐに失敗するのではなく)、お使いのネットワークでは、pip が認識していないプロキシが要求されている可能性があります。
pip install --proxy http://user:password@proxy.example.com:9000 scikit-learn
あるいは、環境変数を通じて設定することも可能です。これは conda やその他のほとんどのツールにも適用されます:
export https_proxy=http://user:password@proxy.example.com:9000
export http_proxy=http://user:password@proxy.example.com:9000
ここでよく問題となる点が2つあります。
パスワードに含まれる特殊文字はパーセントエンコードする必要があります。 プロキシURLに @
や :
があると、文字列が誤った位置で分割され、正しい認証情報を使用しているにもかかわらず認証に失敗してしまいます。
TLSの傍受により、証明書の検証が失敗します。 企業のプロキシではTLSが頻繁に終了され、その結果、pipは証明書が公的な認証局ではなく組織内の認証局によって発行されたものであるとして、その証明書を拒否してしまいます。正しい対処法は、pipに組織内のCAバンドルを指定することです:
pip config set global.cert /path/to/corporate-ca.pem
直感的に思える解決策として ``--trusted-host pypi.org`
` がありますが、これはそのホストに対する検証を無効にするものです。これを使用する前に、その代償を十分に理解してください。実行可能コードをダウンロードするサーバーに対して提示される証明書を、どのようなものであっても受け入れることを選択することになります。
conda の場合、同等の設定は .condarc
の ``proxy_servers`
および ``ssl_verify
` にあります。
よくある質問
scikit-learn のインストール方法は? 仮想環境内では `
`pip install -U scikit-learn、conda を使用する場合は conda create -n sklearn-env -c conda-forge scikit-learn`` と入力します。ドキュメントでは、他のパッケージとの競合を避けるため、仮想環境の使用を強く推奨しています。
なぜ「pip install sklearn」が失敗するのですか?
「sklearn」はインポート名であり、パッケージ名ではないためです。PyPIには、エラーを発生させてユーザーをリダイレクトすることだけを目的としたプレースホルダーパッケージが存在します。そのメンテナンス担当者は、悪意のある者がこの名前を使ってパッケージを公開することを防ぐために、あえて紛らわしい名前を採用したと述べています。代わりに「scikit-learn」をインストールしてください。
sklearnとscikit-learnの違いは何ですか?
scikit-learnは、pipやcondaで使用されるプロジェクト名およびパッケージ名です。一方、sklearnは、import文で使用する名前です。この不一致は恒久的なものであり、これがプレースホルダーパッケージが存在する理由です。
scikit-learnにはどのPythonバージョンが必要ですか?
2026年6月にリリースされたバージョン1.9.0では、Python 3.11以降が必要です。古いバージョンのscikit-learnは古いPythonをサポートしており、pipは失敗するのではなく互換性のあるバージョンに解決します。これが、記事で読んだ機能が利用できない理由となる場合があります。
インストール後に ModuleNotFoundError が発生するのはなぜですか?
ほとんどの場合、環境が間違っているためです。import sys; print(sys.executable) を確認し、インストール先と比較してください。Jupyter では、カーネルの環境はターミナルの環境とは別になっています。ノートブック内で %pip install scikit-learn を実行して、カーネルにインストールしてください。
pip と conda、どちらを使うべきですか?
通常の仮想環境では pip を使用してください。これはほとんどのプロジェクトに適しており、あらかじめビルドされた wheel ファイルを数秒でインストールできます。すでに conda 環境にいる場合や、特定のコンパイル済み数値ライブラリが必要な場合は conda を使用してください。2つのパッケージマネージャーの環境認識が異なるため、1つの環境で混在させることは避けてください。
使用中の scikit-learn のバージョンを確認するには?
バージョンとインストール場所を確認するには python -m pip show scikit-learn を実行し、Python や数値計算スタックを含む完全なレポートを取得するには python -c "import sklearn; sklearn.show_versions()" を実行してください。問題報告の際には、このレポートを添付してください。
プロキシ経由で scikit-learn をインストールするにはどうすればよいですか?
pip install --proxy http://user:pass@host:port scikit-learn を使用するか、http_proxy および https_proxy を環境変数に設定して、conda やその他のツールもそれらを認識できるようにしてください。パスワード内の特殊文字はパーセントエンコードし、検証を無効にするのではなく、所属組織の CA 証明書を設定してください。
まとめ
インストール自体は1つのコマンドで済みます。このトピックにおける難しさのほぼすべては、scikit-learn自体のコードとは無関係な2つの要因に起因しています。
1つ目は名前です。インストールには scikit-learn、インポートには sklearn を使用しますが、紛らわしい名前の場所にプレースホルダーパッケージが配置されており、ユーザーがそこで立ち止まり、その理由を理解できるようになっています。 このプレースホルダーは、サプライチェーンの健全性を保つための小さな工夫であり、それが引き起こすエラーは本来の役割を果たしているのです。
2つ目は環境の問題です。新しいターミナルでモジュールが消えてしまったり、インストールしたばかりのものをノートブックが見つけられなかったり、無関係なアップグレード後にインポートエラーが発生したりといった、多くの失敗は、すべて「環境」という一つの問題が異なる形で現れているに過ぎません。 プロジェクトごとに仮想環境を用意し、意図的に有効化しておけば、こうした問題のほぼすべてを未然に防ぐことができます。また、print(sys.executable) と入力するだけで、残りの問題を1行で診断できます。
もし pip がエラーではなく応答しなくなった場合は、Python よりも先にネットワーク環境を確認してください。pip が認識していない必須のプロキシがあると、エラーではなくタイムアウトが発生します。これは、自身のインフラについて知る上で、非常に混乱を招く方法です。
