わずか半年前、3億5,000万ドルのシリーズCラウンドを完了し時価総額100億ドル（約1兆5,000億円）を突破したAIデータ訓練スタートアップMercor。しかし2026年3月31日のデータ侵害公表以降、そのブランドは急速に傷つきつつある。判明した被害規模は4TBという膨大なものであり、AIモデル開発の裏側を担うサードパーティ企業のセキュリティリスクを改めて業界全体に突きつけた事件となった。

何が起きたのか——オープンソースツールを起点にした連鎖侵害

侵害の入口となったのは、1日に数百万回ダウンロードされる人気オープンソースライブラリ「LiteLLM」だ。このツールに40分間だけクレデンシャル収集マルウェアが混入し、Mercorの認証情報が盗み出された。攻撃者はそこで得た認証情報を使ってさらに別のシステムやアカウントへアクセスし、次の認証情報を入手するという連鎖的な侵害を繰り返した。

40分間という短さに驚く読者も多いだろうが、サプライチェーン攻撃の恐ろしさはここにある。入口となるツールが広く使われているほど、攻撃者は一度の侵害で複数ターゲットを同時に狙える。LiteLLMのように大規模なエコシステムを持つツールであれば、40分あれば十分に致命的なアクセスを確立できてしまう。

流出したとされるデータには候補者プロフィール、個人識別情報（PII）、クライアント企業データ、ソースコード、APIキーが含まれる。Mercorは現時点でデータの真正性についてはコメントせず、調査継続中の立場を維持している。

MetaやOpenAIへの波及——AI訓練データの機密性リスクが顕在化

Mercorが担う事業の本質は「AIモデルを賢くするためのカスタムデータセットと訓練プロセスの管理」だ。これはモデルメーカーにとって最大の企業秘密とも言える領域である。

MetaはMercorとの契約を無期限停止したと複数のメディアが報じている。MetaがMercorの競合であるScale AIに約2兆円を投じた後も、Mercorとの取引を継続していたという事実が、その信頼の深さを物語っている。その関係が今回の侵害で揺らいだ意味は小さくない。

OpenAIも自社の露出状況を調査中と認めたが、現時点では契約の停止・終了はないとしている。ただし業界内では、他の大手モデルメーカーも関係見直しを検討しているとの情報がある。

「認定証」への過信という落とし穴——DelveとLiteLLMの責任論

今回の訴訟で興味深いのは、LiteLLMそのものとAIコンプライアンス企業「Delve」が被告に名を連ねた点だ。LiteLLMはセキュリティ認定取得にDelveを利用していたが、DelveはAIコンプライアンス認定の水増しや形式的な審査を行ったとして内部告発を受けている。Delveはこれを否定しつつも、運営上の変更を実施中だという。

セキュリティ認定証は「ハッカーを撃退する盾」ではなく、「リスク管理プロセスが機能しているかの確認」に過ぎない。認定取得プロセス自体が形骸化していたとすれば、その土台に立つ企業のリスクは認定証の有無と無関係に存在し続ける。

実務への影響——日本のエンジニア・IT管理者が明日から取るべき行動

この事件は決して「海外のスタートアップの話」で終わらない。日本のIT現場でも以下のリスクが直接関係する。

1. オープンソースのサプライチェーン監視を強化する LiteLLMのように広く使われるライブラリほど攻撃対象になりやすい。依存ライブラリの更新履歴や異常なコミットを監視する仕組み（例：Dependabot、Socket.dev、Sigstore等）を導入済みか見直す機会だ。

2. AIサービスの委託先評価にセキュリティ審査を組み込む AIデータ訓練や推論処理をSaaS・スタートアップに委託する場合、そのベンダーが何を保持しているかを把握せずに契約するのはリスクだ。「SOC 2認定あり」の一点だけを信頼するのではなく、認定取得プロセスの実態やインシデント対応の実績も評価項目に加えるべきだ。

3. APIキーの最小権限・ローテーション運用を徹底する 今回の流出物にAPIキーが含まれる点は見逃せない。複数サービス共通のキーを使いまわしていると、1か所の侵害が連鎖する。最小権限の原則と定期ローテーションを改めて徹底したい。

4. 個人情報取り扱い業者の委託先管理を点検する 個人情報保護法の観点から、委託先が実際にどのようなセキュリティ管理をしているかの確認義務が委託元にも生じる。AI活用を進める過程でこの視点が抜け落ちていないか確認を。

筆者の見解

AIモデルを訓練するためのデータを扱う企業は、ある意味でモデルメーカー以上に「高価値なターゲット」だ。完成品よりも「完成品を作るための型と材料」の方が狙われやすいのは製造業の世界でも同じ原理だろう。Mercorがその典型となってしまった。

気になるのは、根本原因がオープンソースツールの40分間の汚染だったという点だ。開発の生産性を高めるためにオープンソースエコシステムを活用するのは正しい選択だが、そのエコシステム自体のセキュリティを誰が担保するかという問いは、今なお業界全体への宿題として残っている。

今回の件は、単なる一企業のセキュリティ事故ではなく、AI時代のソフトウェアサプライチェーン全体が抱える構造的な脆弱性の問題だ。「AIを使えば生産性が上がる」という議論と同じ重みで、「AIサービスのサプライチェーンをどう信頼するか」を議論すべき時期に来ている。認定証や資金調達額は安全の証明にはならない——この教訓を、日本のIT業界が自分事として受け取ってほしい。

出典: この記事は After data breach, $10B-valued startup Mercor is having a month の内容をもとに、筆者の見解を加えて独自に執筆したものです。