ChatGPT検索ポイズニング、374ブランドに被害 AI回答における信頼の溝を露呈
ChatGPT、Gemini、Google AI Overviewが取得する情報源に攻撃者が不正な連絡先情報を埋め込んだ結果、ChatGPTの検索ポイズニングは少なくとも374社に影響したと報じられている。Vigilance Securityによると、標的にはDelta、Lufthansa、Bank of America、Airbnb、Chase、Qatar Airways、Tripadvisorが含まれていた。
Vigilanceが「Dark Sourcery」と呼ぶこの作戦は、AIアシスタントによる親切な回答を詐欺の配信手段へと変える。ユーザーが航空会社の予約電話番号や銀行のサポートページを尋ねると、システムは信頼できる案内として、不正な電話番号、フィッシングリンク、偽のログインページを返す可能性がある。
この違いは重要だ。従来のフィッシングでは、被害者に対して一方的に届いたメッセージを信用させようとする。これに対し今回のキャンペーンは、ユーザーが正当な質問を携えてChatGPTやGoogleにアクセスするのを待ち、その回答に与えられる権威を悪用したとされる。
今回の調査結果は、不正なサポート情報がAI生成の検索結果に入り込む可能性を示すこれまでの証拠を拡大するものだ。同時に、検証上の問題も浮き彫りにした。Vigilanceは事例を公開し、数万件の悪意あるページについて説明したが、完全なデータセットとテスト手法は、第三者が独立して検証できる形では公開されていない。
したがって、目下の競争はハッカー対個別ブランドではない。AI回答を支える検索・検証システムに対する、自動化されたコンテンツ汚染との戦いだ。アシスタントが企業の正規サポート窓口を案内するのか、それとも顧客を犯罪者のコールセンターへ誘導するのかは、この戦いの結果に左右される。
374ブランドを標的にしたキャンペーンは、詐欺を回答の内部へ持ち込んだ
このキャンペーンの最大の新しさは、詐欺情報をAI生成の回答に組み込み、ユーザーが要約生成を検証済み情報と誤認しかねない点にある。
Vigilance Securityは2026年9月23日に調査結果を公表した。同社のキャンペーン調査によると、攻撃者は整った形式の投稿、PDF、レビュー、サポートページを公開ウェブ上に分散させた。
これらの文書は、有名企業の名称と、詐欺師が管理する電話番号、メールアドレス、ログインページ、ソフトウェア手順を関連付けていた。検索・情報取得システムはその後、カスタマーサービスに関する質問へ回答する際に、こうした関連付けを収集する可能性がある。
Vigilanceのリサーチ担当バイスプレジデント、Ariel Simon氏は、研究者らが数万件の悪意あるページを発見したと述べた。チームは、この活動を航空会社、銀行、旅行企業、テクノロジーベンダー、その他の大企業にまたがる少なくとも374の標的事業者と結び付けた。
この数値は完全な実態調査ではなく、研究上の発見として扱うべきだ。Vigilanceは、この数値の算出に用いたすべてのページ、クエリ、ブランド、モデル応答を機械可読な一覧としては公開していない。そのため、独立研究者は現時点で全件数を再現できない。
それでも、後続報道で説明された証拠は懸念される。Vigilanceの研究者は、汚染された情報を通じて返された複数の電話番号に電話をかけたと報じられている。応対者は、クレジットカード情報を求める前に、フライト変更や銀行口座のロック解除を申し出たという。
研究者らはまた、チャットボットの回答に含まれた不正な電話番号を通じて、支払い情報を開示してしまったとする人々の苦情も確認した。これらの報告はキャンペーンの基本的な脅威モデルを裏付けるが、金銭被害を受けた被害者数を確定するものではない。
影響を受けたブランドが虚偽情報を提供したと非難されたわけではない。顧客が緊急性の高い、あるいは金銭的に敏感な状況で既にそれらの企業を検索しているため、その名称が餌として機能した。
欠航に直面した航空会社の顧客は、すぐの支援を求める。口座がロックされた銀行顧客は安心を求める。どちらの状況も、電話番号やドメインを吟味する時間を短くする。
従来の検索ポイズニングは、リンクの表示順を決めるランキングシステムを悪用する。AI回答のポイズニングはさらに一歩進み、攻撃者の主張を抽出して新たに生成された回答として提示する。
これにより、従来なじみのあった警告サインが消える可能性がある。ユーザーは、不審なページデザイン、不自然な見出し、奇妙な検索結果を目にしないかもしれない。目にするのはアシスタントのインターフェースと、それに続く直接的な回答に見えるものだ。
その結果、このキャンペーンは二重の被害者を生む。消費者は詐欺被害に遭い、なりすまされた企業は、自ら管理したことのないインフラに起因する苦情、サポートコスト、評判の毀損、インシデント対応を引き受けることになる。
ここに変化がある。不正な連絡先情報は長年オンライン上に流通してきたが、AIアシスタントはいま、被害者が攻撃者の元ページを訪れることなく、それを個別化された案内として包装できる。
ChatGPT検索ポイズニングはいかにGEOを詐欺チャネルへ変えるのか
ChatGPT検索ポイズニングは、基盤モデルそのものや直接的なプロンプトインジェクションの脆弱性ではなく、情報源の選択を悪用する。
生成エンジン最適化、すなわちGEOとは、AI回答システムがオンライン上の情報を取得・再利用しやすくなるよう構造化することを指す。回答エンジン最適化、すなわちAEOは、簡潔な回答、エンティティの関連付け、機械可読な表現に焦点を当てた、密接に関連する手法だ。
正当な出版社は、回答エンジンが正確な情報を理解しやすくするためにこれらの手法を使う。攻撃者も同じ論理を偽のサポート情報に適用できる。
悪意あるページは、ブランド名の横に不正な電話番号を繰り返し記載するかもしれない。想定される顧客の質問に極めて近いQ&A形式を使うこともある。「公式」「フリーダイヤル」「緊急予約向け」といったラベルを番号に付けることも可能だ。
この種の情報が複数の場所に現れれば、攻撃者は利益を得る。すべてが同一キャンペーンによるものであっても、反復によって虚偽の関連付けが裏付けられているように見えることがある。
Aurascapeによるこれまでの調査は、航空会社のサポートに関するクエリを通じてこの仕組みを記録した。同社のポイズニング調査では、侵害されたウェブサイト、アップロードされたPDF、YouTubeの説明欄、Yelpのレビュー、クラウドホストのファイルを通じて不正な電話番号が配布されていたことが判明した。
一部の汚染コンテンツは、政府、大学、既存の大手出版社のドメインに表示されていた。こうしたドメインは、新規登録された詐欺サイトよりも強い信頼性・可視性シグナルを持ち得る。
攻撃者は必ずしもサイト全体を侵害する必要はない。公開されたアップロード機能、放置されたページ、コメント欄、レビューシステム、管理が不十分な文書リポジトリが、インデックス可能な攻撃面を提供することがある。
鮮度も攻撃を助ける。特に旅行の混乱、返金ポリシー、ソフトウェア更新、アカウント復旧手順に関するサポートクエリは頻繁に変化する。最近公開された文章は、その出所がなりすまし対象企業と無関係であっても、関連性が高いように見える可能性がある。
このため、Gemini AIのポイズニングや類似の攻撃を、単一の技術的欠陥へ還元するのは難しい。リトリーバーが汚染された情報源を選んだから、モデルが主張を誤って統合したから、あるいは防御策が危険な連絡先情報を認識できなかったから、回答が誤る場合がある。
Dark Sourceryキャンペーンは、従来型のプロンプトインジェクションとは異なると報じられている。プロンプトインジェクション攻撃では、悪意あるコンテンツがAIに通常の振る舞いを上書きさせるための指示を与える。
ここでの虚偽コンテンツは、指示ではなく宣言のように見える場合がある。特定の電話番号が銀行または航空会社のものであるとシステムに伝えるのだ。アシスタントは、設計どおりに動作しながらその記述を繰り返してしまう可能性がある。
OpenAIも、取得したコンテンツには注意が必要だと認めている。生成されたリンクに関するガイダンスでは、第三者がChatGPTに虚偽を伝えたり、悪意ある指示を挿入したりする可能性があるとし、リンク先を信用する前に確認するよう利用者へ勧めている。
この警告はリスクの一部に対応するが、電話番号はより難しいインターフェース上の問題を生む。番号そのものからは、認識可能なドメインを通じて所有者を確認できない。ユーザーが電話をかけ始めると、説得力のある応対者が不足しているソーシャルエンジニアリングの層を補える。
AIによる要約生成は、情報源間の不一致も隠し得る。従来の検索結果ページでは、ユーザーは企業公式ドメインとフォーラム、PDF、なじみのないサイトを比較できる。生成された段落は、それらの情報源を一つの自信に満ちた推奨へ圧縮できる。
引用リンクがあっても、この問題が自動的に解決するわけではない。10件の引用は1件より強固に見えるかもしれないが、10件すべてが同じ埋め込まれた情報を反復している可能性がある。効果的な検証は、引用数だけでなく、情報源の独立性、所有者、関連性を測定しなければならない。
Google AI Overview詐欺は、情報取得と検証の違いを露呈する
AIシステムは、連絡先情報が記載された組織に実際に属するかを検証せずとも、もっともらしい回答を取得し、それを裏付けるページを引用できる。
Google AI Overview詐欺は、その隔たりを示している。生成された要約はSearch内でも特に目立つ位置を占め、特に回答が直接的な表現を使う場合、ユーザーはその配置をお墨付きと受け止める可能性がある。
これまでの調査では、AI Overviewsに偽の航空会社サポート番号が表示される事例が見つかった。金融・旅行サービスを検索した消費者が不正な連絡先情報を受け取ったとの報告もあった。
GoogleはWIREDに対し、同社のスパム対策は非常に有効であり、可能な場合は公式カスタマーサポート番号を表示していると述べた。AI Overview詐欺に関する報道によると、同社は詐欺対策を強化しており、追加検索による電話番号の確認を利用者に促しているとも説明した。
この対応は中心的な緊張関係を示している。GoogleはAI Overviewsを有用な情報へのより速い経路として提示する一方、推奨する防御策は、要約が簡略化するはずだった比較をユーザー自身に行わせるものだ。
Googleは検索悪用対策におけるより広範な進展も報告している。2025年の詐欺対策レポートでは、新システムが詐欺ページを20倍多く検出し、2024年中に公式サイトを装う詐欺を70％超削減したとしている。
これらの数値は、Google Searchの保護対策全般を対象とするものだ。Dark Sourceryキャンペーンを独立して測定したものではなく、AI Overviewsが生成するサポート電話番号の誤り率も示していない。
OpenAIは、ChatGPT searchについても類似の選択モデルを説明している。自動システムが意図、関連性、最新性を考慮し、回答にはインライン引用や追加の情報源を含められる。
しかし、関連性は本人性の検証ではない。あるページは「Bank of America support number」という語句に極めて関連性が高くても、Bank of Americaが一度も公開していない情報を含む可能性がある。
同じ弱点は、あらゆる製品に見られる。ウェブには、企業の電話番号、返金ポータル、ソフトウェアパッケージ、アカウント復旧ページをすべて網羅する、普遍的で認証済みのレジストリが存在しない。公式ウェブサイトは強い証拠となるが、組織は多くの場合、地域別ドメイン、アプリ、委託先、パートナーシステムにサポートを分散している。
攻撃者はこの曖昧さを悪用する。複数の窓口や急な変更が想定されるクエリに狙いを定める。航空会社、オンライン旅行サービス、銀行、ソフトウェア企業は、このパターンに当てはまる。
プラットフォームは精度の問題にも直面している。見慣れない番号をすべてブロックすれば、アシスタントの有用性は低下する。複数のインデックス済みページが同じ番号を繰り返しているという理由で許可すれば、合意を人工的に作り出す攻撃者を利する可能性がある。
このトレードオフは、AI検索の安全性を通常のコンテンツモデレーションと分けるものだ。システムは、テキストが攻撃的かどうかだけでなく、特定の現実世界の関係性が真正なものかどうかも評価しなければならない。
電話番号は、ある文脈では無害でも、別の文脈では詐欺的になり得る。正規のコールセンターは、開示されたアウトソーシング契約を通じて複数ブランドを支援できる。詐欺組織は、1つの番号を無関係な多数の企業と結び付けることで、その構図を模倣できる。
したがってGoogle、OpenAI、その他の回答提供事業者には、エンティティを認識する検証が必要となる。回答が高リスクの連絡先情報を示す際には、一般的なウェブ上の反復から正当性を推測するのではなく、一次情報の記録と照合すべきだ。
求められる行動に応じて、検証の負担も変えるべきである。誤ったレストランの推薦は不便にとどまる。偽の銀行ログインページやアカウント復旧用番号は、直接的に金銭的損失につながり得る。
374社という数字は重大だが、重要な疑問は残る
入手可能な証拠は信頼できる攻撃パターンを示している一方で、キャンペーンの規模、成功率、製品ごとの影響は未解決のままである。
Vigilanceは、少なくとも374社の被害企業と数万件の悪意あるページを検出したと述べている。その後のセキュリティ報道では、著名な標的が挙げられ、不正な事業者へのテスト通話についても説明されている。
しかし、公開されている調査には完全な母数が示されていない。研究者が374社を見つけるまでに何ブランドをテストしたのか、また各AI製品が繰り返しのクエリで汚染された情報をどの程度の頻度で返したのかは明らかではない。
生成AI検索の結果は、日付、所在地、アカウント状態、クエリの表現、製品バージョンによって変動し得る。不正な番号が一度でも表示されれば安全上の失敗ではあるが、大半のユーザーに一貫して表示される場合とは異なる。
「被害企業」という表現にも慎重な解釈が必要である。攻撃者がブランドをなりすましたページを公開したこと、AIシステムがそのページを取得したこと、あるいはユーザーが実際に不正情報を受け取ったことを指し得る。
これらの段階を一括りにすべきではない。第1段階は攻撃者の意図を、第2段階はプラットフォームの露出を、第3段階は消費者被害を測るものだ。
匿名化されたクエリログ、タイムスタンプ、スクリーンショット、ソースURL、モデルバージョン、地理設定、反復テストの結果があれば、公開情報はより強固になる。そうすれば研究者は、持続的な汚染と一時的な出力を区別できる。
キャンペーン名も、独立して特定された犯罪グループの名称ではなく、Vigilanceによる呼称である。現在入手可能な報道では、すべての悪意あるページに責任を負う単一の運営者は特定されていない。
最適化されたコンテンツを公開するコストが低いため、複数のグループが似た戦術を採用している可能性がある。共通する番号、ホスティング基盤、テンプレート、決済フローがあれば、協調的な管理を示すより強い証拠となる。
GEOという用語をめぐっても別の不確実性がある。これは生成AIによる取得を意図して作られたコンテンツを正確に表すが、その基礎にある手法の一部は、従来のSEOポイズニング、レビュー・スパム、ドメイン侵害、テクニカルサポート詐欺に似ている。
新しさは主に配信レイヤーにある。AIアシスタントは、会話形式の回答の中で、仕込まれたデータを選択し、書き換え、推奨することができる。
そのため、これは単なる看板の掛け替えではない。従来のSEOポイズニングでは、検索インターフェースと詐欺行為の間に、なお疑わしい遷移先が存在する。生成された回答は、その間を省くことができる。
それでも、誤った番号のすべてが意図的なAI操作を示すわけではない。モデルは連絡先情報をハルシネーションで生成したり、別々のソースから数字を組み合わせたり、古い情報を繰り返したりする可能性がある。調査者は、意図的な汚染と通常の事実誤認を区別する必要がある。
その違いは緩和策にとって重要だ。ハルシネーションには、より強力な根拠付けと不確実性の扱いが求められる。組織的なポイズニングには、不正利用の検知、インフラのマッピング、削除要請、ソースの評判管理が必要となる。
企業も、自社のモニタリングで証明できる範囲を過大に主張すべきではない。少数のプロンプトをテストしただけでは、すべての顧客が同じ回答を見ることの証明にはならない。逆に、今日のテスト結果が問題なくても、汚染されたコンテンツが昨日一度も表示されなかったことの証明にはならない。
責任ある結論は、この話の最も警戒的な見方よりも限定的である。Vigilanceは、プラットフォームとブランドによる調査に値する、大規模かつ活発なキャンペーンを報告している。公開された証拠は、総露出量や損失をまだ定量化していない。
銀行、航空会社、ソフトウェアベンダーはいまAI回答の問題に直面している
企業はもはや、ウェブサイト、広告管理、従来型の検索監視だけでサポート窓口のアイデンティティを守ることはできない。
標的となった企業は、安全なシステムと正確な連絡先ページを備えていても、汚染されたAI回答に表示される可能性がある。セキュリティチームは、すべてのレビュー、アップロードされたPDF、侵害された大学ページ、チャットボットの取得結果を管理しているわけではない。
これはブランド保護を、なじみのない環境へと拡張する。チームは、アシスタントが何を答えるか、どのソースを引用するか、見慣れない電話番号やドメインがクエリをまたいで繰り返し現れるかを監視しなければならない。
優先すべきクエリには、アカウント復旧、予約、返金、支払い、ソフトウェアのダウンロード、テクニカルサポートが含まれる。これらのテーマは、緊急性と認証情報または金融情報の要求を組み合わせる。
監視には地理的・言語的なカバー範囲も必要だ。航空会社や銀行は地域ごとの連絡窓口を通じて業務を行う一方、攻撃者は現地の番号を想定する旅行者や顧客を狙うことができる。
有用なテストは、1つのアシスタントに「カスタマーサービス」と尋ねるだけではない。表現、製品、場所、緊急性、求める行動を変化させる。そのうえでチームは、返されたすべての番号、メールアドレス、URL、ダウンロード指示を、認証済みの企業記録と照合できる。
繰り返し現れる指標は、エスカレーションに値する。無関係な複数の航空会社名のそばに同じ不審な番号が現れれば、共有された犯罪コールセンターを示す可能性がある。複数の偽ソフトウェアサポート回答で引用されるドメインは、より広範なフィッシング活動を明らかにするかもしれない。
顧客からの苦情も同じプロセスに組み込むべきだ。「チャットボットにこの番号を案内された」という報告は、単なるサポート上の問題ではなく、脅威インテリジェンスである。
企業には、AI提供事業者と検索エンジンに対する迅速な訂正経路も必要となる。既存の不正報告システムは、多くの場合、有害なウェブページに焦点を当てている。この脅威では、ページの削除、回答の訂正、関連ソースの再評価、重複インフラの特定が必要になる可能性がある。
明確な一次情報の連絡先ページも引き続き重要だ。組織は、一貫性があり機械可読なサポート情報を維持し、曖昧さを生む古い地域別ページを削除すべきである。
また、スタッフがリモート操作ソフトウェア、暗号資産による支払い、ギフトカード、完全な認証情報を求めることはないと顧客に警告すべきだ。こうした警告は、不正な事業者がすでに最初の通話を受けている場合にも役立つ。
企業利用では、さらに別の露出層が加わる。従業員は、パッケージ名、コマンドラインの手順、ベンダーポータル、アカウント復旧手順について、ますますアシスタントに尋ねるようになっている。
汚染された消費者向け回答は、決済カード情報を盗む可能性がある。汚染された職場向け回答は、従業員をマルウェア、認証情報を窃取するページ、または侵害されたソフトウェア依存関係へ誘導する可能性がある。
したがって、セキュリティ管理は実行時に行動可能な出力を検証すべきである。リンク、電話番号、ソフトウェアパッケージ、コマンド、支払い指示は、一般的な説明文よりも厳しい精査に値する。
ナレッジワーカーは、重要な意思決定の背景にあるソースの経路を保存することで、露出を減らせる。検索可能なパーソナルナレッジベースは、公式手順や過去の検証を保持できるが、保存された資料も連絡先情報が変更された際には見直す必要がある。
最も安全なユーザー行動は、依然として直接検証である。企業の公式アプリを開くか、既知のドメインをブラウザに直接入力する。適切な場合には、決済カードや正式なアカウント書類に印刷された番号を使用する。
2つ目のAI回答を独立した確認として扱ってはならない。ChatGPT、Gemini、Google AI Overviewは重複するソースを取得する可能性があるため、2つの一致する回答が同じ汚染ページを反映していることがあり得る。
AI回答提供事業者が脅威を封じ込められるかを示すもの
次の試験は、報告された詐欺ページを個別に削除するだけでなく、プラットフォームが高リスクの事実を生成前に認証できるかどうかである。
最初の兆候は、電話番号、ログインページ、支払い指示に対する製品レベルの扱いとなる。有意義な対応であれば、これらの詳細には通常の事実主張よりも厳格な検証が適用される。
サポートに関するクエリでは、システムは企業の認証済み一次ドメインを優先し、ソースを明確に表示できる。認証済みの記録がなければ、第三者ページから番号を合成するのではなく、番号の提示を控えることもできる。
これにより、ChatGPT検索ポイズニングが回答レイヤーで封じ込められるという見方が強まる。新たに仕込まれた番号が公式連絡先として現れる報告が続けば、その見方は弱まるだろう。
2つ目の兆候は、透明性のある測定である。Google、OpenAI、その他の提供事業者は、攻撃者を助ける防御策を公開する必要はないが、有用な集計データを公表することはできる。
関連する指標には、一次情報に基づく根拠付けを受けるサポート詳細クエリの件数、確認済みの汚染ソースが消えるまでの速さ、高リスク回答が警告または拒否を引き起こす頻度が含まれる。
独立した再現も重要である。研究者は、一貫したクエリセットを製品、地域、日付をまたいでテストすべきだ。そして、汚染された引用と、実際に不正な詳細を繰り返す回答を分けなければならない。
3つ目の兆候は、ブランド、ホスティング提供事業者、レビュー平台、AI企業をまたぐ協調対応である。悪意ある文書をオンラインに残したまま1つのAI回答だけを削除しても、別のシステムがそれを取得できてしまう。
同様に、同じ運営者が多数のアカウントやドメインを管理している場合、1件の文書を削除しても効果は限定的だ。インフラレベルの妨害は、繰り返し使われる番号、テンプレート、ホスティングのパターン、支払い要求を結び付けなければならない。
Dark Sourceryの公開は、ウェブ取得を直接的な推奨へと変えるインターフェースを持つChatGPT、Gemini、Google AI Overviewに即時の圧力をかける。また、顧客がこれらのシステムを非公式のサポート窓口として利用するすべての組織にも圧力をかける。
ユーザーにとって実践的な原則は単純だ。金銭、認証情報、ダウンロード、アカウントアクセスが関わる場合、AI生成の連絡先情報は未検証の手掛かりとして扱う。
企業にとって取るべき行動は、より広範である。AIシステムが自社のサポートチャネルをどのように表現するかをテストし、引用されたソースを収集し、顧客からの苦情が最初の警告となる前に汚染された回答を訂正するプロセスを構築する。
最後の問いは、AIアシスタントが電話番号を見つけられるかどうかではない。その番号を誰が管理しているのかを、ユーザーに信頼を求める前にアシスタントが確立できるかどうかである。
