Antigravity が WSL2 環境で異常に遅い・ファイル監視が効かない問題の解決ガイド

「自宅の Mac では快適だった Antigravity が、会社支給の Windows + WSL2 に入れた途端に重い」「ファイルを保存しても AI が古い内容のまま回答する」— このパターンに心当たりがある方は、ほぼ間違いなく WSL2 のファイルシステム境界の罠にハマっています。私自身、Windows ノートに開発環境を移したとき、最初は「Antigravity 自体が遅いのかな」と勘違いして30分ほど無駄にしました。

WSL2 のパフォーマンス問題は、Antigravity 固有のバグというよりは「Windows と Linux の境界をまたいだファイル操作が遅い」という設計上の特性に起因します。原因さえ把握できれば、設定変更だけで体感速度が数倍変わります。ここでは症状を切り分けるところから、恒久的な対応まで順番に整理していきます。

まず確認すべき「プロジェクトの置き場所」

WSL2 で開発するときに最も多い間違いは、Windows 側の C:\Users\xxx\projects をそのまま使うことです。WSL2 内からは /mnt/c/Users/xxx/projects として見えますが、この経路で読み書きすると 9P プロトコル経由の通信が発生し、ネイティブ Linux ファイルシステムと比べて10倍以上遅くなることがあります。

# プロジェクトがどこにあるかを確認
pwd
# /mnt/c/Users/xxx/projects/myapp  ← これが遅い原因

Antigravity はバックグラウンドでコードベース全体をインデックスし、AI エージェントは保存ごとにファイル差分を読み直します。ここが遅いと、すべての操作が連鎖的に遅延します。最も効果的な対処は、プロジェクトを WSL2 のネイティブパス配下に移すことです。

# WSL2 ホームディレクトリ配下に移動
mkdir -p ~/projects
mv /mnt/c/Users/xxx/projects/myapp ~/projects/myapp
cd ~/projects/myapp

たったこれだけで、git status の体感速度が分単位から秒未満に変わるケースが多いです。Antigravity 側でも、コードベースインデックスの完了時間が一気に短縮されます。

ファイル監視が効かないときの対処（inotify 上限）

ファイルを保存しても Antigravity の AI が古い内容で回答する、フォーマッタが効かない、HMR（Hot Module Replacement）が動かない — このあたりは inotify の監視枠が枯渇しているサインです。

# 現在の上限を確認
cat /proc/sys/fs/inotify/max_user_watches
# 8192 などの低い値だと、node_modules の規模が大きい時点で枯渇する

Next.js や Vite のような近代的なフロントエンドプロジェクトは、node_modules だけで数万ファイルになることもあり、デフォルト値ではすぐに上限に達します。恒久対応として /etc/sysctl.conf に書き込んでおきます。

# /etc/sysctl.conf に追記（sudo 必須）
echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf
echo "fs.inotify.max_user_instances=512" | sudo tee -a /etc/sysctl.conf
 
# 即時反映
sudo sysctl -p

設定後は WSL2 を一度シャットダウンして再起動するのが確実です。PowerShell から wsl --shutdown を実行し、再度 WSL2 のターミナルを開き直してください。同じ症状でファイル監視で ENOSPC エラーが出るときの解決ガイドも合わせて参照すると、より広範な ENOSPC エラーの対処パターンが整理できます。

メモリと CPU の割り当てを WSL2 側で見直す

WSL2 のリソース割り当てはホスト Windows 側の .wslconfig で制御されています。デフォルトでは Windows 全メモリの50%（最大8GB）が割り当てられますが、Antigravity のような AI エディタは Node.js プロセスやランゲージサーバーをいくつも立ち上げるため、4〜6GB だとすぐに不足します。

# C:\Users\<ユーザー名>\.wslconfig （Windows 側）
[wsl2]
memory=12GB
processors=8
swap=4GB
localhostForwarding=true

メモリは「物理メモリの最大75%」を目安にしておくと、Antigravity の AI エージェントが大きめのコードベースを扱っても余裕が生まれます。processors も全コア数の半分以上を割り当てると、インデックス生成時の体感が大きく変わります。設定変更後は wsl --shutdown で必ず再起動してください。

メモリを増やしてもまだ重い場合は、エディタの拡張機能や常駐プロセスが原因のことがあります。Antigravity の動作が遅いときの総合診断ガイドと CPU・メモリ使用率が高いときの対処を組み合わせて見ていくと、ボトルネックを絞り込めます。

DNS・ネットワーク経由の遅延を疑う

WSL2 はデフォルトで Hyper-V の仮想ネットワークを経由するため、DNS 解決やネットワーク経路に問題があると Antigravity の AI 応答そのものが遅くなります。Gemini API の呼び出しがタイムアウト気味な場合は、まず DNS を疑うのが早いです。

# DNS が機能しているか確認
nslookup generativelanguage.googleapis.com
 
# 名前解決に時間がかかる、もしくは失敗する場合
sudo rm /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf

ただし /etc/resolv.conf は WSL2 起動時に自動再生成されてしまうので、恒久化したい場合は /etc/wsl.conf に下記を追記して自動生成を止めます。

# /etc/wsl.conf
[network]
generateResolvConf = false

社内ネットワーク経由でアクセスしている場合は、DNS だけでなくプロキシ・証明書まで影響することがあります。プロキシ環境特有の症状については企業プロキシ・ファイアウォール環境での接続トラブル解決ガイドを併読してください。

それでも遅いときに見直すべき WSL バージョンと統合形態

ここまでで改善しない場合、WSL のバージョン自体が古い可能性があります。PowerShell から下記を実行して、最新のカーネルに更新してください。

# PowerShell（管理者）で実行
wsl --update
wsl --version
# WSL バージョン: 2.x.x 以上が望ましい

また、Antigravity を「Windows 側で起動して WSL2 のフォルダを開く」という使い方は、便利な一方でファイル境界をまたぐため遅延の温床になります。私が実際に試した範囲では、WSL2 内に Antigravity の Linux 版を入れて、X サーバ（WSLg）経由で起動するか、もしくは WSL2 内のプロジェクトに対してリモートワークスペースの仕組みで接続するほうが安定しました。チームで共有する開発手順としても、こちらのほうが「誰の環境でも同じ速度」になりやすく、おすすめです。

全体を振り返って — 今日試す一手

WSL2 + Antigravity の遅さは、たいてい「プロジェクトの置き場所」と「inotify 上限」の2点で大半が解決します。まずは今開いているプロジェクトが /mnt/c/... にいないかを pwd で確認し、もしそうなら今日のうちに ~/projects 配下へ移動してみてください。それだけで明日からの開発体験が変わるはずです。