何が起きたか
Microsoftが木曜に公表した内容によれば、スパム送信者が「ASCIIスマグリング」と呼ばれる手法を使い、メール本文中のキーワードを難読化してスパム判定をすり抜けようとしています。同社のMicrosoft Defender for Officeのシグネチャ検知では、2月初旬のある日を境に日次の検知数が約2万1000件から130万件超へ急増し、4日後には250万件に到達。この水準が数か月続いたのち、5月中旬に急減しました。
手口の中核はUnicodeの「タグ文字」領域です。U+E0041が「A」、U+E0061が「a」に対応するように、128個のタグ文字がASCIIの一部をほぼ完全に写し取っています。違いは、人間の目にはほとんど何も表示されないこと。テキスト処理のレイヤーには文字として確かに存在するのに、画面上は空白同然という非対称性が生まれます。
なぜ重要か
注目すべきは、同じ仕組みが2年前にはまったく逆の目的で使われていた点です。当時これが話題になったのは、AIエージェントやLLMに対するプロンプトインジェクションを密かに仕込む方法としてでした。メールなど信頼できない入力に混ぜた悪意ある指示をタグ文字で書けば、LLMは指示として読み取るのに、人間の読み手には何も見えない。Microsoftは今回、意図は反転しているが仕組みは同じで、いずれの場合もユーザーの不審を招かないと説明しています。
つまり「モデルに指示を密輸する」用途と「検知器の前でキーワードを難読化する」用途は、同じ性質の裏表です。タグ文字が人間に不可視でありながらテキスト処理レベルには存在する——この一点が、攻撃者にとって両方向に使える資産になっている。
見落とされがちな論点
第一に、これは新しい脆弱性の発見ではなく、既知のUnicode仕様の転用です。パッチで塞ぐ類のものではなく、テキストを扱うあらゆる処理系が「見えている文字列」と「実際に処理する文字列」のズレを前提に設計されているかどうかが問われます。
第二に、スパムという「量で稼ぐ」領域に転用されたことの意味です。日次250万件という規模は、この手法が試験的な悪用ではなく大量配信のインフラに組み込まれた段階を示します。手法が地下市場のツールキットに載れば、次にどの検知器へ向けられるかは需要次第です。
第三に、5月中旬の急減が何を意味するかは公表された事実からは断定できません。防御側の対応が効いたのか、送信者側が別の手法に移ったのか——ここは注視すべき空白です。
💼 事業会社視点：これは自社にどう効くか
直接効くのは、テキストを検査して自動判断している事業です。ECの商品説明・レビュー・出品審査、SaaSのユーザー投稿モデレーション、人材サービスの応募書類スクリーニング、カスタマーサポートの問い合わせ自動分類——いずれも「表示される文字列」と「判定に渡す文字列」が一致している前提で作られています。ここにタグ文字が混ざれば、NGワードフィルターは素通りし、人間のレビュアーの目には正常なテキストしか映りません。
経営判断としてまず打つべきは、正規化処理の棚卸しです。入力バリデーションでU+E0000〜U+E007Fのタグ領域を除去または拒否しているか、自社プロダクトと受託開発の納品物の両方で確認してください。実装コストは小さく、確認しなければゼロのままである典型例です。
より重い論点は、AIエージェント導入を進めている企業です。メールや外部文書をLLMに読ませて処理させる社内ワークフローは、まさに2年前に指摘されたプロンプトインジェクションの入口そのものです。Microsoftが示したのは、この手法が実験段階を越えて日次250万件規模で流通した事実であり、攻撃者側の裾野が広がったことを意味します。PoCの段階で「LLMに渡す前のサニタイズ」を要件に入れるか、後から全社展開後に入れるかで、コストは桁で変わります。受託開発事業者にとっては、この一点を提案書に書けるかどうかが差別化になります。