見た目が自然なメールでも、メール防御システムが読んでいる文字列まで同じとは限りません。Microsoftが2026年2月から5月中旬にかけて追跡したフィッシングキャンペーンでは、受信者には普通に見える文言の内部に、画面に表示されないUnicode文字が埋め込まれていました。1

この手法は**ASCIIスマグリング（ASCII smuggling）**と呼ばれます。もともとはAIへのプロンプトインジェクション研究で知られるようになった手法ですが、今回は金融関連のフィッシング文言をメール防御から隠す目的で使われました。1

何が隠されていたのか

攻撃者は「funding（資金調達・融資）」「loan（ローン）」「credit（与信・信用）」といった誘導語の文字間に、表示されないUnicode Tag文字を挿入しました。人がメールを開くと単語はそのまま読めますが、文字列としては連続した単純な単語ではなくなります。1

この差は、文字列の完全一致、シグネチャ、正規表現に依存する検知で問題になります。たとえば連続した金融用語を探すルールは、見えない文字で分断された語を見逃す可能性があります。Microsoftは、メールゲートウェイ、パーサー、後段のシステムでこうした文字の扱いが一致しないことも、検知を難しくすると指摘しています。1

AIを狙う従来の利用では、人には見えない指示をAIモデルに読ませることが主眼でした。今回の用途は逆です。受信者には金融オファーを読ませつつ、メール分析システムには異なる文字列を処理させようとしました。1

平日に集中した大規模な「事業融資」詐欺

Microsoftのテレメトリーでは、ASCIIスマグリングを検出するハンティングシグネチャのヒット数が2026年2月9日から急増。その後、およそ3か月にわたり平日を中心に高い水準が続きました。1日当たりのメール数は230万通を超えたとされています。1

メールは架空の事業融資やクレジットのオファーを宣伝する内容でした。攻撃者は使い捨ての送信元ドメインを利用し、ActiveCampaignのインフラを経由して送信しました。そのため、侵害されたメールサーバーからの典型的な攻撃というより、大量のマーケティングメールに似た特徴を持っていました。1

Microsoftによると、ActiveCampaignは不正利用を調査し、特定されたアカウントに対応しました。正規の配信サービスにも不正対策はありますが、それでも悪用され得ることを示す事例です。1

最優先は「検知前のUnicode正規化」

実務上、もっとも直接的な対策は明快です。キーワード照合、シグネチャ照合、正規表現の解析より先にUnicodeを正規化することです。Microsoftは、Unicode Tag文字や制御文字を検出・削除・フラグ付けしてから、テキストベースの検知を実行するよう推奨しています。1

メール防御では、次のような多層的な運用が重要になります。

• 本文を早い段階で正規化・検査する。 コンテンツ照合の前、さらに後段のパーサーや分類器へ渡す前に実施します。1
• 処理経路全体を検証する。 ゲートウェイ、パーサー、分類器、下流ツールで、特殊文字の解釈が異なる可能性があります。1
• 本文の文字列照合だけに頼らない。 Microsoftは、送信者・IPアドレス・URL・ドメインのレピュテーション、認証、機械学習による分類、なりすまし検知も保護に利用していると説明しています。1
• 不自然なUnicode利用をハンティングする。 日常的な営業・マーケティング文言の中に不可視文字や制御文字が混じること自体が、調査の手掛かりになります。1

正規化は、ほかの防御を置き換えるものではありません。あくまで、文字列ベースの有効なコントロールがこの限定的な回避策で無力化されるのを防ぐための前処理です。最終的なブロックには、レピュテーションやフィッシング検知を含む防御の重ね合わせが必要です。

メールを読むAIアシスタントも同じく警戒が必要

リスクは受信トレイのフィルターに限りません。組織では、メールをCopilot、要約ツール、ワークフロー自動化、AIエージェントに取り込む機会が増えています。Microsoftは、こうしたAIに渡すメールを信頼できない入力として扱い、モデルが処理する前に正規化と検査を行うこと、プロンプトインジェクションに備えること、自動エージェントが使えるツールや権限を最小限にすることを勧めています。1

対策がなければ、隠しコンテンツは従来のメール防御と、その後メールを読んだり処理したりするAIシステムの両方を狙う足掛かりになり得ます。

AI時代の回避技術は、既存の攻撃経路へ広がる

ASCIIスマグリングの事例は、すべてのプロンプトインジェクション手法がスパムに転用されることを意味するわけではありません。一方で、AIセキュリティで開発・普及した技術が、フィッシングメールのような確立済みの攻撃経路に低コストで再利用され得ることを示しています。1

別の研究でも、モデル単体の安全策に依存し切れない事情が示されています。ウォータールー大学と非営利AIセキュリティ研究団体FAR.AIが主導した研究では、試験対象となった21のオープンウェイト言語モデルすべてで、安全保護を回避できる改変が確認されました。ただし、この結果は試験されたオープンウェイトモデルに関するものであり、今回のフィッシングに特定のモデルが使われたことを示すものではありません。それでも、大規模な悪用を想定する際、モデル内蔵のガードレールだけを唯一の防御にしてはならない、という実務的な教訓を補強します。

メール防御側の優先順位は具体的です。Unicode正規化を標準的な前処理に組み込み、メール処理パイプライン全体で挙動を検証し、AI由来の新しい難読化手法が従来型のソーシャルエンジニアリングに持ち込まれる前提で備えることです。

見た目が自然なメールでも、メール防御システムが読んでいる文字列まで同じとは限りません。Microsoftが2026年2月から5月中旬にかけて追跡したフィッシングキャンペーンでは、受信者には普通に見える文言の内部に、画面に表示されないUnicode文字が埋め込まれていました。1

この手法は**ASCIIスマグリング（ASCII smuggling）**と呼ばれます。もともとはAIへのプロンプトインジェクション研究で知られるようになった手法ですが、今回は金融関連のフィッシング文言をメール防御から隠す目的で使われました。1

何が隠されていたのか

攻撃者は「funding（資金調達・融資）」「loan（ローン）」「credit（与信・信用）」といった誘導語の文字間に、表示されないUnicode Tag文字を挿入しました。人がメールを開くと単語はそのまま読めますが、文字列としては連続した単純な単語ではなくなります。1

この差は、文字列の完全一致、シグネチャ、正規表現に依存する検知で問題になります。たとえば連続した金融用語を探すルールは、見えない文字で分断された語を見逃す可能性があります。Microsoftは、メールゲートウェイ、パーサー、後段のシステムでこうした文字の扱いが一致しないことも、検知を難しくすると指摘しています。1

AIを狙う従来の利用では、人には見えない指示をAIモデルに読ませることが主眼でした。今回の用途は逆です。受信者には金融オファーを読ませつつ、メール分析システムには異なる文字列を処理させようとしました。1

平日に集中した大規模な「事業融資」詐欺

Microsoftのテレメトリーでは、ASCIIスマグリングを検出するハンティングシグネチャのヒット数が2026年2月9日から急増。その後、およそ3か月にわたり平日を中心に高い水準が続きました。1日当たりのメール数は230万通を超えたとされています。1

メールは架空の事業融資やクレジットのオファーを宣伝する内容でした。攻撃者は使い捨ての送信元ドメインを利用し、ActiveCampaignのインフラを経由して送信しました。そのため、侵害されたメールサーバーからの典型的な攻撃というより、大量のマーケティングメールに似た特徴を持っていました。1

Microsoftによると、ActiveCampaignは不正利用を調査し、特定されたアカウントに対応しました。正規の配信サービスにも不正対策はありますが、それでも悪用され得ることを示す事例です。1

最優先は「検知前のUnicode正規化」

実務上、もっとも直接的な対策は明快です。キーワード照合、シグネチャ照合、正規表現の解析より先にUnicodeを正規化することです。Microsoftは、Unicode Tag文字や制御文字を検出・削除・フラグ付けしてから、テキストベースの検知を実行するよう推奨しています。1

メール防御では、次のような多層的な運用が重要になります。

• 本文を早い段階で正規化・検査する。 コンテンツ照合の前、さらに後段のパーサーや分類器へ渡す前に実施します。1
• 処理経路全体を検証する。 ゲートウェイ、パーサー、分類器、下流ツールで、特殊文字の解釈が異なる可能性があります。1
• 本文の文字列照合だけに頼らない。 Microsoftは、送信者・IPアドレス・URL・ドメインのレピュテーション、認証、機械学習による分類、なりすまし検知も保護に利用していると説明しています。1
• 不自然なUnicode利用をハンティングする。 日常的な営業・マーケティング文言の中に不可視文字や制御文字が混じること自体が、調査の手掛かりになります。1

正規化は、ほかの防御を置き換えるものではありません。あくまで、文字列ベースの有効なコントロールがこの限定的な回避策で無力化されるのを防ぐための前処理です。最終的なブロックには、レピュテーションやフィッシング検知を含む防御の重ね合わせが必要です。

メールを読むAIアシスタントも同じく警戒が必要

リスクは受信トレイのフィルターに限りません。組織では、メールをCopilot、要約ツール、ワークフロー自動化、AIエージェントに取り込む機会が増えています。Microsoftは、こうしたAIに渡すメールを信頼できない入力として扱い、モデルが処理する前に正規化と検査を行うこと、プロンプトインジェクションに備えること、自動エージェントが使えるツールや権限を最小限にすることを勧めています。1

対策がなければ、隠しコンテンツは従来のメール防御と、その後メールを読んだり処理したりするAIシステムの両方を狙う足掛かりになり得ます。

AI時代の回避技術は、既存の攻撃経路へ広がる

ASCIIスマグリングの事例は、すべてのプロンプトインジェクション手法がスパムに転用されることを意味するわけではありません。一方で、AIセキュリティで開発・普及した技術が、フィッシングメールのような確立済みの攻撃経路に低コストで再利用され得ることを示しています。1

別の研究でも、モデル単体の安全策に依存し切れない事情が示されています。ウォータールー大学と非営利AIセキュリティ研究団体FAR.AIが主導した研究では、試験対象となった21のオープンウェイト言語モデルすべてで、安全保護を回避できる改変が確認されました。ただし、この結果は試験されたオープンウェイトモデルに関するものであり、今回のフィッシングに特定のモデルが使われたことを示すものではありません。それでも、大規模な悪用を想定する際、モデル内蔵のガードレールだけを唯一の防御にしてはならない、という実務的な教訓を補強します。

メール防御側の優先順位は具体的です。Unicode正規化を標準的な前処理に組み込み、メール処理パイプライン全体で挙動を検証し、AI由来の新しい難読化手法が従来型のソーシャルエンジニアリングに持ち込まれる前提で備えることです。