AIに指示するだけで、アプリが動くコードが出てくる時代になりました。それ自体はすばらしいことです。ただ、そのコードが動く裏側では、あなたが一度も中身を見ていない部品(ライブラリ)が、何十個も自動で取り込まれています。自分で選んだつもりのない部品が、静かに積み重なっているのです。
そして近年、まさにその「他人が作った部品」を経由してコンピュータを乗っ取る攻撃が増えています。サプライチェーン攻撃と呼ばれる手口です。この記事では、サプライチェーン攻撃とは何か、なぜAIを使った開発で特に危ないのか、そして初心者でも取れる現実的な守り方を、順を追って整理します。読み終えるころには、自分の身の守り方が見えているはずです。
結論:信頼されたソフトの通り道に、悪意が混ぜられる
先に結論から言います。サプライチェーン攻撃とは、多くの人に信頼されているソフトウェアの流通経路に、悪意あるコードをこっそり仕込む手口のことです。
怖いのは、利用者が何もミスをしていなくても被害に遭いうる点です。あなたが正規のルートで、いつも通りに部品を取り込むだけで、その中に紛れ込んだ悪意あるコードが一緒に動いてしまうおそれがあります。攻撃者が狙うのは、あなた個人ではなく、みんなが使う「元」なのです。
サプライチェーン攻撃とは:ラベルは同じ、中身だけすり替えられる
言葉をやさしく置き換えてみましょう。まず用語からです。
- ライブラリ:誰かが作って公開してくれた、便利なプログラムの部品。自分でゼロから作らずに済むよう、多くの開発者が共有して使っています。
- 依存関係:あるプログラムを動かすために必要な、ほかの部品のつながり。1つ取り込むと、その部品がさらに別の部品を必要とし、芋づる式に何十個も入ることがあります。
サプライチェーン攻撃は、この「みんなが信頼して取り込んでいる部品」そのものに毒を仕込みます。
書籍的に言えば、ソフトウェアの配布やアップデートといった正規の通り道に、マルウェア(悪意あるプログラム)を紛れ込ませる手口、ということになります。入口が「信頼された正規ルート」だからこそ、気づくのが難しいのです。
具体例:2026年3月31日のaxios事件
抽象的な話が続いたので、実際に起きた出来事で見てみましょう。
2026年3月31日、npm(世界中の開発者がプログラムの部品を公開・共有する仕組み)で、事件が起きました。axiosという、極めて広く使われている定番ライブラリの管理者アカウントが乗っ取られたのです。
axiosは、プログラムから外部のサーバー(API)とやり取りするときに使う、いわば通信の定番部品です。週に数千万から数億回ダウンロードされる規模で使われています。その乗っ取られたアカウントから、悪意あるバージョンの axios 1.14.1 と 0.30.4 が公開されました。これらを取り込んでしまったマシンは、遠隔操作型のマルウェアによって侵害されるおそれがありました。遠隔操作型とは、攻撃者が離れた場所から、そのマシンを勝手に操れるようにする種類のものです。
被害が広がりやすいのには理由があります。「自分はaxiosなんて使っていない」という人でも、先ほどの依存関係のせいで、別の部品の内部でaxiosが取り込まれていることがあるからです。さらにこの事件では、悪意のある依存パッケージが一緒に取り込まれる形になっていたと報じられており、知らないうちに巻き込まれた人もいたとみられます。
なぜ怖いのか、なぜAI駆動の開発で特に危険なのか
サプライチェーン攻撃が怖い理由は、大きく2つあります。
1つ目は、知らないうちに入ってくることです。依存関係のせいで、自分が名前も知らない部品が大量に取り込まれます。その1つに毒が仕込まれていても、見た目は普通に動くため、異変に気づきにくいのです。
2つ目は、守りが固い相手でも突破されうることです。今回のaxios事件では、乗っ取られた管理者は多要素認証(パスワードに加えて、スマホの確認などを重ねる仕組み)を設定していたと伝えられています。それでもアカウントは乗っ取られました。つまり、これは「一部のずさんな人だけの話」ではなく、対岸の火事とは言えないのです。
そして、AIを使った開発ではこの危うさが増しやすくなります。AIにアプリ作りを任せると、必要な部品はAIが判断してどんどん取り込んでいきます。開発を助けるツールの多くも、裏側でnpmを使って部品を取り込んでいます。つまり、あなたが中身を見ていない部品が、これまで以上に大量に、しかも自動で積み上がるということです。脆弱性(セキュリティ上の弱点)や仕込みがあっても、自分の目を通していない分、気づける機会が減ってしまいます。AIの便利さは、そのまま「見えない依存が増える」という側面と背中合わせなのです。
守り方:防ぎきるのではなく、二段構えで備える
ここが記事の核心です。正直なところ、この種の攻撃を100パーセント防ぐのは難しいものです。信頼された正規ルートから来る以上、完全に見抜くことはできません。そこで現実的なのは、防ぐことに全振りするのではなく、二段構えで備える考え方です。
段構え1:起こる前に、被害が小さくなるよう構えておく
もし何かを取り込んでしまっても、それだけで大惨事にならないよう、あらかじめ被害の上限を下げておきます。
- 最小権限で構える:開発中は、本番環境に影響しないテスト用のキー(通行証)を使います。仮にそれが漏れても、本番の大事なデータやお金には手が届きにくくなります。
- APIキーをそのままAIに貼らない:AIに相談するとき、本番のAPIキーやパスワードをそのまま貼り付けるのは避けます。渡した情報がどこまで扱われるか、自分で完全には把握できないからです。APIキーの守り方はAPIキーをクライアント側に書いてはいけない理由でくわしく解説しています。
- 取り込む前に、信頼できる部品か確かめる:名前が似ているだけの偽物や、更新が長く止まっている部品を避け、広く使われている素性の確かなものを選ぶ習慣をつけます。
段構え2:起きたときに、すぐ気づける状態をつくる
そのうえで大切なのが、問題が起きたときにいち早く知る仕組みを持っておくことです。防ぐより、こちらのほうが現実的で効きます。
- CVEという共通番号を知っておく:世の中で見つかった脆弱性には、CVEと呼ばれる共通の識別番号が振られます。世界中で同じ番号で管理されるので、「どの部品のどの問題か」を誰でも追いかけられます。
- 自動通知を受け取れるようにする:自分の作ったものをGitHub(コードを保管・共有する場所)に置いておくと、使っている部品に問題(CVE)が見つかったとき、Dependabotなどの仕組みが自動で知らせてくれます。自分で毎日ニュースを追わなくても、危険が届いた瞬間に気づける状態になります。
- バージョンを固定しておく:ロックファイルという仕組みで、取り込む部品のバージョンを固定します。これがあると、いつの間にか勝手に新しい(危ないかもしれない)バージョンへ入れ替わる事故を減らせます。
もし該当してしまったら:落ち着いて順に対処する
自分の使っている部品が、危険なバージョンに当たっていると分かったときの対処も知っておきましょう。あわてず、次の順で進めるのが基本です。
- 危険なバージョンを避ける:該当バージョンを、安全とされる古いバージョンに戻して(ダウングレードして)固定するか、その部品自体を取り除きます。
- マシンを切り離す:侵害されたおそれのあるマシンは、いったんネットワークから隔離します。遠隔操作の通り道を断つためです。
- 秘密の情報を入れ替える:そのマシンで扱っていたAPIキーやパスワードなどは、すべて新しいものに入れ替えます(ローテーション)。すでに盗まれている前提で動くのが安全です。
- 可能なら作り直す:何が仕込まれたか分からない状態を引きずるより、環境を作り直すほうが安心できる場合もあります。
AIで作ったアプリを外部に公開している場合の注意点はAIで作ったアプリのサーバは安全かもあわせてご覧ください。公開している分だけ、狙われる面も広がるからです。
まとめ:作れる時代ほど、守りの基礎が効いてくる
- サプライチェーン攻撃は、信頼された部品の流通経路に悪意を仕込む手口。使うだけで巻き込まれるおそれがある。
- axios事件のように、多要素認証をしていた管理者でも乗っ取られた。対岸の火事ではない。
- AIに任せる開発では、自分が見ていない部品が大量に入るため、異変に気づきにくい。
- 守り方は二段構え。テスト用キーで被害を小さく構え、GitHubの自動通知(CVE)ですぐ気づける状態を作るのが現実的。
AIのおかげで、コードを書く力そのものは、以前ほど大きな壁ではなくなりました。だからこそ、これからは「何が危ないのかを見抜き、どう構えるか」というセキュリティの考え方や、体系的な基礎知識が、いっそう効いてくるはずです。AIとの付き合い方の落とし穴を先に知りたい方は、バイブコーディングとはもヒントになります。
独学でつまずきやすいのは、知識そのものよりも「何を、どの順番で学ぶか」です。AI時代のセキュリティの基礎も、あなたの目標から逆算した学ぶ順番の一部として、1対1で一緒に整理できます。
