「Antigravity server crashed unexpectedly」が出たとき、CPU・WSL・版のどれを先に疑うか

エラーの文面を読んで、まず「再起動してください」に従うのは自然なことです。けれども同じダイアログが再起動のたびに戻ってくるとき、その一文は手がかりになりません。

「Antigravity server crashed unexpectedly. Please restart to fully restore AI features.」——エディタの画面そのものは開くのに、AI の側だけが起動直後に落ちる症状です。フォーラムを辿ると、この同じ文面のスレッドが何本も立っておりました。環境はそれぞれ違います。古い AMD の CPU の Linux、Pop!_OS、WSL、リモートの SSH 先。文面が同じなだけで、原因は一つではなさそうだと気づいたのは、スレッドを四本ほど読み比べたあとでした。

私自身は、この症状を手元の環境で再現できておりません。ですのでこの記事は「私が直した記録」ではなく、公開されている報告を読み比べて、どの順番で何を確かめれば遠回りが少ないかを整理した覚え書きです。確定していないことは、確定していないと書きます。

同じ文面の下に、少なくとも三つの別の話があります

読んだ範囲で、報告は大きく三つに分かれました。

大事なのは、どの行も「これが原因」と言い切れる状態ではない点です。開発側から公式の説明が付いているスレッドを、私は見つけられませんでした。

だからこそ、切り分けの順番に価値があるのだと思います。原因を当てにいくのではなく、自分の環境がどの行に近いかを、数分で絞り込むほうが現実的です。

最初に取る情報は、一枚のスクリプトで足ります

報告を読んでいて、どのスレッドも最初に欠けているのは同じ情報でした。CPU、OS、WSL か否か、版です。投稿者が後から「実は WSL1 でした」と書き足す流れが何度もありました。

先に自分で一覧にしておけば、切り分けも、質問を書くときも楽になります。Linux と WSL で動く最小のスクリプトを置きます。

#!/usr/bin/env bash
# ag_triage.sh — 「server crashed unexpectedly」の切り分けに要る情報を一度に出します。
# 何も書き換えません。読み取りだけです。
 
echo "== CPU =="
grep -m1 'model name' /proc/cpuinfo
# -w を付けて aes という単語だけを数えます（pclmulqdq 等と混ざらないように）
if grep -qw aes /proc/cpuinfo; then
  echo "aes フラグ: あり"
else
  echo "aes フラグ: なし  <- CPU 系の可能性を先に見る"
fi
 
echo "== OS =="
. /etc/os-release 2>/dev/null && echo "$PRETTY_NAME"
uname -m   # x86_64 以外（aarch64 など）なら別系統の報告を探す
 
echo "== 実行経路 =="
if grep -qi microsoft /proc/version 2>/dev/null; then
  if uname -r | grep -qi 'wsl2'; then echo "WSL2 上"; else echo "WSL（WSL2 の表記なし。WSL1 の可能性）"; fi
fi
[ -n "$SSH_CONNECTION" ] && echo "SSH 経由のシェル"
 
echo "== サーバー側の作業ディレクトリ =="
ls -d "$HOME/.antigravity-server" "$HOME/.gemini/antigravity" 2>/dev/null || echo "どちらも無し"

実行すると、たとえば次のような出力になります。

== CPU ==
model name	: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
aes フラグ: あり
== OS ==
Ubuntu 22.04.4 LTS
x86_64
== 実行経路 ==
WSL2 上
== サーバー側の作業ディレクトリ ==
/home/user/.antigravity-server

なぜ grep -w なのか、少しだけ補足します。フラグ一覧には似た綴りの項目が並んでおり、緩い一致だと取り違えが起きるためです。「なし」と出たときは、本当に無いのか、仮想環境が CPU の機能を隠しているだけなのかも考えます。仮想マシンの上では、ホストの CPU が対応していてもゲストに見えない設定があり得ます。

一行目の結果で、次に見る場所が決まります

aes が「なし」だった場合。 報告を読む限り、この系統は「画面は開くのにエージェントだけ落ちる」という特徴が一貫していました。ただし、AES 命令が必須かどうかは、私が確かめられた範囲では未確認です。実際、Pop!_OS の報告者は「AES は対応済み」でも同じ文面に当たっています。つまり aes の有無は、原因の証明ではなく、可能性の優先順位を決める材料にとどめるのが妥当です。

「なし」で、かつ他の系統にも当てはまらないときは、その機材で AI 機能を使うのをいったん諦める判断も現実的です。個人開発でビルド専用機のように古い機材を使い回すことはありますが、エージェントを動かす役は、新しい側の機材に寄せる——私ならそうします。

WSL や SSH だった場合。 次の三つを、軽い順に見ます。

1. WSL が 1 なのか 2 なのか。Windows 側で wsl -l -v を実行すると VERSION 列に出ます。WSL1 のままだった場合は、2 へ上げるよう勧める返信がありました。ただし、それで直ったという確認はスレッド内にありません。
2. 回線を変えて試せるか。あるスレッドでは、スマートフォンのテザリングでは動き、特定のプロバイダの機器では動かなかったという報告がありました。これは回避策であって、解決とは書かれていません。社内プロキシ越しなら、プロキシやファイアウォール越しの接続を切り分ける記事が手がかりになります。
3. サーバー側の作業ディレクトリ（WSL 内の .antigravity-server）を消して作り直す。報告者は試して直らなかったと書いておりますが、残骸が原因の別環境では効く余地があります。消す前に退避しておけば、元に戻せます。

どちらでもなく、版が古い疑いがある場合。 Pop!_OS の報告では、1.20.4 で直ったように見えると述べられていました。更新で解消することがあるのは確かなようです。一方で、版を上げたあとに別の不具合が出る可能性もあります。更新の前に、いまの版を控えておくことをお勧めします。版を固定して運用する考え方は、CLI の版を固定して定期実行の再現性を保つ記事に書いております。

試さないほうがよいこと

スレッドの中には、フルの再インストールを何度も繰り返した報告がありました。結果は直らなかったそうです。

気持ちはよく分かります。私も、アプリの不具合で原因が見えない夜は、最後は入れ直しに手が伸びます。けれども入れ直しは、設定や履歴を巻き込みます。切り分けの情報が取れていない段階では、直ったときにも「何が効いたのか」が残りません。入れ直しの前に、スクリプトを一回走らせます。 この順番だけは崩さないようにしております。

フォーラムに書くとき、返事が付きやすくなる情報

この症状では、すでに同じ文面の投稿が多く、環境の記載が薄いと、読む側も判断のしようがありません。上のスクリプトの出力をそのまま貼り、加えて次の四点を添えます。

• Antigravity の版（About 画面などで確認できます）を書くこと
• 症状が出る直前に行った操作（更新、プロキシ設定の変更など）を書くこと
• 試したことと、その結果（「直らなかった」も大切な情報です）を書くこと
• Windows 側だけなら動くのか、WSL や SSH 先だけが落ちるのかを書くこと

どれも一行で済みます。

次の一歩

まずは ag_triage.sh を一度走らせて、出力を手元のメモに残してください。aes の有無、WSL の版、Antigravity の版の三つが埋まれば、上の三系統のどこに近いかは数分で見当がつきます。

原因が公式に説明される日が来るかどうかは、私にも分かりません。それでも、自分の環境の事実を先にそろえておけば、説明が出たときに、すぐ照らし合わせられます。