WSL2でAntigravityは動くのか？ARM64環境で3つのエミュレータを試した40分間の記録
こんにちは！YaroTechです。
Day147でAntigravityを試した際、「WSL2内で動かせば完全に隔離できるのでは？」という疑問が浮かびました。
ARM64版のSurface LaptopでWSL2（Ubuntu 24.04）を使い、x64版のAntigravityを動かそうとしたら...
結論から言うと、現時点では不可能でした。
でも、この「動かなかった」という結果こそが、ARM64ユーザーにとって最も価値のある情報だと思います。40分の検証で3つのアプローチを試し、なぜ動かないのかを技術的に明らかにしました。
「自分も試してみよう」と思う前に、ぜひこの記事を読んでください。時間の節約になります！
※見出し画像のプロンプトは一番下におまけで公開中！
🖥️ 実行環境
検証PC:
Microsoft Surface Laptop 7th Edition
Snapdragon X Elite（ARM64）
Windows 11 Pro 25H2（ARM64）
WSL2環境:
Ubuntu 24.04 LTS（ARM64）
WSLgによるGUI表示対応
検証対象:
Antigravity（x64版 Electronアプリ）
🎯 この記事で得られること
WSL2 ARM64でx64アプリを動かす3つのアプローチ
各アプローチの失敗パターンと技術的原因
Electron/Chromiumアプリが動かない根本理由
同様の検証を試みる際の時間節約
🚨 この記事を読む前に
この記事では、WSL2、エミュレータ、メモリ管理など専門的な用語が多数登場します。
「SIGSEGV？TCMalloc？なにそれ？」という方は、先にこちらの用語解説記事を読むことをおすすめします：
関連記事: 【用語解説】WSL2・エミュレータ・メモリ管理を5分で理解する｜Day149の専門用語まとめ
5分で読める補助資料です。この記事を読めば、Day149の技術的な内容もスムーズに理解できます！
🔬 なぜWSL2で試したかったのか
Day147でAntigravityを使った際、以下の課題がありました：
UNCパス問題: `\wsl$...`での開発サーバー実行が不安定
ファイル移動の手間: Windows↔WSL2間でrobocopyが必要
セキュリティ懸念: AIエージェントがWindowsを直接操作する不安
「WSL2内で完結すれば、これらすべて解決するのでは？」
そう考えて検証を開始しました。
📊 実験結果サマリー
検証時間: 約40分
| 試行 | 方法 | 結果 | エラー |
|------|------|------|--------|
| 1 | qemu-user-static | ❌ 失敗 | ライブラリ不足 → SIGSEGV |
| 2 | box64 v0.3.9 | ❌ 失敗 | free(): invalid pointer → SIGABRT |
| 3 | FEX-Emu + RootFS | ❌ 失敗 | 同じくfree(): invalid pointer |
3戦3敗でした。
🧪 実験詳細
試行1: qemu-user-static
最初に試したのは、Linux標準のx64エミュレーション機能です。
sudo apt install -y qemu-user-static
./Antigravity/antigravity結果（1回目）: 共有ライブラリが見つからないエラー
error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory
ARM64環境にはx64用のライブラリがないため、まず起動できませんでした。
そこで、x64用のライブラリを追加でインストール：
sudo dpkg --add-architecture amd64
sudo apt update
sudo apt install -y libc6:amd64 libgtk-3-0:amd64 libglib2.0-0:amd64 ...今度は起動しましたが、サンドボックス関連のエラーが発生。chrome-sandboxの権限設定（`chown root:root` + `chmod 4755`）を行い、`--no-sandbox`オプションで再実行しました。
結果（2回目）: SIGSEGV（セグメンテーションフォルト）
x86_64-binfmt-P: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
Segmentation faultライブラリを追加し、サンドボックス設定を調整しても、QEMUユーザーモードエミュレーションではElectronのような複雑なアプリは動作しませんでした。
試行2: box64（ソースからビルド）
次に、ARM64でx64バイナリを高速実行できるbox64を試しました。事前にDeepResearchで調査し、Electronアプリは厳しいかもしれないとの情報を得ていましたが、実際に試してみました。
git clone https://github.com/ptitSeb/box64
cd box64 && mkdir build && cd build
cmake .. -DARM_DYNAREC=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j$(nproc) && sudo make installビルドは成功し、box64 v0.3.9（Dynarec有効）がインストールされました。
cd ~/antigravity-wslg && BOX64_LOG=1 box64 ./Antigravity/antigravity --no-sandbox --disable-gpu結果: メモリ管理エラーで停止
[BOX64] Warning: Weak Symbol OPENSSL_memory_alloc not found...
[BOX64] Warning: Weak Symbol OPENSSL_memory_free not found...
free(): invalid pointer
Aborted (SIGABRT)
多くのライブラリはネイティブラップに成功しましたが、最終的に`free(): invalid pointer`エラーでクラッシュしました。
試行3: FEX-Emu + RootFS
最後の手段として、より本格的なx64エミュレーション環境「FEX-Emu」を試しました。
FEX-Emuは完全なx64 Linux環境（RootFS）を構築し、その中でx64バイナリを実行する仕組みです。
# FEX-Emu + RootFS のセットアップ
curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py -o InstallFEX.py
python3 InstallFEX.py
FEXRootFSFetcher # Ubuntu_24_04.sqshをダウンロードFEXInterpreterでAntigravityを実行：
cd ~/antigravity-wslg && FEXInterpreter ./Antigravity/antigravity --no-sandbox --disable-gpu結果: box64が呼び出され、同じエラー
ログを見ると、`FEXInterpreter`を実行したのにbox64が起動していることが分かりました：
[BOX64] Box64 arm64 v0.3.9 056999e8 with Dynarec built on Dec 6 2025 10:57:31これはbox64がbinfmt_miscに登録されているため、x64バイナリが自動的にbox64で処理されてしまっています。
最終的に、同じ`free(): invalid pointer`エラーで失敗しました。
FEXBash（x64環境シェル）に入って`arch`コマンドを実行すると`x86_64`と表示されましたが、Antigravityを実行すると結果は変わりませんでした。
🔍 なぜ動かないのか？技術的な分析
根本原因: TCMallocとエミュレータの競合
Antigravityの中核はElectron（Chromium）です。そしてChromiumは、独自のメモリ管理システム「TCMalloc」を使用しています。
Chromium/Electron
↓
TCMalloc（独自メモリ管理）
↓
エミュレータ（box64/qemu）
↓
ARM64ネイティブこの構造が問題です。TCMallocが行うメモリ操作が、エミュレータのメモリ管理と根本的に競合してしまいます。
実は、これはAntigravity固有の問題ではありません。Discord、HTTP Toolkitなど、他のElectronアプリでも同様の報告があります（box64 GitHub Issue #3210 , #1478 ）。
つまり、Electronアプリ全般がWSL2 ARM64では動かないということです。
💡 この検証から学んだこと
1. 「エミュレータで何でも動く」は幻想
box64やFEX-Emuは多くのx64アプリを動かせますが、Electronのような複雑なアプリは例外です。
2. ARM64の「壁」は依然として存在する
Day139のClaude Code on Desktop、Day115のGemini Computer Useに続き、今回もARM64の制約に直面しました。
3. 40分で結論が出せた価値
もし事前調査なしで試していたら、何時間も無駄にしていたかもしれません。「動かない」という情報も、立派な成果です。
🛣️ 代替案：ARM64でAntigravityを使うには
現時点で可能な方法：
方法1: Windows上で直接実行（Day147の方法）
AntigravityはWindows ARM64版が存在
ネイティブで動作し、最も安定
方法2: x64 PCを使用
メインPCやThinkPad X1（x64）で実行
WSL2内での実行も可能
方法3: クラウド環境
GitHub Codespaces、AWS Cloud9など
x64インスタンスを利用
WSL2 ARM64での実行は、現時点では諦めるしかありません。
🔗 関連記事
今回の内容に関連する過去記事もぜひご覧ください：
📝 まとめ
検証結果:
qemu-user-static: ❌ ライブラリ不足 → SIGSEGV
box64: ❌ free(): invalid pointer → SIGABRT
FEX-Emu: ❌ box64が処理し同じエラー
根本原因:
Electron/ChromiumのTCMallocがエミュレータと競合
これはAntigravity固有ではなく、Electronアプリ全般の問題
結論:
WSL2 ARM64でx64版Electronアプリは動かない
ARM64ユーザーは、ネイティブ版を使うか、x64環境を用意する
この記事の価値:
同じ検証をしようとしている人の時間を節約
「動かなかった」という事実の共有も重要
🚀 次回予告
Day150は150日記念記事をお届けします！150日間の振り返りと、これからの展望をまとめる予定です。お楽しみに！
🎨 おまけ：見出し画像作成プロンプト
今日の見出し画像のベースはジミー（Gemini）に下記プロンプトで作成してもらいました！：
詳細なアニメの美意識の画像を作成してください。表情豊かな瞳、なめらかな網掛けセルの色使い、はっきりした線画を使用します。アニメのシーンに典型的な身ぶりと雰囲気で、心情と登場人物の存在を強調してください。
## 🎨 見出し画像案
### デザインコンセプト
- **背景**: 暗めの青→紫のグラデーション（夜・技術的な雰囲気）
- **メインビジュアル**:
- 中央に「×」マーク3つ（3回の失敗を表現）
- 左側にWSL2のペンギンアイコン（Linuxシンボル）
- 右側にARMチップのイラスト
- 下部に「40分」の時計アイコン
- **テキスト要素**:
- 上部: 「WSL2 × ARM64」（大きく・太字・白色）
- 中央: 「3つのエミュレータで挑戦」（中サイズ・白色）
- 下部: 「検証記録」（小サイズ・白色）
- **装飾**: 回路基板パターン、エラーメッセージ風のテキスト
### 作成手順
1. スライドサイズ（1536×1024px）の横長フォーマット
2. 背景に暗い青→紫のグラデーション（技術的・夜の雰囲気）を設定
3. 中央に大きな「×」マーク3つを配置（赤色、3回の失敗を象徴）
4. 左側にLinuxペンギンアイコンを配置
5. 右側にARMチップのイラストを配置
6. 下部に「40min」と時計アイコンを小さく配置
7. テキストを3段構成で追加
8. 回路基板パターンを薄く背景に重ねる
9. 右下に「YaroTech」のロゴを12ptで控えめに配置チャッピー（ChatGPT）が作ったのは下記でしたが、×が多いし、不採用です。
#YaroTech #WSL2 #ARM64 #Antigravity #Electron #エミュレータ #box64 #検証記録 #生成AI #AIコーディング
いいなと思ったら応援しよう！
記事がお役に立てたなら嬉しいです！
いただいたチップは、新しいMCPツールの検証や、より深い実践実験の資金として大切に使わせていただきます。
あなたの応援が次の「AI活用の感動」を生み出す原動力になります✨
一緒に羽ばたき続けましょう！