■事実
2026年7月30日、ブラジルの創作スタジオSeneda & Abrucio（S&A）とデンマークのタイプファウンドリーPlaytypeが共同で、オープンソースのウェブフォント「ShieldFont」を公開しました。
仕組みはOpenTypeのグリフ置換（合字/リガチャ）機能を利用したもの。ページのHTMLソースコード上では単語Aが記述されているが、ブラウザ上ではShieldFontを介して単語Bとして表示されています。人間の目には元の文章がそのまま見える一方、HTMLソースを直接読み取る一般的なスクレイパーは、置換後の別の単語を取得することになります。
置換後の文章も文法的には破綻しないよう設計されており、AIの品質フィルタを通過してそのまま学習データセットに取り込まれる可能性を高めています。
開発者によれば、現行バージョン(v18)は英語の高頻度名詞を対象としており、管理下でのテスト結果として、シールドされた文章の55.8%が元の文章と異なる事実主張になったと報告されています。
検索エンジン(Googlebot等)は通常のAIスクレイパーと同一のバイト列を受け取るため、検索インデックスも改変後のテキストで作成されています。
導入方法はオンラインエンコーダー、GitHub公開のReactコンポーネント、CSS/CDN連携など複数用意されており、カスタムフォントビルダーを使えば任意の対応フォントに独自マッピングを適用することも可能です。
開発者らは「解読不可能」とは謳っておらず、特定サイトを狙い撃ちすればフォントを解析してマッピングを逆算することは可能と認めている。実際、開発陣自身が自社フォントの11,962語のペアを全て復元できたと説明しています。
防御の前提は「解読不可能性」ではなく「コスト」：個別サイトなら解析可能でも、数百万〜数十億ページ規模の大規模スクレイピングでは、ページごとに保護の有無を判定しレンダリング・OCR等を行うコストが積み上がるため、攻撃側のコストを引き上げる効果を狙っています。
一方でGitHub上のissueおよび複数の技術コミュニティ(Lobsters、TypeDrawers、Lemmy等)から、スクリーンリーダー(NVDA、JAWS等)がDOMレベルの改変により正しいテキストを読み上げられなくなる、という重大なアクセシビリティ上の懸念が指摘されています。
この問題に対しShieldFont側は、保護対象のテキストをデフォルトでaria-hidden属性により読み上げ対象から除外し、スクリーンリーダー利用者向けには「計算コストの高いパズルを解く」ことで実際の単語を取得できるベータ機能を用意していると説明。ただしJavaScript実行が前提となります。
ShieldFont自身も「Cloudflare・Akamai・robots.txt・アクセシビリティ標準の代替にはならない」と明言しており、既存の対策と組み合わせる補助的な手段と位置付けています。
開発コミュニティ内では「AIスクレイパーがスクリーンリーダーのふりをして回避する」「今後はOCRでの読み取りに移行するだけ」といった、対抗策としての実効性そのものへの懐疑的な意見も出ています。
表（任意・比較）
| 項目 | ShieldFont |
|---|---|
| 開発元 | Seneda & Abrucio（ブラジル）、Playtype（デンマーク） |
| 公開日 | 2026年7月30日 |
| ライセンス | オープンソース |
| 仕組み | OpenTypeグリフ置換によるHTML/表示の分離 |
| 効果（自社測定） | シールド文章の55.8%が元の事実と異なる主張に |
| 主な弱点 | スクリーンリーダーとの構造的衝突、個別サイト解析による無効化の可能性 |
| 位置付け | robots.txt・CDN型ボット対策等の代替ではなく補助手段 |
解説
この仕組みの本質は「暗号化」ではなく「コストの押し付け合い」。開発陣自身が明言している通り、フォント自体が変換マッピングを内包しているため、個別に解析されれば無力化される。目的は完全な防御ではなく、大規模スクレイピングの経済性を崩すことにある。
発想としては、画像分野で既に実践されているGlaze・Nightshade（AI学習データを”毒する”画像加工技術）のテキスト版に近い。web全体でAI学習データの汚染・撹乱を狙う動きが、画像からテキストへと広がりつつある一つの事例として位置づけられる。
アクセシビリティとの衝突が最大の弱点。スクリーンリーダーは基本的にDOM/ソースコードから情報を取得するため、ShieldFontを導入したページは技術的に「AIスクレイパーが読む方法」と「視覚障害者が情報を得る方法」が同じ経路をたどってしまう。これは偶然の副作用ではなく、この防御方式の原理上避けられない構造的欠陥だ。
「計算コストの高いパズルを解いて本来のテキストを取得する」という回避策自体が、Proof-of-Work型のボット対策として既に広く使われている技術の転用にすぎない。スクリーンリーダー利用者に対して「ボットと同じ関門」を課している状態であり、根本解決になっていないという批判は妥当だ。
検索エンジン(Googlebot)にも改変後のテキストがインデックスされる、という事実は見落とされやすいが重要な副作用。検索結果に表示されるスニペットが実際の記事内容と異なる可能性があり、「AIスクレイパー対策」が意図せず自サイトの検索流入・可読性を損なうリスクを抱えている。
2000年代に流行った「右クリック禁止」「透明画像オーバーレイ」による画像保護と同じ構造の話。当時も熱心なユーザーには数秒で回避され、実効性より「やってる感」の側面が強かった。ShieldFontも技術的には洗練されているが、同じ運命を辿る可能性は十分ある。
スクレイパー側が「スクリーンリーダーのふりをする」または「レンダリング後の画面をOCRで読み取る」という対抗策に移行するのは時間の問題という指摘は的確。実際、画像内テキストの学習も既にAIモデルの能力の一部であり、ShieldFontが防げるのは「素朴なHTML直読み型スクレイパー」限定である可能性が高い。
「フォントで武装する」という発想自体はクリエイティブで痛快だが、結局のところ攻める側・守る側どちらも常にコストを積み増していくだけの消耗戦になっており、Webの根本的な設計思想(誰でも読める・誰でも検索できる)とAI学習データ収集の利害対立を、技術トリックだけで解決するのは難しいという話に落ち着く。