npm auditでcriticalが出てビビったときの判断と対処法（無視していい？）

npm install のあとにこんな表示が出ると、普通に心臓に悪いです。

3 vulnerabilities (1 low, 1 moderate, 1 critical)
Run `npm audit fix` to fix them, or `npm audit` for details

しかも「critical」なんて書かれていたら、なおさらです。 この記事では、この表示にビビったときに、何を根拠に「今すぐ止めるべきか」「後回しでいいか」を判断し、最短で安全に直す手順をまとめます。

ZIDOOKA!のように、執筆や個人用CLIツール運用をしつつ、必要なところだけ堅くする想定で書きます。

結論：表示だけで「即死」ではありません

npm audit の深刻度（low / moderate / high / critical）は、脆弱性の“深刻さ”の目安であって、あなたの環境で直ちに悪用される“リスク”をそのまま示すものではありません。

たとえば、同じ脆弱性でも以下の環境では意味が全く変わります。

• 本番サーバー: 外部からの入力を受け付ける（危険度：高）
• ブラウザ: ユーザーのブラウザ上で動く（危険度：中〜高）
• ビルド・テスト: 開発者のPCやCIだけで動く（危険度：低）

なので最初にやるべきは「怖い」ではなく、以下の切り分けです。

npm audit の警告は無視していいのか？

結論から言うと、「条件付きでYES」です。

以下の条件に当てはまる場合は、直ちに対応しなくても実害がないケースが多いです。

• dev依存（devDependencies）である: 本番環境にはデプロイされないツール類。
• 攻撃条件が成立しない: 例えば「ユーザー入力を受け取るサーバー」の脆弱性だが、あなたのツールは「ローカルでMarkdownを変換するだけ」の場合。
• OSコマンドインジェクション系だが、外部入力を渡していない: 自分で書いた固定値しか渡さないなら攻撃されようがありません。

ビビりポイントの正体：npm audit fix –force が危険な理由

画面に出てくる「全部直すなら npm audit fix –force」という提案。これが怖さの原因であり、罠です。

–force は、互換性（semver）を無視してでも依存を更新することがあり、メジャーバージョンが上がって動作が壊れる可能性があります。 つまり「脆弱性は減ったけど、プロジェクトが動かなくなった」という本末転倒が普通に起こりえます。

基本方針:

1. まず npm audit fix（破壊的変更が起きにくい範囲）
2. それで直らないものは、手で経路と影響を確認してから対処
3. –force は最後の手段（しかもテストできる前提）

5分でできる「危険度の判断」チェックリスト

以下の順で見れば、ビビりが「判断」に変わります。

1) それ、本番で動きますか？（dev依存かどうか）

本番に出さない（ビルド・テストだけ）なら、緊急度が落ちるケースが多いです。

本番依存（dependencies）だけを確認したい場合：

npm audit --omit=dev

※ 以前は –production でしたが、最近のnpmでは –omit=dev が推奨されています。

2) 何が原因パッケージですか？

npm audit

で出たパッケージ名を控えて、依存経路を見ます。

npm ls <package-name>

これで「どの親パッケージ経由で入っているか」がわかると、対処の方針が立ちます。

3) 直し方は「親を上げる」が基本

よくある落とし穴は、「直接触ってない“孫依存”が原因」というパターンです。 この場合、孫だけを無理にいじるより、依存を引っ張っている親パッケージを最新版へアップデートするのがいちばん筋が良いです。

CI / GitHub Actions で落ちる場合

「ローカルでは気にしてなかったけど、GitHub Actions で npm audit が走ってエラーになる」というケースも多いです。 npm audit は脆弱性が見つかると exit code 1 を返すため、CIが止まります。

特定のレベル以上だけ検知したい場合は、以下のように設定できます。

# criticalのみ検知してエラーにする
npm audit --audit-level=critical

package-lock.json はどうなる？

npm audit fix を実行すると、package-lock.json が書き換わります。 「勝手に書き換わって大丈夫？」と不安になるかもしれませんが、fix（forceなし）であれば、基本的には package.json の許容範囲内での更新なので安全です。

よくある失敗例

• いきなり –force を叩く: プロジェクトが壊れて復旧に数時間かかります。
• lockfileを見ない: チーム開発で勝手にlockfileを大幅に変えてしまい、他のメンバーの環境でエラーが出る。
• 孫依存を無理やり固定: overrides や resolutions で無理やりバージョンを固定すると、将来的に別の依存関係エラーを生む原因になります。

ZIDOOKA!的な運用（執筆・個人開発ならこうする）

ZIDOOKA! のように「記事を書く」「CLIでWPに投げる」「自分の環境で完結」が中心なら、優先度はこうなります。

1. 本番サーバーで動くもの: 優先度「高」（早めに潰す）
2. 自分のPCでしか動かないCLI: 優先度「中」（経路と条件を見て、余裕あるときに）
3. テストやビルド専用: 優先度「低」（ただし定期監視はする）

要するに、ビビるのは自然ですが、やることは単純です。

• どこで動くか
• どう成立するか
• どの親が原因か

これだけ見れば、「今すぐ止めるべき案件」か「後で直せばいい案件」かが判断できます。