pip install が ARM64 Windows で通るか、主要20パッケージを実際に試した

numpy 2.5.1 も pandas 3.0.5 も scipy 1.18.0 も、ARM64 版 Windows の Python 3.12 でそのまま入る。2026年8月2日に手元で確かめた結果だった（この時点の pip と配布状況にかなり依存する）。

ARM64 機を仕事で使うか迷っている人が一番気にするのが、たぶんこの点だと思う。C 拡張を含む Python パッケージは、対応する wheel が配布されていないとビルドから始まる。Visual Studio のビルドツールを入れて、失敗して、諦める（昔の Windows Python で何度か見た流れ）。あれをもう一度やりたい人は少ないはずだ。

wheel だけを取りに行く

インストールはせず、pip download でプラットフォームを固定して wheel の有無だけを見た。環境を汚さずに済むし、失敗したときも「今の venv が壊れたのではないか」と悩まずに済む。

pip download <パッケージ名> --no-deps --only-binary=:all: `
    --platform win_arm64 --python-version 312 -d .\wh

--only-binary=:all: を付けているので、ソース配布しかない場合はここで落ちる。つまり「落ちた＝ARM64 用のバイナリが無い」と読める（ビルドできるかどうかは、今回は別の話にした）という切り分けになる。

pip は 25.0.1、Python は 3.12.10。どちらも Python312-arm64 配下のネイティブ版だ。

取得できたもの、落ちたもの

実際に試した20本のうち18本が取得できた、という話。

パッケージ	取得したファイル
numpy	numpy-2.5.1-cp312-cp312-win_arm64.whl
pandas	pandas-3.0.5-cp312-cp312-win_arm64.whl
scipy	scipy-1.18.0-cp312-cp312-win_arm64.whl
pillow	pillow-12.3.0-cp312-cp312-win_arm64.whl
lxml	lxml-6.1.1-cp312-cp312-win_arm64.whl
cryptography	cryptography-46.0.3-cp311-abi3-win_arm64.whl
psutil	psutil-7.2.2-cp37-abi3-win_arm64.whl
matplotlib	matplotlib-3.11.1-cp312-cp312-win_arm64.whl
aiohttp	aiohttp-3.14.3-cp312-cp312-win_arm64.whl
duckdb	duckdb-1.5.5-cp312-cp312-win_arm64.whl
orjson	orjson-3.11.9-cp312-cp312-win_arm64.whl
regex	regex-2026.7.19-cp312-cp312-win_arm64.whl

残りは greenlet 3.5.4、cffi 2.1.0、msgpack 1.2.1、ujson 5.13.0、pyyaml 6.0.3。どれも win_arm64 タグ付きで降ってきた。20本のうち18本、割合にすると9割が素通りしている。

落ちたのは2本だった。

ERROR: No matching distribution found for tiktoken

pyarrow も同じ文言で止まった。数秒で諦めてくれるので、長く待たされることはない（orjson のソースビルドで待ったときとは、失敗の質が違う）。

cryptography と psutil の tag が違う

細かい話だが、拾ったファイル名をよく見ると2つだけ形が違う（この差は、最初に表を作ったときには見落としていた）。

cryptography は cp311-abi3、psutil は cp37-abi3 になっている。安定 ABI 向けにビルドされた wheel で、Python 3.11 以降なら1つのファイルで通る作りになっている。Python を 3.13 に上げても、この2つは同じファイルが使い回されるはずだ。

Python のマイナーバージョンを上げたときに何が壊れるかを予測するとき、この tag は一度見てみる価値がある（地味だが、あとで効く）。

polars だけ挙動が読めなかった

polars は取得に成功したのだが、降ってきたのが polars-1.43.2-py3-none-any.whl だった（このファイル名だけでは、どこに実体があるのかすぐには読めない）。

py3-none-any はプラットフォーム非依存を意味する。Rust で書かれたライブラリなのに、なぜバイナリ抜きの wheel が win_arm64 向けに解決されたのか、まだ分かっていない。中身を展開して確認するところまではやっていないので、この点は未確認のまま残しておく。実際に import して動くかは別途試すことにした。

詰まるとしたらどこか

tiktoken が入らないのは、この環境では地味に効いた。トークン数を数える処理を書こうとして、そこで止まってしまった（ARM64 の話をしていると、こういう小さい依存で急に現実に戻される）。一覧では2本の失敗に見えるだけだが、実際にはその2本が自分の作業経路に刺さるかどうかで印象がかなり変わる。表の上では小さな例外に見えても、普段のスクリプトのど真ん中で使っている依存なら、その1本だけで ARM64 環境の使い勝手が急に変わってしまうし、代替実装を探すのか、x64 Python を横に置くのか、そもそも機能を諦めるのかまで一気に考えることになる。

回避策としては、HTTP 経由で数えるか、別実装に置き換えるか、x64 の Python を並行して入れてそちらで動かすか。3つ目は環境が二重になるので避けた。

pyarrow が無いのは、pandas の一部機能と、Parquet を直接読む処理に効く。この点は今のところ回避策を持っていなかった。Parquet を扱う必要が出たら別の手段を探すことになるが、まだその場面に当たっていないので未解決のまま置いてある。

念のため書いておくと、ここで測ったのは「wheel が配布されているか」だけだ。実際にインストールしてあるかは別の話で、手元の環境に入っているのは numpy 2.4.1、pandas 3.0.0rc2、Pillow 12.1.0、lxml 6.0.2、matplotlib 3.10.8 の5本。duckdb と polars と scipy は wheel が取得できることを確認しただけで、導入はしていない。

いつまで有効な情報か

wheel の配布状況は日単位で変わる。2026年8月2日時点の結果として読んでほしい。同じコマンドをコピーして自分の環境で叩けば、その日の答えが2分ほどで出る（逆に言うと、この表を長く保存して安心する用途には向かない）。

pip 自体からは 26.2 が出ているという通知が毎回表示された。バージョンを上げると解決の挙動が変わる可能性があるので、比べるときは pip のバージョンも揃えたほうがいい。2026年6月に一度 pip を上げてから numpy の解決が変わった経験があるので、この点は慎重にしている（同じパッケージ名でも、解決器の動きが変わると話がずれる）。

なお今回試したのは「wheel が存在するか」だけで、「入れて動くか」は別の話になる。18本すべてを import して走らせたわけではない。実際に入っているのは numpy と pandas と Pillow と lxml と matplotlib の5本で、いずれも import して問題は出ていない。残りは未確認のまま置いてある。