Noroboto攻撃とは ── 「嘘のフォント」で人間とAIに別文章を読ませる新手口を解説

はじめに

「人間が読む文章」と「AIが読む文章」が、同じファイルなのに別物になる――そんな攻撃が現実になった。リーガルテック企業 Tritium Legal の創業者 Drew Miller 氏が公開した Noroboto 攻撃は、悪意あるフォントを仕込むことで、画面では「Maryland 州法に準拠」と見えている契約書を、AIには「Delaware 州法に準拠」と読ませる。プロンプトインジェクションの一種だが、文字エンコードでもプロンプト埋め込みでもなく「フォントの描画レイヤー」を突く点が新しい。本記事では、契約書・請求書をAIに読ませる業務フローを直撃するこの手口の仕組みと、エンジニアが今すぐ取れる防御策を掘り下げる。

何が起きたか ── 名前の由来と攻撃シナリオ

Noroboto という名前は、Googleのオープンソースフォント Noto（“no tofu”＝豆腐状の文字化けをなくす意味）をもじったものだ。Notoが「文字化けをなくす」フォントなら、Norobotoは「ロボット（AI）だけに文字化けを起こす」フォントというわけだ。

攻撃が成立する条件はシンプルで、DOCXやPDFなどにフォントを埋め込めること、ただそれだけだ。Miller氏のデモでは、準拠法を示す条項の文字列を細工した契約書をAIに読ませたところ、テストした主要プラットフォームがいずれも「この契約はDelaware州法に準拠する」と誤って回答した。人間がレビューする分には何の違和感もない。金額でも同じことが可能で、「2億円」に見える数字をAIには「1億円」と読ませられる。

最も厄介なのは、文書の一部だけに細工するパターンだ。全文を壊せばAIの出力が明らかに崩れて異常に気づけるが、準拠法の一語や金額の一桁だけを差し替えれば、AIは残りの正常なテキスト抽出を信頼してしまい、改ざんを見抜けない。契約書レビュー、請求書処理、監査、入札書類のチェックなど、AIが「書面の内容」を根拠に判断する工程すべてがリスクにさらされる。

技術的な仕組み ── フォントの cmap テーブルを悪用する

鍵を握るのはフォント内部の cmapテーブル（character-to-glyph mapping） だ。フォントは「Unicodeコードポイント → 実際に描画する字形（グリフ）」の対応表を持っている。通常この対応は素直で、コードポイント U+004D には「M」の字形が結びついている。Norobotoはこの対応を意図的にずらす。攻撃には2つの系統がある。

Full obfuscation（全面難読化）: グリフをUnicodeの PUA（Private Use Area、私用領域） のコードポイントに割り当てる。画面上は正しい字形で表示されるが、テキスト抽出すると意味のない私用領域の文字列が得られる。ただし出力が露骨に壊れるため気づかれやすく、推論モードを持つ最新のフロンティアモデルは「文書をレンダリングしてOCRし直す」ことで突破してしまう。
Replacement（置換）: グリフを別の正規Unicode値にマッピングする。「Maryland」と見える箇所のコードポイント列が、実体としては「Delaware」を表す。出力は一見もっともらしく崩れないため、テストした全プラットフォームが騙された。Norobotoの本命はこちらだ。

ポイントは、これが文字コードの不可視文字を紛れ込ませる従来手口とは別物だということ。ファイル内のUnicode列・人間が見る字形・AIが処理するテキスト、この3つが食い違う「描画層の間接インジェクション」であり、不可視文字の検出やプロンプトのサニタイズでは防げない。この脆弱性は学術的にも、フォント注入で不可視プロンプトを仕込む論文 Invisible Prompts, Visible Threats（arXiv:2505.16957）として裏付けられている。

エンジニアへの影響と防御策

実務への示唆は明確だ。AIに外部由来のドキュメントを読ませる前処理に「正規化と検証」の一段を挟むことが、もはや任意ではなく必須になる。テキスト抽出ライブラリの出力をそのままLLMに渡す設計は、Norobotoに対して無防備だ。

Miller氏が示した防御は “Trust, but verify”（信用するが検証する）に集約される。Tritiumの実装（Rust製）では、埋め込みフォントのASCIIグリフを実際にレンダリングし、それをOCRで読み取った結果と期待文字列を突き合わせる。一致度は Levenshtein距離 からスコア化し、1.0が完全一致を意味する。OCR精度を上げるためグリフ周囲に WIDTH_PADDING / HEIGHT_PADDING を取る工夫も入っている。Replacement攻撃は「字形とコードポイントの不一致」を必ず生むため、このレンダリング→OCR照合で少なくとも1か所のOCRミスマッチとして検出できる。

自前で組み込むなら、検証の核は3つの表現を一致させることだ。①人間の目に見える字形、②ファイル内のUnicode文字列、③AIが受け取るテキスト――この3者がずれていないかをAI投入前にチェックする。簡易には「埋め込みフォントを無条件に信用せず、レンダリング画像のOCR結果と抽出テキストを比較する」だけでも、Replacement攻撃の大半は弾ける。フリーランスや小規模チームでAI文書処理を組むなら、信頼できない送信元のDOCX/PDFは「フォント埋め込みを剥がして再レンダリング」してから読ませる、という運用ルールだけでも有効な一次防御になる。

まとめ

Norobotoは、フォントのcmapテーブルを改ざんし「人間が見る文字」と「AIが読む文字」を意図的に食い違わせる新型のプロンプトインジェクションだ。
PUAを使うFull obfuscationは気づかれやすいが、別の正規Unicodeに置き換えるReplacementは出力が崩れず、テストした全プラットフォームが騙された。
不可視文字対策やプロンプトのサニタイズでは防げない「描画層」の攻撃であり、契約書・請求書・監査などAIが書面を根拠に判断する工程を直撃する。
防御は「レンダリング→OCR→期待値と照合（Levenshtein距離でスコア化）」が現実解。AI投入前の正規化・検証は今後の標準前処理になる。

文書をAIに読ませる前に「本当にそのテキストを読ませてよいのか」を機械的に確かめる――Norobotoは、その一手間を省けない時代に入ったことを突きつけている。

今日のその他のニュース

100万台のAIサービスをスキャンしたら史上最悪のセキュリティだった: 公開中のAIサービス／MCPサーバ約100万台を調査したところ、認証なし・APIキー露出が横行。自前でMCPやAIサービスを公開する際の必読チェックリストになる調査結果だ。(Qiita)
Webサーバー「nginx」に再び致命的な脆弱性: 重大な脆弱性が見つかり修正版が公開された。広く使われるミドルウェアだけに影響範囲は大きく、早期のアップデートが推奨される。(窓の杜)
なぜAnthropicはプロンプトにXMLタグを推奨するのか: ClaudeでXMLタグが効く理由を、Markdownとの構造的差異（境界の曖昧さ・ネスト・属性付与）から解説。プロンプト設計の実務に直結する内容だ。(Zenn)