Japanese FAQ
最終更新：2022/10/29
内容は各項目執筆時点のものですのでご了承ください。脚注は詳しい方向けです。
A1-1
ダメです。理由は３つあります。
- 日本語フィルタが不在
現在主流の広告ブロッカーはフィルタリストに書かれたルールを強制するためのプログラムであり、フィルタこそが心臓部です1-1。主要な日本語サイトの広告を大体除去するだけなら、100ほどのドメインをブロックするだけでもかなりの効果がありますが、一部の厄介なサイトに対応するには特殊な文法で書かれたフィルタが必要です。そして、各ブロッカーにはそれぞれ専用のフィルタ記法があり、それを無視して使うと十分な効果が得られません。執筆時点で、ABPは日本語サイト用のフィルタリストを用意していません1-2。AdBlockはABP Japanese filtersを用意していますが、すでに更新が停止しており、不具合の修正等は期待できません。実際にYoutubeをはじめ多方面で不具合を起こしています。ではもちフィルタや豆腐フィルタといった外部フィルタを購読すればよいかというと、これもうまく機能しません。これらのリストはuBlock Originを前提としていますが、ABPやAdBlockはuBlock Origin用の文法を解釈できないばかりか、そのような解釈不能ルールがあるとそのページ上でほかのルールまで無効にしてしまいます。
- 機能面
日本語でABPとuBlock Originを比較する話になると、大体がパフォーマンスと後述の「控えめな広告」に終始しがちですが、ABPは純粋なブロック機能においてもuBlock Originに大きく後れを取っています。これはフィルター作者にとってこそ死活問題であり、主要な日本語フィルタがすべてuBlock Originを前提としているのは偶然ではありません。たとえばCSS挿入やリソースリダイレクト、またnowoifなどの有用なスクリプトレットの多くが欠如していますし1-3、ドメインワイルドカードにいたってはすでにパッチがあるにもかかわらず採用されていません。これでは一部のアンチ広告ブロックに対して無力になりますが、ABPはそもそもアンチ広告ブロックには対処しない方針です。
- 信頼面
これは個人的な価値観にもかかわるので軽く触れるにとどめますが、現在の広告ブロッカーはユーザーがアクセスする全URLをのぞける強大な権限を持っているため、信頼は大事です。ABPを提供しているeyeo社の主要な収入源は「控えめな広告」という仕組みによるもので、デフォルトで許可される広告のリストに追加するかわりに、広告事業者からお金を受け取るものです。この許可は設定から無効にすることも可能です。一方で多角的な事業展開をしており、彼ら自身が広告を提供しだしたり、Android版Edgeに組み込ませたりしています。AdBlockは2015年に「身元を明かしたくない」何者かに買収されましたが、実はそれがABP開発元のeyeo社であることが2021年に判明しました。当初は買収していないとコメントしていたため、それは嘘だったことになります。uBlock（Originでない方）は2018年にAdBlockに買収されているため、eyeo社はuBlockも買収していたということです。
注意点として、ABPはデフォルトでは広告のみをブロックするのに対し、uBlock Originはアクセス解析もブロックするため、これによる不具合に遭遇することがあります。アクセス解析をブロックしたくない方は、フィルターリストからuBlock₀ filters - Privacy, EasyPrivacy, およびPeter Lowe's Ad and tracking server listのチェックを外してください。
おまけ： AdGuard, uBlock Origin, Brave, Adblock Plus, Vivaldiの標準設定（Vivaldiは広告とトラッカーをブロック）で同じサイトを訪れたときの比較
1-1: Firefox版uBlock Origin公式ページ：「この拡張機能は、あらかじめ設定されているフィルターのリストが無ければ意味を成しません。ですので、何かしらの形で貢献したいと考えることがあった時は、これらのリストを無料で懸命に更新し続けている方々を思い出してください。」、uBlock Origin Github公式ページの一節："Have a thought for the maintainers of the various lists. These lists are everything. This can't be emphasized enough."、また、AdGuardTeam/AdGuardFilters（AdGuardのフィルタ専門リポジトリ）の副題："The place where ads are actually blocked"
1-2: ABPはChromium Manifest V3互換の日本用フィルタリストを模索していましたが、eyeoのフィルター作者が自作する可能性が濃厚になっています。
1-3: ABPではuBlock Originでいうprocedural cosmetic filtersとスクリプトレットをまとめてスニペットと呼んでいますが、ABPのスニペットは、hide-if-contains-image-hashのような非表示系に偏っています。一方で、uBlock Originのset.jsに相当するoverride-property-readなどはYoutube広告対策に必須となった2020年8月になってようやく実装される始末です。
A1-2
歴史的な経緯についてはほかに優れた記事（日本語ではたとえばこちら）があるのでそちらに譲ります。現在はAdBlock（getadblock.com）のエンジンはAdblock Plusそのものであり、外装を付け替えただけです。A1-1で述べたように、AdBlockはABP運営元に買収されているので当然かもしれません。小文字のAdblockについては知りません。
A1-3
A1-1を参照していただきたいのですが、豆腐フィルタやもちフィルタが採用しているuBlock Origin文法に対応した組込みブロッカーは、PCでは私の知る限りBraveのみです。（Rustの制約により一部の正規表現フィルタが機能しない、ドメインワイルドカードがまだ機能しないなど、対応は不完全です。CEO自ら認めているように、ブロック機能はuBlock Originのほうが上です）。Vivaldiは基本的な文法しかサポートしていません。Manifest V3問題から移行先にあげられることがありますが、2021年5月現在のVivaldiの実装ではむしろV3対応のブロック拡張のほうが（ルール数などマイナーな点を除いて）自由度が高いです。いずれにせよ、もし広告ブロック拡張機能を追加するのであれば組込みのブロッカーは完全に無効にし、併用は避けるべきです。
なお、あまり知られていなさそうですがBraveの広告ブロックは標準ではファーストパーティー広告、つまり訪問したサイトから直接配信される広告（たとえば検索エンジンの広告）はブロックしません。Shields設定からブロックを「積極的」に変えることでそれらもブロックされるようになります。また、デフォルト設定では日本語のモバイルサイトにほとんど対応していないため、モバイルでご利用の方は必ずchrome://adblockからAdguard Mobileを追加してください（A3-8参照）。
A1-4
2022年9月17日追記：MV3対応ブロック拡張機能の性能ですが、現行のMV2拡張機能と比べれば大幅に落ちるものの、総合的には「iOS15以上でのSafariコンテンツブロッカー + Safari拡張機能より少しまし」程度になると思います。（ルール数制限はiOSより厳しく、整形フィルタの安定性やフィルタ更新に大きな問題があるものの、正規表現の制約がiOSほどには厳しくなく、リソースリダイレクトなどの高度な機能が概ね使えるためです）
2022年8月28日追記：BraveがManifest V2のサポートを継続することは確定しています。
2022年5月19日追記：FirefoxもいずれはManifest V3に移行しますが、それによってuBlock Originが死滅するようなことは（作者がやる気をなくさない限り）まずありえません。そもそも、MV3や宣言的アプローチが根本的に悪いというよりGoogle主導のChromium MV3が問題です。MozillaでMV3対応の指揮を執っているRob Wu氏はList Authors Chat（広告ブロックフィルター作者を中心としたコミュニティ）のメンバーでもあり、十分な時間をかけアドオン作者のフィードバックを反映しながら進めていくことを約束しています。仮にブロッカーの機能に一定の制限が出るとしても、それによって実際にセキュリティが向上するならgorhillが反対するとは考えにくく、どこかで妥協点を探すことになると思います。また、MV3の結果として拡張機能のレビューが高速化するならブロッカー側にとっても大きなメリットとなります。
まず、専門外ですので以下には間違った点があるかもしれません。広告ブロック拡張自体はManifest V3準拠のDeclarative Net Request APIでも可能です。V3移行で広告ブロック拡張が死ぬかのような主張は的外れです。しかし、現状のまま移行されるとuBlock Originのような高度で柔軟な機能を持った拡張機能は死滅します。それ以上に、少数のボランティアに頼っている現在のフィルタコミュニティは打撃を受けるでしょう1-4。既にiOSは大きな負担となっています。広告ブロックコミュニティ側も、Manifest V3のすべてに反対しているわけではもちろんなく、ちゃんと意味のある制約は受け入れる意思を示しています。批判の要点は、プライバシー保護が目的というなら筋違いではないかという点と、広告ブロックコミュニティの実情を理解していないという点が大きいのではないかと思います1-5。webRequest APIのうちブロック以外は残るため、Chromiumチームが挙げているような悪用はManifest V3でも可能で、プライバシー保護への直接的な効果はほぼありません。Googleの計画では2023年1月にManifest V2に基づく拡張機能が一般には使えなくなるため、uBlock OriginがChromiumベースのブラウザ上で使えなくなるものと予想されます。
1-4: 機械学習を使えばいいという人もいますが、現状ではフィルタコミュニティの代替になるようなものではありません。Adblock Plusは既にFacebookのフィルタ作成用に機械学習を使っていますし、Braveが関与しているAdGraphをはじめ、機械学習を広告やトラッキングのブロックに使った論文は多く出ています。
1-5: 当初、Googleはパフォーマンスも理由に挙げていましたが、現行のAPIがまったく足かせになっていないデータが示されたためプライバシーに軸足を移しました。一方で、一般にはルール数の制約といったわかりやすい点ばかりが流布している気がします。ルール数は本題ではありません。そもそもuBlock Originが持つような高度な機能が必要となった背景には広告提供側とのいたちごっこが一因としてあります。実際にAdGuardやuBlock Originは絶えず新機能を追加し続けてきましたが、Manifest V3下では多くの場合ブラウザ開発側にそれを要求しなければならず、迅速に対応してもらえるか、そもそも対応してもらえるか自体保証はありません。
A1-5
2020年10月17日追記：Nanoプロジェクト（Chrome版）はトルコの開発者に売却され、危険な機能が追加されたためストアから削除されました。ChromeでNanoをご利用の方は速やかにアンインストールしてください。Firefox版は別の方がメンテナンスしているため大丈夫です。以下の内容は執筆当時のものです。
目的と使い方によります。もし、アンチ広告ブロックを念頭に置いておられるのなら、uBlock Originで十分です。2020年時点で、Nanoに報告されるすべてのアンチ広告ブロックはuBlock₀ filtersかuBlock₀ filters - Annoyancesにて対処されています1-6。ただ、Nanoではコンテンツを妨害しないソフトアンチブロック（例：Outlook.com無料版で右側に出る「お願い」）もデフォルトで対処するのに対し、uBlock Originの場合はuBlock₀ filters - Annoyancesの購読が必要になります。Nanoの最大の利点は強力だがリスクもあるスクリプトレットで一部の迷惑要素に対処できる点ですが1-7、Nano filters - Annoyancesはほぼ海外向けです。日本語サイトを中心に見る人は、自分でルールを書くのでなければNanoを使うメリットはほぼありません。むしろ新機能への追随が遅れることがあり1-8、使うフィルタによってはデメリットさえあります。ただ、NanoにはQuick reporterという問題報告ツールがあり、これは別の意味で大きなメリットといえます。アンチ広告ブロックは目立つため、初心者の方にはなにか特別な対処を要するものに思えてしまうのかもしれませんが、フィルタ作者にとって対処は容易です。しかしこれは評判が悪かったため、近年増えてきているのはブロッカーを検知してそれを迂回する広告を再挿入するパターンです（これもあまり成功していないようです。広告を見たくない人に無理やり見せるのだから当然ですが）。
1-6: Nano Defenderには、あるタイプのアンチ広告ブロック全般に対処するgeneric solutionという仕組みもありますが、機能的にはuBlock Originでもほぼ同等のことは可能です。しかし、パフォーマンスや副作用への懸念などからあえて避けています。
1-7: スクリプトレットにはもともとリスクがありますが、uBlock Originではあらかじめハードコードされたスクリプトのみを使うようにしてリスクを抑えています。この点はNanoも同じです。では何が違うかというと、uBlock Originの組込みスクリプトは最悪でもページの外見や機能を壊すくらいしかできないのに対し、Nanoのスクリプトにはたとえばクリックをエミュレートするものがあり、これを使ったフィルタの存在を知っている攻撃者が対象サイトを乗っ取れば、マルウェアのリンクを自動クリックさせることもできます。ショッピングサイトなどであればもっと直接的な悪用もできるでしょう。このため、uBlock Originではこれらのスクリプトが広告やアンチ広告ブロックへの対処にどうしても必要となるまでは採用しないと決めています。
1-8: DandelionSprout氏によると、domainオプションのワイルドカードサポートへの対応遅れが問題となったようです。
A1-6
A1-5で述べたように、Nanoはいらないと思います。uBlock Originに戻したことでアンチ広告ブロックが出るようになったという人は十中八九、フィルタ選択を間違えていると疑われます。まず、uBlock₀ filtersが有効なことを確認し、それからほかのフィルタについても見直してみてください。初心者の方はフィルタを追加する方向に動いてしまいがちですが、AdGuardへの報告ではむしろ過剰購読により惹起してしまっているケースが後を絶ちません。追加する前に、減らすか切り替えることをご検討ください。また、アンチ広告ブロックのテストページはuBlock₀ filtersの対象外です1-9。テストページでブロッカーが検知されるからと言って、アンチ広告ブロック対策がされていないと早合点しないでください。それでもアンチ広告ブロックに遭遇してしまった場合1-10、フィルタ作者に報告してください。フィルタで対処できないアンチ広告ブロックは知られておらず、サイト側がこちらの対策を監視していたちごっこにならない限りは必ず対処できます1-11。予防的な対処がしたいのであれば、一番簡単で効果的なのは「汎用非表示フィルターを無視する」にチェックを入れることです。ただし広告枠やテキスト広告、一部ポップアップが隠し切れなくなるなど副作用もあるため、中級者以上（ある程度自己対処できる方）向けです。また、Firefoxの強化型トラッキング防止機能は無効にしたほうが遭遇率が下がります。どうしても標準のリストと日本用フィルタ以外にフィルタを追加したいのであれば、せいぜいAdGuard Baseくらいでしょう（uBlock Originの設定の、フィルターリスト ＞ 広告にあるものを使ってください）。まれにuBlock₀ filters未対応のアンチ広告ブロックに対応している場合もあります。ただし、uBlock Originで使うとそれなりに不具合もあり、逆にアンチ広告ブロックを起動してしまうこともあります（一例。スクリプトレットの干渉により起動するケースも時々あります）。Fxxk Fxxkadblock（あえて伏字）はA3-6と同様の理由に加え、不具合リスクの高いルールやパフォーマンス負荷の高いルールが多いためおすすめしませんし、uBlock₀ filtersとBaseがあればまず不要です1-12。Fanboy's problematic-sitesはA3-6で述べたFanboy's Enhanced Tracking Listのサブフィルタで、A3-6と同様の理由でおすすめしません。これらのフィルタで効果がある方は、もともとご利用のフィルタがアンチ広告ブロックのトリガーを引いてしまっている場合がほとんどです。一方、AdGuard AnnoyancesやuBlock₀ filters - Annoyances、ついでにAdblock Warning Removal Listが対応するのはA5で述べたようにソフトアンチブロック、つまり邪魔にならないか×を押せば消せるようなものですので、悩む方は少ないと思います。とくにAdblock Warning Removal Listはロシア語のマニアックなサイトを見る人以外には無意味といってよく、uBlock Originでブラックリスト指定されています。アンチ広告ブロックは個別対応ではきりがないため、雪フィルタにおいてはトリガーをできるだけ丁寧に迂回して個別対策の必要性を減らしています。ほかの日本用フィルタと併用されるとこうした努力が水泡に帰す可能性があるため、やめてください。
1-9: 雪フィルタでも対象外としていましたが、初心者の混乱を避けるため対応してみました。
1-10: 日本用フィルタでのみ惹起されるアンチ広告ブロックもあります。この場合uBlock₀ filtersは対応しませんので、ご利用のフィルタ作者に報告してください。また、AdGuard日本語フィルタで対処されているアンチ広告ブロックは、原則としてuBlock₀ filtersでは対処しません。同様の理屈でちょっと罠かもしれないのが、日本人利用者が多いと思われる違法コンテンツサイトやアダルトサイトの中に、たとえばスペイン/ポルトガル語のサイトがあります。この場合、uBlock Originではスペイン/ポルトガル語用のフィルタを購読するのが前提となりますが、実際にそうされている日本人利用者がどれほどいるか疑問です。そのため雪フィルタでは言語にこだわらず、日本人利用者がある程度いるサイトは網羅的に対応しています。AdGuradにはフィルタの自動有効化機能があるためこうした問題は起きにくいですが、人によってはめったに訪れないサイトのフィルタを大量購読する結果になります。
1-11: uAssetsでcan't fixとなっているものは、いたちごっこの結果、対策が副作用をはらむものとなってしまったものです。一方、迂回広告やポップアップ、迷惑要素の中にはフィルタで対処できないものもあります。
1-12: 同リストのソースのほとんどはuAssetsとAdGuardFiltersであり、uBlock₀ filters, Base, または各言語用フィルタのいずれかで対処されます。しかしそれらと異なるフィルタ記法も多く、それらを購読している人には無駄になります。また、対象サイトの多くは頻繁に仕様を変えてくるのですが、同リストは廃れたルールも大量に含んでいます。古いスクリプトレットルールはパフォーマンスの損失だけでなく不具合の原因ともなります（最近の例）。加えて、多くの汎用非表示用が無効にされており、「汎用非表示フィルターを無視する」同様、枠残りなどの原因ともなります。「A3-6と同様の理由」の例としては@@|http*:*/ima3.js|$script,xmlhttprequestというルールは確かに一部のアンチ広告ブロックに有効ですが、一方で一部の広告が素通りするようになります。
A1-7
確かなことは何も言えませんが、個人的な意見としては、Raymond Hill（uBlock Originの開発者、gorhill）は開発を中止することはあっても売却やその他ユーザーを危険にさらすことはないんじゃないかと思います。彼自身が今回の騒動で述べているように、現在の広告ブロック拡張機能は強大な権限を持っており、開発者を信用できなければ使うべきではありません。私はuBlock Originの前々身であるHttp Switchboardの誕生にも立ち会っている最初期ユーザーの一人で、そのころから何度か言葉を交わしていますが、ことセキュリティやプライバシーには厳格な人です。ほかの悪質な拡張機能を見回ったり、パラメータの書き換え機能をセキュリティ上の問題で却下したり（同機能を採用したAdblock Plusは後に脆弱性として指摘されることに）、例には事欠きません。また、お金に影響されるのを避けるため寄付すら拒否しており、儲け話の誘いがあればさらし者にしています。実は一度、負担に耐え切れずuBlock Originの前身であるuBlockを新開発者に譲渡したことがあるのですが1-13、この時の失敗は氏にとって苦い経験だったようで、今でもときどきRedditなどで言及しています。
1-13: 日本語ではこちらの記事が詳しいです。ただし、「オリジナルの作者が現開発陣の運営方針を疑問視し、独自に開発存続をアナウンス」という時系列は、話としてはわかりやすいですが間違いです。オリジナル版の開発継続は当初より決まっていたことで、uBlock Originの名称もchrisaljoudiが問題行動を始める前に決まっています。
A1-8
PCではブラウザ上のブロックで大抵の人は足りると思います。この場合、一番のおすすめはuBlock Originです。Macは使っていないのでわかりませんが、FirefoxならuBlock Originが使えるようです。モバイルではアプリ内の広告もまれではないため、デバイス全体をカバーできた方がよいでしょう。AdGuard for Android/AdGuard for iOS（PlayストアにあるAdGuardは似て非なるものですので注意）がもっともメジャーで、かつ機能的にも十分だと思います1-14。なんJ AdGuard部さんに記事がまとまっています。なお、iOSではiOS15と14以下で機能に大きな差があります。ネットワーク全体をカバーするには、Pi-holeやAdGuard Homeを使う方法と、DNSキャッシュサーバーを広告ブロック機能のあるものにする簡易的な方法があります。AdGuard Homeについては280blockerさんがわかりやすい記事を書いてくださっています。ただしこれらはドメイン単位の粗いブロックしかできないため、各デバイスのブロッカーを置き換えることはできません。少々乱暴に、主要なブロッカーを機能を機能が強力な順に並べる（フィルターによる差は無視）と
AdGuard（iOS、コンテンツブロッカーを除く）, uBlock Origin > Brave > Adblock Plus, AdBlock, Safariコンテンツブロッカー（Mac, iOS15）, Chromium Manifest V3下のブロッカー >> Safariコンテンツブロッカー（iOS14）, Vivaldi >> ドメインブロック（hostsファイル、広告ブロックDNS、Pi-holeなど）
のようになると思います。
1-14: Android上でuBlock Originを使う場合、Firefoxにインストールするのが無難です。よく挙げられるKiwiブラウザはもともと公式にサポートされていない上に、最近の更新でuBlock Originなどのコンテンツブロッカーが機能しないURLが大量に追加されました。
A1-9
やめてください。1.で述べたブロッカーとフィルタの区別が理解できれば、無意味なことがわかるはずです1-15。しかもuBlock Originのリソースリダイレクトルールを無効にしてしまい、いたずらに不具合、アンチ広告ブロック、広告再挿入を引き起こしてしまいますし、$ghideや$badfilterも無駄にしてしまいます。ブロックを強化したり、アンチ広告ブロックを除去したりしたいのでしたら、するべきことはブロッカーの複数使用ではなく、適切なフィルタの選択です。中級者以上の方であれば、ブラウザの広告ブロック拡張機能にhostsファイルあるいはネットワーク全体のブロックを組み合わせるのもありですし（たとえばPi-hole, AdGuard Home, UnboundなどによるDNSブラックホール。リソースリダイレクトが利かなくなる場合があり、アンチ広告ブロックへの遭遇率が上がるため推奨はしません）、Androidならブラウザ広告をuBlock Originで、その他のアプリをAdGuradでという対処も有効ですが、不具合への対処といった点から初心者にはおすすめしづらいものがあります1-16。また、トラッキング対策のGhosteryやPrivacy Badgerなどを勧める人もいますが、これもほとんど意味がありません。多くの論文で、uBlock Origin（デフォルト設定）が最高レベルのトラッキング保護と高パフォーマンスを両立していることが実証されています。トラッキング対策を強化したいなら、やはりフィルタの選択が肝要です1-17。雪フィルタ単独でも日本のサイトにおいてはかなりのトラッカーをブロックしていますが、これにEasyPrivacyかAdGuard Tracking Protectionのどちらか（両方はほとんど無意味）を加えれば多くの人には十分です。これ以上を求めるなら、ブロッカーの併用などよりMedium modeといったデフォルト拒否の採用を考えるべきです。
2022年8月3日追記：Windscribe VPNの拡張機能、Windscribe - Free Proxy and Ad Blockerは非常に古いバージョンのuBlock Originを組み込んでおり、しばしば問題を起こしています。最新のuBlock Originを導入して同拡張機能のブロック機能は無効にすることをおすすめします。なお、この件についてuBlock Originの作者が直接抗議しており、Windscribe側も対応を約束しましたが何年たっても、再三要請しても果たされていません。個人的に、Windscribeは新興VPNの中では比較的よいサービスだと思っていますが開発者の倫理意識には疑問を抱かずを得ず、残念です。
1-15: たとえばuBlock OriginにAdblock Plusを追加した場合、理論上追加されるブロック項目はuBlock内製フィルタとABP filtersの差分になります。ABP filtersは日本のサイトは一切扱っておらず、海外についてもフランス、ポーランド、ロシア、中国などいくつかの言語を除けばuBlock内製フィルタに遠く及びません。これらの言語は、uBlock Originが（Adblock Plusと異なり）地域用フィルタに高度な文法を利用可能なフィルタリストを採用しているため、内製フィルタで対応する必要がないものになります。なお、併用したブロッカーのカウンターやログに計上されるのはブロック漏れではありません。これはFirefoxのトラッキング防止や、註16でも述べますが条件次第ではブラウザ上のブロックとAdGuard for Android/Windowsを併用した場合にもあてはまります。
1-16: たまに、コンピュータのリソースを使わないからパブリックDNSでのブロックのほうが処理が速いと信じている人がいます。通信のフローを考えれば自明なはずですが、ブラウザ上でブロックすればそもそもDNSや広告サーバーへの通信自体が発生しないのに対し、パブリックDNSでのブロックはキャッシュがなければDNSの応答を待つ必要があります。ブラウザ組込みのブロック機能を除けば、アプリケーション版AdGuardのみが、場合によりブラウザ拡張機能より先にブロックすることがありますが、これは一定のコストがかかる方法のため必ずしもパフォーマンス上ベターとはいえません。ただ、ブラウザ上でもブロックしている場合、ブロック漏れにみえるおそれがあります。なお、Chromium拡張機能ではprefetchがブロックできず、こちらはある意味本当の漏れですが、prefetchではハンドシェイクやTLSネゴシエーションまでしか行われないため、問題とみなすかは人によるでしょう。
1-17: トラッカーは目に見えないためブロックしてもしなくてもほとんどのユーザーは気づかず、一方でしばしば不具合の原因となるため、フィルタ作者にとってモチベーションが上がりにくい対象です。実際、公開されているABP形式日本用ブロックフィルタで、トラッカーを独自解析して他リストにないエントリーを追加し続けている/きたのは280blockerさんと当サイトくらいだと思います。
A1-10
両者間には非常に多くの違いがあり、ここで詳細に論じる余裕はありませんし単純にどちらが優れているということもありません。さらにAdGuardの場合、拡張機能とアプリ版ではまったく別といってよいですし、iOS版もまた別物です。最終的には各自が何をどこまでしたいのか、どこを重視するのかという問題になってきます。まず、パフォーマンスについてはuBlock Originに利があります。ブロックにせよ非表示にせよ、正しくフィルタを書けばフィルタ数が問題にならないといえるのはuBlock Originならではです。人によっては完全無料であることやオープンソースであることもポイントになるかもしれません。また、AdGuard Japaneseを除いたすべての日本用フィルタリストがuBlock Originを前提としており、たまにAdGuardで互換性の問題が起こることがあります1-18。上級者で動的フィルタリングが利点となる方もいると思います。一方、AdGuardの利点としては、アプリ版ならデバイス全体をカバーできることがまず挙げられます。ChromeがManifest V2を廃棄しても影響を受けません。人によってはステルスモードもポイントになるでしょう。上級者の方には、別途ユーザースクリプト用の拡張機能などを用いたり、面倒な設定をしたりせずとも自由度の高いスクリプト挿入ができるのも魅力かもしれません。ブロック機能自体については実際の違いはわずかで、どちらでも十分なブロックができます1-19。ただ、実際のブロック性能はフィルタによって決まるため、違いは出てきます。これもどちらがよいと単純にいえるものではないですが、アンチ広告ブロックへの遭遇率はuBlock Originのほうが少し低いです。これは、uBlock₀ filtersがGoogle Funding Choice Anti-adblockへの汎用解を採用したり、ある種のリクエストをデフォルトでredirect-resourcesに回したりしているためで、ブラウザ拡張機能のみである（多様なプラットフォームを考慮する必要がない）ことが逆に利点となっています（AdGuardに当サイト提供のアンチ広告ブロック対策強化パッチを追加していただくと、ほぼ同等になります）。一方、AdGuardのフィルタはサイトの外見をより丁寧に整え、追跡防止フィルタはuBlock Origin標準のEasyPrivacyより不具合が少ない傾向にあります。また、モバイルアプリのトラッキング対策はEasyPrivacyより充実しています。
1-18: AdGuard + 豆腐フィルタでYouTubeに障害が発生したケースがあり、この際は当管理人も解決に尽力させていただきました。また、もちフィルタで一部のフィルタが機能しないこともありました（解決済み）。
1-19: サポートしているフィルタオプションやスクリプトレットの種類はAdGuardがやや多く、カスタムスクリプトが使えるメリットもありますが、必要性の高いものは結局両者とも採用します。両者に貢献しているフィルタ作者としては、サポートの有無よりも細かな仕様の違いが問題になることが多いです。上述のYouTubeの問題もjson-pruneの違いによるものでした。
A1-11
ありません。いじわるではなく、本当にないのであきらめてください。Ad Blocker Testなどは有名かもしれませんが、こんなものでブロッカーの性能は評価できません。このサイトが行っているのは、いろいろな広告サーバー（どういう基準で選ばれたのか不明）に空っぽのxmlhttprequestを投げ、それらが狭い意味でブロックされたかどうかを評価するというものです。しかし、実際にそれらのサーバーが使って1-20いるURLと異なるため、現実ならブロックされるのにテストでは失敗判定になるケースが多数あります。また、ウェブ上のテストなのにモバイルアプリのトラッカーを多数含んでいたり、クリックスルートラッカーという、本来リクエストを発生させずユーザーがリンクをクリックしたときのみ機能するものも含んでいたりします。挙句の果てにリソースリダイレクトがされるとブロック判定に失敗するためuBlock Origin標準設定の評価が大きく落ちます。
きちんと信頼性のある広告ブロックテストを作ることは理論上は可能ですが、AV-Comparativesのような機関でなければ難しいと思います。
1-20: パスを含んでいない、リクエストタイプが異なるというのみならず、サブドメインさえ現実と違う場合がありドメインリストの評価すら正しくできません。たとえばfreshmarketer.comは、現実のトラッカーとしては必ずcdn.freshmarketer.comとして使われるためPeter Lowe’s Ad and tracking server listでブロックされますが（本稿執筆時点で、実際にはもう稼働していない模様）、このテストではhttps://freshmarketer.com/というURLのためブロックされません。
A2-1
カウンターの上昇は何も問題ありません。どういうわけか、カウンターが上がり続けるとパフォーマンスに悪影響があると信じている人が多いようです。確かに、ブロックされた場合に大量のリクエストを送り続けるケースはあり、フリーズしたりCPU使用率が跳ね上がったりしますがこれはそのサイトの問題です。1秒に1つ程度のカウンター上昇なら何も影響ありません。どうしても信じられないなら、開発者ツールからパフォーマンスレコードをとって報告してください。また、逆にカウンターの数字が大きいほどたくさんブロックしてくれていると信じてアドオンやフィルタを比較する人もいますが、これも一概に言えません。Adblock PlusとuBlock Originではカウンターの仕様が異なりますし、HTMLフィルタで除去してしまえばカウンターの数字は上がりません。そもそもブロッカー検知用プローブ（アンチ広告ブロックとは無関係に、統計的情報を得るため使われることも多いです）などはブロックしない方がいいのですが、この点を理解されていない方も多そうです（例）。
A2-2
AdGuardインストール時にSNSウィジェットのブロックを選択していたなら至極当然です。これらを表示するため、ブロックを（そのサイトで）オフにするのはとんでもない話です。対応は簡単で、設定 > フィルタから「SNSウィジェット」または「ソーシャル」の項目を無効にしてください。インストール時のナビゲーションではデフォルトでチェックが入っているので、気づかずに有効にしてしまった方が多いのかもしれません。これに限らず、よくわからずにフィルタを有効にしてしまい、不具合に遭遇してブロッカーをオフにしてしまう方が多いようです。
A3-1
ご利用のブロッカーとフィルタの種類や書き方に依存します。uBlock Originでは、正しく書けばフィルタ/ルールの数は処理時間やCPU消費に影響を与えません（文字列長など、別の要因のほうが大きな影響を与えます）。「正しく書けば」についてはA3-3, A3-4に要点をまとめていますが、ABP文法からは自明でないことが多いです（uBlock Origin開発者がいうには、いつか暇があれば効率的なフィルターライティングのポイントをまとめたいとのこと）。逆に、たった一つの非効率なフィルタがパフォーマンスを悪化させた例は過去にいくつもあり、数は問題になりませんが質は問題になります。なぜ数が影響しないかについて、大幅に単純化した説明を試みてみます。
あるリクエストが何万ものフィルタのどれかにマッチするかしないかを判定するとき、一個一個ルールを調べていたのでは効率が悪いです。もしそのリクエストがスクリプトなら、$image指定された（= 画像ブロック用の）ルールはマッチする可能性がまったくなく、$script指定されたルールとタイプ指定なしのルールだけ調べれば十分です。これらのタイプ指定はメモリ上にフラグとして置かれており、一括してフィルタリングできるため$image指定されたルールが１個であろうと10000個であろうと関係ありません。１個ないし10000個のルールはマッチング処理の早い段階で、同様の計算コストで候補から除外されます。このような手続きをさらにパーティ種別やトークンに対してもおこなうと、最終的にマッチする見込みのある、調べる価値のあるルールはそれほど多く残らず、その数は元のルール数が指数関数的に増えない限りほとんど変わりません（トークンの部分はもう少し複雑）。
汎用整形フィルタに対してはuBlock OriginはDOM surveyorというものを用い、そのページで実際に必要な汎用整形フィルタだけを挿入するためやはり数は問題になりません3-1。AdGuardでは汎用非表示フィルタの数はパフォーマンスに影響を与えますが、実際は数だけでなく質にもよります。
3-1 :厳密にはLow-generic cosmstic filtersの場合のみ。
メモリ消費とアドオン起動時間、フィルタ更新時の処理時間はフィルタ数の影響を受けます。とはいえFirefox上のuBlock Originでは10万を超えるフィルタを搭載してもそれによるメモリ消費は10MBに満たず、アドオン起動時間や更新時の処理時間もわずかな差です。
A3-2
uBlock Originの「要素をブロック」はフィルター作者のための補助ツールです。同機能で自動生成されたルールをたくさん作るのはおすすめしません。AdGuardの「このページの広告をブロックする」は補助ツールではありませんが同様です3-2。クラス名が変わる場合、まずはクラス名以外で使える属性がないか、開発者ツールで見てみるのがよいと思います。もしなければ、該当要素の先祖や子孫で安定した属性を持つものや、使えそうなテキストを含むものがないか探します。そうしたものがあれば（必ずと言っていいほどあります）、あとはProcedural cosmetic filtersを使うだけです。初心者であれば:has, :has-textと:upwardだけでも十分でしょう。
3-2: スライダーの選び方にもよりますが、YouTubeのような複雑なサイトで下手にフィルタを作ると、のちに問題に見舞われるケースもあります。基本的に、要素をブロックは一時しのぎ程度に使っていただくのが無難かと思います。そのためのElement-zapper（要素抹消モード）もあります。
A3-3
こちらに要点がまとまっています。大事なのは、
- 良質なトークンが抽出されるようにすること、すなわち、仕切られた7文字以内の語（できればbad tokenや１文字でない）をフィルタ中に確保する（正規表現フィルタは条件が複雑なので、ここでは割愛）
- それが難しいときは、タイプオプションやドメイン指定によりできるだけ限定する
- フィルタ中に２つ以上のワイルドカードを使うのはなるべく避ける
効率的なフィルタは正しいフィルタの上に初めて成り立ちます。残念ながら、インターネット上に公開・共有されているフィルタには（ケアレスミスの範囲を超えて）間違ったものが少なくありません。たとえば、||.example.com^や||*.example.com^のようなフィルタはuBlock Originでは基本的に間違いです（AdGuardではiOSのために使う場合があるようです）。これではドメインアンカーの意味がなく、誤爆の可能性が高まります。また、/path/to/が正規表現フィルタになってしまうことを理解していなさそうなもの、セパレータ^を「とにかくフィルタの最後につけるもの」と誤解しているようなケースも見受けられます。
A3-4
細かいTipsはありますが、一番大切なのは最小マッチングを意識することです。通常の非表示ルールでもそうですが、Procedural cosmetic filtersにおいてはとくに重要で、最初のprocedural operatorが評価するノード数を最小化し（ブラウザのCSS処理とは逆に、左から右に読む）、かつそのノードが存在するのはProcedural cosmetic filtersが必要なときのみとなるようにするのが理想です。これを怠るとたった一つのフィルタでも高CPU消費を起こすことがあります。
A3-5
サイト次第であり、どちらがよいということはありません。画面表示上の効果だけみると同じになることもありますが、パフォーマンスを考慮すればどちらを使うべきか自然に決まります（A3-3参照）。なお、EasyListはAdblock Plus文法しか使えないこともあり非効率な:has()ルールを多く含みますが、著名なリストだから効率的に書かれているとは限らないという例かもしれません。また、AdGuardでは:upward()は（一部の例外を除き）ルールの末尾でしか使えないことに注意してください。
A3-6
フィルタ構成についてはこれが正解といえるものはなく、各自で調べて自身の好みに合うものを選択するしかありません。ただ、間違いといえるものはあります。フィルタを解釈して評価できる人はまれなため、インターネット上には主観的な使用感や信念にもとづいた「おすすめ」がたくさん転がっています。たとえば、Adblock Warning Removal Listは、最近になってようやく意味のないリストという認識が広まってきたようですが、数年前まであちこちでアンチ広告ブロック対策に推奨されていました。ここまでひどくはないものの、あまり正しく理解されていなさそうなリストとしてFanboy's Enhanced Tracking Listが挙げられます。このリストの最大部分は許可ルールによるブロッカー検知回避なのですが、ちょっと大雑把すぎて検知と関係ない広告スクリプトまで許可してしまっています。不要なスクリプトを走らせてまで一部の検知を回避することを、同リストの利用者が求めているかは疑問です3-3。あまり意味のないリストについていえば、NoCoinが挙げられるでしょう。コインマイニング自体、絶滅してはいないものの下火ですが3-4、NoCoinでブロックされるものはすべてEasyPrivacy + uBlock₀ filters - Resource abuseでカバーされています。
初心者の方はともかく購読しすぎに注意することです。日本用フィルタ、特定用途用フィルタの多重購読はおすすめしません。おそらく、たくさん購読するとそれだけ多くブロックしてくれるという考えからなのでしょうが、これは正しくありません3-5。また、フィルタによる不具合は天災のようなもので、普段はあまり遭遇しませんが忘れたころにやってきます。多く購読すればするほど、メリットは薄くなっていき、不具合の確率ばかり高まります。そもそもフィルタの購読は「なんとなく役に立ちそう」というあいまいな感覚ではなく、実際のニーズに基づいて行うべきです。
もう少し具体的に、PCの場合なら（あくまで参考程度にお願いします）
- 内製：最低でもuBlock₀ filtersは維持することをおすすめします。ほかのフィルタに比べると不具合の率が少なく、日本語サイト利用者でもメリットは大きいです。Badware risksやUnbreakは意味がわかっている人は外してもよいですが、明確な理由がなければ維持するのが無難でしょう。新規追加されたQuick fixesは一部のサイトのいたちごっこへの対策と、深刻な不具合の迅速な修正を兼ねるものです。
- 広告：海外サイトをよく見る人はEasyListを維持。日本のサイトしか見ない人で、もちフィルタ、豆腐フィルタ、雪フィルタを選択する場合は好みで外してもよい。非表示/整形の意味がわかっており、必要ない中級者以上の方ならEasyList without element hiding rulesも選択肢となります。これはEasyListから整形フィルタを除いたもので、初期にはuBlock組込みリストの一つでした。
- プライバシー：トラッキングを気にしない人、または雪フィルタ使用者は外してもよい3-6。気にする人で、雪以外の日本語フィルタ使用または海外サイトをよく使うなら、平均的なブロック性能が高いが不具合も多いEasyPrivacyを維持するか、不具合は少ないが漏れも多い（※日本のトラッカーに限っていえばそうでもない）AdGuard Tracking Protectionに切り替え。Block Outsider Intrusion into LANはLANへのフィンガープリンティングやCSFRなどの攻撃を防ぐもので、不具合はまれです。一般にコンシューマー向けのルーター等LAN機器のセキュリティは低いと言われており、個人的には有効にしておいてよいと思います（ファームウェア更新など基本的なセキュリティ対策の補完として）
- マルウェアドメイン：お好みで。デフォルトのOnline Malicious URL Blocklistはブラウザのセキュリティ機能（Google Safe Browsing）とデータ共有しており、大部分はブラウザでブロックされます
- 迷惑系：ソーシャルボタンを消したい人はAdGuard Social Mediaを追加してもよいでしょう。ただし、もちおさんが提供されていることりフィルタやこちらで提供しているあられフィルタも検討してみてください。あられはAdGuard Social Mediaの併用も可能です。ほかの迷惑要素についても同じく、AdGuard Annoyances, ねぎフィルタ, みぞれフィルタからの選択をおすすめします。uBlock₀ filters - Annoyancesはやや特殊で、主にソフトアンチ広告ブロックと右クリック/コピー禁止系への対策になりますが、Fanboy AnnoyanceおよびAdGuard Annoyancesの一部ルールがuBlock Origin上で無効化されてしまう場合の補完も兼ねています。EasyList Cookieを含むFanboy系は不具合の率が高く、初心者にはおすすめしません。クッキーの同意ダイアログのみ消したい方はYuki's Cookie Dialogue filtersもご検討ください。
- 多目的：デフォルトのPeter Lowe'sはフィルタ数のわりに良い仕事を（主に海外サイトで）してくれているのですが、たまに誤爆することがあります。日本のサイトを中心に見るなら好みで外してもよいです。余談ですが、EasyListはよく訴訟の対象になり、その場合、対象ドメインをEasyPrivacy（トラッキングも兼ねている場合）やPeter Lowe's（純粋な広告サーバー）に肩代わりしてもらうことがあります。
- 地域・言語：英語、日本語以外のサイトをよく見る人はその言語のフィルタを追加。日本語については別途日本用フィルタを購読するのであればAdGuard Japaneseを外す
- カスタム：お好みでもちフィルタ、豆腐フィルタ、雪フィルタの中から一つを追加
フィルタ構成とは別に、中級者以上の方であれば「汎用非表示フィルターを無視する」はおすすめできるオプションです。パフォーマンスの向上に加え、誤爆やアンチ広告ブロックへの遭遇率を下げることもできます。その代わり広告枠やテキスト広告が隠し切れないケースも出てきます。
3-3: 汎用非表示が有効なら、結局検知されてしまうことが多いです。そもそも同リストで許可されている検知スクリプトは、多くがEasyListなどの主要フィルタ（雪も）で既にブロックから除外されています。
3-4: coinhiveをはじめ主要なマイナーのほとんどがサービス終了しており、フィルタ作者ですら実際に機能しているマイニングに会うことは極めてまれです。
3-5: 理由は大きく二つあります。まず、許可ルールは原則的にブロックルールに対して優先されます。ある程度の規模のフィルタリストであれば必ずといっていいほど不要になった許可ルールが含まれますし、リストによっては絞り込みが甘い許可ルールもあるかもしれません。こうした許可ルールによって広告が貫通するケースが報告されています（最近の例）。もう一つは広告再挿入です。これはアンチ広告ブロックと原理は同じで、ブロッカーを検知し、アンチ広告ブロックの派手な警告の代わりにブロッカーを迂回する広告を再挿入するものです。あるリストがせっかく再挿入を惹起しないようにしていても、他のリストが惹起してしまうと意味がありません。
3-6: uBlock Originの開発者はこのような使い方（very easy mode）は実際は想定していないと述べており、まれにあるトラッカーをブロックしないことによる不具合については公式のサポートは受けられません。
A3-7
実際の問題に遭遇してフィルタを購読する際は、まずは各ブロッカー組込みのフィルタの中から探すとよいと思います。どうしてもその中に適切なものがなければ、
- 一定の評価を確立したフィルタで、広告ブロック界で長年の実績がある人やグループがメンテナンスしている
- よく更新されている（広告ブロック用なら目安として週に一度、少なくとも月に一度。ソーシャルや迷惑系ならもっと低くてもよい）
- それを購読することで実際に問題が解決する
の３点を確認してください。「○○用」と銘打ったフィルタを勧める人がたまにいますが、ほとんどの場合意味がないどころか下手をすると不具合の原因にさえなります。たとえばアンチ広告ブロックについては、それ用をうたうフィルタを追加する前に標準のフィルタ構成で再現するか確かめるとよいでしょう。Youtubeの広告などは複雑なA/Bテストもあり、多数の情報が集まる標準のフィルタリストに勝るものはありません（当サイトのフィルタは情報を共有）。標準のフィルタ構成は大多数の人に最適となるよう調整されており、中途半端な知識でいじるとおかしなことになることも多いです。以下では、uBlock Originの組込みフィルタの一つであるAdGuard Baseを有効にする場合、どういったメリットとデメリットがあるか概説します。十分な評価が確立され、かつuBlock Originでの使用を考慮して調整されているAdGuard Baseでさえも、むやみやたらと有効化すべきではないことがわかるかもしれません。
AdGuard Baseのメリット
- 一部uBlock₀ filters未対応の広告、ポップアップ、アンチ広告ブロックに対応している
uBlock₀ filtersメンテナーはAdGuardのIssueもある程度見ていますが、漏れはどうしてもあります。また、Baseにはアンチ広告ブロック対策という点では有効だがuBlock₀ filtersの基準では採用できない汎用例外ルールがいくつかあり、これらによってBase有効時のみ惹起されないアンチ広告ブロックは何度か見たことがあります。ほかにChromium限定のメリットとして、BaseはCNAMEを利用して迂回を狙う広告サーバーをブロックしています。このうち、PopCashについては正規表現でカバーできるため最近のコミットでuBlock₀ filtersでも対応いたしましたが、AdSpyglassは正規表現でも一部しかカバーできません若干のリスクもあるため、内部ディスカッションに諮りましたが今のところ対応は見合わせています（2022年5月30日修正：現在は一部対応）。おまけとして、AdGuardもuBlock Originも各言語用リストで対応されない問題を自分のところで扱う方針は同じなのですが、Baseのほうが各言語用ルールが充実しています。そのため、「ある言語のサイトを頻繁に訪れるわけではないのでその言語用のリストは有効にしていないが、たまたまその言語のサイトを見ることになった」ような場合に、余計な広告を見ないで済む場合もあるかもしれません。
- 広告による空白や枠残り、残骸などの整形を丁寧にやっていることが多い
uBlock₀ filtersのメンテナーはこれらにあまり興味がない人が多く、またgorhillが示した内部的な方針（あくまで目安で、実際は各メンテナーの判断に委ねられている）でもページ下部の小さな空白などは無視してよいとされています。一方、AdGuardはこれらを比較的丁寧に処理しています。サイト指定の整形フィルタが多いため、英語サイトをよく見る人で汎用非表示を無効化している場合もレイアウトへの影響を緩和できるでしょう。
AdGuard Baseのデメリット
- フィルターの干渉により不具合が起きたり、アンチ広告ブロックを起動してしまったりすることがある
多いのはスクリプトレットやリダイレクトリソース同士の干渉です。これらは頻繁に起こるわけではありませんが、珍しいというほどでもありません。A6で述べた例などは運よく管理人が気づき、なおかつ影響が大きく確実に発生するため対応いたしましたが、気づかれていないケースもあるでしょう。このような干渉はBaseだけでなくスクリプトレットやリダイレクトリソースを使うすべてのフィルターリストに起こりうるため、それらの構文を含むリストを購読するときは注意が必要です。実際、組込みの地域・言語用リストのうちフランス語や中国語はAdGuardのリストに置き換えられたのにドイツ語はEasyList Germanyのままですが、その理由はuBlock₀ filtersがすでにドイツ語サイトのルールを多く含み、干渉が懸念されるからです。
- 前提条件の違いにより不具合が起きることがある
たとえばCNAME uncloakingが考慮されていないため、Firefox上で大きな破損が広範に起きたこともあります。ほかにもCNAME由来の破損をいくつか把握していますが、対応を後回しにしてしまっています。
- 一部の古いルールが乱暴
たとえば##.top-bannersというルールは、深刻ではないにせよいくつもの誤爆を引き起こしており（例）、機会があれば削除を提案しようと思っています。__htas用とコメントされているルールも、ドメイン指定されていながらいくつかの動画を破損しており、一件は例外で対応しましたが、PRを開くか多数の報告が来るまでは根本的に対処されなさそうです （2022年5月30日修正：現在は修正済み）。
- uBlock Originにとって最適でないルールが多い
uBlock Originで効率の劣るルールが比較的多いのは否めません。一般のユーザーがパフォーマンスの影響に気づくことはめったにないと思いますが、Baseで追加的にブロックされる通信はまれであること、フィルタの無駄な重複が大量に出ることも併せますと、パフォーマンスを優先するならBaseは購読しないほうがよい、といっても間違いではないと思います。
- 廃れたルールが多い
不要になったルールが大量にあります。uBlock₀ filtersは日常的にクリーンアップをおこなっているためここまで深刻ではありません。当管理人も暇を見つけてはBaseのクリーンアップをおこなっていますが、焼け石に水と言わざるを得ません。AdGuardのCTOも認識していますが、将来的に自動処理したいらしく、当面はどうにもなりません。メモリの浪費だけならよいとしても、廃れたルールが問題を起こすこともあるのでなんとかしたいと感じています。
A3-8
AdGuardでは組込みのフィルタを使っていただくのが無難と思います。AdGuardはuBlock Origin文法の大部分をサポートしていることになっていますが、実際は仕様の違いにより効かなかったり、動作が異なったりすることもあり、そうした細かい仕様は公式ドキュメントに必ずしも載っていません（みぞれフィルタではなるべくAdGuardとも互換性を保つよう配慮していますが、それでも仕様の違いによりAdGuardでの動作をあきらめたケースがいくつかあります）。当然ですが、AdGuardのフィルタはAdGuard上で完璧に動作します3-7。AdGuard日本語フィルタはかつて不評でしたが、今では昔と別物といってよいほど精度が高くなっています。
Braveも基本的には組込みのフィルタでよいと思いますが（A3も参照）、モバイルでご利用の場合はchrome://adblockからAdGuard Mobile Ads filterの追加を強くおすすめいたします（モバイルではデフォルトで有効にすべきと思いますが、リジェクトされています）。ちなみにchrome://adblockにはフィルターを設定し過ぎるとパフォーマンスが悪化しますと書かれていますが、現在のBraveはuBlock Originのアルゴリズムを採用しているためフィルターの数がパフォーマンスに影響することはありません（参考：Brave自身の記事）
Vivaldiでは、著作権の問題からもちフィルタ、たまごフィルタが日本用に採用されましたが、これらもuBlock Originを前提としています（VivaldiがuBlock文法をサポートするつもりなら歓迎すべきことですが）。Vivaldiでデフォルト有効のEasyList等と併用した場合、かなりの無駄も発生します。少なくともEasyList系を維持するのであれば、PCではiOS用AdGuard日本語フィルタに置き換えるのがよいかと思います。ただし、A1-3で述べたように、現在Vivaldiのブロック機能は簡易的なものでPC用の本格的なブロッカーとは呼べません。一方で、Vivaldi上でuBlock Originを使うと固有のバグが多く、uBlock Origin開発者が公式にはサポートしないと宣言する事態になっています。
3-7: 逆に言うと、uBlock Originでは動作しなかったり、動作が異なったりするフィルタもあるほか、パフォーマンス面で最適とはいえないフィルタもあります。雪系フィルタではそれらの採用を見送ったり、置き換えたりして対処していますが、AdGuardのフィルタリストでも問題となるフィルタの割合はそう大きくはありません。とくにAdGuard Japaneseは当管理人が一部メンテナンスしていることもあり、そうしたフィルタの割合は小さいです。
A3-9
事実です。私もこれまでいろいろな形で、数十件は報告しています。また、EasyPrivacyは純粋な追跡・解析以外にプッシュ通知やセキュリティシールなども一部ブロックしており、人によっては困ることもあるかもしれません。なお、ルールが多いから不具合が多いわけではありません。大部分のルールは不具合と無関係な一方、誤爆しやすいルールというのがあります。雪フィルタではこの点を逆手にとり、誤爆しやすいルールをなるべく外すことにしました3-8。またアンチ広告ブロックを惹起しやすいという議論も聞きます。これは間違ってはいませんが、「それほど違わない」という印象です。EasyListで"Remove unused filter"というコメントで削除されているルールの多くは、私を含むフィルタ作者からのフィードバックに基づくアンチ広告ブロックのトリガーです。逆に日本用フィルタでのみトリガーされるものもあり、とくに海外サイトではその傾向が強いです。ところで、不具合が多い理由の一つは日本のユーザーからの報告がほとんどないことです。EasyListでなくとも、日本では280blockerさんを唯一の例外として、フィルタ作者への報告自体がまばらな印象です。すべてのユーザーが不具合を自己修正できるとは思えないため、ブロックをそのサイトで無効にしたり、動的フィルタリングの緑で上書きしたりといった対処をされている方が多いのではないかと思います。フィルタ作者はそういった「荒療治」より効果的な対処ができますし、あなたの報告がほかの多くのユーザーを助けるかもしれません。ぜひ積極的な報告をお願いします。uBlock Origin標準リストの不具合については、こちらでも受けつけています。
2021年4月12日追記：EasyListは海外用と認識されている場合があるようですが、実際は全世界の広告ブロックのための標準フィルタです。日本用のルールも多く含み、たとえば##.res_adなどはモバイル版5ちゃんねるくらいでしか使われていません。ABPのページに"Specialization: English"と書かれているのもそうした認識が広まった一因かもしれませんが、おそらく、これまでの日本用フィルタがEasyListの併用を前提としていなかったこともあると思います。
3-8: imasdkなど、メリットとの兼ね合いから誤爆が多くても採用したルールもあります。ちなみにルール数というのは、せいぜい大雑把なメモリ消費量の目安にしかなりません。処理時間に影響しないのは随所で書きましたが、ルール数が多いほうがブロック性能が高いとも限りません。DandelionSprout氏のExtremely Condensed Adblocking Listが極端な例ですが、誤爆を気にせずルールを一般化すればルール数を減らしつつ高いブロック性能を実現できます。雪フィルタはこの逆で、なるべく一般化を避けているためルール数は多くなります。メモリ消費についても、フィルタの書き方に左右されるのであくまで大雑把な目安です。
A3-10
透明なオーバーレイを使用するケースはありますが、多くの場合、HTMLにクリックイベントが仕込まれているだけで「見えない広告」という表現はあまり適切ではありません。原因はケースバイケースで、シンプルなブロックルールで済む場合もあれば、スクリプトレットが必要な場合もあります。これらを用いるサイトの多くはアダルト、違法コンテンツ、または短縮プレミアムリンク系のサイトで、頻繁に仕様やドメインを変えてくるため個人フィルタでの十全な対応は困難です。これらのサイトを用いる方はEasyListとuBlock₀ filtersの両方を有効にしてください。雪フィルタの場合はそれらと同期をとっており、また、日本語サイトの場合はまっさきに対応しています。たいていは同時にAdGuard Japaneseでも対応しています。
A3-11
2021年8月16日追記：Gizmodoで扱われたように、すでにFingerprintJSにオプションとして組み込まれていたようです。ただ[こちら(https://fingerprintjs.com/blog/ad-blocker-fingerprinting/)をみる限り、実際にFingerprintJSユーザーが有効利用するには壁がありますし、uBlock Originをご利用であれば「汎用非表示フィルターを無視する」のチェックにより防御可能です。そもそもEasyPrivacyではFingerprintJSを汎用フィルタであらかたブロックしており、スクリプトがリネームされている場合も見つけ次第対応しています。
心配するのはまったくの杞憂です。たとえばこれらのテストページで体験できますが、この程度では誤判定が多くとても実用にならないでしょう。それでいて、日常的にリクエストログをみているフィルタ作者にはリストのフィンガープリンティングを試みているのが手に取るようにわかります。精度を高めようとすればなおさら隠すのは難しくなりますし、各リストの変更に追随する手間もかかります。実際にリストのフィンガープリントが疑われる例の報告はありませんし、みたこともありません。そもそも、広告ブロックユーザーのみが対象で、かつ大多数のユーザーが標準リストを使っている28時点でフィンガープリントとしては使い物にならず、やるとしたら趣味にしかなりません。ブラウザベンダーがフィンガープリント制限への動きを強めているとはいえ、既存のフィンガープリントライブラリはこんなものとは比較にならないほど高精度の判別が可能なので、それを適当にリネームして使うほうがはるかに賢明です（実際そういう例はあります。ただし多くはリネームすらしておらず、EasyPrivacyや雪フィルタの汎用ルールでブロックできます）。
3-9: 言語・地理による違いなどは、こんな手段を使わなくても判別できます。
A3-12
ご自身でフィルタを書ける人は別として、最良の対処はフィルタ作者に報告することです。uBlock Origin標準設定で出る場合はこちらでも受けつけます。以下では、日本のサイトで比較的よくみるアンチ広告ブロックへの簡易的な対処をまとめました。内容的には、以前に「りぃのなんでも知恵袋」さんの記事にコメントさせていただいたものの更新になります。hoge.comでアンチ広告ブロックが出たという仮定です。参考画像は一例で、バリエーションがあります。100%の効果は保証できません。なお、雪フィルタ単独使用（Firefoxのトラッキング防止やDNSでのブロックも使っていない）の場合、これらはほぼみることがないはずです。
-
antiblock.orgの場合
以下のようなUIです。
uBlock Originではhoge.com##+js(acis, document.addEventListener, google_ad_client)、AdGuard（iOSおよびAdGuardコンテンツブロッカーを除く）ではhoge.com#%#//scriptlet('abort-current-inline-script', 'document.addEventListener', '/google_ad_client/')をマイフィルター/ユーザールールに追加してみてください。たまに競合条件により安定して機能しない場合もあります。uBlock Originでは、Firefox上ならhoge.com##^script:has-text(google_ad_client)に切り替えてください。AdGuardではhoge.com$$script[wildcard="*load*google_ad_client*"][min-length="2000"][max-length="7000"]に切り替えてみてください（一部のプラットフォームでは機能しません）。それでダメな場合、uBlock Originではhoge.com##+js(acis, document.addEventListener, nextFunction)に、AdGuardではhoge.com#%#//scriptlet("prevent-setTimeout", "/\.displayMessage[\s\S]*?\.nextFunction\(\)/")に切り替えてみてください。iOS版AdGuardでは、コンテンツブロッカーに以下を追加してみてください（これだけではダメな場合もあります）。
@@#*/ad/$image,domain=hoge.com
@@||hoge.com^$generichide
- BlockAdBlockの場合
以下のようなUIです。
uBlock Originではめったにみることはないはずですが、遭遇した場合はhoge.com##+js(nosiif, visibility, 1000)を追加してください。AdGuardではhoge.com#%#//scriptlet("prevent-bab")を追加してください。iOS版AdGuardでは、コンテンツブロッカーに@@||hoge.com^$generichideを追加してみてください。
- Google Funding Choice Anti-adblockの場合
以下のようなUIです。
×ボタンで消せるタイプのものもあります。uBlock Originでは、uBlock₀ filtersが有効ならめったにみることはありません。AdGuardではhoge.com#$#body { overflow: visible !important; }とhoge.com#$#body div.fc-ab-root { display: none !important; }を一行ずつ追加してください。iOS版AdGuardでは、コンテンツブロッカーに@@||hoge.com^$generichideを追加してください。
- mdpDeBlockerの場合
以下のようなUIです。
uBlock Originの場合はhoge.com##+js(aeld, DOMContentLoaded, adsBlocked)を追加してみてください。ダメな場合はhoge.com##+js(nostif, show)かhoge.com##+js(acs, eval, replace)に切り替えてみてください。AdGuardではhoge.com#%#//scriptlet("prevent-addEventListener", "DOMContentLoaded", "adsBlocked")を追加してみてください。ダメな場合はhoge.com#%#//scriptlet("prevent-setTimeout", "showModal()")かhoge.com#%#//scriptlet('prevent-eval-if', 'adsBlocked')に切り替えてみてください。
iOS版AdGuardでは、コンテンツブロッカーに
@@||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$domain=hoge.com
@@||googleads.g.doubleclick.net/pagead/id$domain=hoge.com
を追加したうえで、DNSフィルタリングを一時無効にするか、pagead2.googlesyndication.comとgoogleads.g.doubleclick.netを（できれば一時的に）ホワイトリストに追加してください。AdGuard DNSなど広告ブロック機能のついたDNSサーバーを使っている場合は、一時ほかのDNSにする必要もあります。
- AdBlock Notifyの場合
以下のようなUIです。
uBlock Origin, AdGuardとも基本的なフィルタ構成（+ 雪フィルタ）ではみないはずですが、カスタムリストを追加した場合みる可能性があります。uBlock Originではhoge.com##+js(aopr, anOptions)、AdGuardではhoge.com#%#//scriptlet("abort-on-property-read", "anOptions")を追加してください。iOS版AdGuardでは、コンテンツブロッカーに以下を追加してください。
/wp-content/uploads/*/*.js$domain=hoge.com
hoge.com#@##adsense
hoge.com#@#.an-advert-banner
hoge.com#@#.an-sponsored
- Admiral Anti-adblockの場合
以下のようなUIです。
これはいわゆるsoft anti-adblockで、対策せずともContinue without disablingをクリックすることでコンテンツを閲覧することができます。そのためuBlock Origin、AdGuardともメインのフィルタでは対策せず、迷惑系フィルタ（uBlock₀ filters - Annoyances, AdGuard Annoyances）で対応していますが、共同通信の場合は挙動の違いによりデフォルトで対応しています。また、EasyPrivacy, Peter Lowe’s Ad and tracking server list, AdGuard追跡防止フィルタのいずれかを使用することでも大部分回避できます。個別に対策したい場合、uBlock Originではhoge.com##+js(acis, document.createElement, admiral)を追加し、効果がない場合hoge.com##+js(aopr, admrlWpJsonP)に切り替えてみてください。AdGuardではhoge.com#%#//scriptlet("abort-current-inline-script", "document.createElement", "admiral")を追加し、効果がない場合hoge.com#%#//scriptlet("set-constant", "admiral", "noopFunc")に切り替えてみてください。
- AdUnblockerの場合
以下のようなUIです。
uBlock Originでは基本的にみないはずですが、Firefoxのトラッキング防止機能を利用している場合（標準ではプライベートブラウジング利用時）に遭遇することがあります。その場合はhoge.com##+js(nostif, css_class.show)を追加してください。AdGuardでは以下を追加してみてください。
hoge.com#%#//scriptlet("set-constant", "adsbygoogle.length", "undefined")
||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$script,xmlhttprequest,redirect=googlesyndication-adsbygoogle,domain=hoge.com
iOS版AdGuardでは@@||pagead2.googlesyndication.com/pagead/js/adsbygoogle.js$domain=hoge.comを追加してみてください。
- ai_front Anti-adblockの場合
以下のようなUIです。
uBlock Originでは基本的にみることはありませんが、外部フィルタを追加している場合などみる場合もあります。その場合、hoge.com##+js(aopr, ai_run_scripts)を追加してください。AdGuardではhoge.com#%#//scriptlet("abort-on-property-read", "ai_run_scripts")を追加してください。iOS版AdGuardでは、コンテンツブロッカーに以下を追加したうえで、DNSフィルタリングを一時無効にしてください。
@@||hoge.com^generichide
@@/wp-content/plugins/ad-inserter/*$domain=hoge.com
@@||contextual.media.net/dmedianet.js$domain=hoge.com
@@||ib.adnxs.com^$image,domain=hoge.com
@@||router.infolinks.com/dyn/apn-usync?$image,domain=hoge.com
- CHP Ads Block Detectorの場合
以下のようなUIです。
AdGuard, uBlock Originとも古いバージョンのものは基本的にみないはずです。新しいバージョンに対しては、uBlock Originではhoge.com##+js(nostif, overflow)、AdGuardではhoge.com#%#//scriptlet("abort-on-property-read", "reqServers") を追加してみてください。
- 上記以外
アンチ広告ブロックプラグインにはほかにも多くのファミリーがあり、ここで網羅することはできません。また、独自実装のものも増えています。以下ではそうした場合にもしかしたら機能するかもしれない簡易的な対処をまとめます。
uBlock Origin：まず、（Firefoxの場合はトラッキング防止を無効にして）以下を追加
*$image,redirect-rule=1x1.gif,domain=hoge.com
*$script,redirect-rule=noop.js,domain=hoge.com
||googlesyndication.com/pagead/js/adsbygoogle.js$script,redirect-rule=googlesyndication_adsbygoogle.js:10,domain=hoge.com
@@||hoge.com^$ghide
ダメなら||hoge.com^$inline-scriptに切り替え、ただしサイトの機能を壊す可能性が高い。
AdGuard：まず、DNSフィルタリング（とFirefoxの場合はトラッキング防止）を無効化して以下を追加
$image,redirect-rule=1x1-transparent.gif,domain=hoge.com
$script,redirect-rule=noopjs,domain=hoge.com
||googlesyndication.com/pagead/js/adsbygoogle.js$script,xmlhttprequest,redirect-rule=googlesyndication-adsbygoogle,domain=hoge.com
@@||hoge.com^$generichide
ダメなら||hoge.com^$csp=script-src 'self' 'unsafe-eval' http: https:に切り替え（DNSフィルタリングやトラッキング防止を無効化した人は戻してよい）、ただしサイトの機能を壊す可能性が高い。
A3-13
みぞれフィルタを購読するか、またはみぞれのTwitter用フィルターだけコピーしてマイフィルター/ユーザールールに貼りつけてください。これらはパフォーマンス面で最適化されており、既知の不具合に対応済みでTwitterの変更にも追随しています。「要素をブロック」（の自動生成ルール）/「このページの広告をブロックする」で消しても長持ちしませんし、そもそもTwitterのような複雑なページで使うものではありません。なお、iOS14以下で消すのは難しいでしょう。
A3-14
AdGuard Cookie Notices filterとEasyList Cookie
どちらもクッキーの同意ダイアログを対象とする点で目的は同じですが、特徴が違います。まず、全般的な網羅性はEasyList Cookieのほうが高い、つまり平均的にはより強力で漏れが少ないです。そのぶん不具合も多い傾向にありますが、それに負けないほど頻繁に不具合修正も行われています（少なくとも欧米のサイトにおいては）。一方、どのようなフィルタリストもそうですが地域による弱み強みもあり、日本のサイトに限ればAdGuard Cookie Notices filterも負けてはいません。もう一つ重要な違いはAdGuard Cookie Notices filterがset-cookieやクリッカースクリプトなどの強力な機能を使える点ですが、これはAdGuardで使う場合のみ恩恵があります。日本のサイトでこれらが必須となるケースはまだ少ないですが、ないわけではありません。ほかに、AdGuard Cookie Notices filterはEasyList Cookieに比べると汎用整形フィルタへの依存度が低いため、AndroidのuBlock Originで使う場合はEasyList Cookieより強力かもしれません。両方を併用することも可能ですが、不具合の確率が上がるうえに相当な無駄が出るため個人的にはおすすめしません。なお、当サイトで提供しているYuki's Cookie Dialogue filtersは汎用整形フィルタ無効を初めから考慮しているためAndroidのuBlock Originで比較的よく機能すると思います。また、 AdGuard Cookie Notices filter、EasyList Cookieいずれとの併用もできるだけ考慮しています（前者優先）。
AdGuard URL Tracking ProtectionとActually Legitimate URL Shortener Tool
どちらもクエリパラメータを除去しますが、方針と地域的な強みに違いがあります。AdGuard URL Tracking Protectionはその名の通りトラッキングパラメータのみを除去する方針です。トラッキングが疑われても、よくわからないパラメータは除去しません。不具合はそれほど多くない印象です。Actually Legitimate URL Shortener Toolはトラッキングかどうかにかかわらず、できるだけあらゆるパラメータを除去する方針です。そのぶん不具合もやや多いですが、報告されれば24時間以内に対応しており、平均的にはAdGuardより対応が早いです。また、メンテナーや報告者の傾向から、欧米のサイトに強いです。それに対してAdGuard URL Tracking Protectionは比較的アジアに強いといえます。
A4-1
New York Timesなどの大手英語メディアや日本人利用者が多い海外マンガ、アニメ、あるいはポルノサイトに加え、以下のようなサイトを対象にしています：
- 他の日本用フィルタで個別対応されているもの
- 日本語のブログや記事などで紹介されている海外サイトで、ある程度トラフィックが高そうなもの
- 特定のテーマに興味を持つ日本人が検索しそうな単語でGoogle検索したとき、検索上位に出てくるサイト
- 上記に該当するサイトの姉妹/系列サイトや、直接リンクされているサイトの一部
例外は短縮プレミアムリンク系です。日本でメジャーなものはsh.*, shorten.*, ouo.*などだと思いますが、目的地につくまでに様々な短縮リンクをたらい回しにされることがありますし、最近は日本でもプレミアムリンクが普及していることからインターフェースが英語のものを中心にある程度網羅的に対応しています。
英語以外ではロシアと中国/広東語のサイトがやや多いですが、これらの言語をよく利用する方には到底足りません。EasyListや各言語用フィルタを使用してください。
A4-2
はい、かなりの程度ブロックされます。一部メディアが騒ぎ立てたため、CNAMEトラッカーをなにか特別なもののように思っている人がいるようですが、実際はEasyPrivacyなどは以前からとくに区別せずブロックしていました。日本では豆腐さんもgenieesspvのCNAMEトラッカーを以前よりブロックされています。Eulerianが少し厄介だったのはCNAMEの利用そのものではなく、CNAMEとランダムにみえるサブドメインの組合せでした4-1。多くのCNAMEトラッカーは、たとえばsmetricsといった、決まったサブドメインを使います。そしてなにも||smetrics.のようなルールを使わずとも、一般ルールで大部分ブロックできます。なお、ファーストパーティートラッカーという呼称が使われることもありますが、CNAMEトラッカーには純粋なサードパーティーのものも少なくないですし、一部メディアが書いたような「ファーストパーティーだとブロックしにくい」などということもありません4-2。
4-1: ランダムドメインの利用もなんら新しいものではなく、PopAdsなどで以前より使われています。Eulerian同様、正規表現でブロックできます。
4-2: CNAMEトラッカーが騒ぎになったときからAレコードやAAAAレコードの利用が予測されていましたが、実際に2020年よりGoogleがサーバーサイドタギングとして提供しています。uBlock Originもこれに対応するためstrict3pオプションを追加しました。このように、ブロッカーの迂回やその他"user hostile"な機能に真っ先に対応し続けているのもuBlock Originが信用されている理由の一つでしょう。
A4-3
アクセス解析は気にする人とそうでない人がわかれるため、そうしたいところですがメンテナンスコストの点で難しいです。リストをわけると、非表示フィルタをメイン単独の場合とサブリストも購読する場合とでわけて考える必要がでてきます。既にみぞれでそういうケースは多数発生していますが、みぞれの場合はまだ限定的です。アクセス解析の場合だとアクセスカウンターやレコメンデーションエンジンを使用する多くのサイトでそうする必要がでてきます。また、広告と解析は常にきっぱりわけられるわけでもなく、現在の分類は正直に申し上げますと大雑把です。リストをわけるとなれば、判断に迷うケースや現実的に言って誤分類も出てきます。そして広告スクリプトを解析に誤分類してしまうと、広告漏れにつながります。実際にEasyListなどでそうしたケースがときどき起こっていますし、プライバシーに分類されているタグマネージャー系のスクリプトから来る広告もあるため、アクセス解析を気にしないとしても、ブロックしたほうが広告やアンチ広告ブロック（とくにAdmiral）のブロック率、およびパフォーマンスが高まるのは事実です。アクセス解析をブロックしたくない方は、プライバシー系のリストを外したうえでAdGuard Japaneseを購読することをお勧めします。
A4-4
最初からAdGuardFiltersの書き込み権限があればそうしたかもしれません。とはいえ、方針も異なりますし、自己管理のフィルタだからできることもあります。たとえばuBlock Originに完全特化して専用機能・最新機能をふんだんに使うこと、非表示に頼らずブロックに特化すること、AdGuardのトラフィック基準にとらわれないことなどがあげられますが、新しいフィルターのアイディアをすぐに実現できるのが最大の違いかもしれません。AdGuard公式フィルタにルールを追加する場合はどうしても慎重になりますし、チームの方針にしたがう必要もあります4-3。とはいえ、フィルタの概念に気づいている広告ブロックユーザー自体が少なく、また、AdGuard JapaneseがuBlock OriginやBraveの標準リストでもあることから、これを改善していくのが最良と認識しています。ちなみに、雪を提供している理由の一つに、日本語ユーザーにおいて標準のフィルタリストを外し日本用フィルタ一本に絞るというのが割と行われているようだというのがあります。EasyList, EasyPrivacyの不具合の多さから理解はできますが、長期的には好ましくないと思っています4-4。不具合が多い最大の理由は、日本語ユーザーがあまり報告を行わない点にあると思われるため、雪を媒介に不具合報告を標準リストに反映させるという意味もあります。
4-3: こういった点では正規メンバーであるuAssetsのほうが自由度が高いですが、それでも好きにできるわけではありません。ルール追加後に慎重意見によりとりさげたこともあります。公共リストのメンテナンスは個人リストとはまったく事情が異なります。
4-4: 10年前は日本のウェブ広告はネット上の孤島状態でしたが、今では日本のサイトでも海外の広告・解析サービスを利用することが珍しくなくなっています。それどころか、アダルト等でない日本語のブログで、毎回異なるランダムな広告ドメインを読み込むものまであります。また、翻訳の発達により日本人でも海外サイトを利用する方が増えている一方、広告のパーソナライズ化やA/Bテストの浸透が進み、YouTube広告などは個人メンテナーによる対応は不可能に近くなってきています。
A4-5
言うは易く行うは難しです。単純な文法互換性の問題ではありません。フィルターリストというのは様々な前提のもとに個々のルールから全体までがが組み立てられています。たとえば、アプリ版AdGuardはブロックされたリソースのタグをソースから除去するため、雪フィルタで大量に用いている[src*="//hoge."]:upward()のようなルールはほとんど書き直しが必要になるでしょう（タグの除去は:nth-childや+を用いたルールにも影響を与える場合があり、誤爆もあり得ます）。末尾以外の:upward()はいうまでもありません。CSSでimportantを指定しているケースへの個別対応も必要です。また、本家Baseと併用すると干渉によりai_frontなどのアンチ広告ブロックや一部のポップアップが起動するようになります（uBlock Origin組込みのBaseについてはある程度対策済み、A1-6, A3-7参照）。干渉がなくても、前提が異なるため様々なアンチ広告ブロックが起動されます4-5。たとえばGoogle Funcing choice（GFC）アンチ広告ブロックであれば
-
fundingchoicesmessages.google.comとgoogletagmanager.comがブロックされている - GFCを起動するcosmetic baitsに引っかからないか、汎用的に対策されている
という前提があり、1については雪フィルタのルールによって解決しますが2はルールの追加が必要です。干渉以外にもabort-on-stack-traceのinlineScript指定など、現時点でAdGuardでは機能しないルールもあるためスクリプトレットルールはできるだけBaseと統一したほうがよいですが、そうすると今度は変更追随の手間が生じます。Baseの使用を前提条件として自前の対応をあきらめるほうがいいかもしれません。Baseの使用を前提とするなら、今の雪フィルタでは多数の無駄も発生します。単に冗長なルールはもちろん、そもそもAdGuardで使うのであればこういう書き方はしないルールもあります。必要な労力を考えますと、AdGuard Japaneseを改善するほうがはるかに効率がよいです。
4-5: Baseで個別対応されていれば基本的に大丈夫ですので、この部分については本来の雪フィルタに比べて性能が制限されるというだけの話かもしれません。
A4-6
ほとんど好みの問題ですが、処理の重い正規表現チェックが入るリクエストを少しでも減らすためです。トークン化可能な一般ルールでブロックされている場合は原則として追加しません。雪フィルタは数か月ごとにデッドドメインのスキャンも行っているため、無駄になる心配もありません。古いバージョンのAdblock Plusでさえ、1つの正規表現フィルタより20の通常フィルタのほうがベターですが、uBlock Originでは（よいトークンが引き出せる正規表現を除き）なおさらです。ただ、ブロックされないリクエストには結局チェックが入ります。また、ある時点では正規表現でカバーできていても、パターン変更でカバーできなくなることもあるため保険の意味もあります。
A5-1
2021年4月27日追記：Googleによる広告ブロック対策といった話が散見されるのではっきり申し上げますが、某ゲーム動画配信サービスと異なり、Googleは本気でブロッカーをバイパスしようとはしていないと思います。（2021年5月15日修正）実際のところわかりませんが、fetchによりバイパスが起きた件もパフォーマンス上の理由などと解釈可能なもので、今のところGoogleはブロックできない手段までは用いていません。ただ、一部の人にしか新型広告が配信されないため、解析が難しいのは確かです。「この設定/フィルタ/拡張機能なら出ない」という主張は、多くの場合、その人が新型広告の対象になっていないだけです。
2021年3月22日追記：Twitterなどで同様の報告が後を絶たないようなので、ABP Japanese filtersをブラックリスト指定させていただきました。
ABP Japanese filtersが原因の可能性が高いです。同フィルタは更新が停止しており、既にAdblock PlusやuBlock Originの標準フィルタリストからは削除されていますが、昔インストールしてそのまま使っている場合は有効になっている場合があります。また、AdBlockでは今でもデフォルトで有効のようです。同フィルタを無効にして別の日本用フィルタに切り替えてください。なお、名前が似ていますがAdGuard Japaneseは問題ありません。また、不具合というより広告漏れの話ですがuBlock OriginのフィルタとBlockTubeは干渉するため、BlockTubeは使用しないでください。もちろん、A1-9で述べたようにほかの広告ブロック拡張も使用しないでください。
A5-2
ほとんどの場合フィルターの問題で、誤爆と呼ばれます。フィルター作者に報告してください。uBlock Originでフィルターをいじっていない場合はこちらかこちら（要アカウント）、AdGuardでカスタムフィルターを追加していない場合はこちらか、またはAdGuard本体から「問題・不具合を報告する」も利用できます。Twitterなどをみていますと、サイト側の広告ブロック対策のように勘違いされる方が多いようです（そういう場合もありますが、稀です）。現在主流のブロッカーは、ブロック対象が広告・追跡かどうか分析などしておらず、URLやHTMLタグが事前に定義されたパターンにマッチするかだけをみています。機械学習などを用いて分析する試みも行われていますが、パフォーマンスへの影響や、この方法でも誤判定が避けられないこともあり、簡易的なヒューリスティック（旧バージョンのPrivacy BadgerやAppleのIntelligent Tracking Prevention等）を除いて実用に至っていません。
A5-3
広告ブロックについての情報は英語のほうが圧倒的に充実していますが、ここでは日本語で比較的信頼できるものをいくつか挙げてみます。なお、言語を問わずインターネット上には明らかに間違った記事やツイート、古い情報が蔓延しており、それが当FAQを作成した最大の動機です。
-
なんJ AdGuard部：Androidのみならずあらゆるプラットフォームの広告ブロックについて、おもに初心者向けの情報が集約されています。誰でも編集できる関係上、一時的に荒らされて誤情報が書き込まれたり、トピックによっては編集者間の合意が得られないこともあったりするようですが、それを差し引いても総合的には価値があると思います。なお、随所に当FAQの内容が反映されているようです。
-
uBlock Origin 再び ＠Firefox - おまえ、うまそうだな：uBlock Originのフィルタ文法について日本語で解説されています。uBlock Originの更新にも追随してくださっているようです。
-
uBlock Origin フィルター覚書（書き方・サンプル）- バグ取りの日々：uBlock Originのほぼ最新の文法がコンパクトにまとまっています。
-
uBlock Origin - Firefox更新情報 Wiki*：uBlock Originのほぼ最新の文法に加え、その他有用な情報がコンパクトにまとまっています。
-
Pokapokaサイト ブロックフィルタの書き方（入門）：もちフィルタ管理者様によるもので、上記ブログでは難しすぎる人向けです。ほかにも役立つ記事を書かれています。
-
280blocker | iPhoneの広告ブロック：280blockerさんのサイトです。参考になる記事が多くあります。
A5-4
2022年2月25日追記：ここのところ数名のユーザーにより処理能力をはるかに上回る大量の報告が送られたため、段階的に対策が取られています。その巻き添えで重要なIssueが閉じられてしまうこともあるかもしれません。
いろいろな理由が考えられます。AdguardFiltersで対処できるのはフィルタの問題だけですが、実際にはそれ以外の問題も多く報告されます。初心者の方にはその区別がつきにくいのは承知していますが、報告前にひと手間かけていただけるとこちらとしては助かります。
-
もっとも多いのは問題が再現できないケースです。再現のための手順を書いていただくのはもちろん、できましたらAdGuardの標準的な設定で、問題が確実に発生するか確認していただけると助かります。フィルターリストの過剰購読による不具合やアンチ広告ブロックはしばしば再現できず（購読数があまりに多い場合、こちらも環境再現をあきらめます）、できたとしてもせいぜい問題のリストの作者に修正を依頼するくらいしかこちらにはできません。iOSの場合はバグも多く、TUNNEL MODEをFull-Tunnelにすることで解決することもあります。もっと多いのはSafariのコンテンツブロッカーのバグで、コンテンツブロッカーを一度すべて無効にしてから再度有効にし、Safariを再起動してからフィルタの更新をかけてください。
-
そもそも何が問題なのかわからないケースも多いです。日本語で構いませんので（スクリーンショット中に日本語で説明を入れるのは控えてください）、一言、説明を加えてください。できればスクリーンショット中にマーキングをしていただけるとなおよいです。
-
AdGuardには何をブロックするかについて一定の基準があります。たとえば、SNS用フィルタではシェアボタンはブロックしますが、フォローボタンは一部例外（明らかに冗長で不要な場合など）を除きブロックしません。また、トラフィックが少ないサイト（目安として月100,000以下）は原則として個別対処しません5-1。上記リンクはあくまで総論なので、実際には現場で決められた指針や例外も多くあり、判断に迷う場合は議論して方針を決めています。議論はGitHub上でオープンに行うこともありますし、内部チャンネルで行うこともあります。既に対処しないと決まったケースの再報告も多いため、過去に同様の事例がないか報告前に検索いただけるととても助かります。AdGuardの基準に当てはまらなくても個人的に邪魔だから消したいという場合、その旨をコメントいただければユーザールールに追加するフィルタを提案します。
5-1: 既存のルールにドメインを追加するだけで済むなど、変更が少ない場合は担当者の判断で対処することもできます。
A5-5
個人開発のフィルタを公開するぶんにはなにも資格はいりませんが、uBlock₀ filters（uAssets）など主要なフィルタリストの場合は招待制です。AdGuard、EasyList、uAssetsのなかでもっとも間口が広いのはuAssetsです。大まかな目安としては、半年ほど優良なプルリクエストを続けることでしょう。頻度も重要で、十分アクティブであるとみなされなければ声はかかりません。協調性も見られていると思います。プルリクエストをするユーザーには、そのリポジトリ/フィルタを自分の思うように変えたいという人が少なくない気がしますが、あくまでそのリポジトリの方針を理解し、メンテナーの負担や時間を軽減するような配慮ができる人が好まれます（現行メンバーのうち一人でも反対票を投じると、招待の話は流れます）。AdGuardの場合はよくわかりませんが、uAssetsより条件が厳しいようです。EasyListのメンテナーになるのは現状ほぼ不可能です。
2021年3月25日追記：意外にもフィルタ作者にあこがれる人もいるそうですので、役に立つかわかりませんが国際的なフィルタリストを前提にもう少し書いてみます。当然ながら、フィルタ記法、HTML、CSS、Javascriptの基本的な知識は前提となります。なにかとPythonを使う機会もあるのでPythonスキルがあるとなおよいでしょう。英語でスムーズなコミュニケーションがとれることは絶対条件です。いちいち翻訳をかけていてはテンポも悪くなりますし、進歩したといってもGoogle, Deeplといった一般的な翻訳ツールは部分的にはおかしな訳もあります。それに国際標準語（？）は英語ではなくbroken Englishです。Gitクライエントは使えたほうがいいでしょう。GithubのWeb UIでもたいていのことはできますが、効率が悪いです。もっとも重要なのは根気です。フィルタメンテナンスなど、慣れてしまえばほとんどが数分で終わる単純作業の積み重ねにすぎません。それをいとわずに継続できるかが要となります。おすすめはしませんが、十分な実績を重ねれば生業にすることも不可能ではありません。ノルウェー用フィルタを提供しているDandelion Sprout氏はeyeoともう一つの広告ブロックベンチャーに就職していますし、当管理人も2021年9月にBraveより正規のフィルタエンジニアの打診を受けています（断りましたが）。
A5-6
Malvertisingと呼ばれる広告を通してマルウェア（ウイルス）を配信する手法（例）はもとより、悪質な広告やクラックされたサイトからのリダイレクトによりワンクリック詐欺など様々な詐欺サイトに飛ばされることがあります。PCの例をいくつか載せてみます（モバイル固有の詐欺も多いです、気が向けば追加予定）
ほかに当選詐欺、ビジターアンケート詐欺と呼ばれるもの（画像追加予定）もあり、これらは上記のほかに検索エンジンの検索結果に紛れ込んでいることが多いです。Malvertisingや広告からの悪質リダイレクトについてはコンテンツブロックが大きな効果を発揮します。また、とくにuBlock Originではこれらの詐欺サイトやリダイレクターも直接ブロックしています。悪質サイトの数は星の数ほどあり、短期間で次々と生まれ変わるためごく限定的な保護しか提供できませんが、それでもこの種の詐欺に限っていえばブラウザの保護機能（Google Safe Browsing, Microsoft Defender SmartScreen）よりましだという事実があります。管理人はこれまで数百件以上の詐欺サイトをみてきていますが、ブラウザの保護機能がこれらをタイムリーにブロックした例はただの一度もみたことがありません5-2。観察していると数日から一週間程度でブロックされることが多いようですが、そのころには当該サイトは決まってドメイン失効しています。これに限らずドメインが失効したり脅威がなくなったりしても報告がなければブロックは（少なくとも当面）継続される模様で、おそらくGoogle Safe Browsingはかなりの無駄なエントリーを含んでいると思います。ブラウザの保護機能を使うなということではありません、むしろコンテンツブロッカーがその弱点を補強できるということです。問題はドメイン単位のブロックが悪質サイトに対してあまり有効ではないことで、AdGuardのブラウジングセキュリティも同様の問題をはらんでいます。uBlock₀ filters - Badware risksではドメインブロックもしていますが、正規表現やパターンベースのブロックを組み合わせることで、とくに当選詐欺についてはときどきあるパターン変更の直後を除きほぼ100%といえるブロックができています。
一方で、メールやソーシャルメディアを通した悪質サイトへの誘導、フィッシングなどのより一般的なネット詐欺、および標的型/水飲み場型攻撃等にはあまり有効ではありません。水飲み場型攻撃については、アンチウイルスベンダーが発表する事例などをみているとMedium modeで防げるケースもかなりあるようですが万人向けとは言えないでしょう。コンテンツブロッカーはあくまで基本的なセキュリティ対策やユーザー教育に追加して使うものだと思います。なお、上記のような詐欺サイトに遭遇してしまった場合、基本的にそのタブを閉じてクッキーを削除していただけば問題ありません（参考）。
5-2: ちなみにFirefoxのDoHでQuad9, CleanBrowsingといったセキュアDNSを別々のプロファイルで使っていますが（フォールバック禁止）、Quad9で１件の明らかな誤判定があった以外にブロック（NXDomain）されたことはありません。
このFAQの初版の作成に当たっては、@280blockerさんから貴重なご意見をいただきました。ここに感謝申し上げます。 （元々見ていただくことを想定していたわけではなく、たまたま別件で話していたときにタイミングがあったため、ご意見をいただくことができました。間違い等の文責はすべて@Yuki2718にあります）