「AIに任せておけば、寝ている間に仕事が終わっている」。そんな時代の到来に酔いしれたい季節ですが、残酷な現実をお伝えしなければなりません。2026年現在、Claude CodeやCursorといったAIエージェントは、かつてない脅威の標的になっています。
npmサプライチェーン攻撃「Shai-Hulud」の最新変種は、あなたのAIエージェントを巧みに騙し、信頼できるアシスタントから攻撃者の手先へと変貌させます。もしあなたのAIがこの攻撃を受けた場合、以下の事態があなたの承認なしに、バックグラウンドで発生します。
- SSH鍵・AWS認証情報の全流出:AIがファイルシステムをスキャンし、見つけた認証情報を攻撃者のサーバーへ送信
- 社内リポジトリへのバックドア設置:AIが正規のコードに見せかけて悪意あるコードをコミットし、組織全体を危険に晒す
- 被害者から加害者へ:あなたのnpmアカウントを乗っ取り、あなたが管理するパッケージにウイルスを混入させて世界中にバラ撒く
- ローカル環境の完全破壊:攻撃の痕跡を消すために、デッドスイッチが作動してホームディレクトリごと削除される恐れ
「まさか自分のAIに限って」と思いませんか? もしYESを連打していたなら特に危険です。
この記事では、自律型AIエージェントが抱える構造的な脆弱性と、今日からできる具体的な防御策を徹底解説します。

AIにできることが増えるほど、猛威増すShai-Hulud
AIコーディングエージェントは、チャットで質問に答えるAIとはまったく別の存在です。あなたのパソコン上で実際にコマンドを実行し、ファイルを読み書きし、インターネットにアクセスする権限を持っています。この権限の大きさを正確に把握しておくことが、Shai-Hulud対策の出発点になります。
コードを書くだけじゃない:ターミナル、ファイル、ネットワークへのフルアクセス
Claude Code、Google Antigravity、Cursorといったツールは、いずれもあなたのパソコンの中で実際に動作します。チャットAIのように「テキストを返すだけ」ではなく、ターミナルコマンドの実行、ファイルシステムの読み書き、外部ネットワークへの接続が可能です。
たとえばClaude Codeは、Bashコマンドを実行してパッケージをインストールし、設定ファイルを書き換え、Gitでコミットやプッシュまで行えます。Antigravityはさらに踏み込んで、エディタ、ターミナル、ブラウザの3つを同時に操作し、アプリケーションのビルドからテストまでを自律的にこなします。
これは開発を効率化するうえでは非常に強力な仕組みです。しかし同時に、もしAIが悪意ある指示に従ってしまった場合の被害範囲も、従来のチャットAIとは比較にならないほど大きくなります。チャットAIが嘘を言っても画面にテキストが表示されるだけですが、コーディングエージェントが悪意ある操作を実行すれば、あなたの認証情報が盗まれたり、コードが改ざんされたりといった実害が発生します。
「自律モード」のスイッチを入れたとき、何が解除されるのか
AIエージェントの多くは、デフォルトでは何かを実行するたびに人間の承認を求めます。しかし、開発効率を上げるために、その承認プロセスを省略するモードが用意されています。
Claude Codeでは--dangerously-skip-permissionsというフラグをつけると、すべてのツール実行が人間の承認なしに行われます。名前に「dangerously(危険に)」と入っていますが、実際に多くの開発者が便利さのためにこのフラグを常用しています。

Antigravityでは、セットアップ時に「Agent-driven development」を選ぶと、AIがコードの作成、コマンドの実行、ブラウザの操作をすべて自律的に行います。さらにAgent Managerから複数のエージェントを同時に稼働させることもでき、それぞれが独立して作業を進めます。
Cursorでは、ターミナルコマンドの自動実行ポリシーを「Auto」に設定すると、エージェントが判断してコマンドを実行します。
どのツールでも共通しているのは、自律モードを有効にした瞬間、人間がリアルタイムで介在するチャンスがなくなるということです。AIがnpm installを実行しても、見覚えのないMCPサーバーを追加しても、.envファイルを読み取っても、あなたに確認は来ません。この状態が、Shai-Huludにとって理想的な攻撃環境になります。
MCP接続の数だけ、攻撃の入口が増える
MCP(Model Context Protocol)は、AIエージェントが外部のサービスやツールと連携するための仕組みです。GitHub、データベース、Slack、各種APIなどに接続するためのMCPサーバーを設定すると、AIはそれらのサービスを直接操作できるようになります。

Claude Codeでは、MCPは基盤的な機能として位置づけられており、複数のMCPサーバーを同時に接続して使うことが一般的です。Cursorも同様にmcp.jsonファイルでサーバーを管理します。Antigravityも含め、2026年のAIコーディング環境では、MCPサーバーなしに開発することのほうが珍しくなりつつあります。
ここで意識すべきなのは、MCPサーバーの1つ1つが、AIエージェントに新しい「手」を与えているということです。GitHub MCPを繋げば、AIはリポジトリの操作ができます。データベースMCPを繋げば、テーブルの読み書きができます。そして、悪意あるMCPサーバーが紛れ込めば、AIは攻撃者の指示通りに動く「内通者」になります。
接続しているMCPサーバーが多いほど、1つのエージェントが侵害された場合の被害範囲が広がります。これは利便性とリスクのトレードオフであり、対策なしに接続数だけ増やすのは危険です。
Shai-Huludとは:npm史上最悪の砂虫を3分で理解する
Shai-Huludは、2025年9月に発見されたnpmサプライチェーン攻撃のコード名です。名前はSF小説『デューン』に登場する巨大な砂虫に由来しています。砂の中を進む砂虫のように、信頼されたパッケージの内部に潜んで開発者の環境を侵害し、次々と新たなパッケージに感染を広げていく自己増殖型のワームです。従来のサプライチェーン攻撃とは異なり、1つの感染が連鎖的に数百のパッケージを汚染するという点で、史上最悪といわれています。
始まりは1通のフィッシングメール
Shai-Hulud攻撃の起点は、高度なハッキング技術ではありませんでした。攻撃者はnpmパッケージのメンテナー(管理者)に対してフィッシングメールを送り、2要素認証の更新を装って認証情報を盗み取りました。

npmというのは、JavaScriptの世界でもっとも広く使われているパッケージ管理ツールです。開発者はnpmを通じて、他の開発者が作ったライブラリ(パッケージ)をインストールして使います。chalkやdebugといった有名パッケージは、週に数億回ダウンロードされるほどの規模を持っています。
攻撃者はこの巨大なエコシステムの信頼を悪用しました。メンテナーのアカウントを乗っ取ることで、正規のパッケージに悪意あるコードを注入できたのです。ユーザーから見ると、いつも使っているパッケージの新バージョンが出ただけに見えます。疑う理由がありません。
この攻撃で最初に侵害されたパッケージ群には、CrowdStrike関連のパッケージや、フロントエンド開発で広く使われる@ctrl/tinycolorなどが含まれていました。


感染→窃取→自己増殖:砂虫が広がるメカニズム
Shai-Huludの感染サイクルは、大きく4つのステップで構成されています。
最初のステップは侵入です。侵害されたパッケージをインストールすると、package.jsonに仕込まれたpostinstallスクリプトが自動で実行されます。postinstallとは、パッケージのインストール完了後に自動で走るスクリプトのことで、本来は初期設定などに使われるものですが、Shai-Huludはこの仕組みを悪用しました。
次のステップは認証情報の窃取です。postinstallで起動した悪意あるコード(bundle.js)は、開発者のマシン上にある認証情報を片っ端から探します。正規のセキュリティツールであるTruffleHogを悪用してファイルシステム全体をスキャンし、AWSキー、GCPやAzureの認証情報、GitHubの個人アクセストークン、npmの認証トークンなどを収集します。
3つ目のステップはデータの流出です。盗んだ情報は2つの経路で攻撃者に送られます。1つは、被害者のGitHubアカウント上にShai-Huludという名前のリポジトリを自動作成し、そこにJSONファイルとしてコミットする方法。もう1つは、GitHub Actionsのワークフローファイルを被害者のリポジトリに書き込み、攻撃者のwebhookにPOST送信する方法です。
最後のステップが自己増殖です。ここがShai-Huludの最も危険な特徴です。盗み取ったnpmトークンを使って、被害者が管理している他のパッケージを列挙し、それぞれに悪意あるコードを注入した新バージョンを自動で公開します。パッチバージョンを1つ上げて(たとえば1.2.3→1.2.4)、postinstallフックを追加し、bundle.jsをコピーする。この自動化されたサイクルによって、1人のメンテナーの侵害が数十、数百のパッケージへと連鎖的に広がりました。

2025年9月から今日まで:砂虫は止まっていない
Shai-Huludは一度きりの攻撃ではありません。時間とともに進化し、規模を拡大し続けています。
2025年9月の第一波では、500以上のnpmパッケージが侵害されました。この時点で、npm史上最大規模のサプライチェーン攻撃と認識されています。


2025年11月には「Shai-Hulud: The Second Coming」と呼ばれる第二波が発生し、最終的に796のユニークなnpmパッケージが侵害されたことが確認されています。Zapier、Postman、PostHog、AsyncAPIといった有名サービスのパッケージも含まれていました。この波では、プライベートリポジトリを勝手に公開に変更するという手口も確認されています。


そして2026年2月には、SANDWORM_MODEと呼ばれる新たな変種がSocket社の調査チームによって報告されました。少なくとも19の悪意あるnpmパッケージが確認され、Claude CodeやCursorなどAIコーディングツールを明確に標的とする機能が組み込まれていました。タイポスクワッティング(名前の似たパッケージを作って間違いインストールを狙う手法)で、Claude Codeを模倣したパッケージも作られています。

攻撃手法も洗練されています。GitHub APIへのアクセスが失敗した場合のSSHフォールバック、GitHub Actionsを偽装した悪意あるワークフロー、無効化された状態のデッドスイッチ(攻撃が失敗した場合にホームディレクトリを消去する機能)など、継続的に機能追加が行われています。
なぜAIを放し飼いにしている人が最もShai-Huludの被害を受けやすいのか
一般的なShai-Hulud対策の記事では、lockfileの固定やnpm auditの実行といった開発者全般に向けた対策が語られます。しかしAIエージェントを自律モードで動かしている人には、それだけでは足りない固有のリスクがあります。AIエージェントの自律性そのものが、Shai-Huludの攻撃効率を飛躍的に高めてしまうためです。
砂虫はAIエージェントをユダにする
SANDWORM_MODEの最も注目すべき特徴は、AIコーディングツールを直接の攻撃対象に加えたことです。
具体的な手口はこうです。悪意あるパッケージをインストールした際に、Claude Code、Cursor、VS Code拡張機能の設定ファイルに不正なMCPサーバーを自動で追加します。このMCPサーバーには、隠されたプロンプトインジェクション(AIへの不正な指示)が仕込まれています。

AIアシスタントがこの不正MCPサーバーを通じて指示を受け取ると、SSH鍵、クラウドの認証情報、各種APIトークンを読み取り、攻撃者のサーバーへ送信します。さらに、複数のLLMプロバイダーのAPIキーもチェック対象となっており、感染したシステムを大規模な認証情報収集プラットフォームに変えてしまいます。

つまり、あなたのAIエージェントが寝返るのです。 AIは自分が攻撃に加担していることを認識しません。MCPサーバーから受け取った指示を、通常の作業指示と区別できないまま実行します。外から見れば、AIが普通に作業しているようにしか見えません。
npm installをAIに任せると、毒入りパッケージが素通りする
人間の開発者であれば、npm installの実行結果に見慣れないパッケージが含まれていた場合、違和感を覚えることがあります。postinstallスクリプトが走ったときに表示される不審なメッセージに気づく可能性もあります。
AIエージェントにはその「違和感センサー」がありません。 指示されたコマンドを実行し、エラーが出なければ次のステップに進むだけです。postinstallで悪意あるコードが実行されても、それがエラーを返さない限り、AIは何も報告しません。
自律モードでは、この問題がさらに深刻化します。AIが「このパッケージをインストールしますか?」と聞いてくることがないため、タイポスクワッティングによる偽パッケージのインストールも素通りします。正しいパッケージ名がsupports-colorであるところを、AIがsuport-colorを指定されてもそのままインストールする可能性があります。SANDWORM_MODEでは、まさにこのsuport-colorという偽パッケージが使われていました。

自律稼働中、あなたの目は閉じている
Antigravityでは、Agent Managerから複数のエージェントを同時に起動して、それぞれ別のタスクを並行処理させることができます。Claude Codeでもバックグラウンドエージェントが作業を進め、完了したら結果を報告してくれます。
この非同期・並行処理の設計は生産性を大幅に向上させますが、同時にセキュリティ上の「検知の窓」をゼロにします。エージェントが5つ同時に動いているとき、あなたがそれぞれの動作をリアルタイムで監視することは現実的に不可能です。1つのエージェントが不正な操作を行ったとしても、気づくのはすべてが終わった後です。
従来のサプライチェーン攻撃では、悪意あるパッケージが公開されてから検知されるまでの「タイムラグ」が問題になっていました。AIエージェントの自律稼働は、この問題をローカルの開発環境にも持ち込みます。攻撃が実行されてからあなたが気づくまでの間に、認証情報の窃取、リポジトリへの書き込み、さらなる感染の拡大がすべて完了してしまう恐れがあります。
1つのエージェントの侵害が、接続先すべてに飛び火する
前のセクションで説明したMCP接続が、ここで致命的な意味を持ちます。
AIエージェントがGitHub MCPでリポジトリにアクセスし、データベースMCPでテーブルを操作し、クラウドMCPでインフラを管理している場合、そのエージェントが侵害されれば、接続先のすべてが攻撃の対象になります。
Shai-Huludのオリジナル版は、npmトークンとGitHubトークンを使った横展開が中心でした。しかしAIエージェントを経由すれば、MCP経由で接続されたあらゆるサービスが射程に入ります。攻撃者にとって、わざわざ各サービスの認証情報を個別に盗む必要がなくなるのです。AIエージェントを通じて、すべてに手が届きます。
権限の足し算がリスクの掛け算になる構図です。 MCPサーバーを1つ接続するたびに、侵害時の被害範囲が線形ではなく指数的に拡大する可能性があることを意識しておく必要があります。
Shai-Huludへの危険度セルフチェック:5つの質問
ここまで読んで「自分は大丈夫だろう」と思った方こそ、以下の質問に答えてみてください。
- AIエージェントを
--dangerously-skip-permissionsや「Agent-driven」モードなど、人間の承認なしにコマンドを実行する設定で使っていますか。 - npm install、npx、pip installなどのパッケージインストールをAIに任せていて、実行結果を毎回確認していないことがありますか。
- MCPサーバーの設定ファイル(mcp.jsonや.mcp.jsonなど)を最後に確認したのがいつか、すぐに思い出せますか。
- .envファイルやSSH鍵、クラウドの認証情報が、AIエージェントがアクセスできるディレクトリに置かれていますか。
- package-lock.jsonやpnpm-lock.yamlを使わず、最新バージョンを自動で取得する設定にしていますか。
3つ以上に該当する方は、Shai-Huludの攻撃が成功しやすい環境を作っている状態です。全問該当する方は、早急に次のセクションの対策を検討してください。1〜2つの方も、該当する項目から優先的に対処することをおすすめします。
今日からできるShai-Hulud対策:5つのレイヤーで考える
対策は「全部やらなければ意味がない」というものではありません。レイヤー(層)で考え、できるところから順に積み上げていくのが現実的です。Layer 0が最もコストが低く効果が大きい対策で、番号が上がるほど本格的な仕組みの導入が必要になります。まずはLayer 0と1から始めることをおすすめします。
Layer 0(最優先):npm installを素で実行しない
Shai-Huludの感染経路の中核はpostinstallスクリプトです。つまり、npm installの実行時にスクリプトが自動で走ることを防げば、感染の最初のステップをブロックできます。
postinstallスクリプトの自動実行を止める
もっとも効果的な方法は、pnpm 10への移行です。pnpm 10では、Lifecycle Scripts(postinstallなど)がデフォルトでは実行されない設定になっています。必要なパッケージだけpnpm approve-scriptで明示的に許可する方式なので、未知の悪意あるスクリプトが勝手に走ることを防げます。
pnpmへの移行がすぐには難しい場合は、npm install時に--ignore-scriptsフラグをつけて実行し、その後に必要なpostinstallだけを手動で実行する方法があります。
依存パッケージの自動更新に「待ち」を入れる
Dependabotやrenovateで依存パッケージを自動更新している場合は、パッケージが公開されてから一定期間(1週間程度)待ってからアップデートのPRを作成する設定にしてください。pnpm 10.16ではminimumReleaseAgeという設定が追加されており、公開直後のパッケージのインストールを遅延させることができます。Shai-Huludのような攻撃は、悪意あるバージョンが公開されてから検知・削除されるまでの短い時間を突いてくるため、この「待ち」が防御として機能します。
lockfileを必ず使う
AIエージェントにパッケージインストールを任せる場合は、lockfileの使用を必ず徹底してください。lockfileがあれば、AIが意図せず最新(かつ汚染された可能性のある)バージョンを取得することを防げます。
Layer 1:AIエージェントをサンドボックスに入れる
AIエージェントを、あなたのメインの開発環境とは隔離された空間で動かすことで、万が一の侵害時に被害を限定できます。
macOSならsandbox-execが手軽
macOSを使っている場合は、sandbox-execを使ったサンドボックス化が比較的手軽です。Claude Codeをsandbox-exec上で動かす具体的な手順がコミュニティで共有されており、ネットワークアクセスやファイルアクセスの範囲を制限した状態でエージェントを稼働させることができます。
OS問わず使えるDevContainers / Docker
よりポータブルな方法としては、DevContainersやDockerコンテナの中でAIエージェントを動かす方法があります。コンテナの中であれば、ホストOSの認証情報やファイルシステムに直接アクセスすることはできません。VS CodeのDevContainers拡張機能を使えば、設定も比較的簡単です。
サンドボックスの導入は、自律モードのリスクを大幅に軽減します。AIエージェントが侵害されても、サンドボックスの外にあるSSH鍵やクラウド認証情報にはアクセスできないためです。
Layer 2:MCP設定ファイルを定期的に開く
SANDWORM_MODEは、不正なMCPサーバーを設定ファイルに書き込むという手口を使います。つまり、設定ファイルを定期的に確認する習慣があれば、異変に気づくことができます。
確認すべきファイルは、使用しているツールによって異なります。Cursorなら~/.cursor/mcp.json、Claude Codeならプロジェクトルートの.mcp.jsonや~/.claude/配下の設定ファイルです。
チェックするポイントはシンプルです。自分が意図的に追加した覚えのないMCPサーバーが記載されていないかを確認してください。サーバーのURLが見慣れないドメインを指していないか、名前が正規のツールに似ているが微妙に違っていないかも要注意です。SANDWORM_MODEでは「ci-quality/code-quality-check」という一見もっともらしい名前のGitHub Actionが悪用されていました。
この確認作業は1分もかかりません。週に1回、あるいはプロジェクトの依存パッケージを更新したタイミングで確認する習慣をつけるだけで、不正なMCPサーバーの存在に早期に気づける可能性が高まります。
Layer 3:認証情報をAIの手の届かない場所に隔離する
Shai-Huludが最終的に盗み取るのは認証情報です。逆に言えば、AIエージェントのワーキングディレクトリから認証情報を物理的に切り離しておけば、仮に侵害されても被害を最小限に抑えられます。
.envファイルをプロジェクトルートに置かない
まず、.envファイルをプロジェクトルートに直接置くのをやめてください。多くの開発者がAPIキーやデータベースのパスワードを.envに書いてプロジェクトルートに置いていますが、AIエージェントのワーキングディレクトリは通常プロジェクトルートです。つまり.envファイルはAIの手の届く範囲にあります。

代わりに、credential helperやキーチェーン、クラウドのシークレットマネージャー(AWS Secrets ManagerやGCP Secret Managerなど)を使って、認証情報をファイルシステム上に平文で置かない運用に切り替えてください。
SSH鍵をAIのアクセス範囲から切り離す
SSH鍵についても、AIエージェントが稼働するディレクトリから~/.sshが参照できる状態は避けるべきです。Layer 1で説明したサンドボックスやコンテナを使えば、この分離は自然に実現できます。
トークンのスコープを最小限にする
npmトークンやGitHubトークンには必要最小限のスコープ(権限)だけを設定してください。読み取り専用で済む作業に書き込み権限を持つトークンを使っていると、侵害時の被害が拡大します。

Layer 4:CIに「最後の砦」を組み込む
ここまでの対策はローカル環境での防御ですが、CI/CDパイプラインにもチェックを組み込むことで、仮にローカルで感染したコードがプッシュされても、本番環境への反映を食い止められます。
npm auditをCIに組み込む
もっとも基本的な対策は、CIにnpm auditを組み込むことです。PRが作成されるたびにnpm audit –audit-level=criticalを実行し、既知の脆弱性を持つパッケージが含まれていないかチェックします。手動のPRでもDependabotによる自動PRでも、同じチェックが走るようにしておけば、後から判明した脆弱性も検出できます。
サプライチェーンセキュリティツールの導入
より強力な対策としては、SocketやAikidoSecのsafe-chainといったサプライチェーンセキュリティツールの導入があります。これらはnpm audit以上に、悪意あるコードのパターンや異常なパッケージの挙動を検知できます。npmやnpxコマンドをラップする形で動作するため、導入のハードルも比較的低いです。
GitHub ActionsのSHA Pinning
GitHub Actionsを使っている場合は、アクションのバージョンをSHA Pinningで固定してください。uses: actions/checkout@v5ではなく、uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8のようにコミットハッシュで指定します。Shai-Hulud 2.0ではGitHub Actionsのワークフローを書き換える手口も確認されており、SHA Pinningはこれに対する有効な対策です。renovateやdependabotもこの書式でのアップデートに対応しているので、運用上の手間は最小限です。

Shai-Huludを恐れながらもAIエージェントを使い倒すために
この記事は、AIエージェントの利用をやめるべきだと主張するものではありません。Claude Code、Antigravity、Cursorといったツールは、ソフトウェア開発の生産性を劇的に向上させます。そして、これらのツールを安全に使いこなせる人が、2026年の開発環境で最も高い成果を出せます。
重要なのは、自律性とセキュリティのバランスを意識的に設計することです。すべての操作に人間の承認を求める設定に戻す必要はありません。リスクの高い操作、具体的にはパッケージのインストール、認証情報へのアクセス、外部サービスへの接続にだけゲートを設ける。それ以外の作業はAIに任せる。この選択的な制御が、安全と効率の両立を実現します。
そしてShai-Huludは、これからも進化し続けます。s1ngularityから第一波、第二波、SANDWORM_MODEへと、攻撃は半年で3世代の進化を遂げました。あなたのセキュリティ対策も、一度設定して終わりではなく、定期的に見直す必要があります。まずはこの記事のセルフチェックリストに戻り、今の自分の状態を確認するところから始めてください。

