AIをきっかけに開発に入った人が狙われている — 2026年6月、人気ツールで相次ぐ攻撃

2026年6月のここ数日、開発者に人気のツールで深刻な問題が立て続けに報告されています。JetBrainsのIDEプラグイン、Chromeの広告ブロッカー拡張、そしてnpmの@mastraパッケージ群。

ここで一度、立ち止まって考えたいことがあります。これらの攻撃が本当に狙っているのは、誰なのか。

セキュリティに敏感なベテラン開発者は、おそらく主な標的ではありません。彼らは公式ツールを選び、APIキーの扱いに慎重で、入れるものの素性を確認します。狙われているのは、もっと広い層です。ここ1〜2年、AIをきっかけに開発の世界に踏み込んできた人たち。普段の業務でAIを触り、「これなら自分にもできる」と感じて、プラグインを入れ、拡張を追加し、npm installを叩き始めた層です。その多くは一般企業の中にいて、開発を本業にしているわけではありません。

この層には二つの特徴があります。一つは、防御の意識がまだ育っていないこと。「動いたから大丈夫」で判断し、APIキーをそのまま設定画面に貼り付け、星評価の高さを信頼の根拠にします。攻撃者にとって、入り込みやすい相手です。

もう一つは、入り込んだ先が驚くほど豊かなことです。専門家でなくても、企業の中にいる以上、その手元には会社のクラウド認証情報、課金されている有料AIのAPIキー、社内データへのアクセス権が揃っています。防御意識は薄いのに、資産と権限は十分にある。攻撃者から見れば、これ以上の標的はありません。

そして3件をこの視点で並べると、偶然の連続ではないことが見えてきます。狙う相手も、近づき方も、痕跡の消し方も似通っている。本稿ではまず3件を個別に整理し、その上で共通する攻撃者の戦術と、それにどう対抗するかを考えます。

1. JetBrainsプラグイン15個がAI APIキーを窃取

Aikido Securityは6月16日、JetBrains Marketplace上で連携した不正キャンペーンを報告しました。7つのベンダーアカウントから公開された少なくとも15個のプラグインが同じ隠し挙動を持ち、合計でおよそ7万回インストールされています。

各プラグインはDeepSeekなどのLLMを使ったAIコーディング支援(チャット、コミットメッセージ生成、コードレビュー、バグ検出、ユニットテスト)を謳い、表向きは広告どおりに動作します。問題は設定画面です。利用者がOpenAI・SiliconFlow・DeepSeekなどのAPIキーを貼り付けて「適用」を押した瞬間、キーは保存と同時に攻撃者サーバ(39.107.60[.]51)へ平文HTTPで送信されます。同意画面も警告もありません。

ここで刺さるのが、まさに先ほどの層です。公式のAIアシスタントの存在を知らず、検索やマーケットプレイスで見つけた「DeepSeek AI Chat」のような名前に飛びつく。APIキーを設定画面に貼るという操作に疑問を持たず、ダウンロード数や星評価を信頼の根拠にします。なお、ダウンロード数や星評価は水増しが可能で、実際このキャンペーンの一部の出品には偽の高評価が並んでいました。

さらに不可解なのが有料ティアの存在です。利用者がプラグイン内の寄付ウォールから少額を支払うと、サーバ側からAPIキーが返却され、プラグインはそのキーで動くようになります。Aikidoは、あるグループが貼り付けたキーをサーバが収集し、別のグループが支払ってそのキーを受け取る——つまり盗んだAPIアクセスを転売するサービスになっている可能性を指摘しています。攻撃者は片側で課金を受け取り、もう片側で無料の認証情報を集め、請求書は本来のキー所有者が払う構図です。

最初のバージョンは2025年10月末に現れ、2026年6月10日にも新しいものが公開されています。

2. Chrome広告ブロッカー拡張がAIチャットを傍受

The Hacker Newsは6月17日、上記のJetBrains事案と並行して、2つのChrome広告ブロッカー拡張がAIチャットボットとの会話を傍受していたと報じました。研究者がPromptSnatcherと名付けた事案です。

対象はChatGPT、Claude、Gemini、Copilot、Perplexity、DeepSeek、Grok、Meta AIなど主要8プラットフォーム。拡張は本物の広告ブロック機能を提供しつつ、裏で非公開の会話内容・モデル利用状況・契約ティア情報を記録し、運営者のサーバへ送信していました。

この事案の標的は、もはや開発者ですらありません。仕事でChatGPTやClaudeを使い始めた、ごく一般のビジネスパーソンです。広告ブロッカーは「みんなが入れている定番」であり、警戒されにくい。両拡張とも数年前から存在しており、AI会話の窃取機能は後からアップデートで追加されたとみられます。記事執筆時点でChrome Web Storeにはまだ掲載されています。このように正規の機能を隠れ蓑にしてAIチャットを盗み取る手口は、Prompt Poachingと呼ばれています。

3. Mastra npmパッケージ141個が乗っ取られる

Aikido Securityは6月17日、人気のオープンソースAIエージェントフレームワーク@mastraスコープ全体を狙った大規模なサプライチェーン攻撃を検知しました。攻撃者はUTC 6月17日 01:15〜02:00のわずかな間に141パッケージを再公開し、すべてに悪意ある依存を仕込みました。対象には週918,000ダウンロードを持つ@mastra/coreや、mastra・create-mastraも含まれます。

この事件は、今のAI開発ブームの危うさをよく表しています。

狙われているのは、npmを熟知した開発者だけではありません。むしろ、自分ではnpmの仕組みをよく知らないまま、AIに「こういうエージェントを作って」と頼み、返ってきた手順をそのまま実行する人たちです。

AIは親切に答えます。

npm install @mastra/core

利用者は、その一行をコピーして実行します。そこに何が含まれているのか、依存関係がどう解決されるのか、postinstallで何が走るのかまでは見ていません。見ていないというより、そもそも見るべき場所だと知らない。

つまり攻撃者は、利用者本人を直接だましているだけではありません。利用者が頼っているAIアシスタントに、危険なパッケージを代わりに入れさせている。人間の判断を飛び越えて、AIが示したコマンドをそのまま実行する流れに乗っているのです。

仕込まれた依存はeasy-day-jsという、人気の日付ライブラリdayjsを装ったクローンです。手口は巧妙でした。前日に公開された最初のバージョン(1.11.21)は、完全にクリーンなdayjsのコピーでした。翌日、@mastraの再公開と同じタイミングで悪意あるバージョン(1.11.22)が公開されます。

各パッケージは^1.11.21を指定していたため、npmのキャレット解決によって、利用者の環境では自動的に最新の1.11.22が引き込まれます。一方で、固定されたパッケージ本体だけを見ても不審な点は見つかりません。攻撃者は、利用者の目だけでなく、単純な確認作業もすり抜けるように設計していました。

1.11.22はpostinstallフックを追加し、インストール時に難読化スクリプトを自動実行します。スクリプトはC2サーバから第2段階のペイロードを取得して一時ディレクトリに書き出し、完全にバックグラウンドの独立プロセスとして起動したのち、自身を削除して痕跡を消します。第2段階はシステム情報を収集し、MetaMask・Keplr・Coinbaseを含む160以上の暗号ウォレット拡張を標的とする長期常駐プロセスとして動きます。

Aikidoは、この手口が2026年3月のaxios事案とほぼ同一だと指摘しています。対象パッケージ本体のコードには触れず、悪意ある依存を注入してpostinstallで自動実行する点、クリーンな囮バージョンを先に置く点、実行後に自己削除する点まで共通しています。

ここで重要なのは、AIが悪いという話ではありません。AIは開発の入口を広げました。これまでコードを書かなかった人でも、AIに聞けばアプリやエージェントを作れるようになりました。しかしその一方で、npm、依存関係、インストールスクリプト、秘密情報の扱いといった、開発者なら少しずつ身につけてきた前提知識を飛ばしたまま、実行環境だけが先に手元へ来てしまっています。

攻撃者は、そこを見ています。

攻撃者の傾向 — 何が新しいのか

3件は別々の事件ですが、並べると攻撃者側の戦術がはっきり見えてきます。

整理すると、共通するのは「インストール時点・利用時点では無害に見える」という一点です。動作は正常、固定バージョンはクリーン、痕跡は消える。利用者が異常に気づくための手がかりを、攻撃者が意図的に取り除いています。

そして、もう一つ重要な変化があります。

昔なら、npmパッケージを入れるのは、ある程度開発に慣れた人でした。しかし今は違います。AIに「作って」と頼むと、AIがライブラリを選び、インストールコマンドを出し、設定方法まで教えてくれます。利用者は、それを信じて実行します。

攻撃者から見れば、これは大きな変化です。技術に不慣れな人でも、開発者と同じ危険な操作をするようになった。しかも、その人は企業の中にいて、会社のクラウド認証情報、有料AIのAPIキー、社内データへのアクセス権を持っている。

つまり、攻撃者は「開発者」を狙っているのではありません。AIによって開発者のような操作を始めた、まだ防御の型を持っていない人たちを狙っています。

これに対抗するには

戦術が「見えなくする」方向に進化し、しかも防御の弱い層を狙ってくる以上、対抗するには判断基準そのものを変える必要があります。

第一に、「動くこと」を安全の根拠にしない。今回のプラグインも拡張も、すべて広告どおりに機能していました。機能の正常さと安全性は、別のものです。

第二に、バージョン固定だけに頼らない。後付けアップデート、キャレット解決、推移的依存のいずれも、固定バージョンの監査をすり抜けます。ロックファイルと、その中身を検査する仕組みの両方が要ります。

第三に、長期間有効な秘密情報を、素性を確認していないツールに渡さない。渡す場合も短命のキーに留め、定期的にローテーションする。盗まれても価値が早く失われる状態にしておくことです。

第四に、組織の側で土台を整えること。権限は必要最小限に絞り、APIキーは短命にしてローテーションを強制し、何が導入され、何が外部と通信しているかを監視する。未検証のプラグインや拡張、パッケージを自由に入れられる状態を放置しないことも重要です。

ただ、それでも足りないものがあります。

最後に、そしておそらく最も重要なのが、教育です。

ここでいう教育は、難しい研修を増やすことではありません。日々、何が起こっているかを伝えることです。

「JetBrainsのプラグインでAPIキーが盗まれた」 「Chrome拡張がAIチャットを読んでいた」 「npm installだけで悪意あるコードが走った」

こうした事実を知っているだけで、次に似た場面に出会ったとき、人は一度止まります。AIに勧められたコマンドをそのまま実行する前に、少し考える。見知らぬプラグインにAPIキーを貼る前に、少し調べる。広告ブロッカーだから大丈夫、と決めつける前に、権限を見る。

注意は、知識から生まれます。

もちろん、仕組みで守ることは必要です。権限を細かく分ける。キーを短命にする。監視する。検査する。これは当然やるべきです。

でも、最後に最初の一手を止めるのは人です。そしてその人を守る一番現実的な方法は、日々の脅威を、日々伝え続けることです。

AIによって、開発の入口は大きく広がりました。だからこそ、セキュリティの入口も広げなければなりません。専門家だけが知っていればいい時代ではありません。AIを使って何かを作るすべての人が、「今、何が狙われているのか」を知る必要があります。

日々の脅威に目を向けること。その習慣こそが、最初の、そして最も確実な防御線です。