AIに環境構築を任せたら偽のnpxが生成され、盛大にハマった (WSL環境)
はじめに
Amazon Q Developer CLI に環境構築を丸投げした結果、偽のnpxスクリプトが生成され、謎現象として跳ね返ってきました。
WSL 環境で作業を行っている際に、この問題に直面しました。
最終的に根本原因を突き止めることができたので、記事にします。
この記事でわかること
- WSL 環境での MCP サーバーに問題が発生する状態について
- ディレクトリによって npx コマンドの動作が変わる現象の原因
- AI エージェントを過信した被害実例
- 初心者の失敗あるある
作業環境
- OS: Windows 11
- WSL2: Ubuntu
発生した事象
起きた現象は 「Amazon Q Developer CLI を起動するディレクトリによって、 MCP サーバーが使えたり使えなくなったりする」 です。
CLI ツールを起動する場所を変えるだけでこんなことが起きるのは変じゃないですか？
問題の始まり
Next.js プロジェクトの開発にて Amazon Q Developer を使っていました。
MCP サーバーも利用して、技術調査や実装を自動化していて、とても快適でした。
ところが、プロジェクトを別のディレクトリに移動した途端...
- 元の場所で Amazon Q Developer CLI を起動 → すべてのMCPが利用可能
- 違う場所で Amazon Q Developer CLI を起動 → 一部のMCPが起動しない
- 元の場所で Amazon Q Developer CLI を戻す → すべてのMCPが利用可能
WSL 環境内で
/mnt/c/Users/<user>/<project> で Q Developer CLI を実行すると MCP が利用可能に。
/home/<user>/<project> で Q Developer CLI 起動すると MCP が利用不可に。
ただただ CLI ツールの起動場所が違うだけ。なにこれ？
利用していた MCP サーバー
利用していた MCP サーバーは以下の 5 つです。
すべてが利用できなくなったわけではなく、fetch のみは起動していました。
- fetch
- deepwiki
- brave-search
- Context7
- sequential-thinking
調査と原因特定
ディレクトリの違い
2 つの場所で何が違うのかを確認しました。
# 動作する場所 (Windows のユーザーフォルダ内)
/mnt/c/Users/<user>/<project>
# 動作しない場所 (WSL 内の Linux ファイルシステム)
/home/<user>/<project>
明確な違いはありますが、よくわかりません。
実行されるプログラムを確認
結果はどちらも同じでした。プログラムには変わりはないです。
# 実行される npx プログラム
which npx
/home/<user>/.local/bin/npx
手がかりを発見
その他にも様々なコマンドを実行していましたがよく分からず。
たまたま Linux ファイルシステムのディレクトリでバージョン確認のコマンドを実行したときに、変な出力が表示されることに気づきました。
$ npx --version
'\\wsl.localhost\Ubuntu\home\<user>\<project>'
10.9.2
npx --versionって、普通はバージョン番号だけ表示するはず。
この意味不明な文字列が一緒に出てくるのは明らかに異常です。
原因を特定
この異常な出力の原因を調べてみました。
# 実際に実行されている npx
$ which npx
/home/<user>/.local/bin/npx
# ファイルの中身は・・・
$ cat /home/<user>/.local/bin/npx
#!/bin/bash
cmd.exe /c "npx $*"
なんと /home/<user>/.local/bin/npxは、偽物の npx でした。
Windows 側の npx を呼び出すだけのラッパースクリプトだったのです。
問題のメカニズム
MCP プロトコル通信障害
偽の npx が変な文字列を出力することで、会話が壊れてしまっていたようです。
- Amazon Q が MCP サーバー(npx 経由)を起動
- 偽の npx が Windows 側 npx を呼び出し
- WSL の Linux パスを Windows 側で解釈する際にパス変換エラーが発生(?)
- 異常なパス文字列（
\\wsl.localhost\Ubuntu\...）が stderr に出力 - JSON-RPC プロトコルの解析が失敗
- 通信確立に失敗し、MCP サーバーが「ロード失敗」
一部の MCP サーバーだけ動いた理由は？
fetch は Python (uvx)を使うので、npx の問題に巻き込まれていませんでした。
その他は npx 経由で、異常出力の影響をモロに受けました。
なぜ場所によって動作が変わったのか？
Windows ファイルシステム（/mnt/c/）から起動した場合
- 正常な npm 設定が読み込まれる
- Windows 側の npm/npx が正常に動作
- 変な出力が発生しない
Linux ファイルシステム（/home/）から起動した場合
- 偽の npx ラッパーが実行される
- パス変換エラーで変な出力が発生
- MCP プロトコル通信が破綻
解決方法
偽物の npx を削除
Node.js はすでにインストールしていたので、偽の npx を削除しました。
rm /home/<name>/.local/bin/npx
削除後の確認
正しい npx が参照されていることを確認します。
# 本物の npx を確認
$ which npx
/home/<user>/.nvm/versions/node/v22.18.0/bin/npx
# 異常出力の消失を確認
$ npx --version
10.9.3
この修正により、すべての MCP サーバーが正常にロードされることも確認できました。
根本原因
そもそもなぜ偽の npx が存在したのか？
偽の npx が存在した理由については、Amazon Q Developer 導入時に問題がありました。
問題の発生経緯
- Amazon Q Developer CLI 導入時に Next.js プロジェクトの開発を行っていた
- もともとは Windows で開発を進めていたので、 WSL 環境で npm コマンドが実行できなかった
- コマンド実行を trust にして AI エージェントに解決をすべて任せた
- Windows 側 npm/npx へのシンボリックリンク・ラッパースクリプトが作成された
- npm コマンドが実行できるようになったが、根本的な解決ではなかった
問題が発生するまでは、なんかいい感じにやってくれたんだなと思っていました。
すべてを丸投げするのは危険だと認識させられました。
今回の問題にたどり着くまでの経緯
実は一発でこの問題が起きたわけではなく、段階的に問題が発生していました。
- Amazon Q Developer 導入時に npm ラッパースクリプトが作成される
- fetchMCP の内部で実行される npm install が失敗して利用できない問題が発生
- 解消のために WSL 環境内に Node.js をインストール
- Node.js のパフォーマンス問題が発生 (WindowsファイルシステムへのI/O負荷増)
- WSL 環境内にプロジェクトを移動
- 今回の MCP サーバーが起動できない問題が発生
まとめ
長くなりましたが、「場所を変えただけで動かなくなる」という現象の正体は、偽の npx による MCP プロトコル通信障害でした。 仕組み自体理解していなかったことと、AI ツールの過信によりなかなかにハマりました。
原因調査も AI を利用しましたが、常にコマンドを監視しながら。いい勉強になりました。
Discussion