保守を引き継いだ案件のリポジトリを開いて、npm install を打つ。あの数秒間に何が起きているかを説明できる人は、実はそう多くありません。
依存パッケージには postinstall などのライフサイクルスクリプトを持たせられます。これはインストール時に自動で実行され、しかもあなたの開発機の権限で動きます。環境変数もSSHキーもクラウドの認証情報も、その時点で射程に入る。直接の依存が20個でも、その先まで含めれば1,000を超えるパッケージが入るのが普通ですから、全部を目視で確認する運用は成立しません。
この「入れたら走る」という既定値そのものを組み替えたパッケージマネージャが、2026年8月にバージョン1.0へ到達しました。
vlt が反転させた3つの既定値
vlt（ボールト）は、npmの元開発メンバーが手がけているJavaScriptのパッケージマネージャです。npm互換で、既存の package.json を持つプロジェクトにほぼそのまま入る位置づけになっています。1.0で押し出されているのは、性能ではなく既定値の設計です。
1つめは、ライフサイクルスクリプトを既定で走らせないことです。インストールとビルドが分かれていて、vlt install は取得だけを行い、スクリプトの実行は vlt build 側で選択的に行われます。冒頭の「入れた瞬間に走る」が、既定では起きません。
2つめは、既知の悪性パッケージをインストール時に止めることです。OSVなどの脆弱性データベースと、公開されているマルウェアのフィードを取り込み、安全なnpmミラー越しに継続的にスキャンする構成になっています。
3つめは、依存グラフをクエリで検査できることです。60種類以上のセレクタが用意されており、うち30ほどがセキュリティ向けです。:malware :cve :vuln :unmaintained :outdated :eval :fs :license といった条件で、依存ツリーの中から該当するパッケージを抽出できます。
性能面では、クリーンインストールがnpmより最大38%速いとされています。ただし乗り換えの理由として速度を先に置くと、判断を誤ります。速度で選ぶならすでに選択肢は複数あり、vltの差分はそこではありません。
「スクリプトを走らせない」を選ぶと何が壊れるか
既定値が安全側に倒れているということは、これまで暗黙に頼っていた挙動が動かなくなるということでもあります。ここを見ずに導入すると、CIが赤くなってから気づくことになります。
| インストール時スクリプトに頼っているもの | 起きること |
|---|---|
| ネイティブモジュールのビルド（node-gyp 系） | ビルド手順を明示しないと動かない |
| バイナリのダウンロード（ブラウザ・CLI 同梱系） | 実行時に本体が見つからない |
| 開発ツールの初期設定（Git フックの登録等） | フックが登録されず、静かに無効になる |
| パッチ適用の自動実行 | パッチが当たらないまま動く |
いちばん厄介なのは4行目と3行目です。エラーで止まってくれるものは気づけますが、フックやパッチは当たらなくても動いてしまうため、レビューやフォーマットの自動化だけが静かに死にます。導入時は「動いた」ではなく「本来走るはずのものが走ったか」を確認する必要があります。
受託・保守の現場で現実的な導入線
複数案件を抱えている前提で、いきなり全部を移すのは無理があります。段階を踏むなら次の順序が現実的です。
- 新規に立てるプロジェクトから使う。既存の依存に引きずられないため、スクリプトを明示する設計を最初から入れられます
- CIの検査ステップとして依存グラフのクエリだけ回す。パッケージマネージャを置き換えなくても、
:malwareや:vulnに該当する依存がないかを定期的に見るだけなら副作用がありません - 保守案件は、依存を大きく更新するタイミングに合わせる。どのみち回帰確認をする回なので、既定値の変更を混ぜても切り分けができます
移行を検討する前に、いま使っているパッケージマネージャで同じことがどこまでできるかを確認しておく価値もあります。pnpmもインストール時スクリプトの扱いを厳格にする方向へ動いており、その経緯はpnpm 11とサプライチェーン対策で扱いました。既存ツールの設定変更で足りるなら、そのほうが安上がりです。
そもそも何を怖がっているのかを言語化しておく
ツールの選定より前に整理しておきたいのは、自社にとってのリスクがどの経路から来るかです。
開発機が踏まれると、そこにある顧客の認証情報が持って行かれます。CIが踏まれると、デプロイ先まで届きます。npmの公開パッケージを経由した攻撃が現実にどう組み立てられているかはnpm install で任意コードが走る経路に、依存関係を通じた攻撃の全体像はサプライチェーン攻撃の手口と対策にまとめています。
この2つを読んだうえで「うちはCI側のほうが危ない」と判断できるなら、優先すべきはパッケージマネージャの入れ替えではなく、CIの権限を絞ることかもしれません。順番を間違えると、手間の割に守れる範囲が増えません。
次にやること
まず、手元の案件1本で依存ツリーの中に古いまま放置されているパッケージがどれだけあるかを数えてみてください。vltを入れずとも、既存のツールで概算は取れます。その数が三桁になるなら、既定値の話に進む価値があります。二桁で収まっているなら、まずは更新の運用を整えるほうが効きます。
依存管理やCIのセキュリティ設計を含めた保守体制の見直しは、グリームハブの開発・AI・自動化のご相談で承っています。案件の規模や運用体制によって適切な線引きは変わるため、個別にお見積りします。お問い合わせからご相談ください。
