ARM64_Lab

Snapdragon X Elite の Windows で、起動中の85本のプロセスのうち何本がネイティブか数えた

この記事の見出し
  1. どうやって数えたか
  2. ネイティブ側に何がいたか
  3. エミュレーション側の14本
  4. py ランチャーだけ x86 だった
  5. 数えてみて分かったこと

Surface Pro 11th Edition を常用し始めたのが2025年5月20日で、そこから1年以上たった。ARM64 版の Windows は「まだエミュレーションだらけ」と言われがちだ。手元の環境が実際どうなのか、感覚ではなく数えてみた。

結論から書く。2026年8月2日の時点で、起動中の85本のうち 71本が ARM64 ネイティブだった。x64 エミュレーションが11本、x86 エミュレーションが3本。割合にすると83.5%がネイティブで動いている。

測定に使ったのは Snapdragon X Elite X1E80100 を積んだ 32GB モデル。OS は Windows 11 Pro 10.0.26200 の ARM64 版だ。

どうやって数えたか

タスクマネージャーの「アーキテクチャ」列は使っていない。実行ファイルの PE ヘッダーを直接読んで判定した。

PE ヘッダーの位置は、ファイル先頭から 0x3C バイト目に書かれた値でわかる。そこから4バイト進んだところに Machine フィールドが2バイト入っていて、この値でアーキが決まる。対応表は次のとおり。

0xAA64 -> ARM64
0x8664 -> x64(エミュレーション実行)
0x014C -> x86(エミュレーション実行)

PowerShell から BinaryReader で読んだ。

$fs = [System.IO.File]::OpenRead($path)
$br = New-Object System.IO.BinaryReader($fs)
$fs.Seek(0x3C,'Begin') | Out-Null
$pe = $br.ReadInt32()
$fs.Seek($pe + 4,'Begin') | Out-Null
$machine = $br.ReadUInt16()

Get-Process が返すもののうち Path を持つものだけを対象にして、プロセス名でグループ化している。システムプロセスの一部は権限の都合で開けず、そこは判定不能として除外した。

ネイティブ側に何がいたか

上位を占めたのは msedge で、4840.3MB を使っていた。次が copilot の1830.2MB、msedgewebview2 が549.7MB。ブラウザ系がネイティブなのは、体感の軽さとつじつまが合う。

開発まわりも全部ネイティブだった。node が392.7MB、pwsh が301.3MB、python が153.0MB、git が15.5MB。chrome も309.6MB でネイティブ側にいる。

意外だったのは PowerToys だ。ColorPickerUI、ZoomIt、Awake、FancyZones、KeyboardManagerEngine、CropAndLock、Peek.UI、AlwaysOnTop と、確認できたモジュールが全部 ARM64 だった。細かいユーティリティほど後回しにされる印象を持っていたので、ここは予想と違った。

エミュレーション側の14本

x64 側に残っていたのはこの顔ぶれ。

プロセス メモリ 種別
LINE 447.1MB チャット
Ueli 432.9MB ランチャー
社内配布のツール(名称は伏せる) 167.9MB 業務ツール
logioptionsplus_agent 78.2MB Logicool の周辺機器管理
LogiPluginService 50.0MB 同上の常駐サービス
ONENOTEM 8.9MB OneNote の常駐部分

x86 側は node-runner が82.7MB、spacedeskServiceTray が3.3MB、そして py が1.0MB。

この py で一度詰まった。

py ランチャーだけ x86 だった

python 本体は Python312-arm64 配下に入っていて、当然 ARM64 だ。ところが Python ランチャーの py.exe は x86 として動いていた。

普段は python を直接叩くので気づかない。スクリプトの先頭に #! を書いて py 経由で実行したときだけ、エミュレーション層を1枚はさむことになる。起動のたびに数十ミリ秒を捨てている計算だ。

気づくまでに時間がかかった。原因を探して Python 側を疑い、環境変数を見直し、最後にアーキを測って初めて分かる。順番を逆にしていれば5分で済んだ話だった。

数えてみて分かったこと

エミュレーションで動いているものには共通点がある。日本のチャットアプリ、周辺機器メーカーのユーティリティ、社内向けの業務ツール、そして古いランチャー。どれも配布元が ARM64 版を出していないものばかりだ。

逆に、Microsoft と Google が自社で配っているものは、ほぼ例外なくネイティブになっていた。

ここから言えるのは、詰まるかどうかは「ARM64 だから」ではなく「そのソフトの配布元が対応する気があるか」で決まる、ということ。手元の85本という母数では、その境界がはっきり出た。

エミュレーション側の14本にしても、体感で困っているものは1つもない。LINE は447.1MB 使いながら普通に動くし、Logicool のユーティリティが少し重いくらいで実害はない。数字を見るまでは「14本も残っているのか」と思ったが、内訳を見れば納得できる並びだった。

同じ数え方をするスクリプトは検証機のスペックと測定条件に置いてある。自分の環境で数えると、たぶん違う内訳になる。数え終わったら x86 のものだけ拾ってみるといい。手元では py が引っかかった。

a
arm64lab — 個人運営

Surface Pro 11th Edition(Snapdragon X Elite)を2025年5月から常用機にしている個人の記録です。ARM64 版 Windows で詰まったところと、その場で測った値をそのまま書き残しています。特定の企業・団体とは関係がなく、いかなる組織を代表する見解でもありません。