Python 11：pip と PyPI：ライブラリはどこから来るのか

一言でいうと：公開の倉庫から、zip の箱を取り寄せて棚に並べる

先に全体をたとえ話で押さえます。通販を思い浮かべてください。

pip は、PyPI という倉庫に「requests をください」と注文し、届いた wheel という箱を開けて、中身を site-packages という棚に並べます。棚に並んだものは、第8章の仕組みで import がいつでも取りに行けます。sys.path の中に、最初から site-packages が入っているからです。

JavaScript の言葉に置き換えると、PyPI は npm レジストリ（npmjs.com）、pip は npm コマンド、site-packages は node_modules に当たります。ただし site-packages と node_modules には大きな違いがあり、それは後で説明します。

登場人物：あなたのパソコンと、インターネットの向こう

これから何度も使う舞台を紹介します。

1つ意外なことを言うと、pip 自身も、site-packages に入っているパッケージの1つです。作りたての環境の site-packages を開くと、pip/ と pip-25.3.dist-info/ だけが入っています。python3 -m pip と打つと、第2章で見た -m の働きで、「この python3 の site-packages にある pip というパッケージ」を実行しています。

PyPI の一覧と、ファイル本体の置き場が別の住所になっているのも覚えておいてください。一覧は pypi.org、ファイルは files.pythonhosted.org から届きます。

① PyPI に問い合わせる：「requests のファイル一覧をください」

最初の段階です。pip は、次の URL を読みに行きます。

https://pypi.org/simple/requests/

これは PyPI の Simple API（シンプル API）と呼ばれる窓口で、パッケージの名前ごとに1ページあります。ブラウザで開いてみると、真っ白な画面にファイル名のリンクがずらりと並んでいるのが見えます。実際に返ってくる情報を、1ファイル分だけ抜き出すとこうなります。

requests なら、2011年ごろの古い版から最新の 2.34.2 まで、すべての版のファイルがこの一覧に載っています。この時点では、まだ何もダウンロードしていません。「何があるか」を知っただけです。

npm も同じように、まずレジストリ（registry.npmjs.org）にパッケージの情報を問い合わせます。倉庫の名前が違うだけで、最初の一歩は同じです。

② 版を選ぶ：条件に合う、いちばん新しいもの

一覧を受け取った pip は、どのファイルを使うかを決めます。決め方は2段です。

版の条件は、pip install "requests>=2.30,<3" のように自分で付けることもできます（書き方は第13章）。また、すでに入っていて条件を満たしているなら、pip は何もしません。上げたいときは --upgrade を付けます。

ファイルの種類は2つあります。

「この Python・この OS で使えるか」は、wheel のファイル名に書かれたタグで判断します。requests の py3-none-any は「Python 3 ならどれでも、どの OS でも」という意味なので、誰のパソコンでも選ばれます。C 言語で書かれた部品を含むライブラリ（numpy や pillow など）は、OS や Python の版ごとに別々の wheel が用意されていて、pip は自分に合うものを選びます。

③ 依存を調べる：METADATA だけ先に取り寄せる

第10章で、requests は urllib3 などの別のライブラリを使っていることを見ました。requests だけを入れても、動きません。そこで pip は、requests が何を必要としているかを調べます。

調べるのに、73KB の wheel 全体を取り寄せる必要はありません。PyPI は、wheel の中の METADATA というファイルだけを、別に取り寄せられるようにしています（4.8KB）。実際の pip の出力にも Downloading requests-2.34.2-py3-none-any.whl.metadata (4.8 kB) という行が出ます。

METADATA の中の、依存を書いた行はこうです。

Requires-Dist: charset_normalizer<4,>=2
Requires-Dist: idna<4,>=2.5
Requires-Dist: urllib3<3,>=1.26
Requires-Dist: certifi>=2023.5.7

pip は、この4つについても①②を同じように繰り返します。さらにそれぞれの依存の依存…とたどり、全員の条件を同時に満たす版の組み合わせを決めます。これを依存の解決（resolve）と呼びます。

図では、依存の4つを札で表しました。この札が、あとで棚に並ぶことになります。npm でも、package.json の dependencies をたどって同じことをしています。

④ wheel をダウンロードする：ハッシュで中身を確かめる

入れるものが全部決まったら、いよいよファイル本体を取り寄せます。取り寄せ先は、①の一覧に書かれていた files.pythonhosted.org の URL です。

charset_normalizer だけ名前が長いのは、C で速くした部品を含んでいて、Python の版（cp313）と OS ごとに別の wheel があるからです。macOS では macOS 用の wheel が選ばれます。

届いたファイルは、①の一覧に載っていた sha256 ハッシュと照合されます。1バイトでも違えば、pip はそのファイルを使わずに止まります。途中で壊れたファイルを棚に並べないための仕組みです。

一度取り寄せたファイルは、pip のキャッシュにも保存されます。macOS なら ~/Library/Caches/pip、Linux なら ~/.cache/pip です（python3 -m pip cache dir で確かめられます）。2回目からは出力が Using cached ... になり、通信せずに済みます。

wheel の正体は zip：中身を開いて確かめる

届いた .whl とは何なのか、実際に開いてみます。Python の仕様（packaging.python.org の Binary distribution format）には、wheel は「特別な形式のファイル名と `.whl` 拡張子を持つ ZIP 形式のアーカイブ」と書かれています。本当かどうか、標準ライブラリの zipfile で中身を一覧してみます。

$ python3 -m zipfile -l requests-2.34.2-py3-none-any.whl
File Name                                   Modified             Size
requests/__init__.py                        2026-05-14 19:21:52  5922
requests/api.py                             2026-05-14 19:21:52  7152
requests/sessions.py                        2026-05-14 19:21:52 34248
...
requests-2.34.2.dist-info/METADATA          2026-05-14 19:21:52  4806
requests-2.34.2.dist-info/WHEEL             2026-05-14 19:21:52    91
requests-2.34.2.dist-info/RECORD            2026-05-14 19:21:52  2027

zip として普通に開けました。file コマンドで調べても Zip archive data と出ます。中身は、第10章で見た `requests/` フォルダそのものと、requests-2.34.2.dist-info/ という控えのフォルダの2つです。つまり wheel は、「site-packages にそのまま置ける形に並べたフォルダを、zip で固めたもの」です。

ファイル名は、仕様で {配布名}-{版}-{Python タグ}-{ABI タグ}-{プラットフォームタグ}.whl と決まっています。図の表のとおり、requests の py3-none-any は「Python 3 用・C の部品なし・どの OS でも」です。npm の .tgz（tar を gzip で固めたもの）と、立場はほぼ同じです。

⑤ site-packages に展開する：依存から順に棚へ

いよいよ棚に並べます。wheel の仕様では、インストールの手順を「展開（Unpack）」と「配置（Spread）」と呼んでいます。やっていることは、次のとおりです。

並べる順番は、依存が先です。pip の出力にも Installing collected packages: urllib3, idna, charset_normalizer, certifi, requests と、requests が最後に書かれています。requests が棚に並んだ瞬間に、requests が使う urllib3 がまだ無い、ということが起きないようにするためです。

図では、③で出てきた依存の札が、そのまま棚に入りました。棚には requests/ と、その隣に requests-2.34.2.dist-info/ も並んでいます。

「インストール」というと、何か複雑な登録作業をしている気がしますが、Python のライブラリのインストールは、ほとんど「zip を開いてフォルダに置く」だけです。だから第10章で見たとおり、site-packages の中はエディタで開けば読める普通のファイルなのです。

⑥ dist-info に記録する：何を入れたかの控え

最後の段階は記録です。棚に並んだ requests-2.34.2.dist-info/ フォルダが、その控えです。中を見てみます。

METADATA・RECORD・WHEEL は wheel の中に最初から入っていて、INSTALLER と REQUESTED はインストールのときに pip が書き足します。RECORD にも、__pycache__/ の .pyc など、インストールで増えたファイルが追記されます。

pip は「何が入っているか」を覚えておくための特別なデータベースを持っていません。*site-packages に並んだ `.dist-info/ フォルダそのものが、入っているものの台帳**です。pip list` はこのフォルダを数えて表にしているだけです。

実際の出力：6つの段階が、そのまま並んでいる

ここまでの6段を頭に入れて、実際の pip install の出力を読んでみます（Python 3.13・pip 25.3 で、キャッシュが無い状態で実行したもの。長い行は一部省略）。

$ python3 -m pip install requests
Collecting requests
  Downloading requests-2.34.2-py3-none-any.whl.metadata (4.8 kB)
Collecting charset_normalizer<4,>=2 (from requests)
  Downloading charset_normalizer-3.5.2-cp313-...whl.metadata (46 kB)
Collecting idna<4,>=2.5 (from requests)
Collecting urllib3<3,>=1.26 (from requests)
Collecting certifi>=2023.5.7 (from requests)
Downloading requests-2.34.2-py3-none-any.whl (73 kB)
Downloading charset_normalizer-3.5.2-cp313-...whl (254 kB)
Downloading idna-3.20-py3-none-any.whl (69 kB)
Downloading urllib3-2.8.0-py3-none-any.whl (135 kB)
Downloading certifi-2026.7.22-py3-none-any.whl (136 kB)
Installing collected packages: urllib3, idna, charset_normalizer, certifi, requests
Successfully installed certifi-2026.7.22 charset_normalizer-3.5.2 idna-3.20 requests-2.34.2 urllib3-2.8.0

出力は呪文ではなく、6つの段階の実況中継だったのです。図の①〜⑥の説明は、この本で書き足したものです。

そして import requests：第8章の仕組みで、棚から見つかる

棚に並んだあとで import requests と書くと、何が起きるか。これは第8章でやったことそのままです。図の小包が、main.py から棚の requests/ にたどり着きます。

>>> import sys
>>> for p in sys.path: print(p)

/Users/you/tenki/.venv/lib/python313.zip
/Users/you/tenki/.venv/lib/python3.13
/Users/you/tenki/.venv/lib/python3.13/lib-dynload
/Users/you/tenki/.venv/lib/python3.13/site-packages

（先頭の空行は、今いるフォルダを表す空の文字列です。標準ライブラリの3行は、実際には venv ではなく Python 本体の場所を指します。）

site-packages は、Python が起動するときに自動で sys.path に加えられます。だから pip は `sys.path` をいじる必要がなく、決まった棚に置くだけで、import から見えるようになるのです。確かめたいときは、print(requests.__file__) で、読まれたファイルのパスを表示できます。

どの site-packages に入る？：pip を動かしている Python のもの

ここで大事なことがあります。site-packages は、Python ごとに1つずつあります。第2章で見たように、1台のパソコンに複数の Python が同居していることはよくあります。

pip が棚に並べるのは、その pip を動かしている Python の site-packagesです。

pip とだけ打つと、第2章の PATH の順番で最初に見つかった pip というコマンドが動きます。それがどの Python に属しているかは、コマンドを見ても分かりません。その結果、「入れたのに No module named」が起きます。図の右の Python には、requests が入っていないのです。

python3 -m pip と書けば、「今 python3 と打って動く Python の pip」と決まるので、スクリプトを動かす python3 と棚が必ず一致します。この本がずっと python3 -m pip と書いているのはそのためです。入った場所は、python3 -m pip show requests の Location: の行で確かめられます。

npm と比べる：node_modules はプロジェクトに、site-packages は Python に

ここで、npm との一番大きな違いが見えてきます。

npm install axios は、今いるプロジェクトのフォルダの中に node_modules/ を作って入れ、package.json に「axios を使う」と書き足します。プロジェクトごとに別々の棚があるので、アプリAは axios 1.6、アプリBは axios 1.7、ということが自然にできます。

pip install requests は、プロジェクトのフォルダには何も作りません。その Python の棚に入れるだけで、「このプロジェクトは requests を使う」という記録もどこにも残りません。つまり、既定のままでは、同じ Python を使う全部のプロジェクトが1つの棚を共有しています。

これが困る場面と、その解決策（プロジェクトごとに棚を分ける仮想環境）が次の第12章です。記録を残す話（requirements.txt や pyproject.toml）は第13章で扱います。

入れる名前と、import する名前は違うことがある

pip に渡す名前は、PyPI 上の配布名（第10章の「配布パッケージ」の名前）です。一方、import に書くのは、棚に置かれたフォルダの名前です。この2つは、たいてい同じですが、違うこともあります。

実際に pillow の wheel を開くと、中に入っているのは PIL/ というフォルダと pillow-12.3.0.dist-info/ です。棚に置かれるのが PIL/ なので、import PIL と書きます。pillow は、昔の PIL というライブラリを引き継いだものなので、import 名が昔のまま残っているのです。

逆向きの間違いにも注意が要ります。pip install sklearn と打つと、PyPI にある sklearn という別物が見つかります。これは「scikit-learn を使ってください」と知らせるためだけに置かれたもので、今は入れようとするとエラーになります。import 名は、dist-info の top_level.txt にも書いてあります。

棚を見る・調べる・片付ける：pip list / show / uninstall

棚の中身を扱う3つのコマンドを覚えておきましょう。どれも、⑥で見た dist-info を読んだり使ったりしているだけです。

pip show の Location: は、棚の場所そのものです。Requires: は requests が使うもの、Required-by: は requests を使っているもの（ここでは空）です。

pip uninstall requests は、requests の RECORD に書かれたファイルだけを消します。依存として一緒に入った urllib3 などは、残ります。 npm の npm uninstall が不要になった依存も片付けるのとは違います。「何を自分で入れて、何が依存で入ったのか」を分けて管理したくなりますが、それも第12・13章の仮想環境と依存の記録で解決します。

import transformers ①：ライブラリ本体は、PyPI から site-packages へ

依頼者の最初の疑問に戻ります。「import transformers と書いて、なんでライブラリが入るの？ どこから？ ローカルに保存されてる？」

答えから言うと、`import transformers` と書いただけでは、何も入りません。先に pip install transformers で入れておく必要があり、そのとき起きることは requests とまったく同じ①〜⑥です。舞台を少し変えて、インターネットの側に Hugging Face Hub、パソコンの側に Hugging Face のキャッシュのフォルダを足しました。

ここで大事なのは、この wheel の中にはモデルの重み（学習済みの数値のファイル）が1つも入っていないことです。実際に開いて .safetensors や .bin を探しても、見つかりません。入っているのは、モデルを読み込み、動かすための Python のコードだけです。

また、計算の本体である PyTorch は、transformers の必須の依存には入っていません。pip install "transformers[torch]" のように、角かっこで「追加の組（extra）」を指定すると一緒に入ります。

import transformers ②：重みは、初めて使った瞬間に Hub からキャッシュへ

では、重みはいつ、どこから来るのでしょうか。次のようなコードを初めて動かしたときです。

from transformers import pipeline

clf = pipeline("sentiment-analysis",
               model="distilbert/distilbert-base-uncased-finetuned-sst-2-english")
print(clf("I love this weather!"))

import transformers（や from transformers import pipeline）の時点では、まだ通信は起きません。モデルの名前を渡して読み込もうとした瞬間に、transformers は依存の huggingface_hub を使って、Hugging Face Hub（huggingface.co）からモデルのファイルを取り寄せます。PyPI とは別の、モデル専用の倉庫です。

2回目からは、このキャッシュから読むので通信しません。キャッシュの場所は、環境変数 HF_HOME（~/.cache/huggingface の部分）や HF_HUB_CACHE（hub の部分まで）で変えられます。大きなモデルを外付けのディスクに置きたいときに使います。

つまり「ローカルに保存されてる？」の答えは「はい。ただし2か所に、別々に」です。

2つの道を並べる：コードは pip、重みは Hub

transformers を使うときの2つの道を、表に並べます。

キャッシュの中は、図の下のような作りになっています。blobs/ にファイル本体がハッシュの名前で入り、snapshots/<コミットID>/config.json は blobs/ の本体を指す参照（シンボリックリンク）です。refs/main には、今の最新のコミットID が書かれています。Hub のモデルは Git と同じように版（コミット）を持っているので、版ごとに snapshots/ の下のフォルダが分かれます。

この区別は、第12章の仮想環境で効いてきます。仮想環境を消して作り直すと、コードは消えますが、重みのキャッシュは残ります。キャッシュはホームフォルダにあって、どの仮想環境からも共有されるからです。何GBもの重みを、プロジェクトごとに落とし直さずに済むのはこのためです。

よくある間違い：入れたのに見つからない

pip まわりのつまずきは、ほとんどが「pip を動かした Python と、スクリプトを動かした Python が違う」ことから来ます。

2つ目の externally-managed-environment は、2023年ごろから macOS の Homebrew の Python や、Linux の多くのディストリビューションで出るようになったエラーです。Python の仕様（externally managed environments）で、「OS やパッケージ管理ツールが管理している Python の棚に、pip が勝手に書き込んで壊さないようにする」ための仕組みです。--break-system-packages で無理に通す方法もありますが、名前のとおり壊す可能性があるので、使わないでください。

迷ったら、次の2つを見比べます。python3 -c "import sys; print(sys.executable)" で今動いている Python の場所、python3 -m pip show requests の Location: で棚の場所です。