Andersonの視点
PythonパッケージのインストールはローカルAIの採用を示す指標である

見つける場所さえ分かれば、把握しにくいPythonパッケージのダウンロード増加がAI普及の物語を明らかにします。
オピニオン ローカルAIの可能性を探ったことがある人なら、関連する巨大なモデルだけでなく、推論、学習、数百もの用途を統括するPythonなどのシステムにも、恐ろしいほどのディスク容量を奪われているはずです。ローカル自動化システムの生成も、その重要な用途の一つです。
この最後の用途は、私のLAN上の各種マシンで最も一般的です。AIを使って、バックアップ、定期点検、ウェブサイト管理など十数種類の「フラットな」Pythonベース自動処理を構築してきました。
こうしたコーディング作業で実現したいことは、ほとんどすべて新しいPythonライブラリを必要とするように思えます。そのためPIP、つまりPython用パッケージインストーラーは、私のLAN内のマシンで最も多くの容量を消費する存在の一つです。

CLIやGUIでは小さく見えるPIPですが、ファイルシステムへの影響は甚大です。キャッシュは非常に大きくなり、システムを機能不全に陥らせる容量に達することもあります。
ローカルAIを試すと、現在のAIハードウェア争奪以前には余りがちだったローカルコンピューターのぜいたくな余剰資源が一転して不足します。豊富なRAMはGPUオフロードに食われ、1テラバイトのディスク容量も量子化の有無にかかわらず巨大なモデルですぐ埋まります。私のように24GBのVRAMという新たな最低水準らしき環境を用意しても、現実的な時間で推論を動かすには各種の近道や工夫が必要です。
インストールしたPyPI(Python Package Index)パッケージは一般的なOSの標準「インストール済みプログラム」画面には表示されません。Pythonから明示的に取り出す必要があり、PowerShellなら例えば pip freeze --all を使います。
一覧は驚くほど長くなることがあります。
| パッケージ | バージョン | パッケージ | バージョン | パッケージ | バージョン |
|---|---|---|---|---|---|
| absl-py | 2.3.0 | Jinja2 | 3.1.4 | pip | 25.1.1 |
| attrs | 25.3.0 | jsonpatch | 1.33 | platformdirs | 4.3.8 |
| beets | 2.5.1 | jsonpointer | 3.0.0 | protobuf | 4.25.8 |
| certifi | 2025.11.12 | kiwisolver | 1.4.8 | psutil | 7.2.1 |
| cffi | 1.17.1 | lap | 0.5.12 | pybrisque | 1.0 |
| charset-normalizer | 3.4.4 | lazy_loader | 0.4 | pycparser | 2.22 |
| click | 8.2.1 | libsvm | 3.23.0.4 | pyparsing | 3.2.3 |
| colorama | 0.4.6 | Markdown | 3.8.2 | python-dateutil | 2.9.0.post0 |
| confuse | 2.1.0 | MarkupSafe | 2.1.5 | PyYAML | 6.0.2 |
| contourpy | 1.3.2 | matplotlib | 3.10.3 | pyyaml_env_tag | 1.1 |
| cycler | 0.12.1 | mediafile | 0.13.0 | requests | 2.32.5 |
| dlib | 20.0.0 | mediapipe | 0.10.21 | scikit-image | 0.25.2 |
| face-recognition | 1.3.0 | mergedeep | 1.3.4 | scipy | 1.16.0 |
| face_recognition_models | 0.3.0 | mkdocs | 1.6.1 | sentencepiece | 0.2.0 |
| filelock | 3.13.1 | mkdocs-get-deps | 0.2.0 | setuptools | 65.5.0 |
| filetype | 1.2.0 | ml_dtypes | 0.5.1 | six | 1.17.0 |
| flatbuffers | 25.2.10 | mpmath | 1.3.0 | sounddevice | 0.5.2 |
| fonttools | 4.58.4 | musicbrainzngs | 0.7.1 | sympy | 1.13.1 |
| fsspec | 2024.6.1 | mutagen | 1.47.0 | tifffile | 2025.6.11 |
| ghp-import | 2.1.0 | networkx | 3.3 | torch | 2.5.1+cu118 |
| idna | 3.11 | numpy | 2.1.2 | torchvision | 0.20.1+cu118 |
| image-quality | 1.2.7 | opencv-contrib-python | 4.11.0.86 | tqdm | 4.67.1 |
| imageio | 2.37.0 | opencv-python | 4.11.0.86 | typing_extensions | 4.12.2 |
| internetarchive | 5.7.1 | opt_einsum | 3.4.0 | Unidecode | 1.4.0 |
| jax | 0.6.2 | packaging | 25.0 | urllib3 | 2.6.2 |
| jaxlib | 0.6.2 | pathspec | 0.12.1 | watchdog | 6.0.0 |
| jellyfish | 1.2.1 | pillow | 11.0.0 |
よく使うマシンの一台にインストールされたPyPIパッケージの一覧です。小さな単語の裏に数ギガバイトものディスク使用量が隠れているものがあり、特にTorch/PyTorch関連が顕著です。
つまりローカルAIは、Wordのようなプログラムを数KBのRAMへ大きなフロッピーディスク一枚ずつから読み込んでいた時代を少し過ぎ、ハードディスク容量にもまだ余裕がなかった1990年代初頭のコンピューティング体験へと私たちを連れ戻し得ます。
底流を探る
ここ数年のPyPIインストール急増が、ローカルAI導入の指標になり得るかに興味を持ちました。ローカルAIの普及は通常、各種AIコミュニティに参加し、どのプラットフォームやパッケージが注目を集めているかを直感的に観察する以外には追跡しにくいからです。
PyPI Statsのウェブサイトをざっと見ると、残念ながら表示期間は非常に短いものの、その範囲ではダウンロード数が一貫して増えています。

表示できる期間は非常に短いものの、2026年初頭以降、全Pythonパッケージのダウンロード数は増加しています。 出典
期間を2020年まで広げ、増加が一定だったのか、それとも予想されるように2024~2026年に急加速したのか確認できれば理想的です。とりわけ、エージェンティックAIシステムが監督なしで実行する処理だけでも増加要因になった可能性があります。
残念ながらPyPIの公式資料は、CDNキャッシュの負荷、キャッシュやミラーによる不正確なダウンロード数、非公式な水増し、過去データの品質問題などを理由に、PyPIのダウンロード統計を公開していないと説明しています。またPythonのサイトによれば、パッケージ品質の指標としての有用性も限られます。
そう簡単ではない
ただしPyPIは、他者がダウンロード傾向を分析するのに必要な構成要素を提供しています。そのためPepySiteなど、1か月を超える期間を表示できるサイトが複数あります。しかし多くはサブスクリプション制で、長期傾向や統計を見るには料金が必要です。あるサービスの「VC」プランは月額490ドルにもなります。
では、裕福な利用者向けに傾向を整然と示す高価なAPIを使わず、AI加速の指標としてPythonから何か読み取れるでしょうか。
PyPIStatsはFOSSのリソースですが、なぜか直近1か月の統計だけを提供しており、料金を払っても期間を延長できません。
幸い、より寛大なサイトがあります。ClickPyでは個々のパッケージの採用履歴を調べられます。ただし全パッケージをまとめた概観はなく、広範で連動した傾向を簡単には把握できません。例えばTransformersライブラリは2016年からの推移を表示できますが、実際に有効なのは2019年の公開以降です。

Transformersの急速な普及。 出典
2002年に初めて公開された由緒あるTorchはどうでしょうか。PyTorchへ発展し、TransformerベースのVLMや画像・動画向け生成AIが台頭するまでは、自作AIを楽しむ人々を悩ませる運命にはありませんでした。

2017年以降のTorchダウンロード数。直近2~3年で急激に増えています。

同じ期間のPyTorch。安定した基盤の上で横ばいになったり、急増したりしています。
特にPyTorchでは、2017年以降の採用状況を複数のPythonバージョン別に見ると、さらに興味深い全体像が得られます。

2017年以降のPythonバージョン別PyTorchダウンロード数。第三次AI革命が本格化して以降の普及を、もう一つの軸から確認できます。
上の統計が本格的に有能なLLMとVLMの登場後の採用急増を示しているなら、OS別に見るとその傾向はいっそう明確です。

OS別に見た2017年以降のPyTorch採用。
accelerateパッケージでも同じ傾向が見られます。これはVRAM不足に悩むAI利用者がシステムの限界から最大限の性能を引き出すため、最も頻繁に必要とするライブラリの一つです。

OS別に見たaccelerateの普及。
ClickPyで調べるどのパッケージやライブラリにも同様の物語があり、断片を一つずつ調べる代わりに全体像を作れれば確かに興味深いでしょう。
「OS別」グラフから明らかになることの一つはLinux採用の増加です。Linuxデスクトップの採用率は、着実ながら緩やかに上昇し、不評なWindows戦略もその追い風になっています。一方、Linuxの環境利用は明らかに大幅に増えています。
例えば私はWindows上のWSL2でUbuntuを仮想化し、各種Dockerコンテナを動かしています。Dockerは開発者が想定した条件どおりの本物のLinuxシステムを利用できます。ベアメタルの観点では完全なWindows LANなのに、二つのLinuxシステムが稼働し、ゆっくり過ごせる時に備えてネイティブLinuxノートPCも電源を抜いて待機しています。
結論
CLI経由のパッケージダウンロードに関して、AI登場後にこの非常にマニアックな領域がどれほど熱心に追求されるようになったかは注目に値します。
パッケージ消費の増加は、スロップスクワッティングの登場によって下流のセキュリティリスクになり始めています。LLMはパッケージ名を幻覚しやすく、実在しないパッケージへの要求を実際に送る可能性があります。同じような推論に収束するため、偽のパッケージ名が別のライブラリ呼び出しでも繰り返される見込みがあり、悪意ある者が将来の取得や呼び出しに備えて偽パッケージを実際に公開し、悪意あるペイロードを仕込む価値が生まれます。

論文『We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs』より。AIによるコード生成はサプライチェーン攻撃面を広げます。LLMは存在しないパッケージ名を頻繁に幻覚し、自動パイプラインが未検証の依存関係を無条件に取得すると、攻撃者が悪用できるスロップスクワッティング脆弱性が生まれます。 出典
2026年7月24日金曜日に初出。












