BrowserOS – Perplexity Cometのオープンソース代替

• BrowserOSは、Perplexity Cometのオープンソースかつプライバシー重視の代替で、ローカルでAIエージェントを実行するエージェンティックブラウザ
• Chromiumをフォークしており、既存のChrome拡張をすべてサポートし、ユーザーデータはローカルにのみ保存されるのが特徴
• OpenAI, Anthropic, Ollamaなど多様なAIプロバイダーと連携でき、個人のAPIキーまたはローカルモデルを利用可能
• ネイティブハイライター、ChatGPTベースのブックマーカー、セマンティック検索など最新の生産性ツールを内蔵し、AIベースの広告ブロック機能も近日対応予定
• 既存ブラウザと異なり、検索・広告企業にデータが渡らず、自動化されたワークフローをローカルでAIが実行する

---

BrowserOS 概要

• BrowserOSはオープンソースのエージェントブラウザで、ユーザーのコンピューター上で直接AIエージェントが動作する環境を提供
• プライバシー優先の思想に基づき、APIキーまたはOllamaなどのローカルモデルを使用して、データが外部に流出しない
• ChromiumフォークベースのためChromeのユーザーインターフェースと同一で、すべてのChrome拡張機能が動作

主な機能

• AIエージェント & ローカル実行

  • ブラウザ内でAIエージェントがローカルで直接実行され、反復作業や自動化ワークフローを処理
  • Ollama統合により大規模言語モデルをクラウドではなく自分のコンピューター上で動かし、データプライバシーを保証

• 生産性ツール

  • ハイライター、ChatGPTブックマーカーなどブラウザ内蔵の生産性ツールをサポート
  • セマンティック検索により履歴やブックマークなどのブラウザデータを素早く見つけられる

• 広告ブロックおよびMCPストア（予定）

  • AIベースの広告ブロック（近日公開）により、ChromeでのuBlock Origin排除後の代替を提供予定
  • MCP（マルチコマンドパッケージ）ストア（近日公開）では、人気のMCPをワンクリックでインストールし、すぐにブラウザバーから活用可能

• オープンソースおよびコミュニティ中心

  • AGPL-3.0ライセンスによる100%オープンソースで、コードと動作の透明性を保証
  • コミュニティ参加と貢献を積極的に奨励

代表的な活用事例

• 反復的で退屈な業務の自動化: ミーティング予約、フォーム入力、反復作業をAIが自動処理
• ディープリサーチ: Webを探索して要約レポートを生成し、手作業でタブ管理をせずに効率的に情報収集
• SNSコンテンツのスキャン: LinkedIn、Twitterなどで有意義な投稿を自動で選別・整理

他ブラウザとの比較

• Chrome: 10年間大きな変化がなく、AI/自動化/MCP機能が不在
• Brave: 暗号資産/検索/VPNなどへの分散戦略で、AIブラウザに集中していない
• Arc/Dia: クローズドでオープンソースではなく、利用停止時の代替がない
• Perplexity Comet: 検索・広告企業中心で、ユーザーデータがサーバーへ送信される一方、BrowserOSはすべてのデータをローカルにのみ保存

インストールと開始

• macOS、Windows向けダウンロードをサポート
• Chromeデータのインポート（任意）
• AIプロバイダー接続（OpenAI、Anthropic、Ollamaなど）
• すぐにエージェント自動化を開始可能

ライセンス

• AGPL-3.0オープンソースライセンスを適用

[luiseok]

https://ja.news.hada.io/topic?id=21581
どこかで見覚えがあると思ったら、Nxtscape が名前だけ変えたものだったんですね

[GN⁺]

Hacker Newsの意見

• デモで見せた歯磨き粉の購入例は、こうした作業がどれほど難しいかを示している。歯磨き粉という指定自体がとても曖昧なので、結局は非常に大きなリストの中からランダムに選ぶことになる。前の行動が手がかりになる作業もあるが、そうでない場合も多い。たとえば以前買った歯磨き粉が品切れならどうするのか分からない。結局、こういう例が本当に時間を節約してくれるのか疑問だし、どうせ結果を確認するなら二度手間になる。このため、Alexaのようなシステムも当初Amazonが期待した購買体験を提供できなかったのだと思う。むしろ、時間節約が明確で失敗ケースが最小化された、より複雑な例を見せるか、あるいは失敗ケースからどう復旧するかに焦点を当てたほうがよい気がする。特定の問題向けのUIを提供するのか、それともチャットで解決するのか。この世界全体が決して簡単なものではないと思う。みんなの幸運を祈る。
  • その通り。agentic browser分野全体がまだ始まったばかりだ。私たちもようやく始めたところで、価値のあるニッチなuse-caseを探している。反復的で退屈な作業の中には、時間節約の効果がはっきりしているものもある。たとえばWalmartのサードパーティーセラーが1日に何度も競合価格を確認して自分の商品の価格を調整する作業だ。これはagentic browserで簡単に自動化できる。
  • ユーザーごとの美的センスに合わせて作業を実行できるべきだとも思うが、そうするとセキュリティ上の悪夢になりかねない気がする。
• Nxtscapeをすでにインストールしていたのだが、製品名が変わったと知らずにBrowserOSを起動したら、同じUIとチャット欄にキツネの絵文字まで同じで面食らった。正直、以前の名前のほうがよかった。法的な理由で改名したのだろうと推測している。<br>Arstechnicaの記事コメントを要約してくれと頼んでみたが、最初は「コメントが含まれていないので要約できない」という返答しかなかった。こちらが明示的に「comments」リンクをクリックしてみろと指示して初めて、ちゃんとコメントを読み始めた。ちなみにコメントページは全部で3ページあるのだが、20分以上かけて100回前後のアクションを実行し（その中には1074ピクセルずつスクロールするような非常に細かい動作も多かった）、今なお「Validating task completion...」の状態で要約を待っている。<br>機能的には強力に見えるが、あまりに手間がかかって遅く、実際には使えないと感じた。<br>ちなみにNxtscapeでも同じ実験をしてみたが、そちらのほうが速く、少ないアクションで作業を終えた。それが偶然なのか、内部的に別のロジックだからなのかはよく分からない。<br>それから、iCloudパスワードをChromeで使えるようにするChrome拡張機能があるのだが、NxtscapeとBrowserOSでは動作しない。パスワードマネージャーを毎回手動で開かなければならないなら、こういうブラウザを使う気にはなれないし、パスワードマネージャーを変えるつもりもない。
  • 問題が起きるのを防ぐために名前を変えた。それに以前の名前は発音もしづらかった。 フィードバックありがとう。Discord(https://discord.gg/YKwjt5vuKr)でもっと話せたらうれしい！ 私たちのチームは毎日デプロイしながらものすごい勢いで改善していて、エージェントも数日中にはかなり良くなる予定だ。 iCloudパスワード拡張についても確認する。オンボーディングとパスワード管理をずっと簡単にするのが目標だ。
• これがprivacy first browserなら、なぜFirefoxを使わなかったのか気になる。Firefoxのほうがこの目的にははるかに合っているし、デフォルトでもより良い選択肢だ。Tor Browser、Mullvad Browser、LibreWolfなど、セキュリティ/プライバシー優先のWebブラウザはすべてFirefoxエンジンベースだ。 また、多様な「Webブラウザエンジン」は絶対に必要だと思う。巨大テック企業のエンジンしか使われなくなれば、最終的には消費者にとって大きな損失であり、イノベーションも阻害される。 Firefoxのような独立系ブラウザをもっと支援すべきだ。
  • 本当に難しい決断だった。 webkit上でブラウザを作った人たちとも話したが、ランダムなバグを直し、サイト互換性の問題を潰すだけでもほぼ2年かかったそうだ。firefox/geckoエンジンはwebkitより良いかもしれないが、結論としてはchromium以外のエンジンを使うと、Webサイト互換性の問題や拡張機能サポートまで含めて莫大な追加作業が必要になる。 私たちもたった2人のスタートアップで、chromiumコードベースのほうがビルドしやすい出発点だったので選んだ。 それにBraveのように、chromium上でも十分にプライバシー重視のブラウザを作れる。 特にagentic browserの時代には、プライバシー面で今すぐ改善できることがあまりにも多い――たとえばPerplexity Cometのようなところへ機密データを送るのは広告収益目的なので本当に良くない。ローカルLLMをサポートしたり、ユーザーが自分のAPI keyを使えるようにしたりすることのほうがずっと重要だ。
  • まったく同じ疑問を持った。 プライバシー志向をうたいながらchromiumを使う理由が気になる。
• 「ChromeのC++ソースコードを直接パッチして、Google Chromeと同等のセキュリティを得ている」という記述を見た。 だとすると、Chromiumが更新されるたびに毎回独自ビルドをやり直しているのか気になる。というのも、一見何でもなさそうなcommit messageのパッチが、実際には深刻な脆弱性に関するもので、90日後にCVEとして公開されることがよくあるからだ。
  • いい質問だ。今のところ私たちは、Google ChromeがベースにしているChromiumリリース版を基に継続してビルドしている。
• これは独立したブラウザではなく、ブラウザ拡張機能の形で提供されたほうがいいと思う。
  • 私たちも元々はブラウザ拡張として作りたかった。 しかし、良いagent copilotを作るにはChromiumのC++レベルでさまざまな変更が必須だと考えている。たとえば、すべてのWebサイトのアクセシビリティツリーをChromiumが持っているが、それをchrome extension APIから取得できない。アクセシビリティツリーに直接アクセスできれば、agentの性能は大きく向上する。 また、クリック動作やelement indexなど、agentがWebサイトとやり取りするためのいろいろな機能をC++レベルで追加している。これをJSでやると20〜40倍遅い。
  • 私たちもまったく同じ考えだ。agenticな機能を実装するのに、必ずしもブラウザ全体が必要だとは思わない。制限された権限の範囲内でも、ブラウザ拡張だけで十分実現できる。 Googleが即時配布するzero dayパッチも多いし、GoogleがChromiumに入れない機能も確実に存在する。だから、メインブラウザとして無名のオープンソースforkを信頼することはできない。 AI Web Agentのブラウザ拡張としてrtrvr.ai(https://rtrvr.ai)を勧める。すでにユーザーのワークフローに合わせて実装されている。
  • nanobrowserがここで言及されたとき、私も同じことを思った。
  • https://github.com/nanobrowser/nanobrowser 試してみる価値はある。
• これはchrome extensionのnanobrowserに似たプロジェクトだ https://github.com/nanobrowser/nanobrowser
  • プロジェクトページをざっと見たところ、外部LLM API keyを使うようだ。元の投稿で紹介されているこのプロジェクトは、transformer.jsを使ってローカルでLLMが動く形に見える。
  • こうした機能がすでに拡張機能として実装可能なら、なぜ既存ソフトウェアをforkしてまで作る必要があるのか気になる。 nanobrowserとbrowserOSの間で、明確にbrowserOSでしかできずnanobrowserにはない機能があるのか、押さえておくべき違いが知りたい。
  • 言及してくれてありがとう。
• 「<i>私たちはChromeがuBlock Originをブロックした後、LLMベースの広告ブロッカーも作っている</i>」という話があるが、どうせChromium forkならuBlock Originを再利用すればいいのではと思う。
  • ChromiumはManifest V2 APIを廃止する予定で、どのforkもこれを維持し続けたいとは思っていない。Braveですら独自の内蔵広告ブロッカーを別途作っている。 本当の疑問は「なぜFirefoxをforkしないのか、Firefoxが全部やってくれるのに、なぜわざわざChromiumを選ぶのか」だ。
• Linux向けのロードマップが気になる。MacもWindowsも持っていない。
  • その点は認識している。来週の初めにはサポートできるようにする予定だ。 まだ2人チームなので、本当にやることが多い。
• AIがマウスカーソルを実際に動かしてクリックし、キー入力もリアルタイムで画面に表示されるところを見たい。ソフトウェアチュートリアルのように、実際の人が使っているようなインタラクションがあるとよい。 今のようにAIがページを切り替えてUIを次々変えると、画面がぶつ切りになる感じで流れを追いにくい。 何に注目して見ればいいのかのヒントが足りず、ただスクリーンレコーディングを見ているような感覚だ。 それでもmcp/browser automationのような分野では有用な活用例がありそうなので、今後の発展に期待している。
  • とても有用なフィードバックだ、ありがとう！<br>カーソルの動きも追加できるか見てみる。キー入力もすでに実際の人のように見えるが、もう少しゆっくり見えるよう改善できそうだ。
  • 本当に欲しいのはcaretaker aiだと思う。
• おめでとう！<br>このプロジェクトを財務面・開発面・保守面でどう持続可能にする計画なのか気になる。
  • ありがとう！<br>基本的にはブラウザのEnterprise版のライセンス販売で、オープンソースプロジェクトと同じように進める予定だ。
  • 私の推測では、単なるelectronアプリ、あるいはchromium wrapperにollama wrapperを付けた構成なのではないかと思う（ブラウザを操作できる無料のオープンソースライブラリも山ほどある）。