ローカルファーストの設計で、データを外部に送らない仕組み

WebBrain は Chrome と Firefox に対応するブラウザ拡張機能で、MIT ライセンスのもと GitHub で公開されています。（参考：WebBrain GitHub）最大の特徴は、クラウド API を使わずにローカルで実行できる点です。

ローカルモデルで動作させれば、ページデータは一切マシン外に出ません。

ブラウザのサイドパネルに統合され、Chrome では Manifest V3 と sidePanel API で動作し、Firefox では Manifest V2 と sidebar_action を使用しています。拡張機能はブラウザの既存の認証セッション内で動作するため、ユーザーの登録済みアカウントにアクセスでき、外部データストレージやテレメトリは一切含まれません。

言語サポートは英語、スペイン語、フランス語、トルコ語、中国語に対応し、初回起動時にブラウザの言語設定を自動検出します。

個人開発ツールを複数運営しているエンジニアの立場からすると、この「ローカル実行」という設計選択が非常に魅力的です。自宅の RTX 3090 で Stable Diffusion を動かすのと同じ感覚で、ブラウザ自動化を自分の環境で完結できるというのは、開発効率とプライバシー両面で優位性があると感じます。

Ask モードと Act モード：読み込みから操作まで段階的に制御

WebBrain には 2つの動作モードが用意されています：

モード 機能 特徴
Ask モード ページの読み込み・データ抽出のみ 読み取り専用、ページを変更しない
Act モード クリック・入力・スクロール・ナビゲーション・ワークフロー実行 Chrome DevTools Protocol（CDP）経由で実行

Ask モードは通常のコンテンツスクリプトでページを読み込みます。一方、Act モード は Chrome.debugger API 経由で DevTools Protocol を使い、信頼できるイベント入力を生成するため、モダンな Web サイトでも確実に操作が認識されます。さらにクロスオリジン iframe やシャドウ DOM にもアクセスでき、コンテンツスクリプトでは到達不可能な領域も操作可能です。

Act モードの力は意図的にスコープされており、アクション実行時にのみデバッガを接続します。

Chrome では拡張機能の標準的なデバッグバナーが表示されますが、Firefox は CDP 相当機能がないため、Act モードの機能が限定的です。

モデルの出力安定性を保つため、温度（temperature）は固定されており、Act モードは 0.15、Ask モードは 0.3、ビジョン機能のスクリーンショット説明は 0 に設定されています。

セキュリティモデル：段階的な同意と API 呼び出し制限

ブラウザエージェントは悪意あるページから攻撃を受けるリスクにさらされています。Web ページに隠された プロンプトインジェクション が、エージェントの挙動を乗っ取る可能性があるためです。WebBrain はこれに直接対応しています。

エージェントはデフォルトで読み込み専用の Ask モードから始まり、影響の大きなアクション（送信・購買など）の前にユーザーの確認を求めます。Permissions 設定でこの確認を無効化できますが、デフォルトはオン状態です。

さらに、データ変更を伴う操作（作成・送信・購買）には UI ファーストルール が適用されます。WebBrain は REST や GraphQL エンドポイントに直接アクセスするのではなく、ユーザーが見える UI を経由して操作を行います。UI が機能しない場合のみ、会話ごとの /allow-api 上書きオプションで API 呼び出しを許可します。

読み込み処理は別扱いで、README の取得や価格比較など読み取り専用の操作は fetch_url や research_url ツール経由でバックグラウンド HTTP を使用できます。リモート側の状態が変わらないため、厳格なルールは適用されません。

実装検討時の注意点：拡張機能の署名とローカルモデルの選定

開発者が WebBrain を導入する場合、いくつか検討すべき点があります。

ローカルモデルの選定 が重要です。ブラウザ内で動作するため、推論コストとレイテンシーのバランスを考慮する必要があります。小規模なオープンソース LLM（Mistral、Llama 2 など）でテストし、タスク精度を確認することをお勧めします。

クロスプラットフォーム互換性 も実装時の課題です。Chrome では CDP 経由の強力な Act モードが使えますが、Firefox は制限的なため、同じワークフローで両ブラウザ対応を目指す場合は事前テストが欠かせません。

こうした仕組みを見ていると、ブラウザ自動化の民主化が進んでいる印象です。従来はセレニウムなど外部ツールに依存していた領域が、エージェント側で統合されつつあり、開発効率が大きく向上する可能性を感じます。

参考として、同時期に Google が発表した A2UI v0.9（出典）も、フレームワーク非依存な UI 宣言標準として、AI エージェントの UI 制御を簡素化する動きを示しています。これらのプロジェクトが相互に補完されば、AI 駆動の自動化は一層実用的になるでしょう。