AIツールに潜むマルウェア：信頼の連鎖が崩れるとき

人気AIライブラリ「LiteLLM」にマルウェアが混入。1日340万回ダウンロードされるツールが標的に。オープンソースのサプライチェーンリスクと、形骸化するセキュリティ認証の問題を読み解きます。

あなたが毎日使っているソフトウェアの中に、あなたの知らない「訪問者」が潜んでいるとしたら、どうしますか。

2026年3月、AIツール開発者の間で広く使われているオープンソースライブラリ LiteLLM に、悪意あるコード——マルウェア——が混入していたことが発覚しました。LiteLLM はOpenAIやAnthropicなど数百のAIモデルへの統一的なアクセスを提供するツールで、Snyk の調査によると1日あたり最大340万回ダウンロードされています。GitHubでは4万のスターを獲得し、AI開発者にとって「あって当然」のインフラになっていました。

何が起きたのか：依存関係という「抜け穴」

マルウェアを発見したのは、AIエージェントを開発する FutureSearch の研究科学者、Callum McMahon 氏です。LiteLLM をダウンロードした直後、自分のマシンが突然シャットダウンしたことをきっかけに調査を始めました。

皮肉なことに、マルウェアの「バグ」が自らの存在を暴露したのです。

問題のコードは LiteLLM 本体ではなく、その「依存関係（dependency）」——つまり LiteLLM が内部で利用している別のオープンソースパッケージ——に仕込まれていました。マルウェアは感染したマシンのログイン認証情報を窃取し、その情報を使って別のオープンソースパッケージやアカウントにアクセス、さらに認証情報を収集するという連鎖的な攻撃を展開していました。

AI研究者の Andrej Karpathy 氏をはじめ複数の専門家が、このマルウェアのコード品質の粗さから「バイブコーディング（AIに雰囲気で指示して書かせたコード）によって作られた可能性が高い」と指摘しています。高度な国家主導型攻撃ではなく、AI生成コードを使った「雑な」サイバー攻撃であるという点が、むしろ新たな脅威の形を示しています。

幸い、発覚は比較的早く、数時間以内だったとみられています。LiteLLM のCEO Krrish Dholakia 氏は現在、セキュリティ企業 Mandiant と連携して調査を進めており、「フォレンジックレビューが完了次第、技術的な教訓を開発者コミュニティと共有する」と述べています。

もう一つの問題：「認証」は何を保証するのか

広告掲載について

[email protected]

この事件には、もう一つの層があります。

LiteLLM のウェブサイトには、SOC2 と ISO 27001 という二つの主要なセキュリティコンプライアンス認証を取得済みであることが、現在も掲載されています。これらは企業がセキュリティポリシーを適切に整備していることを示す認証です。

しかし、その認証を発行したのは Delve というスタートアップ。Delve は Y Combinator 出身のAI活用コンプライアンス支援企業ですが、「顧客に対して実際のコンプライアンス適合状況を誤解させるような虚偽データを生成し、形式的な監査を行っていた」と別途告発されています。Delve 側はこの主張を否定しています。

エンジニアの Gergely Orosz 氏はX（旧Twitter）でこう書きました。「冗談かと思ったら……本当に LiteLLM は『Secured by Delve』だったのか」。

ここで重要な点を整理しておく必要があります。SOC2やISO 27001のような認証は、セキュリティインシデントを防ぐ「盾」ではありません。企業がセキュリティ管理のポリシーや手続きを持っているかを確認するものです。依存関係を通じたマルウェア混入は、認証があっても起こりえます。ただし、SOC2はソフトウェア依存関係の管理ポリシーも対象とするため、今回の事件との関係は引き続き議論されています。

日本企業への示唆：「使っているつもり」のリスク

この事件は、日本のAI開発環境にとっても他人事ではありません。

国内の多くのスタートアップや大企業のエンジニアチームが、LiteLLM のようなオープンソースのAIライブラリを積極的に活用しています。トヨタ、ソニー、NTTグループなど大手企業のDX推進部門でも、こうしたツールが内部プロジェクトに組み込まれているケースは珍しくありません。

サプライチェーン攻撃——つまり「信頼されたソフトウェアを経由した攻撃」——は、2020年の SolarWinds 事件以降、世界的に最も警戒されるサイバー脅威の一つです。日本でも経済産業省や情報処理推進機構（IPA）がソフトウェアサプライチェーンのリスク管理強化を呼びかけていますが、実際の現場では依存パッケージの監視体制が追いついていないケースが多いのが実情です。

さらに、日本企業が導入しているセキュリティ認証の「中身」についても、改めて問い直す機会かもしれません。認証取得そのものが目的化し、実質的なセキュリティ向上につながっていないケースは、日本でも決して少なくないでしょう。