uBlock OriginがFacebookでの広告排除の戦いを諦める

2026年8月12日原文(digitalescapetools.com)

概要

Facebook広告のブロック が困難な理由を解説
uBlock Origin ユーザーの議論内容を要約
Metaの対策技術 について説明
現状の広告回避策 の有効性と課題を整理
今後の対策動向を展望

Facebook広告がブロックしにくい理由

Meta（Facebook運営会社） は広告表示技術の進化を継続
広告要素のコードや構造 を頻繁に変更し、フィルタリング回避を実施
広告コンテンツ が通常の投稿と同じHTML構造を持つ場合が多い
CSSクラス名やID をランダム化・難読化することで、特定を困難化
JavaScriptでの動的描画 により、従来型の広告ブロック手法が通用しにくい現状
uBlock Origin などの拡張機能でも、完全なブロックが困難なケースが増加

uBlock Originコミュニティの議論

RedditのuBlock Originスレッド で、広告ブロックの難しさを共有
フィルタリストの更新頻度 が高まり、ボランティアメンテナンス負担が増大
一時的な回避策 （カスタムフィルタやスクリプト）も、Meta側のアップデートで無効化されやすい
根本的な解決策 が見つからず、いたちごっこ状態が続く現状

現状の広告回避策と課題

カスタムフィルタ導入 による一部広告の非表示
サードパーティフィルタリスト 利用による精度向上
Facebookの軽量版（Facebook Lite） やモバイルWeb版の利用で広告量を減らす方法
広告ブロックによるアカウント制限リスク も指摘される
MetaのAI検出技術 進化で、ブロック手法の寿命が短縮傾向

今後の展望

Metaと広告ブロッカー開発者 の技術競争の継続
ユーザー体験とプライバシー保護 のバランスを巡る議論の深化
より高度な広告検出アルゴリズム や、機械学習活用の可能性
コミュニティ主導の情報共有と協力 の重要性増大
根本的な広告非表示手段 の登場は現時点で不透明

Hackerたちの意見

DNSレベルでfacebook.comをブラックリストにするのは、私には結構効果的だったよ。

└

それ、本当に大丈夫？

└

それは機能するけど、広告を完全にブロックしてるわけじゃないよね。

彼らは、無駄なマークアップをたくさん追加して、「ad」みたいな単語をランダムなクラス名の一文字のスパンに分けたり、8層も深いネストを作ったりしてるから、セレクタを書くのがすごく難しいんだ。これがアクセシビリティにどう影響するのか気になるよね。このコンテンツが支援ツールにちゃんと表示されるとは思えないし。これに対してADAの訴訟を受けるべきだと思う。

└

Facebookのカスタムルールを書こうとしたのは数年前だけど、その時はちゃんとしたaria属性があったし、uBlock Originにはテキストコンテンツ用のセレクタもあったよ。これらは2020年のものだね： facebook.com##span:has-text(Suggested for You):xpath(../../../../../../../../../../../../../../../../../..) facebook.com##div[aria-label="Sponsored"] span[aria-label="Sponsored"]:xpath(../../../../../../../../../../../../../../../../../../../../..) facebook.com##div[aria-label="Sponsored"]:xpath(../../../../../../../../../../../../../../../../../../../..)

└

最近、これを痛感したよ。Instagramのウェブアプリにはすごくウザいポップアップがあるんだ。投稿のコメントボタンをクリックするには、カーソルをユーザー名の上に通さないといけなくて、そのせいで「フォロー」ボタンがコメントボタンのところに出てきて、意図せずそのアカウントをフォローしちゃうんだ。uBlock Originでこのポップアップをブロックしようとしたけど、全然ダメだった。どの要素を選んでも、まだそこにあった。最終的にはInstagramのアカウントを削除して問題を解決したよ。

└

だから、セレクタを書くのがすごく難しいんだ。これって、デバイス上のLLMにぴったりじゃない？

└

深くネストされたスパンを狙うことはできないの？彼らはそれ以外の部分をめちゃくちゃにしてるわけじゃないと思うけど。

└

でも、ノードの計算されたテキストコンテンツをテストするために、xpath式を使えばいいんじゃない？例えば /path/to/ad/div[contains(., 'sponsored')] みたいな。あの式の中には、終端の `` の中にどんなにネストされた要素があっても関係ないし。(そして、厄介なホワイトスペースを考慮するために、正規表現テストを使う必要があるかもね。)

└

彼らがこの件で受けるべきADA訴訟を全部受けることを願ってる。つまり、Facebookに2億ドルくらい払わせたいってこと？それってすごく少ない金額だから、実際には気づかないだろうし、1億7000万ドルは弁護士に行って、他の人には1.30ドルしか行かないってことだよね。それがどうなるかって感じだね。

└

逆の戦術を使って、見たくないものは全部ブロックしたり隠したりするのもありかもね。

└

セレクタを書くのがすごく難しい。AIが出てくる前は特にね。今、諦めるのは皮肉だよね。新しいdivの迷路を自動で探して、セレクタを書くエージェントを作ることもできるかも。Facebookがこれらの迷路を生成するのにAIを使ってるのは間違いないよね！

Hacker Newsで議論の続きを見る

ハクソク