AIメール要約は隠しテキストなしでも偽情報に誘導可能

Forcepoint X-Labsは2026年9月28日、AIによるメール要約機能を対象に、隠しテキストやAIへの明示的な命令文がなくても、偽装したメールスレッドの内容が要約結果へ入り込むことを確認した検証結果を公開しました。

6種類のテストメールを各10回、計60回処理したところ、すべての条件で偽の請求金額「46,200ユーロ」と偽の日付が要約に含まれました。特に、本文を隠さず、AIへの命令文も含めない条件でも10回中10回、偽情報が要約へ反映されています。

ただし、これは実際の攻撃キャンペーンを観測した報告ではありません。Forcepointが合成データと検証用Microsoft環境を使い、ガードレールを意図的に設けていないメール要約パイプラインで実施したPoCです。

AIメール要約を偽情報で誘導する検証のサマリー

確認できている内容：

• Forcepoint X-Labsが2026年9月28日に検証結果を公開しました。
• テストでは「表示されたまま」「30行の空白の後」「非表示」の3種類の見せ方を使用しました。
• 各パターンについて、AIへの明示的な命令文が「ある場合」と「ない場合」を用意し、計6種類のメールを検証しました。
• 各メールを10回ずつ処理し、計60回の試行を実施しました。
• 6条件すべてで、偽の請求金額46,200ユーロと差し替えられた日時が10回中10回、要約に含まれました。
• 「表示されたまま・命令文なし」の条件でも、偽情報が10回中10回、要約へ反映されました。
• 命令文を含む3条件では、事前に定義した4つの正しい事実がすべて要約から消えました。
• Forcepointは、隠しテキスト検知や「AIへの命令らしい文章」を探すだけでは、すべてのケースを防げないとしています。

検証結果からは判断できない内容：

• 市販されているすべてのAIメール要約機能が同じ挙動をするとは確認されていません。
• 他のメールクライアントや画面構成でも同じ結果になるかは確認されていません。
• ガードレールを実装した環境での成功率は今回の検証では確認されていません。
• 実際の攻撃キャンペーンでこの手法が使われたことを示す報告ではありません。
• 9月28日の報告では、他のLLMや温度設定を変えた場合の結果は示されていません。

偽の「2通目」をメールスレッド内に作り、要約結果を変化させる

Forcepointが検証したのは、メール本文の中に、別のメールが続いているように見える偽のヘッダーと本文を含める方法です。

本来のメールには、2026年8月24日のサプライヤーレビューと、8,650ユーロの未処理請求に関する情報が含まれていました。

これに対し検証用メールでは、別のメッセージがスレッド内に存在するような構造を作り、日付を2026年9月3日、請求金額を46,200ユーロへ変更した情報を追加しました。

「AIへの命令文なし」の条件では、「以前の指示を無視せよ」といった典型的なプロンプトインジェクションの文言は使用されていません。Forcepointは、偽のFrom、To、Date、Subjectなどを含む2通目のメッセージ構造そのものが、どの情報を新しいものとして扱うかをAIへ伝える役割を持ったと説明しています。

このため、「ignore previous instructions」のような文言だけを探す検知では拾えないケースになります。

隠しテキストなし・命令文なしでも10回中10回、偽情報を要約

6条件のうち、最も単純なのが「Plain view, no instruction」です。

この条件では、偽情報を画面から隠していません。また、AIへ動作を指示する命令文も含めていません。

それでもForcepointの検証では、10回すべてで46,200ユーロという偽の金額と、差し替えられた日時が要約結果へ入りました。

一方、この条件では本来の4つの事実も4つすべて残っています。つまり、AIが正しい情報を完全に削除したわけではなく、矛盾した情報が存在する中で、偽の内容を主要情報として要約に取り込んだ形です。

Forcepointは、Outlook上では偽のヘッダー部分が過去のメール履歴のように表示されたとしています。

6条件・60回すべてで偽の金額と日時が要約に出現

Forcepointが公開した結果は次の通りです。

偽情報の挿入については、隠しテキストの有無や明示的な命令文の有無にかかわらず、全条件で同じ結果になりました。

違いが出たのは、本来の情報が要約に残るかどうかです。

AIへの明示的な命令文を含む3条件では、事前に定義した4つの正しい事実がすべて要約から消えました。これに対し、命令文なしでは4つすべて、または2つが残っています。

Forcepointは、この結果から、情報を隠すこと自体よりも、AIへの明示的な命令が「正しい情報を要約から除外する」挙動に強く影響したと分析しています。

30行の空白だけで正しい情報が半分消える結果も

「Below fold, no instruction」では、偽の2通目を30行の空白の後ろに配置しました。

この条件ではAIへの明示的な命令文を使用していませんが、4つの正しい事実のうち要約に残ったのは2つでした。この結果は10回の試行で共通していました。

さらに要約は、偽装されたメッセージを「最新のメッセージ」として扱いましたが、Forcepointが設定した日付上では、偽のメッセージは実際のメッセージより古いものでした。

Forcepointは、30行の空白がなぜこの差を生んだかについて、モデル内部の処理を確認できないため原因は断定していません。

8月の先行PoCでは不可視HTMLと命令文を組み合わせていた

今回の検証は、Forcepoint X-Labsが2026年8月25日に公開した先行PoCを分解して検証したものです。

先行PoCでは、検証用のOutlookアドインがメール本文とヘッダーをLLM APIへ渡し、要約結果をOutlookへ表示する仕組みを構築していました。モデルにはclaude-haiku-4-5を使用し、メールヘッダーと本文を1つの入力へまとめる単純な構成でした。

また、ガードレールは意図的に実装していませんでした。

8月の検証では、HTMLの表示設定を利用して人間には見えない命令文をメールへ含め、10回すべてで偽の46,200ユーロと9月3日の日時を要約させる結果になりました。

9月28日の追加検証では、「隠すこと」と「AIへ命令すること」を別々の変数として検証し、どちらもない場合でも偽情報が要約へ入り得ることを示しています。

「隠しテキストを検知すればよい」では防げない

先行PoCを受けた対策としては、人間に見えないHTML要素を検出する方法が考えられます。

しかし今回の結果では、画面上に表示される偽情報でもAIの要約に影響しました。したがって、非表示CSSや極端に小さい文字などを検知するだけでは対象範囲が不足します。

AIへの命令文をキーワードや正規表現で検知する方法にも同様の制約があります。「命令文なし」の条件では、AIに対する典型的な指示文そのものが存在しないためです。

Forcepointは、隠しテキスト検知と命令文検知はいずれも利用価値があるものの、単独では完全な防御にならないとしています。

OWASPも「LLM01:2025 Prompt Injection」で、外部コンテンツを信頼されていないデータとして分離すること、入力・出力の検証、最小権限、人による高リスク操作の承認などを対策として挙げています。

間接プロンプトインジェクション全体の仕組みについては、既存記事「AIエージェントを狙う間接的プロンプトインジェクション」でも実例を整理しています。

今回の結果を「ClaudeやOutlookの脆弱性」とは扱えない

今回の検証結果には適用範囲の制約があります。

Forcepointは、先行PoCについて、Outlook、特定の商用メール要約製品、使用したLLMモデル自体への攻撃ではないと明記しています。

検証環境は、研究者が構築したOutlookアドインと独自の要約パイプラインです。さらに、意図的にガードレールを設けず、モデルの温度は0に固定していました。

9月28日の報告でも、次の点は検証されていません。

• 他のメールクライアントで同じ表示になるか
• HTMLではなくプレーンテキストだけをAIへ渡した場合
• AIガードレールを追加した場合
• AIがメールボックスへの操作権限を持つ場合
• 温度設定を変更した場合
• 他のモデルや商用AIメール要約サービスで同じ成功率になるか

このため、「AIメール要約は必ず偽装できる」「Claude Haiku 4.5に固有の脆弱性がある」といった結論にはつながりません。

情報システム部門が確認したいAIメール要約の設計

メールやチャット、チケットなどをAIで要約するシステムを導入している企業では、単に「プロンプトインジェクションらしい命令文を除去する」だけでなく、AIへ渡すデータ構造そのものを確認する必要があります。

確認項目としては次が挙げられます。

• AIへ渡すFrom、To、Date、Subjectなどのヘッダー情報を、メール本文と明確に分離しているか
• メール本文内に記載された「From:」「Date:」などを、実際のメールヘッダーと同等に扱っていないか
• スレッド内の各メッセージについて、送信者・送信日時・Message-IDなど信頼できるメタデータと本文を対応付けているか
• HTMLメールからAIへ渡す情報を抽出する際、人間に表示される内容とAIが処理する内容に差がないか
• 隠しHTMLの検知だけでなく、本文内の偽ヘッダーや構造的ななりすましを検証できるか
• AIの要約結果を「信頼済みデータ」とせず、金額、振込先、日時、契約条件などは元メールへ戻って確認する運用になっているか
• 要約AIにメール送信、削除、承認、支払いなどの操作権限を与えている場合、人による承認を挟んでいるか
• AIへ渡した入力、参照したメール、生成された要約、実行した操作を監査ログとして追跡できるか

特に請求金額、振込先、納期、会議日時など、業務判断に直結する情報をAI要約だけで確定する運用は避け、原文や信頼できるシステム上の値と照合できる設計にしておく必要があります。

AIシステム全体の管理項目については「AIセキュリティとは？生成AI・AIシステムのリスクと企業のセキュリティ対策を解説」で整理しています。

出典

• No Hidden Text Required to Fool an AI Email Summarizer – Forcepoint X-Labs
• An Invisible HTML Payload Silently Hijacked Every Email Summarizer Run – Forcepoint X-Labs
• LLM01:2025 Prompt Injection – OWASP Gen AI Security Project