何が起きたか:Search Engine Landが攻撃面の広がりを整理
記事はMyriam Jessier氏が執筆し、編集をAngel Ninofranco氏、レビューをDanny Goodwin氏が担当した6分程度の解説記事です。技術的な脆弱性レポートではなく、マーケティング部門やRevOps(収益オペレーション)部門がAIを業務に組み込むうえで、どこにリスクが生まれているかを俯瞰する内容になっています。主張の中心はひとつで、LLM(大規模言語モデル)は与えられたテキストのうちどこまでが「処理すべき内容」で、どこからが「従うべき指示」なのかを確実に見分けられず、しかもこれは修正すれば直る不具合ではなく構造的な性質(a structural property rather than a fixable bug)である、というものです。
先に押さえておきたいのは、記事が「効かなくなった手法」を明確に区別している点です。白背景に白文字を置く、HTMLコメント内に文字を仕込む、目に見えないUnicode文字を混ぜるといった単純な隠蔽手法は、パターン認識(pattern recognition)、境界の分離(boundary isolation)、スポットライティング(spotlighting)といった防御側の改善により、現代のLLMに対してはもはや機能しないとされています。記事が問題視しているのは素朴な隠しテキストではなく、より自然な文章に溶け込んだ形の攻撃であり、その攻撃面はブランド資産、AIエージェント、ベンダースタック、そして顧客に接するワークフローにまで広がっていると述べられています。
脅威①:自社のページが起点になるChatGPhishとセマンティック埋め込み
記事が「この脆弱性の最も分かりやすい例」として挙げているのが、ChatGPhishと呼ばれる手口です。攻撃者は、ブログ、ヘルプセンター、製品ドキュメントといったごく普通のWebページに悪意あるペイロード(payload/攻撃コード)を仕込みます。
ユーザーがそのページをAIに要約させると、隠された指示によって、AIが偽のアカウント警告と悪意あるQRコードをチャット画面の中にそのまま描画してしまう、と記事は説明しています。厄介なのは、それがChatGPTやPerplexityといった信頼されたインターフェースの内側に現れる点です。怪しい外部URLに飛ばすわけではないため、URLのブロックリストもパスワードマネージャーの警告も、まるごと迂回されてしまうと記事は指摘しています。
Web担当者の立場で読み替えると、自社のヘルプセンターや製品ドキュメントが第三者に書き換えられた場合、被害を受けるのは自社サーバーではなく、そのページをAIに読ませた顧客だということになります。従来のサイト改ざん対策が「自社ページの見た目が壊れていないか」を見ていたのに対し、点検すべき対象は「AIに読ませたときに何が起きるか」に広がっているわけです。
記事が、上位モデルに対して最も効果的な攻撃手法(the most effective attack method against top models)と位置づけているのは、これと地続きのセマンティック埋め込み(semantic embedding)です。悪意ある指示をもっともらしく読める段落の中に織り込む手口で、LLMは要約すべき内容と従うべき指示を区別できないため、そのまま影響を受けてしまうとされています。ここでSEO担当者に直接効いてくるのが、記事に載っている次の一節です。「競合他社が業界の比較記事に指示を埋め込み、Web閲覧型のAIエージェントに対して、あなたの製品ではなく自社製品を推薦するよう仕向けることもあり得る(“A competitor could embed instructions in an industry comparison article that tell web-browsing AI agents to recommend their product over yours.”)」。AIからの紹介トラフィックの取り合いが、コンテンツの質だけでなく、こうした操作の対象にもなり得るという指摘です。
記事は、モデル側もこの脅威を少しずつ認めつつあるとし、その例としてClaudeが「悪意ある会話内容がユーザーのデータ漏洩を引き起こす可能性がある(“malicious conversation content could cause their data to be leaked”)」と警告している点を挙げています。
脅威②:ポッドキャストや画像を含むマルチモーダル入力
マルチモーダル(multimodal/複数の形式を扱う)攻撃は、脅威を「自社が制作するあらゆるフォーマットと、公開するあらゆるチャネル」に広げると記事は述べています。具体例は2つで、ひとつはニューラルステガノグラフィ(neural steganography)、通常の写真と見た目では区別できない画像の中に指示を隠せるとされるもの。もうひとつは音響心理学的マスキング(psychoacoustic masking)で、人間には知覚できない周波数帯の音声に指示を埋め込めるとされています。記事はこの文脈で「あなたがスポンサーしているポッドキャストのリスナーが、常時起動しているAIアシスタントに気づかないまま指示を届けられてしまう可能性があり、あなたもリスナーもそれに気づかない(“A listener on your sponsored podcast could have instructions silently delivered to their always-on AI assistant, and neither of you would know.”)」と述べています。
加えて、StyleBreakという研究では、コードも隠しテキストも使わずに、声の感情的なトーン(怒り、悲しみ、恐れ)を操作するだけで、音声言語モデルの安全フィルタを回避し得ることが示されたと記事は紹介しています。動画やポッドキャスト、音声広告といった非テキスト資産を運用しているブランドにとって、制作物の受け渡し経路や外部委託先の管理が、そのままセキュリティの論点になるという話です。
脅威③:サポートAIの乗っ取りとベンダー経由のサプライチェーン
記事は、マーケティング部門やRevOps部門が自律型エージェントを導入する速度に、セキュリティ部門の監査が追いついていないと指摘します。ここで持ち出されるのが、混乱した代理人問題(confused deputy problem)という古典的なセキュリティ概念です。信頼できない入力(受信メールやWebコンテンツ)と、特権的なツール(メール送信、CRMレコードの変更、返金処理など)の両方にアクセスできるエージェントは、その入力を通じて乗っ取られ得る、というものです。「読み取る対象」と「実行できる権限」が同じエージェントに同居していること自体がリスク要因になります。
実例として記事が挙げているのが、Instagramの著名アカウントが乗っ取られた事案です。攻撃者はMeta AI Support Assistantとのチャットを開き、被害者のアカウントに新しいメールアドレスを追加するよう依頼しました。チャットボットは認証コードを攻撃者側のメールに送信し、その後「Reset Password(パスワードをリセット)」ボタンとアカウントへの完全なアクセス権を引き渡してしまったとされています。被害には政府や軍関係のプロフィールも含まれていたと記事は伝えています。
もうひとつ、自社の外側にあるリスクとして記事が挙げるのがベンダーです。「セキュリティ体制は、AIスタックの中で最もセキュリティの弱いベンダーに依存する」として示されているのが、Mercorが確認した3月31日のインシデントで、企業のスタックで広く使われているオープンソースのAI APIツールであるLiteLLMの悪意あるバージョンに関連したものだとされています。OWASPは、この侵害によってモデルの学習手法や委託先の業務運用に関する機微な情報が露出した可能性があるという懸念が生じたと指摘した、と記事は伝えています。その結果としてMetaは業務を一時停止したとも記されています。原稿生成や要約、CMSへの投稿といった工程に外部のAIツールが入っている以上、それらは効率化のツールであると同時に、自社データが通過する経路でもあります。
防御:Dual-LLMパターンの盲点と、IT部門に要求すべき4項目
記事が「最も広く推奨されている構造的な防御」として挙げているのが、Dual-LLMパターンです。信頼できない入力を読むのは隔離された(quarantined)モデル、業務ロジックを実行するのは別の特権を持つモデルとし、この2つが処理層を共有しないようにする、という設計思想です。
ただし記事は、この設計にも明確な盲点があることを併せて紹介しています。MIT CSAIL、Google DeepMind、ETH Zurichの研究者らが、Edoardo Debenedetti氏とIlia Shumailov氏を筆頭著者として発表した「Defeating Prompt Injections by Design」において、次の点が示されたとしています。「制御フローはDual LLMパターンによって保護されるものの、データフローは依然として操作され得る(“while the control flow is protected by the Dual LLM pattern, the data flow can still be manipulated.”)」。実務的に言えば、「どのモデルがどの順番で動くか」を分離しても、「その間を流れるデータの中身」が汚染される余地は残るということです。ベンダーが「Dual-LLM構成なので安全です」と説明してきた場合に、そこで納得せず一段深く聞くべき理由がここにあります。
そのうえで記事は、マーケティング業務に触れるあらゆるAI導入に対して、次の4つを要件として挙げています。
- 5つのしきい値でAIのアクセス範囲を洗い出す: 取得(retrieval)、記憶(memory)、計画(planning)、ツール選択(tool selection)、出力(output)の5点。記事は「あらゆる権限ポイントがインジェクションの侵入面である」と述べています。
- 重大な操作には人間の承認を挟む(Human-in-the-loop): メール送信、データベースの変更、返金の実行、コンテンツの公開ができるエージェントは、実行前に明示的な人間の確認を必須とすること。
- 分離アーキテクチャ: Dual-LLMによる分離を実装したうえで、制御フローだけでなくデータフローを監査すること。
- ベンダー審査をセキュリティ実務として扱う: スタックに入るサードパーティのAIツールはすべて潜在的な攻撃経路とみなし、契約前に分離パターンとインシデント対応の透明性を要求すること。
4項目のうち3つが、技術そのものではなく運用と契約の話である点は注目に値します。記事が結論部分で「ブランド資産、ポッドキャスト、ヘルプドキュメント、ベンダーとの関係は、いまや攻撃面である」「ガバナンスが追いつく必要がある」と締めくくっていることとも一致しています。
実務への影響と、今日からできる確認手順
ここからは記事本文に書かれていない、Scale Basics編集部による一般的な実務上の整理です。個々の攻撃手法への直接的な対策ではなく、Web担当者がどの論点を自分の担当領域に引き寄せるべきかという観点で読んでください。
最も切実なのは、公開コンテンツの位置づけが変わったことです。ヘルプセンターや製品ドキュメント、ブログ記事は、これまで「人間の読者に向けた資産」であり、SEOの文脈では「検索エンジンに評価される資産」でした。記事の指摘を踏まえると、そこに「第三者のAIエージェントが読み取り、その内容に基づいて動く素材」という三つ目の性格が加わります。AI経由の流入を増やそうとする施策は、裏返せば、自社コンテンツがAIに読み込まれる機会を意図的に増やす施策でもあります。
着手順としては、まず自社サイト上で「自社以外の誰かが本文を書ける場所」を棚卸しします。レビュー欄、コメント欄、Q&A、コミュニティ投稿、外部ライターの下書き権限、プラグイン経由で本文が書き換わる経路が該当します。ポッドキャストや動画を外部制作に出しているなら、成果物の受領経路と差し替え検知の仕組みも同じ文脈です。
次に、自社で使っているAIツールを記事の5つのしきい値に沿って一覧化し、それぞれが「何を読めるか」と「何を実行できるか」を分けて書き出します。両方を兼ね備えているものがあれば、そこが混乱した代理人問題に該当する候補です。広告運用でも構図は同じで、フィードや広告文の生成、レポートの要約、問い合わせ対応の自動化が対象になります。そのうえで、コンテンツの自動公開、CRMの更新、返金や与信に関わる処理には人間の確認を挟み、利用中のAIベンダーには入力の隔離の実装方法とインシデント時の通知方法を契約更新のタイミングで確認します。オープンソースのライブラリを社内で組み込んでいる場合は、Mercorの事例が示すとおり、バージョンの出所を追える状態にしておくことが前提になります。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。今回の記事で最も重い一文は、攻撃事例の生々しさではなく、「LLMは内容と指示を確実には区別できず、それは修正可能なバグではなく構造的な性質である」という指摘だと考えます。もしこれがバグであれば、待っていればベンダーが直します。構造であるなら、待っても直らず、運用側で境界を引くしかありません。記事が挙げた4要件のうち3つが運用と契約の話である理由も、そこにあると読めます。
SEOの実務者にとっての示唆は、AI検索対策の議論を「どう引用されるか」だけで終わらせないことだと考えます。自社コンテンツをAIに読ませやすく整えるほど、そのコンテンツの影響力は自社サイトの外側に広がり、同時に改ざんされたときの被害範囲も広がります。AI向けの整備と、コンテンツの改ざん検知や入稿権限の管理は、本来セットで語られるべき話題だと感じます。
もうひとつ現実的な論点として、この記事が想定する対策の多くはマーケティング部門だけでは完結しません。ヘルプセンターの管理はカスタマーサポート部門、AIツールの選定は情報システム部門、契約条件は法務や購買と、担当が分かれているのが一般的です。記事が「IT部門に何を要求すべきか」という構成を取っているのは示唆的で、Web担当者に求められているのは自力で防御を実装することではなく、自分が管理する資産のどこがAIに読まれているかを言語化し、適切な部門に持ち込むことだと考えます。
まとめ
・Search Engine Landが2026年7月29日付でMyriam Jessier氏による記事を公開し、プロンプトインジェクションの攻撃面がブランド資産、AIエージェント、ベンダースタック、顧客向けワークフローにまで広がっていると整理した
・白背景の白文字やHTMLコメント、不可視Unicodeといった単純な隠蔽手法は現代のLLMには通用しなくなった一方、内容と指示を区別できないというLLMの構造的な性質は残っていると記事は指摘している
・脅威としては、チャット画面内で偽の警告とQRコードを描画するChatGPhish、比較記事に指示を織り込むセマンティック埋め込み、画像や音声を使うマルチモーダル攻撃、信頼できない入力と特権的ツールを併せ持つエージェントの混乱した代理人問題、ベンダー経由のサプライチェーンが挙げられた
・サプライチェーンの事例としてMercorが確認した3月31日のインシデント(LiteLLMの悪意あるバージョンに関連)が挙げられ、OWASPは機微情報の露出の懸念を指摘し、Metaは業務を一時停止したと記事は伝えている
・防御の中心はDual-LLMパターンだが、MIT CSAIL、Google DeepMind、ETH Zurichの研究者らによる「Defeating Prompt Injections by Design」は制御フローは保護されてもデータフローは操作され得ると指摘。記事はアクセス範囲の洗い出し、重大な操作への人間の承認、分離アーキテクチャ、ベンダー審査の4項目をIT部門への要求事項として挙げている
よくある質問
Q1: 白背景に白文字のような単純な隠しテキストは、もう気にしなくてよいのですか?
記事によれば、白背景に白文字を置く、HTMLコメント内に文字を仕込む、目に見えないUnicode文字を混ぜるといった単純な隠蔽手法は、パターン認識、境界の分離、スポットライティングといった防御側の改善により、現代のLLMに対してはもはや機能しないとされています。ただし記事の主眼は、こうした素朴な手口ではなく、もっともらしく読める段落の中に指示を織り込むセマンティック埋め込みや、画像や音声を使うマルチモーダルな手法にあります。記事は、LLMが内容と指示を確実には区別できないことを、修正可能な不具合ではなく構造的な性質だと述べています。
Q2: SEOやコンテンツ運用の担当者は、この記事のどこを自分の担当範囲として読むべきですか?
記事には担当部門別の指針は書かれていないため、以下はScale Basics編集部による一般的な実務上の補足です。記事が攻撃の起点として挙げているのは、ブログ、ヘルプセンター、製品ドキュメントといった、Web担当者が日常的に管理しているページです。そのため、自社ドメイン上で第三者が本文を書ける領域、つまりレビュー欄、コメント欄、ユーザー投稿、外部ライターの入稿フローを棚卸しし、改ざんや意図しない差し替えを検知できる状態にしておくことが、担当範囲の中で最も直接的な対応になります。ポッドキャストや動画など非テキストの資産を外部制作に出している場合は、成果物の受領経路の確認も同じ文脈に入ります。
Q3: Dual-LLMパターンを導入すれば、プロンプトインジェクションは防げるのですか?
記事はDual-LLMパターンを、最も広く推奨されている構造的な防御として紹介しています。隔離されたモデルが信頼できない入力を読み、別の特権を持つモデルが業務ロジックを実行し、両者が処理層を共有しないという設計です。ただし記事は、MIT CSAIL、Google DeepMind、ETH Zurichの研究者ら(筆頭著者はEdoardo Debenedetti氏とIlia Shumailov氏)による「Defeating Prompt Injections by Design」を引き、制御フローはDual LLMパターンで保護されるがデータフローは依然として操作され得るという盲点を紹介しています。記事は要件のひとつとして、Dual-LLMによる分離を実装したうえで制御フローだけでなくデータフローを監査することを挙げており、導入すれば完了という位置づけではありません。
出典:How prompt injection puts your brand and AI workflows at risk(Search Engine Land、Myriam Jessier氏、2026年7月29日)https://searchengineland.com/prompt-injection-brand-ai-workflows-risk-483819
