CI環境でnpm run audit:ciというスクリプトを実行する目的として、最も適切なものはどれですか？

解説

正解は「依存関係に既知の脆弱性が見つかった場合、終了コードを非ゼロにしてCIを失敗させる」です。audit:ci という名前は慣習的なもので、多くのプロジェクトでは package.json 内に "audit:ci": "npm audit --audit-level=high" のような形で定義されています。npm audit は依存関係の脆弱性をチェックするコマンドで、CI で実行することで脆弱なパッケージを含んだままデプロイされるのを機械的に防ぐのが目的です。選択肢1は npm update や npm-check-updates の役割、選択肢3はキャッシュ管理（GitHub Actions の actions/cache など）、選択肢4は jest --coverage などテストツールの役割で、いずれも audit とは別物です。npm auditが終了コードで合否を伝える仕組みCI/CD の世界では、コマンドの成否は終了コード（exit code）で判定されます。0 なら成功、それ以外は失敗です。npm audit は脆弱性が1件でも見つかると非ゼロで終了するため、CI パイプラインのステップとして組み込むだけで「脆弱性があればビルドを止める」という挙動が実現できます。// package.json { "scripts": { "audit:ci": "npm audit --audit-level=high --production" } }--audit-level=high を付けると、low や moderate レベルの脆弱性では失敗させず、high 以上でのみ CI を止められます。誤検知やまだ修正パッチが出ていない軽微な脆弱性でビルドが止まると開発が滞るため、重大度の閾値を設けるのが実務的です。npm audit fix との違いと注意点よく混同されるのが npm audit fix です。こちらは自動修正を試みるコマンドで、パッチバージョン程度のアップデートで解決できる脆弱性を自動で直してくれます。ただし破壊的変更を含む修正（メジャーアップデート）は --force を付けないと適用されず、--force は別の問題を引き起こす可能性があるので CI で自動実行するのは危険です。監査だけ: npm audit（読み取り専用、CI向き）安全な範囲で自動修正: npm audit fix（ローカルで実行してPR作成）強制修正: npm audit fix --force（破壊的変更あり、慎重に）実務で押さえておきたい運用パターン脆弱性対応は「見つけた瞬間に全部直す」が理想ですが、現実には依存ライブラリ側の修正待ちで即座に対応できないケースもあります。その場合は npm audit の --omit=dev オプションで本番依存のみに絞ったり、Dependabot や Renovate といった自動PRツールと組み合わせて継続的に更新する運用にするのが一般的です。audit:ci は最後の砦であって、日々の更新を怠らないことがセキュリティ担保の本質です。