Claude DesktopとNVMは相性が悪い？原因と解決策を徹底解説

「Claude DesktopにMCPサーバーを設定したのに、nodeが見つからないエラーが出る」

こんな経験をしたことはないでしょうか。nvmでNode.jsを管理している環境では、Claude Desktopとの間に厄介な問題が発生することが知られています。この記事では、その根本的な原因と実際に動く解決策を丁寧に解説します。

なぜClaude DesktopでNVMが使えないのか

GUIアプリはシェルの設定を読み込まない

問題の核心は、macOSにおけるGUIアプリとシェル環境の分離にあります。

ターミナルを開いたとき、macOSは ~/.zshrc や ~/.bashrc などの設定ファイルを自動的に読み込みます。nvmはまさにこの仕組みに依存しており、これらのファイルに以下のような初期化コードを追記して PATH を動的に書き換えます。

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

ところが、Claude DesktopはDockやFinderから起動されるGUIアプリケーションです。GUIアプリはログインシェルとして起動されないため、~/.zshrc の内容が読み込まれません。その結果、nvmが設定した PATH がClaude Desktopには引き継がれず、node や npx コマンドを見つけられない状態になります。

macOSのアプリケーションサンドボックスも影響

さらに、macOSのセキュリティ機構もこの問題を複雑にしています。GUIアプリはシステムレベルの最小限の PATH（/usr/bin、/bin など）しか継承しないよう制限されているため、ユーザーが自分でカスタマイズした環境変数の恩恵を受けられません。

よく見るエラーメッセージ

Error: spawn node ENOENT
command not found: node
Claude Code requires Node.js version 18 or higher to be installed

これらはすべて「Claude DesktopがNodeを見つけられない」ことを示すエラーです。ターミナルで node -v を実行すると正常に動作するにもかかわらず、このエラーが出る場合は、ほぼ確実にnvmとGUIアプリの相性問題が原因です。

「npxフルパス指定」では解決しない理由

一見すると、npx のフルパスを指定すれば解決しそうに思えます。しかし、これは根本的な解決になりません。

npxのフルパスを指定
  └→ npxが内部でさらにnodeやパッケージを探し始める
       └→ この「内部の探索」でまた迷子になる ← ここが盲点

npxはあくまでパッケージを「探して実行する」ラッパーです。npx自身が見つかっても、その内部で行われる探索が失敗すればエラーになります。これが「npxのフルパスを指定したのに動かない」という現象の正体です。

本当に確実な解決策：nodeフルパス ＋ 実体ファイルを直接叩く

最も確実な方法は、nodeのフルパスで、実体ファイルを直接指定することです。

nodeのフルパス + ファイルの実体
  └→ 「この場所にあるこのファイルを動かせ」と直接命令
       └→ 内部での探索が一切発生しない ← だから確実

この方法が確実な理由は2つあります。

• OSの影響を受けない：macOSがPATHを知らなくても、住所（フルパス）を直接教えているのでClaude Desktopが迷いません。
• nvmに依存しない：nvmが裏で何をしていても、特定の場所にあるnode本体を直接叩くのでブラックボックス化しません。

実践手順

STEP 1：nodeのフルパスを確認する

which node
# 例: /Users/yourname/.nvm/versions/node/v20.18.2/bin/node

STEP 2：MCPサーバーの実体ファイルを用意する

自作MCPの場合は手元にファイルがあるのでそのまま使えます。

外部MCP（Filesystemなど）の場合は、npxが都度ダウンロードする前提で設計されているため、実体ファイルが手元にありません。そこで npm install -g で一度グローバルインストールして実体を作ります。

# nodeのフルパスでnpmを叩いてインストール
/Users/yourname/.nvm/versions/node/v20.18.2/bin/npm install -g @modelcontextprotocol/server-filesystem

インストール後、実体ファイルの場所は以下で確認できます。

/Users/yourname/.nvm/versions/node/v20.18.2/bin/npm list -g --depth=0
# → /Users/yourname/.nvm/versions/node/v20.18.2/lib/node_modules/
#   └── @modelcontextprotocol/server-filesystem

STEP 3：すべてのMCPを同じ形式でconfig.jsonに書く

自作MCPも外部MCPも、同じルール（nodeフルパス ＋ 実体ファイル） で統一します。

{
  "mcpServers": {
    "自作MCP": {
      "command": "/Users/yourname/.nvm/versions/node/v20.18.2/bin/node",
      "args": ["/Users/yourname/path/to/your-mcp/index.js"]
    },
    "filesystem": {
      "command": "/Users/yourname/.nvm/versions/node/v20.18.2/bin/node",
      "args": [
        "/Users/yourname/.nvm/versions/node/v20.18.2/lib/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js",
        "/Users/yourname/Documents",
        "/Users/yourname/Downloads"
      ]
    }
  }
}

この構成の強みはすべてのMCPが同じルールで動く透明性の高さにあります。1つのMCPが別の方式になっていると、それが原因で他のMCPまで巻き込まれてエラーになるケースがあります。形式を統一することで、問題の切り分けも格段に楽になります。

各解決策の比較

どの方法が正解かは環境や構成によって異なります。「動かない理由がどこにあるか」を起点に、自分の状況に合った方法を選ぶのがポイントです。

デバッグのヒント：ログを確認する

設定しても動かない場合は、Claude Desktopのログファイルを確認してみましょう。

# macOSの場合
tail -f ~/Library/Logs/Claude/mcp.log

エラーメッセージを確認することで、問題の原因をより正確に特定できます。また、Claude Desktopの終了は必ずCmd+Qで完全終了してください。ウィンドウを閉じるだけではプロセスが残り、設定変更が反映されないことがあります。

まとめ

Claude DesktopとNVMの相性問題は、GUIアプリがシェルの設定を読み込まないというmacOSの仕組みに起因しています。

一見シンプルに見える「npxのフルパス指定」や「~/.zshenv への追記」では、npxの内部探索という「もう一段階の問題」が残ります。環境や構成によって有効な手段は異なりますが、「どこで迷子になっているか」を意識すると解決策が見えてきます。

• 複数のMCPが混在していて原因が特定しにくい → nodeフルパス＋実体ファイルで統一すると切り分けが楽になります
• シンプルな構成で手早く解決したい → ~/.zshenv への追記から試してみるのも有効です
• Node環境ごと整理したい → voltaやfnmへの乗り換えで根本から解消できます

大切なのは「なぜ動かないか」の構造を理解した上で、自分の環境に合った方法を選ぶことです。