AIエージェントのnpm installを安全にする3段階フロー

なぜAIエージェントの「npm install」はそのまま危険なのか

Claude CodeやCodexにコーディングを任せていると、「このパッケージを追加します」と提案されてそのままインストールが走る場面が頻繁にある。人間がひとつずつpackage.jsonを見て判断していた工程が、エージェントの一存で完結してしまう。

便利だが、依存追加はサプライチェーン攻撃の入り口そのものだ。2026年8月4日に発覚したShai-Hulud攻撃は、その入り口がどれほど無防備かを突きつけた。

Shai-Huludは何をしたのか

発端はkeyvメンテナーのGitHubアカウント侵害だった。攻撃者はメインブランチに悪意あるファイルを混入させ、GitHub Actionsの正規プロベナンス署名付きで汚染版をnpmに公開した。keyv 6.0.0、flat-cache 6.1.24、cacheable-request 13.0.20などが対象になり、2026年8月4日13時37分CEST時点で434パッケージ・1381バージョン、月間インストール合計20億件超が汚染された。

preinstallフックがBunランタイムv1.3.13を取得し、728KBのMath_Symbol.jsを実行。npm、GitHub、AWS、Kubernetes、HashiCorp Vault、Stripe、Slackの認証情報を収集し、暗号化して公開GitHubリポジトリへ送信する。失敗時はnpm-cache[.]com:443/routerへ流れる仕組みだった。

とりわけ見過ごせないのが、ghs_形式のGitHubトークンを取得した場合の挙動だ。ワームは最大50ブランチへ感染を広げ、.claude/settings.jsonと.vscode/tasks.jsonへ悪意あるフックを追加する。AIコーディングツールの設定ファイル自体が攻撃対象に含まれている。

「隔離・検証・昇格」フローの中身

エージェントが依存を提案してから本番に入るまでを、3段階に分けて運用する。

• 隔離 ネットワーク遮断したサンドボックスコンテナ内でインストールを実行し、preinstall/postinstallスクリプトの挙動をログに残す。外部通信が発生した時点で止める。
• 検証 パッケージ名・バージョン・メンテナー変更履歴を確認し、既知の侵害情報と突合する。学習データそのものにシークレットが混入している構造的リスクにも目を配りたい。TruffleHogの調査では、HuggingFace上の約7.6ペタバイトのデータから、有効な認証情報が221,303件見つかっている。GitHubの個人アクセストークン349件のうち223件がリポジトリへの完全な書き込み権限を持っていた。
• 昇格 検証を通過したパッケージのみlockfileにピン留めし、本番ブランチへのマージはエージェントではなく人間のレビュー承認を経る。

この3段階を経ることで、汚染パッケージが本番環境やCI認証情報に触れる前に検知できる。

導入すべき人・しないほうがいい人

個人開発や小規模チームでAIエージェントに依存追加を日常的に任せているなら、隔離実行だけでも導入価値がある。CIに組み込むコストは小さく、被害を未然に止める効果が大きい。

一方、すでに全ての依存追加を人間が手動レビューしている体制なら、3段階フローを重ねると承認待ちが増えて開発速度が落ちる。既存レビューの精度を上げる方が優先度は高い。

まとめ

AIエージェントに依存追加を任せる利便性と、サプライチェーン攻撃の被害規模は表裏一体だ。汚染パッケージを本番に直行させない仕組みを持たない限り、エージェントの提案は検証されないまま実行され続ける。まず自分のCIにサンドボックス実行を1つ挟むところから始めるのが現実的だ。