「npmでプロジェクトをビルドしたら、突然『15 vulnerabilities (3 high, 1 critical)』といった大量のセキュリティ警告が表示されて焦った」という経験はありませんか？
脆弱性を手軽に解消できるコマンドとしてよく紹介されるのが npm audit fix です。しかし、「とりあえず実行してよいのか」「--force オプションを付けると何が起きるのか」「実行したらエラーが出て動かなくなった」といった疑問やトラブルに直面する開発者も少なくありません。
結論から言うと、npm audit fix は依存ライブラリのセキュリティ脆弱性を、プログラムの互換性を壊さない安全な範囲（SemVerのパッチ・マイナー更新）で自動的に修正・インストールしてくれるコマンドです。
この記事では、npm audit fix と npm audit の違いなどの基礎知識をはじめ、以下の内容をわかりやすく解説します。
単にコマンドの意味を暗記するだけでなく、プロジェクトの依存関係を安全にコントロールしながらセキュリティ対策を施す実戦的なノウハウが身につきます。開発環境の安全性を高めるために、ぜひ最後まで参考にしてください。
ConoHa AI Canvas｜ブラウザだけでできる本格的なAI画像生成
npm audit fixとは？npm auditとの違いと基本の使い方
npm audit fixとは何をするコマンド？
npm audit fixは、プロジェクトの依存ライブラリ（node_modules）に含まれるセキュリティ脆弱性を、互換性を維持できる安全な範囲で自動的に修正（アップデート）するコマンドです。
JavaScript / Node.jsの開発環境では、多数のオープンソースパッケージを組み合わせてアプリケーションを構築します。その依存パッケージに既知のセキュリティホール（脆弱性）が発見された際、手動でひとつずつバージョンを調べて更新するのは手間がかかります。
npm audit fixを実行すると、npmは内部で既知の脆弱性データベース（GitHub Advisory Database等）を参照し、セマンティックバージョニング（SemVer）のマイナー更新およびパッチ更新の範囲内（例: ^1.2.3 の指定なら 1.x.x の最新まで）で、脆弱性が修正されたバージョンへ自動的に置き換えます。
注意: 単にテキストファイルを書き換えるだけでなく、パッケージのダウンロードと再インストール、および
package-lock.json（必要に応じてpackage.json）の更新までを一括で行います。
npm auditとnpm audit fixの違い
npm auditは脆弱性の「検出・レポート表示」を行うコマンドであり、npm audit fixはそれを「自動修正・更新」するコマンドです。
両者の主な違いは以下の通りです。
| 項目 | npm audit | npm audit fix |
|---|---|---|
| 主な役割 | 脆弱性の検出とレポート出力 | 互換性を保つ範囲での自動修正 |
| ファイル変更 | 発生しない（読み取りのみ） | 発生する（package-lock.jsonやnode_modules等を更新） |
| 実行タイミング | 状態の確認、CI/CDでの定期チェック時 | 検出された脆弱性をまとめて解消したい時 |
| 修正範囲 | なし | 安全と判断される範囲（SemVer内）のみ |
npm auditはプロジェクトの依存関係ツリーを解析し、どのパッケージにどんな危険度の脆弱性があるかを報告するだけなので、プロジェクトのコードやファイル構造を変更することはありません。
一方でnpm audit fixは、実際にパッケージのインストール処理を伴うため、実行後にファイル変更が発生します。まずはnpm auditで現状を把握してからnpm audit fixを適用するのが基本の流れです。
npm audit fixを実行する基本手順
npm audit fixを実行する際は、事前にGitなどのバージョン管理システムで変更をコミットしておき、実行後にテストを行うのが安全な基本手順です。
プロジェクトの作業ディレクトリでターミナルを開き、以下の手順で実行します。
1.作業ツリーのクリーン化（事前準備）
実行前にGitで未コミットの変更がない状態にしておきます。これにより、万が一意図しない変更が発生しても容易に元に戻せます。
2.現状の脆弱性を確認
まずは以下のコマンドで、プロジェクト内にどのような脆弱性が存在するかを確認します。
npm audit fix3.自動修正の実行
検出された脆弱性を安全な範囲で自動修正します。
npm audit fix 実行結果の例:
added 2 packages, removed 1 package, and changed 5 packages in 3s fixed 3 of 5 vulnerabilities in 1204 packages 2 vulnerabilities required manual review or a force update ※出力結果はプロジェクトの依存関係や脆弱性の状態によって異なります。
4.変更結果の確認とテスト
git diff や git status で変更されたファイルを確認し、アプリケーションが正常に動作するか（ビルドや自動テストが通るか）を検証します。
npm audit fixの使い方と–dry-runによる事前確認
npm auditで脆弱性を確認する
npm auditを実行すると、プロジェクト内の脆弱性の詳細（影響を受けるパッケージ、深刻度、修正可能なバージョン）を一覧で確認できます。
修正コマンドを実行する前に、まずは現状のプロジェクトが抱えるセキュリティリスクを正しく把握することが重要です。
実行コマンド
npm audit
実行結果の確認ポイント
コマンドを実行すると、以下のようなレポートが出力されます（※出力結果はプロジェクトの構成や脆弱性の状態により異なります）。
# npm audit report
lodash < 4.17.21
Severity: high
Prototype Pollution in lodash - <https://github.com/advisories/GHSA-xxxx-xxxx-xxxx>
fix available via `npm audit fix`
node_modules/lodash
1 high severity vulnerability
To address all issues, run:
npm audit fix
レポートで特にチェックすべき項目は以下の3点です。
- Severity（深刻度）:
low（低）、moderate（中）、high（高）、critical（緊急）の4段階で表示されます。 - Path / node_modules: どのパッケージ経由で持ち込まれた脆弱性かが表示されます。
- fix available via…:
npm audit fixで自動解決できるか、それとも手動更新（あるいは-force）が必要かが明記されます。
npm audit fixで脆弱性を自動修正する
npm audit fixを実行すると、互換性を壊さない安全なバージョン（SemVerのマイナー・パッチ更新）へパッケージが自動的に更新されます。
実行コマンド
npm audit fix
実行時に起こること
- 依存関係の解析: 脆弱性データベースと照合し、互換性を保ちながら更新できる対象を特定します。
- パッケージのダウンロードと設置: 更新後のパッケージを
node_modulesにインストールします。 - 設定ファイルの更新:
package-lock.json（および必要に応じてpackage.jsonの互換指定）が自動的に書き換えられます。
実行後の表示例
changed 3 packages, and audited 1200 packages in 4s
fixed 2 vulnerabilities in 1200 packages
1 vulnerability required manual review or a force update
自動修正完了後、「fixed X vulnerabilities」と表示されれば対象の脆弱性は解消されています。一方で、「required manual review or a force update」と表示された場合は、メジャーバージョンの変更（Breaking Changes）を伴うため、通常の npm audit fix では修正されずに残ります。
npm audit fix –dry-runで変更内容を確認する
npm audit fix --dry-runは、実際にファイルを変更したりパッケージをダウンロードしたりせず、「修正を実行した場合にどのファイルやパッケージがどう変わるか」を事前シミュレーションするコマンドです。
実行コマンド
npm audit fix --dry-run
なぜ実務で -dry-run が重要なのか？
チーム開発や本番運用中のプロジェクトにおいて、依存関係の意図しない変更はビルドエラーや意図しない不具合の原因になります。以下のような場面では、必ず --dry-run による事前確認を行うことが推奨されます。
- 本番環境やリリース直前の環境で修正を行う場合: 不要なパッケージ更新や影響範囲を事前に把握するため。
-forceオプションを検討している場合: 大型アップデート（メジャーバージョンアップ）がどこまで及ぶかを前もってチェックするため。- どのファイル（
package.jsonやpackage-lock.json）が更新対象になるか確認したい場合: 変更差分のスケールを掴むため。
-dry-run 実行時の出力例
+ lodash@4.17.21
updated 1 package in 1s
# NOTE: This was a dry run. No changes were made to your package-lock.json or node_modules.
末尾に No changes were made... と出力されている通り、ローカル環境のコードやファイルには一切変化を与えません。安全に影響範囲を特定できるため、修正作業の最初のステップとして活用しましょう。
npm audit fix –forceとは？通常版との違いと注意点
-forceを付けると何が変わる？
npm audit fix --forceは、セマンティックバージョニング（SemVer）の制約を無視し、メジャーバージョンの更新（Breaking Changes）を伴う脆弱性であっても強制的にパッケージをアップデートするコマンドです。
通常の npm audit fix は、互換性が保証される範囲（パッチバージョンやマイナーバージョンの更新）でのみ修正を行います。そのため、APIの仕様変更などが含まれるメジャーバージョンの更新が必要な脆弱性は、意図的にスルーされる仕組みになっています。
そこに --force オプションを付与すると、npmは package.json で指定されているバージョンの制約を跨いででも、脆弱性が解消された最新バージョンへ強制的にアップデートを試みます。
| 項目 | npm audit fix（通常版） | npm audit fix –force |
|---|---|---|
| 更新範囲 | 互換性を保つ範囲（パッチ・マイナー） | 互換性を超える範囲（メジャー更新も含む） |
| SemVerの尊重 | 尊重する | 無視して更新を適用する |
| Breaking Changesリスク | 極めて低い | 非常に高い |
| 主な用途 | 日常的な安全な脆弱性修正 | 通常版で直らない場合の最終手段・検証 |
Breaking Changesが発生する可能性がある理由
-force を指定するとメジャーバージョンアップが実行され、関数名や引数の変更、機能の削除といった「仕様変更（破壊的変更）」がコード全体に影響を与えるためです。
セマンティックバージョニング（SemVer）では、主バージョン.副バージョン.パッチバージョン（例: 2.4.1）の形式で管理されます。主バージョン（メジャーバージョン）が上がるときは、既存のコードと互換性が失われる変更が含まれていることを意味します。
npm audit fix --force を実行すると、以下のようなプロセスが発生します。
package.jsonのバージョン表記書き換え: 例えば"example-lib": "^1.2.0"と指定していても、脆弱性解消のために"example-lib": "^2.0.0"や"^3.0.0"に直接書き換えられます。- 破壊的変更の混入: 新しいバージョンで引数の順番が変わっていたり、依存する別のライブラリが不適合になったりします。
- アプリケーションの破損: 構文エラーや実行時エラーが発生し、ビルドが通らなくなったり、特定の機能が意図通り動かなくなったりします。
「脆弱性をゼロにできたが、Webサイトやアプリ自体が動かなくなった」という事態が起こるのは、まさにこの Breaking Changes が原因です。
-forceを実行する前に確認したいこと
npm audit fix --force は非常に強力ですがリスクも高いため、安易な実行は避け、必ず復元できる準備をしてから段階的に検証を行う必要があります。
実行を検討する際は、以下のステップと注意点を必ず確認してください。
1. 事前に npm audit fix --dry-run --force を実行する
実際にファイルを書き換える前に、--dry-run と --force を組み合わせて実行します。
npm audit fix --dry-run --force
どのパッケージがメジャーバージョンアップされようとしているかを事前にリストアップし、影響度を推測します。
2. Gitで作業ツリーをクリーンにし、別ブランチを作成する
実行前に必ず現在の変更をコミットし、動作検証用の専用ブランチ（例: fix/audit-force-test）を切ってから実行してください。万が一アプリが壊れた場合に、一瞬で元の状態に戻せる環境を作ることが鉄則です。
3. 実行後は網羅的なテストと動作確認を行う
コマンド実行後は、単にビルドが通るか確認するだけでなく、以下のチェックを実施してください。
- 単体テスト・結合テストの実行（
npm testなど） - 主要な画面や機能のUI動作確認
- コンソールエラーやビルドログの警告の確認
もし大規模な破壊的変更が含まれており修正コストが見合わない場合は、無理に --force で一括更新せず、手動で該当パッケージの互換性を調べながら個別対応するアプローチへ切り替えましょう。
npm audit fixで解決しないときの原因と対処法
No fix availableと表示される場合
No fix available は、対象の脆弱性を修正した新しいバージョンがまだリリースされていないか、またはメジャーバージョンの変更を伴うため自動適用できない状態を意味します。
npm audit を実行した際、レポートに No fix available や requires a force update と記載されている場合、通常の npm audit fix では自動解消できません。主な原因は以下の通りです。
- 開発元が修正パッチを未公開: パッケージの作者が脆弱性を解消したバージョンをまだ提供していない。
- メジャーバージョンアップが必要: 修正版は存在するが、APIの互換性を壊す（Breaking Changes）更新が必要になる。
- 間接依存（ネストされた依存関係）の制約: 自分が直接インストールしたパッケージではなく、依存先のパッケージがさらに依存しているライブラリで問題が発生しており、上位パッケージ側が更新されていない。
単純にコマンドを再実行するだけでは解決しないため、手動での切り分けと対応が必要になります。
npm error code ENOLLOCKが出る原因と対処法
ENOLLOCK（Error No Lock）は、package-lock.json（または npm-shrinkwrap.json）が存在しないディレクトリで npm audit や npm audit fix を実行した際に発生するエラーです。
npm audit は、インストールされているパッケージの正確なバージョン構造を package-lock.json から読み取って脆弱性を判定します。そのため、ロックファイルが存在しない状態では監査を行えません。
発生原因
- プロジェクトのルートディレクトリ以外でコマンドを実行している。
- 新規作成直後のプロジェクトで
npm installを一度も実行していない。 .gitignoreの設定ミス等により、環境上にpackage-lock.jsonが生成されていない。
対処手順
- 実行ディレクトリの確認:
package.jsonがあるルートディレクトリに移動します。 package-lock.jsonの生成: 以下のコマンドを実行してロックファイルを生成します。Bashnpm install- コマンドの再実行: ロックファイルが生成されたことを確認した上で、再度実行します。Bash
npm audit fix
依存関係の競合をnpm lsで確認する
npm ls コマンドを使用すると、プロジェクト全体の依存関係ツリーを視覚的に表示し、どのパッケージが原因で脆弱性が持ち込まれているかを特定できます。
特に間接依存のパッケージで脆弱性が報告された場合、どの親パッケージがそのライブラリを引き込んでいるか（依存のルート）を把握することが解決の第一歩です。
実行コマンド
例えば、脆弱性が報告されたパッケージが semver であった場合、以下のように実行します。
npm ls semver
実行結果の確認例
my-app@1.0.0 /path/to/project
└─┬ webpack@5.88.0
└── semver@7.5.1
上記の場合、自分自身が直接 semver を入れたのではなく、webpack@5.88.0 の依存関係として semver@7.5.1 が組み込まれていることが分かります。このように問題の「親」を特定することで、親パッケージ（例: webpack）自体を更新すれば脆弱性が解消できるかどうかを判断できます。
npm audit fix後も脆弱性が残る場合の確認手順
自動修正で解決しない脆弱性が残った場合は、原因の切り分けから手動でのパッケージ更新、最終テストまでを順を追って実施します。
以下のステップに沿って対応を進めてください。
[1. npm auditの再実行]
│
[2. 脆弱性の詳細・依存ツリーの確認 (npm ls)]
│
[3. 直接依存パッケージの個別アップデート]
│
[4. オブライド (overrides) の検討]
│
[5. 再チェック・動作確認]
1. npm audit で残存している脆弱性の詳細を確認
コマンドを実行し、残っているパッケージ名と深刻度（Severity）、および直接依存か間接依存かを確認します。
2. npm ls <パッケージ名> で依存ツリーを調査
どの親パッケージ経由で脆弱性が持ち込まれているかを特定します。
3. 直接依存パッケージの手動更新
もし親パッケージの新しいバージョンがリリースされている場合は、通常の手動更新を試みます。
npm install <package-name>@latest4. 間接依存で親パッケージの更新が期待できない場合の対処（overrides の活用）
親パッケージ側の更新が滞っており、間接依存のライブラリだけを強制的に安全なバージョンへ引き上げたい場合、package.json に overrides フィールド（npm v8以降で導入）を記述することでピンポイントに指定できます。
package.json の記述例:
{
"dependencies": {
"some-parent-package": "^1.0.0"
},
"overrides": {
"vulnerable-sub-package": "^2.0.0"
}
}
設定後、npm install を実行して依存ツリーを再構築します。
5. 修正後の再検証とアプリケーションテスト
再度 npm audit を実行して脆弱性が解消されたか確認し、最後にアプリケーションが問題なく動作・ビルドできるかテストを行います。
npm audit fixに関するよくある疑問
-
npm audit fixでpackage.jsonやpackage-lock.jsonはどう変わる？
-
npm audit fixを実行すると、依存関係のロックファイルであるpackage-lock.jsonが優先的に更新され、修正にマイナーやメジャーバージョンの変更が必要な場合にのみpackage.jsonが書き換えられます。両ファイルと
node_modulesの変化の役割と違いは以下の通りです。対象 npm audit fix（通常）での変化 npm audit fix –force での変化 package-lock.json常に更新される
実際にインストールされた正確なバージョンやハッシュが書き換わります。常に更新される
メジャーバージョン変更に伴う大規模なツリー再構築が行われます。package.json基本は変わらない
キャレット（^）やチルダ（~）の範囲内で収まる場合はバージョン表記は維持されます。書き換えられる
バージョンの範囲指定を超えて強制更新されるため、設定値が直接変更されます。node_modules更新される
最新のパッケージファイルがダウンロード・再配置されます。更新される
新しいメジャーバージョンのパッケージに差し替えられます。npm audit fixは単にログを表示するコマンドではなく、内部的にインストーラを伴う処理です。そのため、実行後は必ずgit diffを使用してpackage-lock.jsonやpackage.jsonにどのような差分が発生したかを確認する習慣をつけましょう。
-
npm audit fixはグローバルパッケージにも使える？
-
結論から言うと、
npm audit fix（およびnpm audit）はローカルプロジェクトの依存関係を対象としたコマンドであり、グローバルにインストールされたパッケージに対しては使用できません。npm auditは、現在の作業ディレクトリに存在するpackage-lock.jsonやnode_modulesの構造を解析して脆弱性を特定する仕組みになっています。環境全体に-gオプションで導入したグローバルパッケージには個別のpackage-lock.jsonが存在しないため、判定を行えません。グローバルパッケージで
npm auditを実行した場合グローバル環境でコマンドを実行すると、以下のようなメッセージが出力されます。
npm audit -g # または npm audit fix -g実行結果例:
npm error code ENOAUDIT npm error audit does not support testing global packagesグローバルパッケージの脆弱性や更新への対応方法
グローバルパッケージを安全に保ちたい場合は、
npm auditではなく以下のようにパッケージの更新状況を個別に確認・手動アップデートします。- 古いグローバルパッケージの一覧確認
npm outdated -g - 特定のグローバルパッケージの更新
npm install -g <package-name>@latest
- 古いグローバルパッケージの一覧確認
-
npm audit fix –forceで変更した内容を戻すには？
-
npm audit fix --forceによって意図しない変更や不具合が発生した場合は、Gitの変更履歴を破棄して依存関係を再構築するのが最も確実に元に戻す手順です。単に
npm installを再実行するだけでは、すでに書き換わってしまったpackage.jsonやpackage-lock.jsonの内容に基づいてインストールが行われるため、変更前の状態には戻りません。変更前へ正確に復元するには、以下のカテゴリ別に手順を踏んで対応します。
1. Gitで変更管理を行っている場合（標準的な戻し方）
作業ツリーの変更をすべて打ち消し、クリーンな状態に復元します。
# 1. 変更された package.json と package-lock.json を元のコミット状態に戻す git restore package.json package-lock.json # 2. node_modules 内のパッケージを変更前の状態に再同期する npm ciポイント:
npm installではなくnpm ciを使用することで、復元したpackage-lock.jsonと完全に一致する状態でnode_modulesを高速に再構築できます。2. Git管理外だが手動でバックアップを取っていた場合
実行前に
package.jsonやpackage-lock.jsonのバックアップ（コピー）を作成していた場合は、手動でファイルを置き換えた上で同期します。- バックアップファイルから
package.jsonとpackage-lock.jsonを上書き復元する。 - 以下のコマンドを実行して
node_modulesを再構築する。Bashnpm ci
3. バックアップがない・Git管理もしていない場合
変更前の正確な状態を自動復元することは極めて困難です。手動で
package.jsonのバージョン記述を修正し、node_modulesとpackage-lock.jsonを削除してから再生成する必要があります。# node_modules と ロックファイルを削除 rm -rf node_modules package-lock.json # 再度インストールを実行してツリーを生成 npm install※この方法は元の依存関係と完全に一致する保証がないため、日頃からGitによるバージョン管理を行っておくことが極めて重要です。
- バックアップファイルから
まとめ
npm audit fix は、Node.js / フロントエンド開発においてプロジェクトの依存ライブラリに含まれるセキュリティ脆弱性を解消するための非常に有用なコマンドです。安全かつ効果的に運用するために、本記事で解説した以下の重要ポイントをおさらいしておきましょう。
プロジェクトのセキュリティを安全に保つために、まずはターミナルを開いて現在のプロジェクトの状態を確認することから始めましょう。
npm auditで現状の脆弱性をチェックする- 修正前に Git で作業状態をコミットしておく
npm audit fix --dry-runで影響範囲を確かめてからnpm audit fixを実行する
脆弱性の放置はセキュリティリスクにつながりますが、無計画な一括更新によるアプリケーションの不具合も防ぐ必要があります。正しい知識を持って npm audit fix を活用し、安全で堅牢なWebサイト・アプリケーション開発を進めていきましょう。
