Windowsのnpmが使えない?まず確認したい原因と直し方

2026年10月6日

この記事は、Windowsでnpmを使おうとして「コマンドが認識されない」「npm.ps1を読み込めない」「npm installが失敗する」といった問題に遭遇した人向けです。
npmの導入方法から、PATH、PowerShellの設定、プロジェクト内のエラーまで、症状ごとに確認する順番を解説します。
まずは表示されたエラーを確認し、当てはまる項目から試してください。

windows npmが使えない？まずはエラーと実行環境を確認

Windowsでnpmが使えないときは、すぐに再インストールするより、どのコマンドをどのターミナルで実行し、何と表示されたかを確認するほうが近道です。
npmは通常、Node.jsと一緒に導入されますが、未導入、PATHの問題、PowerShellの実行ポリシーなど、原因によって対処法が異なります。
まずnode --versionとnpm --versionを実行し、それぞれの結果を控えましょう。
片方だけ失敗する場合も、切り分けに役立ちます。

「Npmコマンドが認識されない」など、表示されたエラーを確認する

「npmは認識されていません」と表示されるなら、Node.jsが未導入か、npmのある場所がPATHに登録されていない可能性があります。
一方、「npm.ps1を読み込めない」はPowerShellの実行ポリシー、「ENOENT」は作業場所やファイル、「EPERM」はファイルの使用状況や権限を疑います。
同じ「使えない」でも対策は別です。
エラーの最初の一行だけでなく、エラーコード、対象のファイル名、実行したコマンドを含む全文を残しておきましょう。

• コマンドが見つからない：導入状況とPATHを確認
• npm.ps1を読み込めない：PowerShellの設定を確認
• npm install中の失敗：エラーコードと作業場所を確認

PowerShell・コマンドプロンプト・Git Bashのどのターミナルで実行したか調べる

Windows TerminalやVS Codeのターミナルを使っていても、内部で動いているシェルはPowerShell、コマンドプロンプト、Git Bashなどに分かれます。
特にPowerShellだけでnpm.ps1のエラーが出る場合、npmそのものが壊れているとは限りません。
同じnpm --versionを別のターミナルでも試し、結果を比べてください。
シェルによって環境変数の反映状況やコマンドの書き方も異なるため、手順を試す前に現在のシェルを確認しましょう。

ターミナル	確認時のポイント
PowerShell	npm.ps1の実行ポリシーエラーに注意
コマンドプロンプト	npm.cmdで動くかを切り分けやすい
Git Bash	パス表記やシェル固有の設定の違いに注意

macOS・Linux（Ubuntu）向けのコマンドライン手順と混同していないか確認する

検索で見つけた手順がmacOSやUbuntu向けの場合、brewやaptなどのコマンドを通常のWindows環境にそのまま入力しても使えません。
また、環境変数の指定方法やパスの区切り方もシェルごとに異なります。
たとえばWindowsでNode.jsを導入するなら、公式インストーラーやwingetが選択肢です。
WSL上のUbuntuを使っている場合は逆に、Windows側へ入れたNode.jsとWSL側のNode.jsを区別し、実際にコマンドを打つ環境に合わせて導入してください。

Node.jsが未導入ならnpmをWindowsにインストールする方法

node --versionとnpm --versionの両方が認識されず、まだNode.jsを入れていないなら、最初にNode.jsをインストールします。
npmは通常、Node.jsの公式インストーラーや一般的なNode.jsの配布方法に含まれるため、npmだけを別途探す必要はありません。
導入方法は、画面を見ながら進める公式インストーラーと、コマンドで入れるwingetが代表的です。
どちらか一方を選び、導入後に新しいターミナルでバージョンを確認しましょう。

方法	向いている人
公式インストーラー	画面で設定を確認しながら導入したい人
winget	コマンドで導入・更新したい人

公式サイトで最新のLTSバージョンを選択し、インストーラーをクリックする

ブラウザーでNode.jsの公式サイトを開き、Windows向けダウンロードページからLTSと表示されたバージョンを選びます。
LTSは長期サポート版で、特定の新機能が必要な場合を除き、初めて導入する人が選びやすい選択肢です。
Windows Installerをクリックして、自分のPCに合うインストーラーを取得してください。
検索結果にある古い配布ページや、出所が分からないサイトからダウンロードするのは避けます。
会社のPCでは、インストール前に社内ルールも確認しましょう。

インストーラでインストール先とPATH追加を確認し、導入を完了する

ダウンロードしたインストーラーを起動し、表示される内容を確認しながら進めます。
通常は初期設定で進められますが、インストール先と、Node.jsをPATHに追加する設定は確認しておきましょう。
PATHに登録されると、特定のフォルダーに移動しなくてもnodeやnpmを実行できます。
組織のPCでは管理者権限が必要になる場合があります。
完了後、インストール前から開いていたターミナルは閉じ、新しく開いて動作を確かめてください。

winget install OpenJS.NodeJS.LTSでインストールする手順

wingetが利用できるWindowsなら、PowerShellまたはコマンドプロンプトを開き、winget install OpenJS.NodeJS.LTSを実行します。
表示されたインストール内容や確認画面を読み、必要に応じて同意して完了を待ってください。
この方法でも、通常はnpmを含むNode.jsが導入されます。
「wingetが認識されない」と出る場合は、公式インストーラーを使う方法に切り替えましょう。
導入後はターミナルを開き直し、インストールの成功表示だけで判断せず、実際にコマンドが動くかを確認します。

ターミナルを開き直し、node –versionとnpm –versionを入力する

インストールが終わったら、開いていたターミナルやVS Codeのターミナルを閉じ、新しいウィンドウでnode --versionとnpm --versionを順番に実行します。
両方ともバージョン番号が表示されれば、基本的な導入は完了です。
nodeは動くのにnpmだけ失敗する場合は、表示されたエラーを読み、PATHかPowerShellの項目へ進みます。
古いターミナルでは導入前の環境変数が残ることがあるため、開き直してから判断することが重要です。

npmが認識されないならpath（PATH）の設定を見直す

Node.jsを導入済みなのに「npmが認識されない」と出る場合は、Windowsが実行ファイルを探すためのPATHを確認します。
ただし、最初から環境変数を書き換えるのではなく、実際にどのnodeとnpmが見つかっているかを調べましょう。
Node.js本体のコマンドが使えない場合と、グローバルに入れたツールだけが使えない場合では、確認するフォルダーが異なります。
変更する際は既存のPATHを消さず、必要な項目だけを修正してください。

where.exe nodeとwhere.exe npmで実行ファイルの場所を確認する

PowerShellまたはコマンドプロンプトでwhere.exe nodeとwhere.exe npmを実行します。
見つかった場所が行ごとに表示され、複数あれば候補も確認できます。
PowerShellではwhereが別の意味で扱われるため、明示的にwhere.exeを使うと混同を避けられます。
何も見つからないなら導入先とPATHを確認し、古いNode.jsの場所が先に出るなら優先順位を疑いましょう。
結果は後で比較できるよう、変更前に控えておくと安心です。

システム環境変数・ユーザー環境変数にNode.jsのインストール先があるか調べる

Windowsの「環境変数を編集」画面を開き、ユーザー環境変数とシステム環境変数の両方にあるPathを確認します。
公式インストーラーを標準的な場所に導入した場合、Node.jsのフォルダーはC:\Program Files\nodejs\などです。
実際の導入先は環境によって異なるため、where.exeの結果やインストール時の設定と照らし合わせてください。
重複や古いパスにも注意し、編集前には既存の値を控えます。
関係のない項目まで削除すると、ほかのアプリにも影響します。

グローバルに入れたツールだけ使えない場合は%AppData%\npmを確認する

nodeとnpmは動くのに、npm install -gで導入したコマンドだけが認識されない場合は、Node.js本体とは別のPATHを確認します。
標準的な設定では、グローバルパッケージのコマンドが%AppData%\npmに置かれます。
npm config get prefixで実際の保存先を確認し、その場所がPATHに含まれているかを調べてください。
prefixを変更している環境では保存先も変わります。
npm本体の不具合と決めつけず、対象のコマンドがどこへ入ったかを先に確かめましょう。

PATHを修正したらターミナルを開き直して再実行する

PATHの変更は、すでに開いているPowerShellやコマンドプロンプトにはすぐ反映されないことがあります。
編集を保存したらターミナルを閉じ、VS Codeの内蔵ターミナルを使っている場合はVS Code自体も起動し直してから確認しましょう。
新しい画面でwhere.exe node、where.exe npm、npm --versionを実行し、意図した場所が使われているかを比べます。
改善しなければ、PATHの入力ミスや複数のNode.jsが共存していないかを確認してください。

powershell.exe（PowerShell）でセキュリティエラーが出るときの直し方

PowerShellで「npm.ps1を読み込めない」「スクリプトの実行が無効」と表示される場合、npmが見つからない問題とは切り分けて考えます。
PowerShellがnpm.ps1を実行しようとして、実行ポリシーによって止められている可能性があるためです。
まずは設定を変更せずにnpm.cmdが動くかを試し、必要な場合だけポリシー変更を検討しましょう。
会社や学校の管理端末では、セキュリティ設定を自分の判断で変えないことが大切です。

「npm.ps1を読み込めない」は実行ポリシーが原因か確認する

PowerShellでnpm --versionを実行したとき、npm.ps1に関するセキュリティエラーが出るなら、実行ポリシーを確認します。
Get-ExecutionPolicy -Listを実行すると、適用範囲ごとの設定を一覧できます。
ただし、エラーが「コマンドが認識されない」なら、先にNode.jsの導入状況やPATHを確認してください。
実行ポリシーはスクリプトの実行条件に関する設定であり、すべてのセキュリティ対策の代わりになるものではありません。
表示されたエラーに合わせて対処を選びましょう。

設定を変えずに試すならnpm.cmdを実行する

PowerShellの設定を変更したくない場合は、npm --versionの代わりにnpm.cmd --versionを実行します。
Windowsに導入されたnpmには通常、コマンドプロンプト向けのnpm.cmdが含まれ、PowerShellからも明示して呼び出せます。
これで動くなら、Node.jsやnpmの導入自体は成功しており、npm.ps1の実行が問題だと切り分けられます。
npm.cmd installのように続けて使う方法や、コマンドプロンプトに切り替える方法もあります。

変更が必要ならCurrentUserのRemoteSignedを選択し、適用範囲を限定する

PowerShellから通常のnpmコマンドを使う必要があり、自分のPCで設定変更が許可されているなら、Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSignedを検討します。
CurrentUserは現在のユーザーに適用範囲を限定する指定です。
RemoteSignedの意味を確認し、変更後にGet-ExecutionPolicy -Listとnpm --versionで結果を確かめましょう。
安易に全ユーザー対象の設定へ変えたり、制限を広く緩めたりする必要はありません。

会社の管理環境ではポリシーを無断変更せず管理者に相談する

会社や学校の端末では、実行ポリシーが管理者によって設定されている場合があります。
Get-ExecutionPolicy -ListでMachinePolicyやUserPolicyに設定が表示されるなら、自分で変更した設定より組織のポリシーが優先されることがあります。
エラーを避けるために無断で設定を変えず、npm.cmdが利用できるかを確認したうえで管理者に相談してください。
相談時にはエラー全文、利用中のターミナル、実行したコマンドを伝えると状況を共有しやすくなります。

npm installが失敗する場合はpackageと作業ディレクトリを確認

npm --versionは表示されるのにnpm installが失敗するなら、npmの導入ではなく、作業中のプロジェクトやインストール対象を確認します。
まず、現在いるフォルダーが正しいか、その場所にpackage.jsonがあるかを調べましょう。
続いてエラーコードから、通信、アクセス権限、キャッシュ、使用中のファイルなどを切り分けます。
エラーが異なるのに一律で再インストールを繰り返すと、原因を見失いやすくなります。

package.jsonのあるプロジェクトへ移動してnpm installを実行する

既存のプロジェクトの依存パッケージを入れるときは、package.jsonがあるフォルダーへ移動してからnpm installを実行します。
PowerShellならGet-Locationで現在地を、dirでフォルダー内のファイルを確認できます。
別の場所で実行すると、想定したプロジェクトへインストールできないなどの混乱につながります。
READMEに専用のセットアップ手順がある場合は、それも確認してください。
ロックファイルがある既存プロジェクトでは、指定された導入方法を優先しましょう。

package.jsonがない場合はnpm init -yで作成してから開始する

新しく自分でNode.jsのプロジェクトを始めるなら、作業用フォルダーを作成して移動し、npm init -yを実行します。
既定値を使ったpackage.jsonが作成され、以後はnpm install パッケージ名で必要なパッケージを追加できます。
ただし、既存プロジェクトでpackage.jsonが見つからない場合は、すぐに新規作成しないでください。
単に違うフォルダーにいる可能性があります。
先にプロジェクトの構成と作業場所を確認することが大切です。

通信・権限・キャッシュのどれがエラーの原因か切り分ける

インストール中のエラーは、コードと周辺のメッセージを一緒に読みます。
ネットワーク関連のエラーなら接続やプロキシ設定、EACCESやEPERMなら対象フォルダーへのアクセスやファイルの使用状況を確認してください。
キャッシュを疑う場合も、最初から削除せず、npm cache verifyで状態を検証できます。
通信が必要な処理では、オフライン環境も確認しましょう。
表示されたエラー全文を残しておけば、対処後に同じ原因で失敗しているか判断できます。

主な症状	最初に確認すること
通信エラー	接続状況、プロキシ、接続先
EACCES・EPERM	権限、ファイルを使用中のアプリ
キャッシュ関連の疑い	npm cache verifyの結果

EPERMでファイルを削除できないときは使用中のツールを閉じる

EPERMとともにファイルの削除や変更に失敗したと表示されたら、まず対象ファイルを使っているプロセスがないか確認します。
開発サーバー、テストツール、エディター、別のターミナルなどを終了し、同じ操作を再試行してください。
同期ソフトやセキュリティソフトの影響が疑われる場合もありますが、安全性を確認せずに無効化するのは避けます。
管理者権限での実行を最初の手段にせず、エラーに記載されたパスと使用状況を調べることから始めましょう。

導入後のバージョン不一致は更新・切り替えで対処する

npmが起動しても、プロジェクトが要求するNode.jsより古いバージョンを使っていると、インストール時に警告やエラーが出ることがあります。
まず現在のNode.jsとnpmのバージョン、プロジェクト側の指定を比べましょう。
必要に応じて公式インストーラーやwingetで更新し、複数の案件で異なるバージョンを使うなら管理ツールを検討します。
更新しても古い版が表示される場合は、複数のNode.jsが共存していないかPATHも確認してください。

node –versionとnpm –versionで現在のバージョンを確認する

node --versionとnpm --versionを実行し、表示された番号を控えます。
そのうえで、プロジェクトのREADMEやpackage.jsonのenginesなどに、必要なNode.jsのバージョン指定がないか確認してください。
npmのバージョンだけを見てNode.jsも新しいと判断することはできません。
インストール時にEBADENGINEが出た場合も、要求されるバージョンと現在値を比較します。
まず条件を把握し、必要な範囲で更新するのが確実です。

winget upgradeまたは公式インストーラでNode.jsを更新する

wingetでLTS版を導入した場合は、winget upgrade OpenJS.NodeJS.LTSで更新を確認できます。
公式インストーラーを使う場合は、Node.jsの公式サイトから必要な版のインストーラーを入手し、画面の案内に従って更新してください。
更新前にはプロジェクトが対応するバージョンを確認し、作業中のファイルも保存します。
完了後はターミナルを開き直してnode --versionとnpm --versionを再実行し、想定した版になったか確かめましょう。

Node Version Manager（nvm-windows）で複数のバージョンを管理する

プロジェクトごとに異なるNode.jsが必要なら、Windows向けのバージョン管理ツールであるnvm-windowsが選択肢です。
導入後は必要な版をインストールし、利用する版を切り替えてからnode --versionで確認します。
nvm-windowsはmacOSやLinuxで使われるnvmとは別のツールなので、手順を混同しないでください。
既存のNode.jsインストーラーと併用するとPATHが競合する場合があります。
現在の導入方法を確認し、公式の案内に沿って移行することが大切です。

複数のNode.jsが共存する場合はPATHの優先順位を見直す

Node.jsを更新したのに古い版が表示される場合は、PATH上で別のNode.jsが先に見つかっている可能性があります。
where.exe nodeとwhere.exe npmを実行し、複数の場所が表示されないか確認してください。
公式インストーラー、nvm-windows、ほかの開発環境がそれぞれNode.jsを持っている場合もあります。
どの版を使うか決めたうえで、不要になった導入方法や古いPATHを整理します。
変更後はターミナルを開き直し、場所とバージョンの両方を再確認しましょう。

Windowsでnpmが使えるようになったか最終確認

エラーへの対処後は、バージョン番号が表示されるだけで終わらせず、実際のプロジェクト操作まで試しましょう。
新しい検証用フォルダーでnpm init -yを実行し、必要に応じて小さなパッケージをインストールすると、作成と通信を伴う処理を確認できます。
さらにターミナルを開き直して同じコマンドを実行し、設定が継続しているかを確かめてください。
解決しない場合は、エラー全文と環境情報を整理すると、次に相談しやすくなります。

検証用プロジェクトでnpm init -yとnpm installを試す

既存プロジェクトを変更したくない場合は、空の検証用フォルダーを作り、そこへ移動してnpm init -yを実行します。
続けて、試したいパッケージを指定してnpm install パッケージ名を実行すると、取得とインストールまで確認できます。
パッケージを指定しないnpm installは、package.jsonに記載された依存関係を入れる操作です。
作成直後で依存関係がなければ、通信を伴う導入の検証にはなりません。
確認後、不要な検証用フォルダーは削除できます。

新しいコマンドラインを開いても同じエラーが再発しないか確認する

一度動いたら、ターミナルを閉じて新しく開き、node --version、npm --version、必要なインストール操作をもう一度試します。
PowerShellで直した場合はPowerShellで、コマンドプロンプトだけで確認していた場合は普段使うターミナルでも試してください。
VS Codeの内蔵ターミナルを使うなら、VS Codeを再起動した状態でも確認します。
新しい画面だけで再発するなら、一時的な設定で動いていなかったか、PATHや実行ポリシーの適用範囲を見直しましょう。

解決しない場合はエラー全文と環境情報を整理する

ここまで試しても解決しなければ、質問先に状況が伝わるよう情報をまとめます。
Windowsのバージョン、利用したターミナル、実行したコマンド、node --versionとnpm --versionの結果、where.exe nodeとwhere.exe npmの結果、エラー全文が基本です。
npm installの問題なら、作業フォルダーにpackage.jsonがあるかも添えます。
ログを共有する前に、ユーザー名、認証情報、社内の接続先などの機密情報が含まれていないか確認してください。