[ローカルLLMで生活ファイアウォール] 力業ブラウザーフィルター

確定申告の横でバイブコーディングするのによいネタはないかと考えていたのですが、生活ファイアウォール関係で前々から考えていたものをちょっとやってみました。

(この記事は私の記事の中ではダントツにビュー数が多いほうです。イイネは付かなくても皆、こういう話が気になっているのだと思います)

リアルタイムTVCMフィルタを作った後に、同様にLLMで自分好みにフィルターしたかったものにWebブラウザーがあります。

ご存知の通りWebの世界も今では広告だらけです。インターネットの黎明期には本当にオープンな知識の共有場所として美しく育つかと思ったら、広告にまみれてしまった。

ある程度は仕方ないと思うのですが、だまし討ちするようなポップアップにイライラさせられると、そこまでして金が欲しいのか と思ったりもします。
でも現実にはお金の暴力で押し込んでくる広告や挙動を追跡する広告だらけです。

私は基本的には「情報は一切制約も検閲もしない。でも制約しなかったら多すぎて情報に溺れてしまう。だから個々の人が自分の欲しい情報をより分けて使う。皆がそう使えば全ての情報がチェックできる」と思っています。
だから「情報は制約しない。その上で自身で情報をより分けるのは権利」だと思っています。
(注: 例外としてある程度の年齢までの制限は必要と考えています)

まぁごたくはこのくらいにして、

つまり広告も含めて多すぎるWeb情報をリアルタイムTVCMフィルタみたいに「自分の見たいものだけフィルタする」ブラウザということで、LLMを使った力業(ちからわざ)ブラウザーフィルターです。

LLMを使ったブラウザー広告フィルタ試作

当初リアルタイムTVCMフィルタを作った後で、同様のことをWebブラウザもやれるはずなので少し作りかけてたのです。

技術的にはChrome機能拡張でやれるはずです。Chrome機能拡張で文字列を抽出し、LLMに送ってそれが「自分が見たいもの/自分が見たくないもの」を判定させて、その結果でブラウザ上に表示するかしないかを設定します。

多くの広告フィルターもChrome機能拡張で作られていますし、大筋はどういう仕組みなのか想定がつきます。Chrome機能拡張は個人的には自分で使うためのものをいくつか作ってるので一応はわかります。古くなったブックマークのエージングアドインとか、今でも使っているものがあります。

でもChrome機能拡張もブラウザのテキストの直編集もWeb技術に強依存しているし、Chromeの機能拡張用APIも癖があります。LLMに送ってテキストを判定して表示のオンオフまでやれたのですが、やはり重いし、短いテキストでは広告かどうかを判定するのは難しく誤検出も多かったです。
「これをこのまま完成に持ち込んでも微妙かな。。」と感じたので仮実装までで放って置いたのです。やりたいとは思ったけど、想定通り結構技術的にも難しく、かつ出来ても微妙な性能になりそうだったのです。

バイブコーディングでの再試作

でもここにきてバイブコーディングがかなり賢くなり、そういう試作もゼロ時間で出来るようになりました。しかもWeb技術の細かい部分なら明らかに私より詳しいでしょう。

という訳で、バイブコーディングの練習がてらもう一度LLMを使ったブラウザフィルタを作ってみたのです。練習とプロトタイプ評価を目的とするのであんまり細かいところの仕上げはしない方針にします。

「次の文は映画の話題を含みますか?」

まぁすごく高精度という訳ではないです。すごく早いという訳でもないですが最初に作ったものよりかなり早いです。

変換モードも入れてみました。ブラウザの表示テキストをニャーに変換するChrome機能拡張は確か以前に誰か作成したものがあった気がします。今回はLLMを経由するので遅めの代わりにかなり柔軟な変換ができます。

処理中マークを出させるようにしました。

やや重いのではあるのですが、動作は思ったより安定しています。

LLMは高速で動く必要があり、多量にテキストを判定する必要があります。
多量のAPIコールが発生するのでローカルLLMでないとコストが厳しい。高速で動く必要があるので出来るだけ軽量なLLMということで、qwen3.5の4bモデルをローカルOllama APIで動かしています。
4bより小さいモデルではjson出力が安定せず、4bが最小かなと考えています。

設定画面

基本設定

バイブコーディングで「Chrome機能拡張で広告フィルタを作って下さい」と言ったら広告ドメインのフィルタを勝手に作ってくれたのでそれも一応残しています。画像抑止やポップアップ抑止、iframe置き換えなどはバイブコーディングでの指示で自動生成しました。細かい技法はすべて任せています。概ねの抑止はきちんと働くのですが、サイト側もそういうのは対処していて、広告ビジネスやってるサイトでは効果がないケースも多いです。

今回は試作なので効果がないケースは放置しています。強引に抑止する方法を探して対応してもイタチごっこですし。

テキストフィルタ/変換設定

変換モードオフの場合は「元々のテキストを表示するか/マスクXするか」のフィルタモードになります。フィルターモードの場合は以下のルールでマスクします。

1. タグ内の一定長以上の文字列を一旦###に置き換えて、元文字列を保持します。

2. 元文字列に指示を付けてLLMに送ります。「次の文は映画の話題を含みますか? (元文字列)」

3. 判定結果をjsonで取得し、trueの場合は元文字列に戻す。falseの場合は###置き換えのままにする。

変換モードがオンの場合は元々のテキストをLLMの指示で変換します。

1. タグ内の一定長以上の文字列を一旦###に置き換えます。

2. 元文字列に指示を付けてLLMに送ります。「次の文の語尾をニャーにしてください。 (元文字列)」

3. 変換結果を取得し、その文字列を元の場所に設定する。

指示プロンプトや検出文字列長の設定、フィルタモードのtrue/falseの反転なども設定できます。

API設定

使うOllamaのAPIエンドポイントを設定します。またそのOllamaで使うLLMモデル名を設定します。

今回qwen3.5:4bを使いましたが、json返答が出来る性能のモデルであれば他のモデルでもokです。qwen3.5の場合4bより小さいとjson返答がうまく返らなかったので4bより大きくしてください。

フィルターと変換性能は?

元々のアイデアは広告をLLMで除去するためのものですが、広告フィルターの性能はやや微妙です。。通常のWebページでも最近の広告は画像ベースのものが多く、文章で書かれた釣り広告は少なくなっているし、広告文字列も短めで誤認させようとしているので、LLMでテキストを読ませても広告と判断するのはかなり難しかったです。

広告画像については、ビジョン性能があるLLMを使えば、画像を広告かどうか判定させるということが可能ですが、それは今回は使っていません。画像だとさすがにちょっと重すぎで処理遅すぎと思いますし、今回は試作ですし。
現時点はAIが勝手に追加してくれた「一般的な広告ドメインを抑止する」の機能の部分のほうが広告には効いているかもです。

画像フィルタはきちんと入れればおそらく効果はあります。問題は広告サイトがhtml+jsを巧みに使ってフィルタリングを逃れている場合があり、複雑なサイトではフィルタ出来ないケースがある(というかイタチごっこになるので面倒くさい)ところでしょうか。

ということで少し主旨を変更します。。

「自分の好む分野・テーマのテキストを表示し、その他の分野・テーマのテキストは表示しない」なら精度はよくなるのではないか、と思って例えば「この文は映画の話題の話題ですか」というプロンプトを使って、映画エンタメのみを表示するというフィルタはどうかを試してみました。

広告検出よりはマシになった感じ。でもすごくよくフィルターできているかはちょっと微妙です。

というわけでさらに主旨が変わりますが、テキスト変換の機能を付けてみました。
「語尾をニャーにしてください」という指定をしてみました。

ああ、これなら結構上手くできている。###が残っているところは変換エラーになったケースかもしれません。

たしかChrome機能拡張で「ニャーに変換する」みたいなのはすでにどこかにあった気がします。でもこれはLLMで変換指示するのでもっと細かい変換指示もできます。要約をするように指示もできます。

試しに今週の旅botたよりのページを要約表示してみます。

そこそこらしくは表示されています。でもかなり重いです(変換が確定するのに数分かかる)。でもその間、別のブラウザ操作をしてもエラーやクラッシュはしません。

常用するにはしんどいけど、ちょっとした気分転換にはなるかも? くらいの感じ。

各社のクラウドLLM APIを使えば変換精度も変換速度も全然上がるとは思いますが、こんな用途にトークンコストを使うのはちょっと違う感じもあります。。
現状、プライバシー・元データの権利面も考えるとローカルLLMでの実行が妥当なのだと思います。

まだすごく役立つという感じではないけど、アイデアのプロトタイプとしては何かの可能性を感じるものです。

何か可能性は感じるけど、この先を進めて面白いものになるかまだちょっとわからない。でも見ていて別のアイデアが思いついたので、これをヒントにちょっと別のものをバイブコーディングしようかと検討中です。

で、せっかく作ったのでここまでをGitHubに公開中です。

興味があればご覧下さい(注意:後述)。

仕様・プロンプトは売り物になるのか

ここでちょっと実験的なことをしてみます。
よく言われる話で「Chrome機能拡張はマルウェアなどセキュリティが割と危ない」と知られています。

Googleの公式ストアでは確認はされているけど、後になってマルウェアが検出されるというケースも以前はいくつかありました。
上記で力業ブラウザフィルターをGitHubに掲載しましたが、見知らぬ人がインターネットに公開しているChrome機能拡張は決してインストールしてはいけません。

上記のGitHubは今回の試作の実証やバイブコーディングのソースの参考として公開していますが直にインストールするのはお勧めしません。

じゃ試して見たいならどうすればよいのか、という問いに対して

というアプローチを試してみます。

バイブコーディングが安全かどうかは賛否両論ありますが、バイブコーディングは使用者の指示に従う訳ですから

見知らぬ人が書いたソースやバイナリより、自分が読める指示でAIに作らせたバイナリのほうが悪意処理が入る可能性は少ないです。

今回これに200円を付けてみます。

実行形式バイナリやソースではなく、「プロンプト・仕様は売れるものなのか?」という実験です。

コンシューマー向けには仕様書が商品として認識されるケースは少ないです。「仮想通貨のホワイトペーパー」などは仕様書が商品というわかりやすい例かもしれません。

ちなみに生成に使ったプロンプトといってもCLAUDE.mdのようなものではなく、IDEのAIプロンプトのコンソールにどんな文を送ったかというものだけです。
同じプロンプトを使っても作られるソースは違うものが作られると思いますし、Ollama起動付近は一部手でソースを直した部分もあります。
GitHub側との比較は参考になるかもしれません。

自分で指示して作ったコードならマルウェアなど悪意のあるコードは入りませんので、GitHubから試すより圧倒的に安心です。

生成環境:
JetbrainsのWebStormのAIチャットコンソールから以下のプロンプトを入力しました。
LLM設定はCodex(gpt5.3-codex-midium)を主に一部はClaude Agent(Claude Code)を使用しました。
Claude Agentの指示時にソースリストの一部をSelectionして添付指示した場合があります。

WebStormのAIチャットコンソールを使っていますが、最近のIDEのAIコンソールは皆似たようなものなので、VS Code, Antigravity, Cursorなどどれも同じようにやれると思いますよ。 Claude Codeなどcliのツールでも同様だと思います。

サンプル

25行くらいの会話的な平文ですので、バイブコーディングに慣れている方なら、以下を見なくても思いつきで入力して同等品が作れると思います。

まぁ興味のある方はどうぞ。