株式会社TIMEWELLの濱本隆太です。
2026年5月11日の夜、世界中のエンジニアのタイムラインに衝撃的なニュースが流れました。React開発者なら誰もが使ったことのある人気ライブラリ群「TanStack」のnpmパッケージが、大規模なサプライチェーン攻撃によって汚染されていたというのです12。
被害はTanStackだけにとどまりませんでした。Mistral AI、Guardrails AI、OpenSearch、UiPath、そしてSquawkパッケージ——いずれも開発者に広く使われているツールです。170を超えるパッケージ、400件以上の悪意ある版がわずか数分の間に公開されました。CVE番号はCVE-2026-45321、深刻度（CVSS）は9.6という極めて高い評価がつけられています34。
私がこの事件でもっとも注目したのは、感染パッケージの数でも、影響を受けた企業の知名度でもありません。このマルウェアが「Claude Codeの設定ファイル」に潜り込んで永続化するという、これまでに見たことのない手口を使っていたという事実です5。
「信頼されたパイプライン」そのものが武器にされた
この攻撃の仕組みを整理しておきたいと思います。
TanStackのnpmパッケージが汚染された時間帯は、2026年5月11日19:20〜19:26UTC（日本時間では翌朝4時20〜26分）のわずか6分間です。84個の悪意あるパッケージが42のパッケージ名前空間にわたって公開されました1。不思議なのは、これが「外部から不正なトークンを盗んで公開した」のではなかったという点です。
攻撃者はTanStackの正規のリリースパイプライン——GitHub ActionsのOIDC（OpenID Connect）認証——を乗っ取り、TanStack自身の信頼されたIDを使って悪意あるパッケージを公開しました。つまり、パッケージには正規の署名がついていたのです。
さらに厄介だったのは、このマルウェアがSLSA Build Level 3のプロベナンス（出所証明）を持った状態で公開されたことです。SLSAはGoogleが主導するソフトウェアサプライチェーンセキュリティのフレームワークで、「このパッケージは信頼できるビルドプロセスを経た」ことを証明するものです。Level 3はその中でも高い信頼レベルを指します。ところがこの攻撃では、そのSLSAの証明書が悪意あるコードに対して正当に発行されたという前代未聞の事態が起きました6。
これは単なる技術的な珍事ではありません。「公式の署名がついているから安全」という前提が根底から崩れ去ったことを意味します。
「npm uninstallでは直せない」——AIツールへの永続化という新発明
今回の攻撃でもっとも革新的（そして恐ろしい）だったのは、マルウェアの永続化手法です。
従来のnpm系マルウェアは、感染したパッケージを削除すれば被害が止まりました。npm uninstallやpip uninstallで汚染パッケージを除去し、認証情報をローテーションすれば、少なくともマルウェアの実行環境は断ち切れました。
ところがMini Shai-Hudulは、感染後にAIコーディングツールの設定ファイルを書き換えるという手口を使いました。具体的には、
.claude/settings.json（Claude Codeの設定ファイル）.vscode/tasks.json（VS Codeのタスク設定ファイル）
この2つのファイルにフックを仕掛けることで、パッケージを削除した後も、ツールのイベント（ファイル保存、コード実行、AIへの質問など）のたびにマルウェアが再実行される仕組みを作り上げました5。
Claude Codeは、開発者がコードを書く際にAIがターミナルコマンドを自動実行したり、ファイルを読み書きしたりできるエージェント型の開発ツールです。その設定ファイルに悪意あるフックが書き込まれると、Claude Codeを使うたびにマルウェアが動き続けます。設定ファイルはプレーンテキストなので、セキュリティソフトが検知しにくいという側面もあります。
この手口が「世界初」と評される理由はここにあります。npmのエコシステムが直接感染経路となり、そこからAIコーディングエージェントの設定を書き換えて半永久的に居座る——開発者が日常的に使うツールそのものが、攻撃インフラの一部に組み込まれてしまうのです。
AI駆動開発を、実務で使えるところまで
トレンドを追うだけで終わらせないための実践プログラムがWARPです。元大手DX・データ戦略の専門家が、現場で動かすところまで伴走します。
なぜAI開発者が狙われるのか
Mini Shai-Hudulが特にAI開発者向けのツールを標的にしていた点は、意図的な戦略です。
このマルウェアが実際に行う行動を見ると、その目的が鮮明になります。感染後に実行されるのは、クラウドプロバイダー（AWS、Azure、GCP）の認証情報の収集、GitHub・GitLabのパーソナルアクセストークンの窃取、CI/CDシステム（GitHub Actions、CircleCIなど）のシークレットの漏洩、そして暗号通貨ウォレット情報の収集です6。
AI開発者は、これらすべてを高い確率で保有しています。AIモデルを動かすにはクラウドのAPIキーが必要です。コードはGitHubで管理されています。継続的なモデルの学習・評価のためにCI/CDパイプラインを組んでいます。AI関連のスタートアップでは暗号通貨でのやり取りも珍しくありません。
AI開発者はnpmやPyPIのパッケージを大量に、しかも素早くインストールする傾向もあります。Claude CodeやCursorのようなAIコーディングエージェントが「このパッケージをインストールしましょう」と提案すれば、多くの開発者はほぼ無意識に承認します。攻撃者はその「信頼と速度」を突いているのです7。
先行する攻撃（2026年3月のaxios侵害）では、OpenAIのGitHub Actionsワークフローが悪性のaxiosパッケージをダウンロード・実行し、macOS版ChatGPTアプリの署名用証明書が露出するという事件が起きました。OpenAIは全ユーザーにアプリの更新を要請しました。今回のMini Shai-Hudulはその延長線上にあり、AI開発者を狙う攻撃が単発ではなく、組織的なキャンペーンとして続いていることを示しています8。
Shai-Hududという名前の意味——攻撃の系譜
「Shai-Hulud」という名前は、SFの古典『デューン/砂の惑星』に登場する巨大砂虫の名前から来ています。砂漠の地下を縦横無尽に動き回り、何者にも止められない存在——攻撃者はそのイメージをマルウェアに重ねています。
オリジナルのShai-Hulud wormが最初に確認されたのは2025年9月です。当時のトレンドマイクロの分析によれば、npmリポジトリで高度に標的化された攻撃が確認され、自己複製しながらnpmトークンやGitHubのPATを窃取していくワーム型マルウェアとして報告されました9。
その後、同じ攻撃グループ「TeamPCP」によるキャンペーンは進化を続けました。2026年4月には「Mini Shai-Hulud」として、SAPのCloudアプリケーションプログラミングモデル（CAP）関連パッケージを標的にした攻撃が発生し、Claude Codeへの永続化という新手法が初めて確認されました5。今回5月の攻撃では、その手法がTanStack、Mistral AI、UiPathなどの主要パッケージに対して大規模に展開されたのです。
注目すべきは、このグループの技術力の高さです。Bun（Node.jsとは別のJavaScriptランタイム）を使って一般的なEDR（エンドポイント検知・対応）ツールの検知を回避し、RSA-4096で暗号化したチャンネル経由でデータを外部に送信し、Dependabotに偽装したGitHub Actionsワークフローを埋め込む——これらはいずれも高度な技術と、エコシステムへの深い理解があって初めて実現できる攻撃です6。
「SLSA Level 3でも安全ではない」という不都合な真実
セキュリティ界隈でこの事件が特に大きな議論を呼んでいるのは、SLSA（Supply-chain Levels for Software Artifacts）への信頼が揺らいだからです。
SLSAはGoogleが提唱し、業界横断で支持されてきたソフトウェアサプライチェーンセキュリティのフレームワークです。Level 1〜4のレベルがあり、Level 3になると「ビルドプロセスが改ざんされていないこと」を自動的に証明できるとされていました。多くの企業が「SLSAのプロベナンスがついているから検証済み」として、パッケージの採用判断を簡略化していました。
ところがMini Shai-Hudulは、正規のCI/CDパイプラインを乗っ取ることで、悪意あるコードに対してSLSA Level 3の証明書を正当に取得しました。「プロベナンスがある＝安全」という等号が成立しなくなったのです。
これはSLSAそのものが設計上の欠陥を持つという話ではありません。SLSAは「ビルドプロセスが改ざんされていない」ことを証明するものであり、「ビルドの入力（ソースコード）が改ざんされていない」ことの保証ではないのです。攻撃者はパイプラインを乗っ取ってビルドの入力を差し替えました。SLSAは正常に機能した——ただし、悪意あるコードに対して。
この微妙だが致命的な違いを、多くの組織がこれまで意識してきませんでした。今回の事件はその盲点を突きました。
では、私たちはどう身を守るべきか
技術的なリスクの深刻さを理解した上で、実践的な対策を考えてみます。
第一に、パッケージの鮮度に注意するというアプローチが最初の防衛線です。新しく公開されたパッケージバージョンは、一定期間（たとえば72時間）がたってから本番環境に採用するという「リリース年齢」の考え方があります。今回の攻撃では公開から20分以内に悪意あるバージョンが検知されています。週次でしか依存関係を更新しない運用であれば、多くのケースで被害を回避できたでしょう8。
第二に、パッケージのロックファイルを厳格に管理することも重要です。package-lock.jsonやyarn.lock、pnpm-lock.yamlのハッシュ値を変更管理に組み込み、予期しない更新が入っていないかを確認する習慣をつけてください。CIパイプラインでnpm ci（lockfileを厳守するインストール）を使うことも基本です。
第三に、AIコーディングツールの設定ファイルを監視するという発想は、今回の事件で新たに加わった視点です。.claude/settings.jsonや.vscode/tasks.jsonは、通常の開発作業中に頻繁に変更されるものではありません。これらのファイルをGitでバージョン管理し、予期しない変更を検知するアラートを設定しておくことが有効です。特にCI/CDで使うワークスペースでは、これらのファイルの整合性チェックをパイプラインに組み込むことを強く推奨します。
第四に、Socketのようなリアルタイムな脅威検知サービスの導入も検討に値します。今回の攻撃を最初に検知したのはSocket社のAI駆動の脅威検知システムでした2。npmやPyPIのパッケージ変更をリアルタイムで監視し、疑わしい挙動（難読化されたコード、異常なネットワーク接続、環境変数へのアクセスなど）を自動検知します。SnykやDependabotとの組み合わせで多層防御を構築することが望ましいです。
第五に、AIエージェントのサンドボックス化も重要な対策です。Claude Codeの設定でsandboxを有効にすることで、AIが実行するBashコマンドをOSレベルで隔離し、ファイルシステムやネットワークへのアクセスを制限できます。AIが便利なほど、その権限範囲が広くなる——その逆説を常に意識し、最小権限の原則（Principle of Least Privilege）をAIツールにも適用してください。
「便利さ」と「安全さ」の新しい均衡点を探る
正直に言えば、今回の事件を調べながら、私自身も日々の開発習慣を振り返らざるを得ませんでした。
AIコーディングツールの普及によって、パッケージのインストールは反射的な行動になっています。ChatGPTやClaudeが「このライブラリを入れてください」と言えば、多くの場合そのままコマンドを実行します。毎週何十ものパッケージが更新され、それらすべての変更内容を人間が追うことは現実的ではありません。AIはその認知コストを下げてくれるからこそ便利なのに、その便利さが攻撃面を広げているという皮肉があります。
だからといって「npmを使うな」「AIコーディングツールを使うな」という結論に私はなりません。オープンソースのエコシステムとAI開発ツールは、現代のソフトウェア開発にとって不可欠なインフラです。問題はそれらを使うこと自体ではなく、「信頼を自動化しすぎていた」点にあります。
SLSAのプロベナンスがついていれば大丈夫、人気パッケージだから大丈夫、公式アカウントから公開されているから大丈夫——そうした「条件付きの信頼」を過信していたことが、今回の攻撃に対する脆弱性を生みました。
これからの開発者セキュリティに求められるのは、「信頼の多層化」です。単一の証明書や単一のチェックポイントに依存するのではなく、パッケージの出所、行動パターン、変更の文脈、そして実行環境の分離を組み合わせて、どれか一つが突破されても全体が崩れない仕組みを作ることです。
エンジニア個人ができる最初の一歩
大きな対策の話をすると「自分一人には難しい」と感じる方も多いと思います。ですからここでは、今日からでも始められる具体的なことを3つに絞って書きます。
まず、今使っているAIコーディングツールの設定ファイルをGit管理に入れてください。.claude/settings.jsonをgitignoreしている方は、一度その判断を見直してほしいのです。設定ファイルがバージョン管理されていれば、不審な変更がすぐにgit diffで見えます。
次に、npmの依存パッケージをnpm auditで定期的にチェックしてください。週に一度、CI/CDが自動で実行してくれるようにするのが理想です。Dependabotは最低限の設定として有効化しておくことをお勧めします。
最後に、AIエージェントに「なんでも実行させる」設定を見直してください。Claude Codeなどのエージェントが要求する権限を最小化し、特に本番環境の認証情報を持つマシンでは慎重な設定を心がけてください。
Mini Shai-Hudulという名前が示す通り、この脅威は砂漠の地中で動き続ける砂虫のように、私たちの気づかない場所で活動します。砂虫と違って、ソフトウェアの脅威は適切な知識と習慣があれば、確実に対処できます。便利さを手放さずに、少しだけ意識を変えること——それが今、私たちエンジニアに求められていることだと私は思っています。
AI時代のセキュリティ統制を、組織に組み込む
ここまで読んできて「個人の対策は分かったが、組織としてどう動けばいいか」と感じた方も多いのではないでしょうか。AIコーディングツールの導入が進むほど、開発者個人のリテラシーだけでは守りきれない領域が増えていきます。
TIMEWELLのWARPコンサルティングでは、AI導入戦略の設計と一緒に、開発者ツール・パッケージ依存・CI/CDのサプライチェーンリスクを棚卸しする支援を行っています。「どのAIコーディングツールに、どの権限を、どこまで与えるか」「依存パッケージの鮮度と承認フローをどう運用するか」「Rules / settings.json などの設定ファイルをどう統制するか」を、現場と経営の両方の言葉で整理します。
社内でAIエージェントを使い始めるフェーズで気になりやすいのが、社内ナレッジが外部のSaaSや汎用クラウドを経由して流れていく経路です。国内サーバーで動くエンタープライズAIのZEROCKは、こうした「社外に渡したくない情報をAIで使い倒したい」というニーズに直結しています。
「自社の開発フローにAIコーディングツールを安全に導入したい」「サプライチェーンのリスクを経営層に説明したい」。そんなお悩みがあれば、ぜひお気軽にご相談ください。
参考文献
Footnotes
-
Snyk. 「TanStack Npm Packages Compromised Inside The Mini Shai Hulud Supply Chain Attack」 https://snyk.io/blog/tanstack-npm-packages-compromised/ (2026-05-11) ↩ ↩2
-
Socket. 「TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply Chain Attack」 https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack (2026-05-11) ↩ ↩2
-
The Hacker News. 「Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, and 170 Packages」 https://thehackernews.com/2026/05/mini-shai-hulud-worm-compromises.html (2026-05-12) ↩
-
SecurityWeek. 「TanStack, Mistral AI, UiPath Hit in Fresh Supply Chain Attack」 https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-in-fresh-supply-chain-attack/ (2026-05-12) ↩
-
ScriptWalker. 「The First Supply-Chain Worm to Weaponize Claude Code」 https://scriptwalker.app/blog/sap-npm-mini-shai-hulud-claude-code-supply-chain-attack-april-2026 (2026-04-29) ↩ ↩2 ↩3
-
Upwind. 「Mini Shai-Hulud npm Worm: Dissecting a Multi-Vector Supply Chain Worm」 https://www.upwind.io/feed/mini-shai-hulud-npm-supply-chain-worm (2026-05-12) ↩ ↩2 ↩3
-
Qiita (SoySoySoyB). 「AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術」 https://qiita.com/SoySoySoyB/items/ff885e6de32c8e3e09c4 ↩
-
Mondoo. 「npm Supply Chain Security in 2026」 https://mondoo.com/blog/npm-supply-chain-security-package-manager-defenses-2026 (2026) ↩ ↩2
-
トレンドマイクロ. 「NPMサプライチェーン攻撃の現状と分析」 https://www.trendmicro.com/ja_jp/research/25/i/npm-supply-chain-attack.html (2025-09) ↩
