Antigravity の MCP サーバーが spawn npx ENOENT で起動しないときの原因と対処

Antigravity の設定で MCP サーバーを追加した直後、エージェントのログに spawn npx ENOENT と一行だけ出てサーバーが灰色のまま立ち上がらない——。私が Figma MCP と Stripe MCP を手元の開発環境へ組み込もうとしたとき、最初にぶつかったのがこの壁でした。設定ファイルの JSON は何度見直しても正しいのに、サーバーだけが起動しません。

先に結論を書きます。この ENOENT はほとんどの場合 MCP サーバー側の不具合ではなく、Antigravity（GUI アプリ）が npx の在りかを見つけられていない という PATH の問題です。同じコマンドをターミナルで叩くと素直に動くのに、GUI から起動すると失敗する。この非対称こそが、問題の正体を物語っています。

2014年から個人開発を続けてきて、ローカルツールと GUI アプリの PATH の食い違いには何度も悩まされてきました。Dolice Labs の4サイトを回す中でも MCP まわりの初期設定でつまずく場面が多かったので、私自身の切り分け手順を整理しておきます。

まず症状を正しく読み取る

ENOENT は "Error NO ENTry" の略で、OS が「指定された実行ファイルが見つからない」と返したときのコードです。MCP の文脈では、Antigravity が設定の command に書かれたプログラム（多くは npx）を起動しようとして、その実体を解決できなかったことを意味します。

ログには次のような行が出ます。

[MCP] failed to start server "figma": spawn npx ENOENT
[MCP] server "stripe" exited with error: spawn npx ENOENT

ここで大事なのは、ENOENT は「npx というコマンド自体が無い」ではなく「今のプロセスの PATH からは見つけられない」を意味する点です。npm install -g で入れたパッケージが壊れている、といった方向に調査を広げる前に、PATH を疑うのが近道になります。

なぜターミナルでは動くのに GUI からは失敗するのか

macOS で Dock や Spotlight からアプリを起動すると、そのアプリは launchd 経由で立ち上がります。このとき読み込まれる環境は、ログインシェルの ~/.zshrc や ~/.bashrc とは別物です。つまり、これらの設定ファイルで PATH に追記した nvm・Homebrew・asdf 配下の node や npx は、GUI から起動した Antigravity のプロセスには引き継がれません。

特に nvm を使っている場合、npx の実体は ~/.nvm/versions/node/v20.x/bin/ のような深い場所にあります。ターミナルではシェルがこのパスを通してくれるので動きますが、launchd から起動したアプリの PATH は /usr/bin:/bin:/usr/sbin:/sbin 程度しか持っておらず、npx を見つけられません。これが spawn npx ENOENT の最頻出パターンです。

切り分け: npx の実体パスを確認する

直す前に、自分の環境で npx がどこにあるかを確定させます。ターミナルで次を実行してください。

# npx の実体パスをすべて表示
which -a npx
 
# node 本体の場所も確認
command -v node
 
# 現在のシェルが持っている PATH
echo "$PATH"

which -a npx が /Users/you/.nvm/versions/node/v20.11.0/bin/npx のようにホームディレクトリ配下を指していたら、ほぼ確定です。GUI アプリにはこのパスが見えていません。逆に /usr/local/bin/npx や /opt/homebrew/bin/npx のように標準的な場所を指していれば、別の原因（後述の Windows 系や typo）を疑います。

解決策1: command を絶対パスにする

最も確実なのは、設定の command を npx ではなく実体の絶対パスに置き換える方法です。which -a npx で得たパスをそのまま貼り付けます。

{
  "mcpServers": {
    "figma": {
      "command": "/Users/you/.nvm/versions/node/v20.11.0/bin/npx",
      "args": ["-y", "figma-developer-mcp", "--stdio"]
    }
  }
}

この方法は一発で通りますが、node のバージョンを上げるとパスが変わって再び壊れる弱点があります。私は検証用にはこれを使い、長く使うサーバーには次の解決策2か3を選んでいます。

解決策2: env で PATH を補う

command は npx のままにして、env で node の bin ディレクトリを PATH に足す方法です。サーバー定義ごとに環境を閉じられるので見通しが良くなります。

{
  "mcpServers": {
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp", "--tools=all"],
      "env": {
        "PATH": "/Users/you/.nvm/versions/node/v20.11.0/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

注意点として、env の PATH は既存の PATH を上書きします。/usr/bin や /bin を書き忘れると、今度は sh などの基本コマンドが見つからなくなって別のエラーに化けます。node の bin を先頭に置きつつ、標準ディレクトリも必ず併記してください。

解決策3: ラッパースクリプトで環境を固定する

node のバージョンを上げてもパスを書き換えなくて済むようにしたい場合は、薄いラッパースクリプトを挟むのが実用的です。スクリプト内で nvm を読み込んでから npx を exec します。

#!/usr/bin/env bash
# ~/bin/mcp-npx.sh
# nvm を読み込んでから npx を実行するラッパー
export NVM_DIR="$HOME/.nvm"
# shellcheck disable=SC1091
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
exec npx "$@"

実行権限を付けて（chmod +x ~/bin/mcp-npx.sh）、設定の command をこのスクリプトの絶対パスにします。

{
  "mcpServers": {
    "figma": {
      "command": "/Users/you/bin/mcp-npx.sh",
      "args": ["-y", "figma-developer-mcp", "--stdio"]
    }
  }
}

node を更新してもスクリプトが nvm の現在の既定バージョンを解決してくれるので、設定ファイルを触らずに済みます。複数の MCP サーバーを使い回す環境では、この方式が一番メンテナンスコストが低いと感じています。

解決策4: バージョン管理ツールを見直す

そもそも GUI アプリとの相性で言えば、nvm のようにシェル関数で PATH を動的に書き換える方式は GUI と噛み合いにくい面があります。GUI 中心の開発で MCP を多用するなら、node の実体が固定パスに置かれる Homebrew や Volta に寄せるのも一つの判断です。

# Homebrew で安定版 node を入れると /opt/homebrew/bin/node に固定される
brew install node
 
# Volta はシム経由で常に同じパスを公開する
curl https://get.volta.sh | bash
volta install node

固定パスに node と npx が置かれれば、GUI アプリが標準の PATH だけでも解決できる可能性が上がります。既存プロジェクトが nvm 前提なら無理に乗り換える必要はありませんが、新しく環境を組むなら検討の価値があります。

Windows と WSL での注意

Windows のネイティブ環境で spawn npx ENOENT が出る場合、原因が少し違います。Windows では npx は npx.cmd として配布されており、command に npx とだけ書くと拡張子を解決できずに失敗することがあります。command を npx.cmd にするか、cmd /c npx ... の形にすると通ります。

WSL を併用している場合は、Antigravity が Windows 側で動いているのか WSL 側で動いているのかで npx の場所が変わります。WSL 内の node を使いたいなら、サーバー起動を wsl npx ... で包むか、Antigravity 自体を WSL のリモート接続で開く構成にそろえてください。混在させると、どちらの PATH を見ているのか分からなくなって切り分けが難しくなります。

再発させないための運用

MCP の設定をリポジトリで共有するときは、絶対パスを直書きすると他のメンバーや別マシンで壊れます。ラッパースクリプト方式にして、スクリプト側で環境差を吸収する形にしておくと移植性が保てます。チーム開発であれば devcontainer に node の固定パスを焼き込み、その中で Antigravity を開く構成が安定します。

私の場合、Figma MCP・Stripe MCP・Google Workspace MCP を日常的に使い分けているので、すべて ~/bin/mcp-npx.sh 経由に統一してあります。node を上げるたびに設定を直す作業から解放されただけでも、導入の手間に見合う効果がありました。同じところでつまずいている方の時間が少しでも節約できれば嬉しいです。