安全法が検閲ツールになるとき

2023年、英国の大手ISPのコンテンツフィルターが、ドメスティックバイオレンスの支援フォーラムをブロックしました。子どもを有害なコンテンツから守るために設計されたフィルターは、このフォーラムを「暴力」に分類し、数百万人のユーザーの検索結果からこっそり除外していたのです。助けを求めていた生存者には「このページは表示できません」という汎用的なメッセージだけが届きました。説明もなければ異議申し立ての手段もなく、ブロックされていること自体を知る方法もありません。サイト運営者がそれに気づいたのは数か月後、英国からのアクセスがほぼゼロにまで落ち込んでからでした。

これは厳密に言えばバグではありません。フィルターは設計どおりに動いていました。暴力に関連するコンテンツを見つけてブロックしただけです。問題は、コンテンツフィルタリングの仕組みが文脈を理解しないことにあります。生存者を支援するために暴力について扱うリソースと、暴力を助長するサイトを区別できないのです。しかも一度フィルタリングの基盤が整うと、その対象範囲は当初の目的を超えて広がっていくのがほとんどです。

パターン：安全のための規制が統制インフラになるまで

政治的なロジックはいつも同じです。政府が子どもを守るためとしてインターネットフィルタリングを提案します。原則として反対する人はほぼいません。法案は幅広い支持を得て成立します。そして、DNSレベルのブロックやディープパケットインスペクション、ISPに対する義務的なフィルタリングといった技術基盤が構築されます。すると、いつの間にかブロック対象のカテゴリが増えていくのです。

オーストラリアの当初のインターネットフィルターは、児童性的搾取素材のブロックを目的として提案されました。実装される頃には、ブロック対象に安楽死に関する情報、中絶反対サイト、一般的なポルノ、ギャンブル、さらにクイーンズランド州の歯科医院のウェブサイトまで含まれていました（最後のは誤ブロックでしたが、数週間そのままでした）。英国の「ポルノフィルター」は、フォーラム、暗号化メールサービス、VPNプロバイダーにまで広がりました。トルコの家族向けセーフティフィルターはLGBTQ+のリソースをブロックしています。ロシアの児童保護法は、反体制派メディアを遮断する法的根拠になりました。

これは陰謀論ではなく、インフラの経済学です。任意のインターネットコンテンツをフィルタリングできるシステムを一度作ってしまえば、ブロックリストにカテゴリを一つ追加する限界コストは事実上ゼロになります。一番高くつくフィルタリング基盤そのものがすでにあるからです。政治的影響力を持つ利益団体は、いずれ必ずこう言い出します。「ついでにXもブロックできませんか？」

コンテンツフィルタリングが意図どおりに機能しない理由

対象範囲が広がるという問題のほかに、より根本的な問題があります。大規模なコンテンツフィルタリングは、そもそもうまく機能しないのです。技術的な限界は深刻です。

過剰ブロックの問題

自動フィルタリングシステムは、膨大な数の誤検知を生み出します。英国のデフォルトONのISPフィルターに関する調査では、上位10万サイトのうち約19%が、少なくとも1つのISPで誤ってブロックされていたことがわかりました。ブロックされたのは、慈善団体、政治団体、教育リソース、小規模事業者などです。スカンソープ問題、つまりフィルタールールに一致する部分文字列を含むというだけで正当なコンテンツがブロックされる問題は、大規模ではいまだに解決されていません。

さらに厄介なのは、過剰ブロックが非対称だということです。大規模で資金力のあるサイトは異議申し立てのプロセスを使ってブロック解除を実現できます。しかしボランティアで運営されている小さなLGBTQ+の若者向け支援サイトには、それができません。過剰ブロックに巻き込まれやすいサイトは、まさにそれに対抗する力が最も乏しいサイトなのです。

過少ブロックの問題

一方で、意欲のあるユーザーはフィルターを簡単に回避します。月に数ドルで使えるVPNを使えば、ISPレベルのフィルタリングはまったく役に立たなくなります。DNSベースのブロックは、DNSリゾルバを1.1.1.1や8.8.8.8に変えるだけで回避できます。技術に詳しい10代であれば30秒ほどでできることです。ディープパケットインスペクションも暗号化トラフィックには苦戦しており、その割合は今やWebトラフィックの95%以上に達しています。

# Bypassing DNS-based content filtering:
# Step 1: Change DNS resolver (takes 10 seconds)
# On Linux/Mac:
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
# Or use DNS-over-HTTPS, which is invisible to ISP filters:
# Most modern browsers support this natively.
# Firefox: Settings → Privacy → Enable DNS over HTTPS
# Chrome: Settings → Security → Use secure DNS
# The filter infrastructure cost millions to build.
# Bypassing it took 10 seconds.

その結果、逆説的な事態が生じます。最もリスクの高い子どもたち、つまり技術に詳しい友人がいる子や、有害なコンテンツを積極的に探している環境にいる子どもたちは、フィルターを回避してしまいます。一方でブロックされるのは、そもそも有害なコンテンツを探すことなどなかったのに、たまたま誤検知を引き起こすサイトを訪れてしまった人たちです。

エンジニアが理解しておくべき技術的な現実

アプリケーション、API、サービスを開発しているなら、コンテンツフィルタリングの義務づけはあなたに直接影響します。知っておくべきポイントは次のとおりです。

• SNIによる検査は廃れつつあります。Encrypted Client Hello（ECH）が主要なCDNとブラウザに展開されています。広く普及すると、ISPは共有IP上でユーザーがどのサイトにアクセスしているかを見られなくなり、見えるのはCDNのドメインだけになります。これにより、ホスト名ベースのフィルタリングは完全に成り立たなくなります。
• DNSの暗号化はDNSベースのフィルターを無効にします。DNS-over-HTTPS（DoH）とDNS-over-TLS（DoT）はDNSクエリを暗号化するため、ISPレベルの監視からは見えなくなります。主要ブラウザがこれをデフォルト設定として展開しつつあります。
• 次の争点はクライアント側のフィルタリングです。ネットワークレベルのフィルタリングが効かなくなると、デバイスやアプリストアにフィルタリングソフトウェアを義務づける提案も出てきています。技術的にはより効果的ですが、あなたのデバイス上であなたの行動をすべて検査するソフトウェアを必要とするため、深刻なプライバシーの懸念を生みます。
• 年齢確認の義務化はプライバシーリスクを生みます。いくつかの法域では、特定のコンテンツに年齢確認を求めるようになっています。実装方法は、クレジットカードによる確認（閲覧履歴と身元を結びつけたデータベースが生まれる）から、生体認証（インターネット利用に顔認証を当たり前にする）まで様々です。

実際に子どもをオンラインで守るものは何か

残念ながら率直に言うと、ネットワークレベルのコンテンツフィルタリングは子どもの安全対策として最も効果の低い方法です。それでも政治的には最も都合がよいのです。プラットフォームの運営方法や、保護者がテクノロジーとどう関わるかを変える必要がないからです。

実際に効果のあるアプローチは、派手さに欠けるものの、より効果的な傾向があります。

• プラットフォームの設計変更：若年ユーザーに対して推薦アルゴリズムの強度を下げる、見知らぬ人からのダイレクトメッセージをデフォルトで無効にする、社会的比較を促す機能を減らす、などです。Instagramのティーンアカウントに対する制限は、問題のあるやり取りに測定可能な効果をもたらしました。
• 透明性の義務化：プラットフォームに対し、コンテンツモデレーションの判断、未成年者への推薦アルゴリズム、有害コンテンツの蔓延状況に関するデータの公開を求めることです。日光は最良の消毒剤、というように、透明性はフィルターより効果的です。
• 通報と対応の体制：明らかに違法なコンテンツ（CSAM、グルーミング）を、プラットフォームレベルでより迅速に削除できるよう投資し、専門の法執行機関のリソースを充てることです。これは実際の被害を標的にするものであり、汎用的な検閲ツールを作るものではありません。
• デバイスレベルのペアレンタルコントロール：ISPレベルのフィルタリングのようにすべての人に影響するのではなく、特定のデバイスで保護者が任意で管理する仕組みです。国全体の検閲インフラを作ることなく、保護者に主体性を与えます。

問題は、オンラインで子どもを守るべきかどうかではありません。もちろん守るべきです。問題は、そのために国民全体に影響する検閲インフラを作るべきかどうかです。特に、そのインフラが実際にはうまく機能しない場合にはなおさらです。

オープンソースとセキュリティ研究への萎縮効果

コンテンツフィルタリングの義務化は、見過ごされがちな形で技術コミュニティに直接影響を与えます。セキュリティ研究者は日常的に脆弱性の詳細、エクスプロイトコード、マルウェアの分析を公開していますが、それらはすべて自動フィルターに引っかかる可能性があります。暗号化、匿名化、検閲回避ツールを扱うオープンソースプロジェクトは、まったく別の目的で設計されたブロックに巻き込まれています。

Tor Projectのウェブサイトは、複数の国のコンテンツフィルターによってブロックされてきました。特定の違法コンテンツがあったからではなく、このツールがブロックされたサイトへのアクセスに使われうるからです。VPNプロバイダーのサイトも同じ理由でブロックされています。これは自己強化的な悪循環を生みます。フィルタリングによって利用者は回避ツールへ向かい、そのツールがブロックされると、利用者はさらにマイナーな回避ツールへ流れていくのです。

開発者にとって、実際の影響は現実的です。セキュリティに関わるドキュメント、ツール、ライブラリをホストしている場合、特定の法域でサイトがブロックされていても、通知も明確な異議申し立て手段もないまま気づかないかもしれません。地域ごとのアクセス状況を監視し、代替の配布経路を用意しておくことには意味があります。

エンジニアにできること

私たちエンジニアは、こうしたフィルタリングシステムの実装を求められることが多い立場です。同時に、その限界を最もよく理解し、より良いアプローチを提唱できる立場でもあります。

1. あらゆる場面で暗号化を支持しましょう。HTTPS、暗号化DNS、暗号化SNI——これらはユーザーのプライバシーを守り、大雑把なフィルタリングを難しくします。これは有害なコンテンツを可能にするという話ではありません。フィルタリングの判断を適切なレベル（ISPではなくプラットフォーム）で行わせるための話です。
2. モデレーションシステムに透明性を組み込みましょう。コンテンツモデレーションを作るなら、判断を監査可能にしてください。誤検知率の統計を公開し、明確な異議申し立てプロセスを用意しましょう。モデレーションと検閲の違いは、多くの場合、透明性の有無だけなのです。
3. セキュリティの見せかけに反対しましょう。プロダクトマネージャーから、うまく機能しないと分かっているコンテンツフィルターの実装を求められたら、そう伝えてください。限界を文書化し、本当の問題に対処する代替案を提案しましょう。
4. 政策議論に関わりましょう。技術者は政策の議論を避けがちですが、私たちの視点は重要です。EFF、Open Technology Institute、Access Nowなどの組織がこうした問題に取り組んでおり、エンジニアリングの専門知識を必要としています。
5. 最悪の規制当局を想定して設計しましょう。コンテンツフィルタリングに使われうるシステムを作るなら、どう悪用されうるかを考えてください。ブロックリストは監査できるか。個々のブロックに異議を申し立てられるか。失効条項はあるか。たとえ間違った人物がそれを支配しても、被害を最小限に抑えられるようにシステムを設計しましょう。

インターネットの最大の強みは、常にそのオープンさでした。誰もが発信でき、誰もがアクセスでき、既存のものの上に誰もが構築できること。コンテンツフィルタリングの義務化は、たとえ善意に基づくものであっても、そのオープンさを少しずつ削ぎ落としていきます。私たちの世代のエンジニアにとっての課題は、統制のインフラを作ることなく、脆弱なユーザーをどう守るかを考えることです。難しい問題であり、簡単な答えはありません。しかし最初の一歩は、自分たちが作っているツールが実際に何をするのか、そして何ができないのかについて正直になることです。