AIの「もっともらしい嘘」を見抜く検証術

女性政治家のディープフェイク広告はなぜ配信され続けたのか

「AI画像スタイラー」を名乗るアプリKromixが、Metaのプラットフォームで広告を配信していた。宣伝文句は「Unleash Next-gen AI Magic」。だが実態は、著名な女性米国政治家に似た顔でポルノ動画を生成するサービスだった。Ars Technicaの報道によれば、広告の一つは政治家に似た女性が映った直後、同じ顔のポルノ動画に切り替わる構成だった。

有料会員には写真をアップロードさせ、「寝室でのレイプ」といったシナリオまで用意していたという。広告主のページは配信開始のわずか前、8月3日に作られたばかりでフォロワーはゼロ。それでも広告は配信され、男性ユーザーだけに向けて表示されていた。

Metaは規約上、性的画像を含む広告や同意のない親密画像、「ヌード化」アプリの宣伝を禁止している。にもかかわらず、Kromix関連アカウントは32件の広告を5〜46時間流し続けた。表示回数の大半は10回以下と少なかったが、これは氷山の一角に過ぎない。WIREDの調査では、AI生成の児童性的虐待素材を含む50件超の広告が2025年11月から8月まで確認され、一部は数千人に到達していた。

Metaは広告に性的画像を含めることを禁じ、同意のない親密画像や「ヌード化」「AIキス」アプリの宣伝も認めていないと説明する一方、該当の広告はWIREDの問い合わせ後に削除された。

Appleも同様だ。WIREDの問い合わせを受けてKromixをApp Storeから削除し、初回審査後に禁止コンテンツが追加された可能性を認めている。審査をすり抜けた後で機能を差し替える手口は、プラットフォーム側の事後対応の限界を露呈させた。広告主の見た目を信じるのではなく、配信元の実態を疑う視点が必要になる。

広告の「見た目」より先に何を確認すべきか

Kromixの事例が突きつけるのは、審査を通過した広告でも安全とは限らないという事実だ。個人がSNSで広告を見た際にできる確認は限られるが、いくつかの手がかりはある。

• 広告主ページの作成日とフォロワー数。作られたばかりで実績がないアカウントは警戒対象になる
• 宣伝文句が「制限なし」「実在人物も可」を強調していないか。合法的なAIツールはむしろ制限を明示する
• ターゲティングが不自然に狭くないか。特定の性別・属性だけに絞った広告は、公開の場では出しにくい内容を隠している可能性がある

企業の広報・マーケティング担当者にとっても他人事ではない。自社ブランドの画像や役員の顔がディープフェイク広告に悪用されるリスクは、政治家に限った話ではない。SNS上で自社名や役員名が検索に引っかかった際、どこに通報すればいいかを事前に整理しておく価値はある。

存在しない脆弱性がCriticalとして登録された経緯

画像や動画だけがAI生成の嘘の温床ではない。セキュリティの世界でも、もっともらしい「Critical脆弱性」がまかり通っていた。

GitHubリポジトリ「programmervuln/cveadvisory-」が公開したSQLiteの脆弱性アドバイザリーを、NVDはCriticalとして登録し、CISAの認定発行元も同意していた。ところがSQLite公式の脆弱性アドバイザリーページには、対象CVEが一件も掲載されていない。JFrogのリサーチチームが実際にコードとPoC(概念実証)を検証したところ、内容が破綻していた。

CVE-2026-51302はRed Hatが当初CVSS 10.0のCriticalと評価し、後に7.6のHighへ引き下げている。JFrogがSQLite公式リポジトリの3.41.0、3.51.2、3.51.3をDocker上でビルドし、AddressSanitizer付きでPoCを実行したところ、クラッシュは一切発生せず、クエリは正常に完了した。指摘された関数exprComputeOperands()自体、3.41.0には存在していなかった。

他のCVEも似たような穴があった。CVE-2026-51303は3.51.2と3.51.3のsrc/expr.cに差分がなく、提示された修正内容が確認できない。PoCも不正なSQLでパーサー段階から失敗していた。CVE-2026-51300が指した行番号は、脆弱性と無関係なコメントとメモリ確保処理を指しており、PoCは正常なSQLとして期待通りに実行された。CVE-2026-51296に至っては、示された行番号3555・3575が、対象ファイルの全行数2706行を超えていた。存在しない行を指していたことになる。

同じGitHubアカウントが公開した55件のアドバイザリーのうち54件が偽造で、残る1件も未検証のCVEメタデータに実在バグが包まれた状態だった。

関数名は実在するがバージョンが違う。行番号は実在するが中身が違う。CVSSスコアは権威ある機関がつけている。この部分的には本物という作りが、生成AIによる偽情報の厄介さを物語る。JFrogはこの調査結果をGHSA、Red Hat、NVDに正式報告した。

セキュリティ担当者は何をチェックすればいいか

Criticalな番号を見た瞬間にパッチ適用や緊急会議を始めるチームは多い。だがSQLiteの一件は、番号がついているだけでは信用できないことを示した。実務で有効な確認手順は次の通りだ。

1. ソフトウェア公式のアドバイザリーページに同一の脆弱性が掲載されているか照合する
2. PoCを自社の隔離環境(サンドボックス)で実際に動かし、主張通りの挙動が再現するか確かめる
3. 指摘されたコード行・関数名が、対象バージョンに実在するか確認する
4. CVSSスコアを付与した機関が複数あれば、その評価が変動していないか(今回は10.0→7.6のような引き下げ)を追う

NVDやCISAの認定発行元でさえ誤って承認した事実は重い。組織の名前や肩書きがついているからといって、内容の検証を省略していい理由にはならない。生成AIがそれらしいコード片と行番号を作文できる時代、一次情報との突き合わせが唯一の防御線になる。

まとめ

広告の見た目、CVEの番号、権威機関の認定。どれも「もっともらしさ」を装う土台にAIが使われ始めている。判断基準はシンプルだ。配信元の実態、公式の一次情報、実際に動かした検証結果、この三つが揃わない情報は保留する。拡散も対応も急がず、まず確かめる習慣が仕事にも生活にも要る。