💭

ARM版Windows 11 + WSL2で（できるだけ）ネイティブの開発環境を構築する

に公開
arm64
AArch64
Windows 11
tech

2025/03の頭に、アキバのジャンク通りを歩いていたところ、Snapdragon X Elite（X1E-78-100） + 32GB RAM + 2.8K OLEDのノートPC（ThinkPad T14s Gen 6 Snapdragon）が200kで転がっていました。
勢いに任せて買ってしまったので、せっかくですしWindows 11+ WSL2環境下で、ARM64ネイティブな日常用途・開発環境を構築してみようと思ったので、環境構築までのメモを残します。

1. 日常用途系

a. ブラウザ

ブラウザに関しては主要なブラウザはほとんど全てがARM64に対応したバイナリを用意しています。
そのため、基本的にはx64エミュレーションに頼る必要はないはずです。

例外: Edgeのアップデータ

Edgeの本体はARM64ネイティブで動作しているのですが、なぜかEdgeの自動更新を行うためのアップデータはx86（x64ですらない）で動作しています。ちょっと酷い

b. ワークスペース・コミュニケーションツール

ワークスペース・コミュニケーションツールはやや対応状況がまちまちであり、以下のように対応状況ははっきりと分かれています。

ネイティブ対応

  • notion
  • Slack
  • Zoom

ネイティブ非対応だが動く

  • Discord
  • LINE Desktop

非対応の場合はPrismでx64互換で動かすことになるのですが、DiscordのようにElectronで動かしているアプリケーションはオーバーヘッドが大きいのか、スペックの割にかなりもっさりとした動作になることが多い印象です。
そのため、Discordなどはできればブラウザ上から利用したいですね。

c. その他細かいツール類

分類に悩んだのですが、個人的に使用しているツールです。

ネイティブ対応

  • PowerToys

ネイティブ非対応だが動く

  • UnigetUI

動かない

  • ATOK
  • Google日本語入力

UnigetUIについてはWinGet自体はネイティブで動くものの、フロントエンドがx64互換で動いている、という状況です。
WinGetをCLIで完結させられれば特に困らないはず？

ATOK/Google日本語入力はいずれも公式にARM64が非対応だと明言されています。
インストール自体が通らないですし、過去のバイナリをインストールすることで無理やり入れてもアプリケーションによってはマトモに入力できない、などの不具合が発生します。

個人的に一番困っているのが、IMEがARM64に非対応である問題であり、これが一番体験を損ねている状況です。

2. 開発環境

a. WSL2

当たり前ですがWSL2に関してはARM64に対応しており、ディストリビューションも十分に選択可能です。
x64とは違い、一部のディストリビューションには対応していない（SLES、Oracle Linuxなどは非対応です）ですが、
よく使われるであろうUbuntu、Debian、AlmaLinux辺りは対応しているので困ることは少ないと思います。

b. エディタ/IDE

ネイティブ対応

  • Visual Studio Code
  • IntelliJ IDEA

ネイティブ非対応だが動く

  • Arduino IDE
  • Quartus Prime

動作自体はするがドライバがないせいで事実上動作しない

  • Vivado Design Suite

エディタはVisual Studio Codeと、IntelliJ IDEAは完全対応しています。
一応IntelliJ IDEAはWSL2での利用時に一部バグはあるのですが、2025.1では解消されるようなのであまり気にしなくてもよさそうです。

所謂組み込みやFPGAなどで使用されるArduino IDEや、Quartus PrimeはIDE自体はネイティブ非対応なものの、
ドライバはARM64に対応したものが用意されている関係上、パフォーマンスに難はあるものの問題なく使用することができます。

一方、VivadoについてはドライバもARM64に非対応なため、実際にFPGAを動かすことはできないです。
残念ですが、個人的にはIntelのFPGAを触ることが多いため、一応何とかなっている次第です。いずれ対応はしてほしいですが、AMDにはやる気はなさそうです・・・

c. 仮想化環境

ネイティブ対応

  • Docker（ベータ版）
  • Hyper-V
  • QEMU（試していない）

ネイティブ対応しているが動作に難あり

  • Podman

動かない

  • VMWare Workstation
  • VirtualBox
  • Rancher

Dockerについてはベータ版とは言えDocker Desktop含め完全対応ですが、ARM64に対応していないイメージの場合はコンテナの起動に失敗します。
最近はmac対応の関係で少なくなってきましたが、非対応のイメージの場合は対応しているイメージ、またはアーキテクチャを明示的に指定することでQEMUでのエミュレーションを行う必要があります。（エミュレーションが入るのでパフォーマンスは下がります）

ARM64版Windows 11に対応しているハイパーバイザーはHyper-VとQEMUの2つです。（QEMUは自前でビルドをする必要があります）
VirtualBoxとVMWareは残念ながら非対応です。

PodmanはPodman Desktopのアプリケーションこそネイティブ対応していますが、初回の
podman machine initを行った際に、x64のイメージを引っ張ってきてしてしまうため失敗します。
一応、issueを参考に最新版のPodmanのインストールを行えば解決します。 https://github.com/containers/podman/issues/25621

3. おまけ（パフォーマンス）

おまけとして、Cinebench 2024（ARMネイティブ）、Cinebench R23（x64エミュレーション）の結果を見てみます。

比較的リリース時期の近い、Core Ultra 7 258Vと比較してみると、シングルコアのスコアは5～10%ほど低いが、マルチコアのスコアは35%ほど高いということが分かります。
一方、他の平均的なX1E-78-100のスコアと比較するとおよそ15%ほど低いこともわかりました。
（参考: https://www.cpu-monkey.com/ja/compare_cpu-qualcomm_snapdragon_x_elite_x1e_78_100-vs-intel_core_ultra_7_258v）

これは、Snapdragon X EliteのTDPの設定幅が広いことと、ThinkPad T14s Gen 6 SnapdragonのTDPの設定値が低いであろうことが原因として考えられます。
こちらはモバイルノートであるため、熱設計を考慮したうえでこの値になっているのでしょう。

全体的には、「十分高いパフォーマンスだが、現行世代と比べるとやや物足りない」結果ではありますが、これはQualcommとARMのライセンス問題などに起因しており、本来このCPUがリリースされたであろう時期はもう少し早いことを考えると、より大きなインパクトを持っていた、と言えるのではないでしょうか。

4. まとめ

自分が開発環境を構築するにあたって、なるべくARM64ネイティブな環境を構築できるようにするための備忘録ついでに、現時点（2025/04/13）での状況をまとめてみました。

動作的には全体的に気に入ってはいるのですが、まだ他人に勧めるには注意点が多く、手放しで褒められない個所もあるのが難しいところです。

まだまだ全体的には発展途上なところもあるので、今後に期待・・・したいのですが、MicrosoftのARM64対応は定期的に放り投げる悪癖があるので、今からどうなるのかはちょっと怖いですね。

Discussion