Antigravityをアップデートしたら pnpm も gh も使えなくなった話
はじめに
2週間ぶりに Antigravity を開きました。
デザインに合わせてリンクを1つ追加するだけ。10分でサクッと終わらせるつもりでした。
エージェントが返してきたのはこんなメッセージです。
pnpm: command not found
……え、ちょっと待ってください。
gh コマンドも試してみると、コマンド自体は見つかるものの認証が通りません。
gh: authentication required
前回使ったときは普通に動いていたのに、なぜ？
最初は Antigravity の不具合だとは思いませんでした。
ローカル環境が壊れたのだと思い、直近で導入した fnm のセットアップを疑いました。
~/.zshrc を見直し、fnm のドキュメントを読み返し、パスの通し方を何パターンも試す。
あらぬ方向の調査に時間を溶かした結果、原因が Antigravity のアップデートにあると気づくまでに2時間かかりました。
そしてそのボルテージのままこの記事を書き始めたので、さらに1時間。
10分で終わるはずの作業が、合計3時間になりました。
この記事ではその原因と解消方法をまとめます。
以前書いた Antigravity 関連の記事もあわせてどうぞ。
症状
pnpm が見つからない
私は Node.js のバージョン管理に fnm を使っています。
~/.zshrc に以下のようなセットアップコマンドを書いて、シェル起動時に fnm が $PATH を構成する仕組みです。
eval "$(fnm env --use-on-cd --shell zsh)"
Antigravity が GUI（Dock やランチパッド）から起動されると、このシェルの初期化処理が実行されません。
結果として fnm が構成するはずの $PATH がまるごと欠落し、pnpm も npm も node も見つからない状態になります。
gh の認証が通らない
gh コマンド自体は /usr/local/bin/gh にあるため見つかります。
しかし、私は GitHub の認証トークンを環境変数 GITHUB_TOKEN で管理していました。
Antigravity が $PATH だけでなく環境変数全般を引き継がなくなったため、GITHUB_TOKEN も消失。
コマンドは実行できるのに認証だけ通らないという、地味にわかりにくい症状でした。
共通する原因
どちらも根っこは同じです。
Antigravity が GUI 起動時にシェルの環境変数を正しく引き継がなくなった。
ターミナルから直接 pnpm や gh を叩けば問題なく動きます。
Antigravity の内蔵ターミナルやエージェントを経由したときだけ、環境が壊れている状態です。
原因
調べてみると、Google AI Developers Forum にも同様の報告が上がっていました。
以下のスレッドでは、macOS の GUI から起動した際に MCP サーバーが $PATH を継承できずクラッシュする問題が詳しく報告されています。
複数のユーザーが再現を確認しており、フィードバック機能自体も壊れていて報告すらできないという声も上がっています。
原因は主に2つあります。
1. GUI 起動時の $PATH 継承失敗
Dock やランチパッドなどの GUI から Antigravity を起動すると、内蔵の MCP（Model Context Protocol）オーケストレーターがローカルシェルの $PATH を正しく引き継ぎません。
macOS では GUI アプリケーションはログインシェル（~/.zshrc など）を経由せずに起動されます。
これ自体は macOS の仕様ですが、以前の Antigravity はこの問題をうまく回避していました。
アップデートのどこかでその回避処理が壊れた、あるいは仕様が変わったようです。
2. mcp_config.json での環境変数上書き問題
「じゃあ設定ファイルで $PATH を明示的に渡せばいいのでは？」と思うかもしれません。
しかし、mcp_config.json の env フィールドで "PATH": "/usr/local/bin:..." のように記述すると、バックグラウンドの Go ランタイムが子プロセスの環境変数を完全に上書きしてしまいます。
その結果、$HOME や $USER など他の環境変数が欠落し、別のクラッシュを引き起こすという悪循環に陥ります。
また、JSON ファイル内での ${MY_VAR} のようなシェル変数の展開も機能しません。
解消方法
現時点で最も確実な回避策は、ターミナルから Antigravity を起動することです。
ターミナル経由であればシェルの初期化処理が走るため、$PATH も環境変数も正しく継承された状態で立ち上がります。
実際にこの方法で pnpm も gh も問題なく動くことを確認しました。
起動コマンド
# 新規ウィンドウで起動する
antigravity -n
注意点として、antigravity だけで実行すると、すでに起動している Antigravity のウィンドウがアクティブになるだけです。
新しいウィンドウを開くには -n オプションを付けます。
# オプション一覧を確認する
antigravity -h
-h で他のオプションも確認できるので、一度見ておくと便利です。
GUI ツールを CUI で起動する違和感
これで問題は解消しますが、正直なところ釈然としません。
GUI のコードエディタを使いたいのに、毎回ターミナルから起動しなければならない。
macOS ユーザーが Dock から起動するのは当然の使い方です。
その「当然の使い方」で環境が壊れるのは、ワークアラウンドがあるとしても不具合に変わりありません。
その他のワークアラウンド（参考）
コミュニティでは他にもいくつかの回避策が共有されています。
私自身は未検証ですが、参考として紹介します。
mcp_config.json を空の env で記述する
{
"mcpServers": {
"example": {
"command": "npx",
"args": ["-y", "example-server"],
"env": {}
}
}
}
空のオブジェクト {} を指定すると、シェル側で export した変数をそのまま継承するそうです。
"env": { "MY_VAR": "" } のように空文字を入れると逆に上書きされて壊れるので注意が必要です。
実行コマンドを絶対パスに書き換える
{
"mcpServers": {
"example": {
"command": "/usr/local/bin/npx",
"args": ["-y", "example-server"]
}
}
}
$PATH が通っていなくても絶対パスなら直接実行できます。
ただし、fnm や nvm のように動的に $PATH を構成するツール群では、バイナリの場所がバージョンごとに変わるためこの方法は使いにくいです。
v1.21.9 にダウングレードしてから再アップデートする
フォーラムでは、Antigravity を完全にアンインストールした後、Releases ページから v1.21.9 をインストールし、その上でアップデートすることで解消したという報告もありました。
v1.22.2 のインストールプロセス自体が壊れている可能性があるようです。
考察
ここからは個人的な考察です。
すぐ気づくはずの問題が、なぜリリースされたのか
pnpm が動かない。gh の認証が通らない。
これは「些細な不具合」ではなく、開発者が日常的に使う CLI ツールが軒並み動かなくなる致命的な問題です。
もし Antigravity の開発チームが自分たちのプロダクトを日常的に使っていれば、リリース後すぐに気づくはずです。
少なくとも npm や git 関連のコマンドが動かなくなれば、開発作業自体が止まります。
この規模の破壊的変更がテストをすり抜けてリリースされている事実は、内部でのドッグフーディング（自社プロダクトの日常利用）が十分に行われていない可能性を示唆しています。
さらに気になるのが、フォーラムで複数のユーザーが報告している「フィードバック機能自体が壊れている」という問題です。
バグを見つけて報告しようにも、送信ボタンを押しても反応がなくハングするそうです。
バグ報告の導線が断たれている状態では、問題の発見も修正もさらに遅れてしまいます。
競合プロダクトとのドッグフーディング温度差
他の AI コーディングツールと比較すると、この差はより鮮明になります。
Claude Code は Anthropic 社内の開発効率化から生まれたプロダクトで、社員が先行機能を日常的に使い込んでいるそうです。
Codex も同様に、OpenAI 社内で積極的に利用されていると聞きます。
公式ブログの直近4件の投稿日を並べてみると、温度差が一目でわかります。
| # | Claude Code | 日付 | Antigravity | 日付 |
|---|---|---|---|---|
| 1 | Auto mode for Claude Code | 2026/03/24 | Gemini 3.1 Pro in Antigravity | 2026/02/19 |
| 2 | Product management on the AI exponential | 2026/03/19 | Gemini 3 Flash in Antigravity | 2025/12/17 |
| 3 | 1M context for Opus 4.6 and Sonnet 4.6 | 2026/03/13 | Nano Banana Pro in Antigravity | 2025/11/20 |
| 4 | Bringing Code Review to Claude Code | 2026/03/09 | Introducing Google Antigravity | 2025/11/18 |
Claude Code は2週間で4本。Antigravity は3ヶ月で4本、しかもすべてモデル追加のアナウンスです。
開発チーム自身のワークフローや使い方に関する発信は一切ありません。
このドッグフーディングの温度差が、環境変数が消えるような基本的な不具合をリリース前に潰せるかどうかの差に直結していると感じます。
アップデート頻度と内容の変化
Antigravity の Changelog を見ると、初期と最近でアップデートの傾向が大きく変わっています。
| 時期 | バージョン | 日付 | 主な内容 |
|---|---|---|---|
| 初期 | 1.11.2 | 2025/11/18 | 初回リリース |
| 初期 | 1.11.3 | 2025/11/18 | 初日の不具合修正 |
| 初期 | 1.11.5 | 2025/11/20 | Nano Banana Pro 対応 |
| 初期 | 1.11.9 | 2025/11/26 | 認証フロー修正 |
| 初期 | 1.11.14 | 2025/12/04 | レート制限引き上げ |
| 初期 | 1.11.17 | 2025/12/08 | セキュアモード追加 |
| 初期 | 1.12.4 | 2025/12/17 | Gemini 3 Flash 対応 |
| 初期 | 1.13.3 | 2025/12/19 | レート制限引き上げ |
| 最近 | 1.20.6 | 2026/03/17 | ルール・ワークフロー作成の修正 |
| 最近 | 1.21.6 | 2026/03/25 | Linux サンドボックス対応、MCP 改善 |
| 最近 | 1.21.9 | 2026/03/30 | オンボーディング修正（修正1件のみ） |
| 最近 | 1.22.2 | 2026/04/07 | Agent Permissions（改善1件のみ） |
初期は1ヶ月で8回、週2〜3回のペース。最近は週1回で内容も小粒です。
積極的な開発フェーズから、メンテナンスモードに移行しつつあるように見えます。
プロダクトとしての信頼性
AI エディタに求めるものは人それぞれです。
コード生成の精度、最新モデルへの対応、ブラウザ連携。
ただ、開発環境として最低限の信頼性——昨日まで動いていた CLI ツールが今日も動くこと——は、機能以前の前提条件です。
アップデートのたびに環境が壊れるかもしれないと心配しながら使うのは、なかなかつらいものがあります。
おわりに
Antigravity のアップデートで $PATH や環境変数の引き継ぎが壊れ、pnpm や gh が使えなくなる問題と、その解消方法をまとめました。
- 症状: GUI 起動時にシェルの環境変数が引き継がれない
-
原因: MCP オーケストレーターの
$PATH継承処理の不具合 -
解消:
antigravity -nでターミナルから起動する
もともと機能面の不足は感じていました。
それでも期待感があって使い続けていたのが正直なところです。
ただ、ここ最近の状況を見ると、Claude Code や Codex、Cursor と戦える土俵に上がることはないだろうと感じました。
アップデート頻度の鈍化、ブログ発信の少なさ、品質管理の甘さ。
以前 Note の記事に書いた有料プランのクォータ大幅削減も含め、ユーザーの方を向いた判断が見えません。
本日、この記事の執筆をもって Antigravity の利用を終了するつもりです。
記事のレビューや裏付け調査には Antigravity の Opus モデルを使いました。
最後の仕事が自分自身への引導になるというのは、なかなか皮肉な話です。
同じ症状で困っている方の参考になれば幸いです。
Discussion