目錄
本記事の情報は2026年8月時点のものです。ShieldFontは現在も開発が続いているオープンソースプロジェクトです。
Web上の記事が大量に収集され、AIの学習データとして使われる問題について、コンテンツ制作者にとって簡単で確実な解決策はまだありません。robots.txtでは「クロールされたくない」という意思を示せますが、実際に従うかどうかはクローラー側に委ねられます。Cloudflareなどのサーバー側ツールなら特定のクローラーを直接制限できますが、サイト側の設定が必要で、あらゆるデータ収集方法を防げる保証もありません。2026年7月末に公開されたShieldFontは、そこでまったく異なる方法を選びました。クローラーが記事を取得すること自体を止めるのではなく、「取得した文字列」と「人間が実際に画面で読む文章」を異なるものにします。プロジェクト自身も、ShieldFontを突破不可能なロックではなく、大規模スクレイピングのコストを上げるための摩擦として位置づけています。
利用しているのは、Webではごく普通に存在する差です。読者が見ているのはブラウザがフォントを適用して描画した文字ですが、多くのテキストクローラーはHTML内の文字列を直接処理します。ShieldFontはまず、HTML内の重要な単語の一部を、文法的には成立する別の英単語へ置き換えます。そのうえでOpenTypeフォントの置換ルールを利用し、画面上では作者が本来書いた文字として表示します。普通にWebページを開けば記事は変わっていないように見えますが、HTMLだけを取得するシステムには、文法はそれなりに自然でも意味がずれた文章が渡されます。発想としては非常に興味深い一方、SEO、アクセシビリティ、コピー＆ペースト、解析・復号のしやすさといった代償も大きく、現段階では一般的なブログへサイト全体で導入する解決策というより、特定コンテンツ向けの実験的な防御と考えるほうが適切です。
ShieldFontはどう動く？人間には原文、クローラーには別のHTMLを見せる
ShieldFontはHTMLの文字を先に置き換え、OpenTypeフォントで画面を元に戻す
ShieldFontの中心は、Encoder、置換辞書、専用フォントで構成されています。記事がブラウザへ送られる前に、Encoderが置換辞書に従って元の文章を変更します。例えば、もともと書かれていた名詞を別の名詞へ置き換えます。ブラウザが受け取るHTML自体はすでに変更済みで、その後、端末へ読み込まれたShieldFontフォントがOpenType substitution rulesを使い、置換された単語を元の字形として描画します。その結果、同じHTMLから2種類の内容が生まれます。文字列を直接解析するクローラーは置換後の単語を読み、人間は通常のブラウザ上で作者の原文を目にします。
この仕組みは、実装方法が重要であることも意味します。公式が推奨するReactコンポーネントでは、サーバー側またはbuild timeにエンコードを行い、元の平文がブラウザへ送られないようにします。もし開発者が原文を先にclient-side JavaScriptへ渡し、その後ブラウザ側で変換すると、クローラーがJavaScript bundleから保護前の原文を直接見つけられる可能性があります。そのためShieldFontは、保護したいテキストを可読な形でフロントエンドへ送らないよう明確に注意しています。WordPress、Wix、Squarespaceなど独自のbuild工程を持たないサイト向けには、Encoderで先に文字列を変換し、その後CSSフォントを適用する方式が用意されています。
なぜ記事全体をそのまま文字化けさせない？
現在のShieldFont v18-alphaは、すべての文字を無差別に壊す仕組みではありません。ホワイトペーパーによると、全単語のうち平均約24.4％が置換されます。名詞、動詞、形容詞、副詞など、実際に意味を担うcontent wordsだけを見ると、置換率は約45.8％です。一方、冠詞、前置詞、接続詞、そのほか多くの機能語はできるだけ残されます。これらまで大きく変えると、文章がすぐに普通の英語らしくなくなり、データ品質フィルターによって学習データへ入る前に除外されやすくなるからです。
置換も単純な「名詞を別の名詞にする」だけではありません。ShieldFontは約250のgrammatical poolsを作り、品詞、意味カテゴリー、具体・抽象、単数・複数、動詞の自動詞・他動詞、活用、形容詞の級などを同時に考慮します。例えば、複数形で、抽象的で、コミュニケーションに関係する名詞なら、できるだけ同じ種類に属する別の単語へ置き換えます。単にランダムな名詞を入れるわけではありません。さらに、同義語、反義語、意味が近すぎる単語も置換候補から除外されます。目的は、文章を英語らしく保ちながら、意味だけを原文からずらすことです。現在の辞書には約1万2,000組のペアが含まれています。
このバランスは重要です。変更が少なすぎればクローラーは元の意味をかなり維持できますが、変更しすぎれば、学習データへ入る前の品質チェックで低品質コンテンツとして除外されます。ShieldFontが狙っているのはその中間です。明らかな文字化けではなく、一見すると普通の英語なのに、細部の意味が崩れている文章を作ります。
ShieldFontは本当に効果がある？公式データが示すのは「意味が変わる」ことであって、モデルが必ず汚染されることではない
ニュースでは55.8％の段落が同じ事実主張を維持しなくなった
ShieldFontチームは、ニュース、一般Webページ、小説、古い時代の小説という4種類のデータで現在のv18辞書をテストし、置換前後の文章が同じfactual claimを維持しているかを測定しています。その結果、ニュースでは55.8％、一般Webでは51.9％、小説では34.5％、古い小説では31.1％にbidirectional NLI failureが発生しました。つまり、原文とエンコード後の文章が互いに同じ主張を支持できなくなったということです。対照実験として同じ数だけ本当の同義語へ置換した場合、この割合は約2.1％でした。
| テスト内容 | ShieldFont後に同じ主張を維持しなくなった割合 |
|---|---|
| ニュース | 55.8% |
| 一般Web | 51.9% |
| 小説 | 34.5% |
| 古い小説 | 31.1% |
| 同義語置換の対照群 | 約2.1% |
この数字から言えるのは、ShieldFontがクローラーの取得する文章の意味をかなり変えられる、特にニュースや一般Webコンテンツでその効果が大きいということです。しかし、大規模言語モデルがこの文章を学習した結果、必ず性能が低下するとまでは証明していません。ShieldFontチーム自身もREADMEでこの境界を明記しており、エンコード後のテキストがすべてのデータ品質フィルターを通過するとは主張しておらず、それを実際に学習した大規模モデルが悪影響を受けることも証明済みとはしていません。
ShieldFontの文章の多くは、むしろ品質フィルターで先に捨てられる
ここは特に重要な点です。ShieldFontは、主に「間違った文章をこっそりモデルへ混ぜ込む」ことで機能するわけではありません。チームがFineWeb-Edu方式の品質フィルターでテストしたところ、エンコード済みコンテンツの99.0％〜99.8％がフィルターによって除外されました。別の見方をすれば、元は品質検査を通過できた文章でも、ShieldFont処理後にはごく一部しか残らないということです。実際にフィルターを通過した文章については、Token budgetの約19.4％に意味が変更されたトークンが含まれるとチームは推定しています。
そのため、ShieldFontの実際の作用は2方向に近いと考えられます。一部の記事は品質が低下したため学習データに入らず、残った一部はすでに作者の原文とは意味が変わっています。プロジェクト自身はこれをcollective defenseと呼んでいます。単独の記事1本が数兆Token規模のデータセットへ入っても影響はほぼありません。狙っているのは、多数のサイトが異なる置換ルールを導入したとき、大規模収集側がそれぞれへ対応するために必要な処理コストを引き上げることです。
ShieldFont最大の制限｜実際には復号できる
フォントそのものが復号表なので、特定サイトだけを狙えば突破は難しくない
ShieldFontはこの点をかなり率直に認めています。ブラウザが置換された文字列を元の文章として描画するには、対応するフォントファイルを取得しなければなりません。そしてフォントに含まれるglyph substitutionルール自体が、復号に必要な情報を持っています。開発チームは実際にこの攻撃を自らテストし、公式フォントから11,962組の置換ペアを完全に復元し、エラーはなかったとしています。
つまりShieldFontは暗号学的な保護ではなく、特定の1サイトを狙う攻撃者への防御にも向いていません。公式がカスタムmapping機能を提供しているのは、大規模クローラーが公式辞書1種類だけ準備し、ShieldFont利用サイトを一括で復号する状況を避けるためです。サイトごとに異なるmappingを使えば、クローラー側はフォントを識別し、正しいファイルを取得し、置換規則を解析し、そのサイト用に復号する必要があります。増えるのは作業量であり、突破不可能な壁ができるわけではありません。
OCRならフォント置換をそのまま回避できる
Webページを普通にレンダリングして画像として取得し、その後OCRや視覚モデルで読むだけなら、人間が画面上で見ている原文を取得できます。ShieldFontもこの回避方法を否定しておらず、むしろOCRを現在の防御コストの下限として明示しています。前提にあるのは、大規模クローラーが数十億ページの文字を収集できるのはHTML取得が安価だから、という考え方です。もし各ページでブラウザを起動し、レンダリングし、スクリーンショットを撮り、さらに視覚認識まで行う必要があれば、コストと処理時間は増えます。
そのためShieldFontは、technical impossibilityではなくeconomic defenseと表現するほうが正確です。OCR自体を不可能にする必要はなく、「公開Web全体をこの方法で処理する」ことを割に合わなくするのが狙いです。ただし、どの程度コストが増えれば大手AI企業が諦めるのかについては、現時点で独立したデータはありません。
ShieldFontはSEOに影響する？保護した本文は検索流入向けではない
検索エンジンも置換後の文字列を見る
ShieldFont公式はSEOについても曖昧にしていません。検索エンジンも一般的なテキストクローラーと同様に、ページ下層にある置換済みコンテンツへアクセスするため、Shieldされた文章部分は作者が本来順位を取りたいキーワードではなく、decoy wordsとしてインデックスされる可能性があります。プロジェクトは、Google検索で順位を取りたいMarketing Pages全体を保護せず、検索流入へ依存しないコンテンツ、例えば有料記事、Archive、Manifesto、そのほか検索流入を失ってでもAI学習データとしての利用価値を下げたいコンテンツだけに使うよう勧めています。
ブログ運営者にとって、ShieldFontとコンテンツSEOは本質的に衝突します。ただし、必ずしも完全な二者択一ではありません。ShieldFontはブロック単位で適用でき、React版には<NonShield>も用意されているため、タイトル、ナビゲーション、Captionなどを通常のテキストとして残せます。実際の戦略としては、H1、H2、概要、商品ページ、主要な検索対象コンテンツは原文のままにし、自然検索に依存しない特定の長文や会員向けコンテンツだけを保護する方法が考えられます。
ただし、サイトの主な収益源がGoogleの自然検索なら、SEO記事本文全体をShieldFontに置き換えるのは合理的ではありません。このタイプのサイトでは、robots.txt、AI crawler controls、Cloudflareなどのサーバー側ツールのほうが、少なくとも検索エンジンが必要とする本文を別の文字列へ変えてしまうことはありません。
ShieldFontのスクリーンリーダー問題は改善されたが、現在もWCAG準拠ではない
最新React版ではスクリーンリーダーが単純に偽の文字を読み上げるだけではなくなった
ShieldFontの初期にあった最も直接的な問題は、スクリーンリーダーもクローラーと同じように下層の文字列を読むため、置換後の文章を視覚障害のある利用者へ読み上げてしまうことでした。現在推奨されているReactの<Shield>コンポーネントにはbeta Accessibility Layerが追加され、まずaria-hiddenで置換済み本文を隠し、そのうえで暗号化された本当のテキストを別途提供する仕組みになっています。スクリーンリーダー利用者は、支援技術だけが取得できるボタンから原文を復号できます。ブラウザ側では追加計算に数秒かかります。公式によると、現在はVoiceOverと自動Screen Readerでテストされ、NVDAもCIへ組み込まれています。
ただし、これを「アクセシビリティ問題が解決した」と表現することはできません。ShieldFont READMEでは、Accessibility機能をすべて有効にしても、保護ブロックはWCAG 2.2 SC 1.3.1に準拠していないと明記されています。また、支援技術を使う読者は追加で数秒待つ必要があり、コンテンツ取得までの流れも一般ユーザーとは異なります。公式は、法的にAccessibility基準への準拠が必要なサイト、またはWCAG準拠を掲げるサイトでは、該当コンテンツへShieldFontを使わないよう明確に勧めています。
一般的なWordPressや静的サイトではさらに注意が必要です。公式Reactパッケージではこの代替レイヤーが自動で含まれますが、CDNフォントと手動エンコードだけを使う場合、Accessibility Layerはサイト運営者自身で構築しなければなりません。ShieldFontを「CSSを1行貼れば終わるアクセシビリティ対応済みの防御」と考えられない理由の一つです。
コピー＆ペーストでも置換後の文字列が取得される
SEOより日常利用で気づきやすい制限もあります。ShieldFontを使ったページ上で普通に文字を選択してコピーすると、Clipboardへ入るのは画面に見えている原文ではなく、HTML内に実際に存在する置換後の単語です。つまり、読者が文章を引用しようとしたり、ノートアプリ、翻訳ツール、ChatGPTへ貼り付けたりすると、取得されるのはすでに変更された文章である可能性があります。
そのため公式も、読者がSearch、Quote、Citeする必要のあるコンテンツへShieldFontを使うのは適していないと注意しています。学術論文、教材、政府情報、医療情報、サービス上重要な内容では、このトレードオフを特に慎重に考える必要があります。
ShieldFontは中国語に対応している？現時点では英語のみ
現在、ShieldFontが対応しているのは英語だけです。公式にはalpha、beta、gammaという3種類の主要な英語mappingがあり、それぞれ約1万2,000組の単語ペアを含んでいます。また、置換範囲をさらに広げたmaxhide版もあります。ほかの言語の文字列は置換されないため、英語と中国語が混在するページ全体へShieldFontを適用しても、実際に保護されるのは英語部分だけです。
これは中国語ブログにとって非常に直接的な制限です。中国語対応は、英語の置換辞書を単純に翻訳すれば済むものではありません。ShieldFontの仕組みは、品詞、意味分類、単数・複数、動詞形態といった言語固有の特徴に依存しているからです。プロジェクト自身も、他言語版を作るにはその言語に詳しいネイティブ話者がsubstitution pairsを新たに設計する必要があるとしています。そのため現段階では、中国語サイトはこの技術の発展を観察することはできても、中国語記事の実用的な保護ツールとして導入する段階にはありません。
TwitchがAI学習のオプトアウト設定を追加、ただし過去にどれだけ使われたかは不明
ShieldFontがクリエイター自身でWebサイトを変更して防御する方法なのに対し、同じ週にはTwitchがプラットフォーム側から別の選択肢を提供しました。2026年8月12日、TwitchはTraining for Generative AI設定を追加し、チャンネル所有者がStreams、VODs、Clips、Stream Chats、さらにチャンネル上のテキストや画像を、Amazonの将来の生成AIモデル学習へ使用しないよう選択できるようにしました。この設定はアカウントのSecurity and Privacy内にあり、無効にしてもAutoMod、推薦、字幕など、そのほかTwitch上のAI機能には影響しません。
最も議論を呼んでいるのは、この設定がデフォルト参加で、利用者自身がオプトアウトしなければならない方式であることです。Twitch Chief Product OfficerのMike Mintonは公式配信で「なぜopt-inではないのか」と問われた際、opt-inにするとほとんど誰も参加しないからだという趣旨の回答をしています。
一方、元の記事にあった「Twitchは何年もAmazon AIの学習へコンテンツを使っていたと認めた」という表現は、確定事項として残すべきではありません。Twitchの現在の説明は「将来の学習」から退出できることを明確にしていますが、配信視聴者から過去の動画がすでにAmazonに使われていたのか尋ねられた際、MintonはAmazonが過去のモデル学習で具体的にどのTwitchデータを使ったのか分からないとしています。そのため現在確認できるのは、プラットフォームがAmazonによる生成AI学習へのコンテンツ利用を可能にし、新たな退出設定を提供したことです。過去何年間使われていたのか、どのコンテンツがどのモデルへ入ったのかを公式説明だけで断定することはできません。
米国政府もオープンウェイトモデルを再検討しているが、現時点では未公表の政策調整
米ホワイトハウスは2026年6月、Frontier Model向けの自主的な安全評価フレームワークを設ける大統領令に署名し、基準を満たすモデルについて、公開前最大30日間、連邦政府によるテストを可能にしました。8月初旬に発表された実施方針では、当初は主にクローズドなフロンティアモデルが対象とされ、オープンウェイトモデルは同じ事前テストの対象に含まれていませんでした。
8月12日、WIREDはホワイトハウス関係者と事情を知る人物の話として、この枠組みは今後修正される見込みであり、将来オープンモデルが現在のクローズドFrontier Modelsと同程度の能力へ達した場合、同じテスト対象へ含まれる可能性があると報じました。ただし、これはあくまで関係者の発言に基づく報道であり、ホワイトハウスがすでに新ルールを正式発表したわけではありません。現行フレームワーク自体も自主参加型で、詳細なテスト基準は公開されていません。
そのため、ShieldFont、Twitch、ホワイトハウスの政策を一つの記事で扱うことはできますが、3つをすでに成立した一つの共通制度として書くことはできません。ShieldFontはクリエイター側がデータ収集コストを増やす試み、Twitchはプラットフォーム側が提供するopt-out、ホワイトハウスで議論されているのは高能力AIモデルを公開前の安全評価対象にするかという問題です。共通するのは、「誰がデータやモデルの使い方を決めるのか」という問題が、単なる技術論から製品設計や政策の問題へ広がっている点です。
コンテンツ制作者は今、AI学習用クロールのリスクをどう下げられる？
まず各プラットフォームにAI学習のオプトアウト設定があるか確認する
現時点で最もコストが低い対策です。Twitchの例からも分かるように、この種の設定は初期状態で無効になっているとは限らず、最も分かりやすい場所に置かれているとも限りません。文章、写真、動画、音声を頻繁に投稿するサービスでは、Privacy、AI、Data Usage、Securityなどの設定を確認し、コンテンツが生成AIの学習へ使われる設定になっているか、opt-outが用意されているかを確認する必要があります。プラットフォームごとに方針は異なり、地域によって設定が変わる場合もあるため、すべてのサービスが同じルールだと考えず、個別に確認する必要があります。
自前サイトではrobots.txtとサーバー側制御を先に使い、その後ShieldFontを検討する
ShieldFont自身も、robots.txt、Cloudflare、Akamai、一般的なセキュリティ対策の代替として使わないよう明確に勧めています。robots.txtは少なくとも、サイトが特定crawlerへアクセスを許可したくない意思を明示できます。サーバー側ツールでは、既知のUser-Agent、IP、そのほかのクロール挙動を直接遮断できます。ShieldFontはこうした対策の代わりではなく、その外側に追加する、大規模な無許可mass scrapingのコストを高める実験的な層として考えるのが適切です。
リスク管理の順序としてもこちらのほうが自然です。相手がデータを取得すること自体を止められるなら、わざと変更済みの文章を渡すよりもシンプルです。アクセス制限が無視されたり回避されたりする可能性がある場合に初めて、ShieldFontの「取得されても原文ではない」という性質が追加の意味を持ちます。
SEO記事・会員コンテンツ・オリジナル作品で同じ保護戦略を使わない
検索流入に依存するサイトなら、サイト全体の本文をShieldFontへ置き換えるべきではありません。現実的な使い方として考えられるのは、ホーム、カテゴリページ、検索流入口、SEO記事、商業ページは通常どおりインデックス可能な状態にし、Google順位を必要とせず、大規模収集も避けたい会員向け記事、Archive、一部のオリジナル作品だけを別途保護する方法です。ShieldFont自体がblock-by-blockで適用できるため、技術的にもページ全体を同時に有効化する必要はありません。
中国語サイトの場合はさらに単純です。ShieldFontはまだ中国語コンテンツを実際に保護できないため、現時点でSEOやアクセシビリティを犠牲にしてまで導入する理由はありません。現実的には、各プラットフォームのAI training opt-out、robots.txt、CDN／WAF設定を整理しつつ、中国語mappingが本当に利用可能な段階へ進むかを観察するほうが合理的です。
ShieldFontで最も興味深いのは、「AIが二度と記事をクロールできなくなる」方法を発明したことではありません。自分たちのフォントからmappingを完全に復元できることも公開しており、OCRでも回避でき、SEOとAccessibilityにも明確なコストがあります。本当に新しいのは、防御目標を「コピーを完全に禁止する」ことから、「大量・安価・無差別なコピーを少し面倒にする」ことへ変えた点です。
この方法が最終的に大規模AIの学習データ収集方法を変えられるのか、現時点では証拠がありません。1サイトだけが使っても影響は限定的であり、ShieldFontチーム自身も、多数のサイトが異なるmappingを使うことでcollective defenseが成立することに賭けています。現段階でコンテンツ制作者が取るべき位置づけは、ShieldFontを新しい実験的ツールとして見ることであり、robots.txt、サーバー側ブロック、ライセンス条項、プラットフォームのオプトアウト機能の代替と考えることではありません。
よくある質問 FAQ
ShieldFontは、サーバー側またはbuild段階でHTML内の重要な英単語の一部を別の単語へ置き換え、その後、専用フォントのOpenType置換ルールによって、ブラウザ上では原文の文字として描画します。通常の読者には作者の元の文章が見えますが、HTMLだけを直接取得するクローラーは置換後の文章を取得します。
現在のv18-alphaでは、全単語の平均約24.4％が置換されます。名詞、動詞、形容詞、副詞などのcontent wordsだけを見ると、約45.8％が置換されます。置換語は品詞、意味、単数・複数、動詞活用などに応じて約250のgrammatical poolsへ分類されています。
保証はできません。OCRを使えばレンダリング後の原文を読み取ることができ、フォントファイル自体を解析してsubstitution mappingを復元することもできます。ShieldFontの目的は、特定の攻撃者から文章を永久に隠すことではなく、大量自動クロールに識別、レンダリング、復号などの追加コストを発生させることです。
保護したコンテンツには影響します。ShieldFont公式によると、検索エンジンは置換済みHTMLを読むため、decoy wordsがインデックスされる可能性があります。公式は、Googleで順位を取りたいMarketing Pagesを保護せず、検索流入に依存しない特定コンテンツへ使うことを推奨しています。ShieldFontはブロック単位で適用できるため、サイト全体へ導入する必要はありません。
現時点では準拠していません。React版にはbetaのスクリーンリーダー向け代替機構が追加され、支援技術から本当の文章へアクセスできるようになっていますが、公式はShielded BlockがWCAG 2.2 SC 1.3.1に準拠していないと明記しています。法的にAccessibility対応が必要なサイトでは、該当コンテンツへ直接ShieldFontを使うべきではありません。
現在は対応していません。現行mappingが処理するのは英語だけで、そのほかの言語はそのまま残ります。中国語版を作る場合も、英語辞書を単純に翻訳すればよいわけではなく、中国語の文法や意味に合わせた置換ルールを新たに設計する必要があります。そのため現在、中国語コンテンツ制作者はほかのクローラー制御手段を中心に考える必要があります。