Claude Code導入の落とし穴！Windows・WSL2・Dev Containerの環境の違いを理解して最強のAI作業環境を作る

最近、「Claude Codeを使って日常業務を爆速化する」という素晴らしい記事（Qiitaの参考記事）を読み、自分でもAIエージェントを活用した「プチ仕様駆動開発」の環境を構築してみることにしました。

しかし、いざターミナルから起動しようとしたところで、思わぬ環境構築の沼にハマってしまいました。今回は、私が躓いたポイントとその解決策、そして最終的に行き着いた「理想のClaude Code環境」について備忘録としてまとめます。

目指した理想の環境

記事を参考に、私が目指したのは以下のような環境です。

Claude Code ＋ターミナル：専用のディレクトリでAIに自律的な作業（ファイルの生成や整理）を任せる。
Cursor（エディタ）：生成されたファイルの確認や細かな微調整を行う。
仕様駆動のアプローチ：PLAN.md（音声入力などで思考をダンプ）、SPEC.md、TODO.mdなどを用いて、AIへの丸投げを防ぎアウトプットを安定させる。

これらを実践するため、早速WindowsマシンのPowerShellからWSL（Windows Subsystem for Linux）に入り、Claude Codeを起動しようとしました。

最初のつまずき：「command not found」と「node: not found」

WSL環境で claude コマンドを実行しようとしたところ、エラーが発生しました。

最初に遭遇したのは command not found。

そこでグローバルインストール（npm install -g @anthropic-ai/claude-code）を実行してみたものの、今度は以下のようなエラーが出ました。

Plaintext

/mnt/c/Users/ユーザー名/AppData/Roaming/npm/claude: 15: exec: node: not found

原因は「Windows側」の環境を参照していたこと

このエラー文の /mnt/c/... というパスが最大のヒントでした。

実は、WSL（Linux）側にNode.jsが正しくインストールされていなかったため、無意識にWindows側（Cドライブ）のnpmを参照してしまい、Linux上で実行できずに失敗していたのです。

独立したLinux環境であるWSL上で動かすためには、WSL内に専用のNode.js環境を構築する必要がありました。

解決策：nvmを使ってWSLにNode.jsをインストール

WSLのターミナルで、以下の手順でNode.js環境を整え直しました。

Bash

# 1. nvm（Node Version Manager）のインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

# 2. 設定の反映
source ~/.bashrc

# 3. Node.js（v20）のインストール
nvm install 20

# 4. Claude Codeの再インストール
npm install -g @anthropic-ai/claude-code

これでWSL上で無事に claude コマンドが通るようになりました！……しかし、物語には続きがありました。

最大の気づき：実は「Dev Container」の中にいた！

WSL本体での設定が完了した後、いつも開発に使っているAIエディタ「Cursor」のターミナルを開き、念のためClaude Codeがどこから呼び出されているか確認するコマンドを打ってみました。

Bash

which claude

すると、返ってきた結果は以下の通りでした。

Plaintext

/usr/local/share/npm-global/bin/claude

先ほどWSLにインストールしたパス（~/.nvm/...）とは全く別の場所です。プロンプトの作業ディレクトリも /workspace となっていました。

結論：Cursorは「Dev Container」に接続されていた

この表示は、**Dockerを利用した「Dev Container（開発コンテナ）」**環境で作業している際の典型的なパスです。

つまり、私の環境は以下の3層構造になっていました。

Windows（ベースOS）
WSL2（Windowsの中のLinux。先ほどNode.jsを入れた場所）
Dev Container（WSLの中、さらにDockerの中にある「プロジェクト専用の隔離された部屋」）👈 Cursorはここに繋がっていた！

実はすでに「最高・最強の環境」が完成していた

Dev Containerの中でコマンドが認識されているということは、**「プロジェクトごとに完全に隔離された安全なコンテナ内に、すでに正しくClaude Codeがインストールされていた」**ということです。

Dev Containerを利用すれば、他のプロジェクトとNode.jsのバージョンやツールが混ざって環境が壊れる心配がありません。

Cursorでプロジェクトを開く（Dev Containerが立ち上がる）
Cursor内のターミナルを開く（自動的にコンテナ内に接続される）
claude と打ち込む（コンテナ内のClaude Codeが起動する）

特別な設定や紐付け作業は一切不要で、すぐにターミナル上のClaude Codeに「PLAN.md を作って」と指示を出し、隣のタブ（Cursorのエディタ）でその結果をリアルタイムに確認・修正するという「二刀流」の作業環境が実現できていました。

まとめ

今回の環境構築を通じて、Windows、WSL2、そしてDev Containerの仕組みと「今自分がどこでコマンドを実行しているのか（パスの確認）」の重要性を改めて学びました。

これからClaude Codeを使って日々の雑務や開発タスクを自動化していくのが非常に楽しみです。環境構築で同じように迷っている方の参考になれば幸いです！