騙しの3ステップ：二次創作小説を1pxに、コマンドを文字化けに、フォントで文字化けを人が読める形に

当サイトはこのデモページのソースコードを取得して確認しました。ページ全体はわずか3つの動作で構成されており、合わせても20行未満です。

ステップ1：二次創作小説を1pxに縮め、黒字に黒背景

あの二次創作小説の数段落は、このようなタグの中に書かれています。ページの背景色は真っ黒なので、黒い文字は黒い背景に溶け込み、高さが1pxしかありません。あなたが今読んでいるこの行の文字は約17pxの高さで、1pxはその約17分の1です。

<p style="color: #000000;font-size: 1px;">This website was created as a tribute to Bioshock</p>

ステップ2：人に見せるためのコマンドを、コード上では文字化けの羅列に

ページ中央には、ごく普通の <div> があり、その中に4行の文字があります。見た目はbase64エンコードされた塊のようです。AIアシスタントはこれを見ると、「高エントロピー文字列で、鍵なしでは解読できない」と判断し、ノイズとしてスキップします。

<div> vRmUwAgRmAiPjwUgARrhjAgRmbAshbVPjcUAcjwAsgrhAfcao
<br>RjJhAgRmAhnhJmshwAPsAsgrh
<br>fcaoADPAHBAFwhuFsJrF859E806E8E35F6266A2HB8
<br>PsAOPUUAcUUROAgRmAsRAahhAgRmbAhcashbAhWWAxbRVAMcrsmbh </div>

当サイトはソースコード中で、研究レポートや報道でも触れられていない点も発見しました。この文字化けボックスのすぐ上の行に、同じく1pxの隠しテキストがあり、その内容は5語のみ、LLM Generation Seed:（大規模言語モデル生成シード）です。つまり、AIが読む順序は「生成シード：」の後にランダムな文字列が続く、というものです。AIがこれが何かを推測する必要はありません。攻撃者がすでにラベルを貼っておいたからです。研究者が公開したソースコードのスクリーンショットにはこの部分がないため、ページはスクリーンショット後に変更されたことがわかります。

ステップ3：文字の描画がすり替わったフォントを適用

ページのヘッダーでフォントファイルを参照し、ページ全体に適用しています。文字サイズ48px、緑色の文字、黒い背景。それが画面に表示される状態です。

@font-face {
  font-family: 'fontie';
  src: url('RaptureFont.ttf') format('truetype');
}
body {
  font-family: 'fontie', sans-serif;
  font-size: 48px;
  background: #000;
  color: #0f0;
}

3つの動作は、それぞれ単独では完全に合法です。CSSでは文字を小さくしたり、背景と同じ色にしたりすることはもともと可能です。<div> には任意の文字列を書けます。Webページが独自のフォントを持つことは当然できます。どこにもJavaScriptは使われておらず、ブラウザの脆弱性も利用していません。JSを完全に無効にしても、このページは問題なく騙せます。

なぜAIはまったく気づかないのか？ AIはWebコードしか読まず、ブラウザだけがフォントを読み込んで再描画するから

AIアシスタントがWebページを取得するとき、取得するのはWebコードです（DOM＝ブラウザがコードを読み込んだ後にメモリ上に構築するテキストの骨組み）。タグ、構造、その中のテキストです。完全なブラウザレンダリングパイプラインは実行せず、フォントファイルをダウンロードせず、「この文字が最終的にどんな形で描画されるか」も計算しません。LayerXはこの種のアシスタントを非エージェント型（non-agentic）と呼んでいます。ページを取得し、コードを解析するが、完全なレンダリングは実行せず、カスタムフォントのグリフマッピングも分析しません。

ここには、誰もが当然だと思っている前提があります。Webコードはコンテンツであり、フォントは見た目を良くするだけで、文字の意味を変えるものではない、という前提です。この前提はほとんどの場合成立するため、誰も検証しません。そして、普段は安全だからこそ、この手口は非常に有効なのです。

さらに重要な結果があります。アシスタントは問題を見つけられないだけでなく、「このページは安全そうだ」と伝えます。

攻撃者が悪意あるページを作り、AIアシスタントにそれを安全だと判定させた場合、実質的にアシスタントの権威を利用し、その信頼を自分の主張の裏付けにしているのです。

LayerX 研究レポート（当サイト訳）

この結論の適用範囲に注意してください。これは「コードのみを読み、レンダリングしない」タイプのアシスタントに対するものです。アシスタントが実際にページをレンダリングし、スクリーンショットで確認する場合、理論上はあの4行の緑の文字を見ることになります。ただし、LayerXはこのタイプのアシスタントをテストしていません。テスト対象はすべて前者のタイプでした。

当サイトがこの詐欺フォントを分解して検証：改変されていたのは文字の形、対応表はクリーン

以下の段落はLayerXのレポートにも、どの報道にも由来しません。当サイト自身の検証です。デモページで使われているフォントファイルをダウンロードし、内部の各テーブルを読み、それを使って文字化けを再レンダリングしました。

フォントファイルにはcmapと呼ばれるテーブルがあり、「文字aはどのグリフを使うべきか」を管理しています。フォントが改変されていないか確認する最も簡単な方法は、このテーブルを調べることです。このフォントのcmapは完全に正常です。文字aはaという名前のグリフを指し、文字0はzeroという名前のグリフを指します。5918の文字マッピングすべてに異常はありません。グリフ置換や字間の位置調整を管理するGSUB、GPOSの2つのテーブルはそもそも存在しません。

改変されていたのはglyfテーブル内の輪郭データ、つまり各グリフが具体的にどのように描画されるかです。aという名前のグリフの中には、sの描画が入っています。直接測定できる数値をいくつか示します：

最初の行の最初の16文字を照合すると、置換関係が一目でわかります：

置換はすべて厳密に1対1です。最初の行の49文字から復元された文も49文字で、過不足はありません。4行169文字すべてが対応し、矛盾はありません。各文字の対応関係は次の通りです：

騙しの綻び：画面上のその行をコピーすると文字化けになるため、攻撃は手入力を強制する

画面上でそのコマンド行を選択してコピーを押すと、クリップボードに入るのはWebページのコード上の文字、つまりあの文字化けであり、目に見えるものとはまったく異なります。ブラウザがコピーするのは文字そのものであり、グリフがどのように描画されるかとは無関係です。

つまり、このデモページは被害者にコマンドを手入力させる必要があります。ページ上の動詞はtype（打ち込む）で、全文のどこにもcopyはありません。ただし、この制限はこのページにのみ当てはまります。攻撃者がクリップボードを書き換えるスクリプトを追加すれば、コピーされたものがデコード後のコマンドになる可能性があるため、下記の自己チェックは万能ではありません。

逆に、これは即席の自己チェック方法になります。同様に、ブラウザのリーダーモードやカスタムフォントを無効にすると、この偽装はその場で無効になります。偽装はページ付属のフォントに依存しているため、システムフォントに置き換えると、そのテキストは文字化けに戻ります。

ベンダーは修正したか？ 7社中、修正したのはMicrosoftのみ。Googleは高危険と判断後、格下げ・クローズ

LayerXは2025年12月、この発見を各社に報告しました（まず非公開で通知し、期限後に公開する、業界用語で責任ある開示）。7社中6社は最終的に修正しませんでしたが、その理由はそれぞれ異なります。4社は最初から受理範囲外とし、Googleは受け付けたものの翻意し、Perplexityは大規模言語モデル共通の課題だと述べました。そのうち2社の言い分は「これは詐欺であり、当社システムの侵害ではない」というもので、セキュリティ業界ではこの種の詐欺をソーシャルエンジニアリングと呼びます。

2025年12月のテストからすでに7ヶ月以上が経過しました。当サイトは、他の企業がこっそり修正したかどうかについて、公開情報を確認できません。確認できるのはただ一つ、デモページとフォントファイルは今もオンラインであり、プレーンテキストで取得しても、やはり二次創作小説と文字化けしか見えないということです。

LayerXが示す対策：レンダリング後にコードと比較、フォントも攻撃面として検査

レポートはベンダー向けに4つの検出方法を提案し、さらに発言のトーンに関する1つの要件を加えています。

1番目が4つの中で最も具体的です。一方の経路はコード内のテキストのみを取得し、もう一方はフォントを適用して完全にレンダリングし、レンダリング後に見える文字を抽出して、両者の差分を比較します。この方法は攻撃手法に関する事前知識に依存しません。フォント、透明度、画面外配置など、人間が見えるものとコードに書かれているものが一致しなければ、それを報告できます。

5番目はアシスタントの話し方に関する要件です。ページのレンダリング、カスタムフォントの分析、視覚情報とコードの比較の3つができないなら、「このページは安全です」といった発言をすべきではない、というものです。このケースに関して言えば、最後のこの1文を変えることは、前述の4つの対策を実施するよりはるかに安上がりです。

WebページはHTMLだけではありません。意味はレンダリングパイプラインに移すことができます。テキストだけを分析するシステムは、生まれつき盲目なのです。

LayerX レポート結語（当サイト訳）

ページ全体で20行未満。JavaScriptは1行もなく、ブラウザの脆弱性も利用していません。ブラウザのスクリプトを完全に無効にしても、このページは問題なく騙せます。

当サイトはデモページのフォントファイルをダウンロードし、テーブルを1つずつ読み、それを使って文字化けを再レンダリングしました。結論は一つ、予想外のことでした。最も簡単に思える検査方法では、ここでは何も検出できないのです。

この偽装には迂回できない綻びがあります。画面上でそのコマンド行を選択してコピーを押すと、クリップボードに入るのはコード上の元の文字、つまりあの文字化けです。ブラウザがコピーするのは文字そのものであり、グリフがどのように描画されるかとは無関係です。そのため、このデモページはあなたに手入力を強制します。ページ上の動詞はtypeで、全文のどこにもcopyはありません。

• コピペして見比べる：不一致なら疑う
• リーダーモード、またはカスタムフォント無効化：システムフォントに置き換われば、そのテキストは文字化けに戻る
• 見知らぬページが指示するコマンドは手入力しない
• AIの「安全」という判断を唯一の基準にしない：そもそも画面上のその行を見ていない可能性がある（これはLayerXとBleepingComputerがユーザーに推奨していること。他の3つは当サイトが検証済みのメカニズムに基づいて導き出したもの）

LayerXは2025年12月にこの発見を各社へ報告しました。6社は最終的に修正せず、理由はそれぞれ異なります。

日付と説明はLayerXレポートの開示スケジュールからの引用です。アシスタントのテストは2025年12月に完了し、すべてLayerXの自己テストであり、第三者による再現はまだありません。LayerXはブラウザセキュリティ製品を販売しているため、事態をより深刻に語る動機がありますが、攻撃自体は当サイトが再現しました。2026年7月30日時点で、デモページとフォントファイルは依然としてオンラインであり、プレーンテキストで取得しても、やはり二次創作小説と文字化けしか見えません。他の企業がこっそり修正したかどうかは、公開情報では確認できません。