サプライチェーン攻撃をカレーに例えて説明してみた。+AI利用時の意識

こんにちは、貫徹まるです。

「セキュリティ対策はバッチリです！」

そう言っている大企業が、気づかないうちに攻撃を受けていたとしたら…
怖くないですか？

実は2026年5月、そういう事件が実際に起きました。

今回は、そのきっかけになったサプライチェーン攻撃という概念を、カレーを作る例え話を使いながらできる限りわかりやすく解説していきたいと思います。

ITに詳しくない方でも「なんとなく怖さがわかった」と感じていただけたら嬉しいです。

1. サプライチェーン攻撃とは何か カレーで例えてみます

エンジニアが開発をするときには、「ライブラリ」や「パッケージ」と呼ばれる、誰かが作ってくれた便利な部品を使うことがほとんどです。

毎回ゼロから作るのは大変なので、外部から調達してくるわけですね。

これがカレーを作るときの「カット済み野菜パック」のイメージです。

私は正直、面倒くさがりなので、カレーを作るときに野菜を一から切ることはしません。

スーパーで売っている「カレー用カット野菜セット」を買って、そこに牛肉とルーとサトウのご飯を組み合わせて完成させています。

さて、ここで恐ろしいことを考えてみてください。

もし、そのカット野菜パックの中の人参だけに毒が入っていたとしたら？

パックの外見は普通だし、玉ねぎもジャガイモも問題ない。

でも人参だけ毒入りだったら、気づかずに毒入りカレーを食べてしまいます。

これがサプライチェーン攻撃の本質です。

開発に使う部品（パッケージ）に悪意のあるコードを仕込まれると、
その部品を使っているすべての人が影響を受けてしまうのです。

セキュリティがどれだけ堅固な企業でも、仕入れた材料が汚染されていれば防げないというところが、この攻撃の最も怖いところだと思います。

2. 実際の攻撃パターン 4つ

「具体的にどうやって毒を混ぜるの？」という部分を見ていきましょう。

❶ タイポスクワット（似た名前の偽パッケージ）

有名なパッケージの名前を少し変えたニセモノを公開して、インストールのタイプミスを狙う手法です。

カレーで言うと、ご飯を買うときに
有名な「サトウのご飯」とそっくりな「サイトウのご飯」を作って、
間違えて買ってしまうようなイメージです。

❷ Dependency Confusion

社内だけで使われているパッケージと同じ名前のものを、外部の公開リポジトリに公開します。

すると、本来は社内版をインストールするはずが、
外部の毒入り版をインストールしてしまうことがあります。

A社内でしか売っていなかった「A社特製カレールー」が、
なぜかネットでも売られていて、社員が誤って外部の偽物を買ってしまう感じです。

❸ 正規パッケージの乗っとり

信頼されているパッケージを管理している人のアカウントを乗っとり、
新バージョンとして毒入りコードを配布します。

「A農家さんの野菜は安全」と信頼していたのに、
A農家さんのアカウントを誰かに乗っとられて、
最新の分だけ毒入り野菜が届いていた、というイメージです。

名前が正しくても、
バージョンが新しければ安全とは限らないというのがポイントです。

❹ インストールスクリプトの悪用

パッケージをインストールした瞬間に悪意のあるスクリプトが走り、
パソコン内の秘密情報を外部に送信する手法です。

カレー用野菜パックに爆弾が入っていて、開けた瞬間に爆発するような、
開封と同時に仕掛けが発動するイメージです。

3. 2026年5月に起きたこと Shai-Hulud（シャイ・フルード）ワーム

これは遠い世界の話ではありません。

2026年5月12日、TanStack・Mistral AI・UiPathなど160以上のnpmおよびPyPIパッケージが侵害され、「Mini Shai-Hulud」と名付けられたワームによるサプライチェーン攻撃が明らかになりました。

この攻撃で影響を受けたパッケージの累計ダウンロード数は5億1800万回以上にのぼります。

攻撃の怖さは、その自己増殖する仕組みにあります。

このワームはインストールしたエンジニアのシステム内に入ると、GitHubトークンやnpmトークンなどの認証情報を盗み出し、さらにそのトークンを使って被害者が管理しているパッケージを改ざんして再公開します。

つまり、被害者が次の感染源になってしまうわけです。

カレーで言うと、毒入り野菜を食べた人が、今度は自分の農園の野菜に毒を混ぜて出荷してしまうような連鎖反応です。

さらに怖いのは、セキュリティの証明書まで正規品に見えたという点です。

今回の攻撃では、パッケージが正規のビルドパイプラインを乗っとることで、SLSAと呼ばれる「このパッケージは信頼できるソースからビルドされた」という暗号証明書まで取得してしまいました。証明書自体は正しい手順で発行されており、コードが安全かどうかまでは保証されないことが露呈しました。

外見も証明書も完璧な毒入りカレーです。これでは気づきようがありません。

4. AIを使って開発するときの新しい怖さ

ここが、私が一番「ヤバいな」と思ったところです。

最近のエンジニアは、Claude CodeやCursorといったAIコーディングアシスタントを使って開発することが増えてきました。

「このパッケージをインストールして」とAIにお願いすると、コマンドを提案してくれる。それをそのまま実行する。とても便利です。

でも、その便利さが新しい攻撃面になっています。

AIが「インストールして」と言ったら信頼してしまう問題

あるエンジニアが実際に体験したケースとして「AIコーディングアシスタントがnpm installの実行を提案してきて、危うくそのまま実行するところだった」という話があります。その直前にRedditで侵害情報を見かけて気づいたそうです。

AIの提案は便利ですが、AIはそのパッケージが今この瞬間に安全かどうかは判断できません。

AIアシスタント自体が攻撃の入口になる

さらに踏み込んだ話をすると、AIコーディングアシスタントそのものが攻撃に使われるケースも出てきています。

2026年2月、AIコーディングアシスタント「Cline」のGitHubリポジトリに届いたIssueのタイトルに悪意ある命令が埋め込まれており、
Issueを自動でトリアージしていたAIエージェント（Claude）がその命令を実行してしまいました。
結果としてnpmの公開トークンが奪われ、約8時間で4000人の開発者のシステムに不正なパッケージがインストールされました。

普通のGitHub Issueを開いた、それだけで攻撃が始まったわけです。

AIの設定ファイルに隠れた命令が仕込まれる

さらに新しい手口として、
AIコーディングアシスタントの設定ファイル（.cursorrulesやCLAUDE.mdなど）にゼロ幅のUnicode文字を使って見えない命令を埋め込む攻撃も確認されています。
開発者がプロジェクトをAIで開いた瞬間に、AIが「セキュリティスキャン」に見せかけた情報窃取を実行してしまうという手口です。

カレーで言えば、
レシピメモに書いてないはずなのに「ショートケーキを買っていれること」
と書かれていて、それを読んだ料理ロボットが実行してしまい、
カレーケーキが誕生してしまうイメージです。

AIが便利になればなるほど、AIを騙すことの価値も上がっているのだと思います。

5. じゃあ私たちはどうすればいい？

エンジニアでない方にとっては
「自分には関係ない」と思われるかもしれません。

でも、あなたが使っているアプリやサービスは、
エンジニアが作ったものです。

そしてそのエンジニアが攻撃を受ければ、
あなたの個人情報が流出するリスクがあります。

エンジニアの方がすぐにできることをまとめると、

• パッケージのバージョンをロックファイルで固定する（自動アップデートを無闇にしない）

• AIが提案したインストールコマンドも、実行前に必ず差分を確認する

• インストール後に認証情報（トークン類）をローテーションする習慣をつける

• セキュリティアドバイザリを定期的にチェックする

といったことが有効だと言われています。
（※詳細は各セキュリティガイドラインをご確認ください）

特に「AIが言ったから大丈夫」という感覚は、少し疑うくらいがちょうどいいかもしれません。

6. おわりに 知ることが最初の防御です

私がShai-Hulud（シャイ・フルード）のニュースを見たとき、最初は「なんかかっこいい名前だな」と思いました（笑）。

でも調べてみると、これは映画やゲームの話ではなく、現実のエンジニアが今まさに格闘している問題だとわかりました。

技術的に完璧に防ぐことは難しい。

でも
「そういう攻撃が存在する」と知っているだけで、日常の行動が少し変わると思います。

カレーの野菜パックを買うときに「この野菜、大丈夫かな」と一瞬でも考える人は、毒入りを食べてしまうリスクが下がりますよね。

知識は、最初の防御です。

この記事を読んで「へぇ、怖いな」と思った方、ぜひスキで教えてください。

「もっとこういうセキュリティの話をわかりやすく書いてほしい！」という声があれば、続編も書いていきたいと思います。