BrowserOSとは｜エージェント内蔵のAIブラウザをOSSで持つ選択肢とComet/Atlasの違い

Webブラウザに「AI」を足す動きは、2026年に入って一気に製品カテゴリになった。Perplexity Comet、ChatGPT Atlas、Dia——どれもAIブラウザと名乗り、どれも提供元のクラウドを経由して動く。BrowserOS（browseros-ai/BrowserOS）は、そこに「エージェントをChromium本体に組み込み、モデルは自分で選ぶ」という別解を出したプロジェクトだ。GitHubスターは2026年7月27日時点で約12,755、ライセンスはAGPL-3.0で、Chromiumへのパッチ群とビルドシステムまでリポジトリに入っている。

AIエージェントの実行基盤としてどんな選択肢があるかを俯瞰したい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 が全体地図になる。本記事はその地図のうち「エンドユーザーが日常使うブラウザ製品そのものにエージェントが載るとどうなるか」という一角を扱う。

BrowserOSとは｜AIブラウザをChromiumフォークとして作るという判断

BrowserOSの正体は、AIエージェントを組み込んだChromiumのフォークだ。READMEの表現では「an open-source Chromium fork with an AI agent built into every new tab」、つまり新規タブごとにエージェントが待機している構成になる。ページを要約させる、フローをクリックして進ませる、データを抽出させる、定期実行のタスクを仕込む——こうした操作を20以上の組み込みツールと40以上のアプリ連携（Gmail・Slack・GitHub・Linear・Notionなど）で処理すると説明されている。

リポジトリの実測値を並べると、このプロジェクトの規模感がつかめる。

言語の内訳が、このプロジェクトの構造をよく表している。TypeScriptが最大だがRustが2.4MB、C++が956KB、Pythonが1.3MB入っている。これは「拡張機能を1つ書いた」規模ではない。C++はChromium側のパッチ、Pythonはブラウザのビルドシステム、Rustは後述するBrowserClawのバックエンド、Goは操作用CLIにあたる。

「AIブラウザ」という言葉が指すものが2つある

ここで用語を整理しておきたい。2026年時点で「AIブラウザ」と呼ばれているものは、実際には性格の異なる2つに分かれる。

・人間が使うブラウザにAIが載っているもの：Comet、Atlas、Dia、そしてBrowserOS。主役は人間で、AIは要約・調査・操作代行を手伝う側にいる
・AIエージェントに使わせるためのブラウザ／ライブラリ：browser-use のようなライブラリ、あるいはエージェント専用のブラウザ本体。主役はエージェントで、人間は指示と監督に回る

この2つは検索意図も評価軸もまるで違う。前者はブックマークの移行や広告ブロック、日常の使い勝手が問題になる。後者はログイン状態の引き継ぎ方、CIで回るか、APIの安定性が問題になる。BrowserOSは前者だ。エージェント側の選択肢を探しているなら、ライブラリ型の代表である Browser-Useの使い方｜AIに実ブラウザを操作させるOSSの仕組み・導入・他ツール比較【2026】 や、ブラウザ本体をエージェントに渡す設計の ego lite解説｜AIエージェントに自分のログイン状態を渡すブラウザをbrowser-useと比較 のほうが噛み合う。

1つのリポジトリから2つのブラウザ｜BrowserOSとBrowserClawの線引き

BrowserOSを調べるとき最初につまずくのが、このリポジトリが2つの製品を同時に配っていることだ。READMEの冒頭は左右2カラムのテーブルになっていて、左にBrowserClaw、右にBrowserOSが並ぶ。標語は「Two browsers, one codebase.」だ。

役割は正反対に設計されている。

公式FAQはこの違いを「BrowserClaw is a browser your AI drives; BrowserOS is a browser you drive, with an AI agent built in」と説明し、両方を並行して使う人が多いとも書いている。日常のブラウザはBrowserOS、エージェント専用のブラウザはBrowserClaw、という住み分けだ。

本記事が扱うのはBrowserOS側だ。BrowserClaw側の「エージェントに自分のログイン済みブラウザを渡す」という設計思想については、同じ問題に別のアプローチで取り組んだ ego lite の記事で扱っているので、そちらと読み比べるほうが理解が早い。以下はBrowserClaw側の画面だが、参考として1枚だけ挙げておく。

なぜ拡張機能ではなくChromiumフォークなのか

「Chromeに拡張を入れれば済むのでは」という疑問には、READMEが「Not Chrome with an AI extension」という節で答えている。挙げられている拡張機能の限界は3点だ。ブラウザのUI（chrome）自体に手を出せないこと、常駐してスケジュール実行ができないこと、エージェントがネイティブに使う20以上の組み込みツールを同梱できないこと。

この判断のコストは小さくない。Chromiumのフォークを維持するとは、上流のリリースに追従してパッチを当て直し続けるということだ。リポジトリの packages/browseros/chromium_patches/ がその作業の集積で、CONTRIBUTINGはブラウザ側の開発に約100GBのディスク容量が必要だと明記している。拡張機能なら数MBで済む世界と比べると、フォークという選択がどれだけ重いかがわかる。

一方で、フォークだからこそ既存資産が生きる。Chromiumベースなので既存のChrome拡張はそのまま動き、初回起動時のインポートでブックマーク・パスワード・拡張・設定がワンクリックで移る。プライバシー面では ungoogled-chromium のパッチを一部取り込んでいるとCreditsに記載がある。

AIブラウザとして何ができるか｜組み込みツールと定期タスク

READMEが「Key features」として挙げているものを整理すると、BrowserOSがどの作業を狙っているかが見えてくる。

・エージェントへの自然文指示：やりたいことを平文で書く。20以上の組み込みツールと40以上のアプリ連携（Gmail・Slack・GitHub・Linear・Notionなど）を使って進める
・サイドパネルでのチャット：いま見ているページについて質問する、要約する、書き換える。ページを離れずに使える
・データ抽出：ページを指してほしい項目を伝えると、構造化されたデータで返す
・Cowork（ファイル操作との併用）：ブラウザ操作とローカルのファイル操作を1つのセッション内で組み合わせる
・定期タスク：エージェントを自動運転させる。日次・時間単位・数分単位の粒度が挙げられている
・MCPサーバー化：BrowserOS自身をMCPサーバーとして公開し、Claude CodeやCursorから操作する

冒頭のデモ動画がわかりやすい実例になっている。サイドパネルに「go to amazon and order sensodyne toothpaste」と入力すると、パネル内に思考のステップが流れ、左側の実際のAmazonのページで検索語が入力され、商品が選ばれ、カートに追加されていく。人間は自分のブラウザを見ているだけで、操作は同じウィンドウの中で進む。ここが「別プロセスのヘッドレスChromeが裏で立ち上がる」ライブラリ型との体感差だ。

同じ「マルチエージェントでブラウザを操作する」発想をChrome拡張として実装した例としては Nanobrowser徹底解説：マルチエージェントでWeb操作を自動化するChrome拡張 がある。拡張という制約の中で何ができて何ができないかを見ておくと、BrowserOSがフォークを選んだ理由が具体的に理解できる。

「20以上の組み込みツール」の中身

機能一覧に出てくる「20以上の組み込みツール」は抽象的だが、エージェント側モノレポのREADMEを読むと具体的な系統がわかる。サーバーが公開しているのはCDP（Chrome DevTools Protocol）に裏打ちされたブラウザ操作ツール群で、タブ、ナビゲーション、入力、スクリーンショット、ブックマーク、履歴、コンソール、DOM、タブグループ、ウィンドウが列挙されている。

この一覧の意味は、並べ替えて読むとはっきりする。

・ページを動かす系（ナビゲーション・入力・タブ）：クリックや入力といった、人間が手で行う操作の代替
・ページを読む系（DOM・スクリーンショット・コンソール）：エージェントが「いま何が表示されているか」を判断する材料。コンソールが入っているのは、JavaScriptエラーを含めた状態把握ができるということ
・ブラウザの持ち物にアクセスする系（ブックマーク・履歴）：拡張機能でも権限次第で触れるが、エージェントの標準ツールとして最初から使える
・作業領域を整える系（タブグループ・ウィンドウ）：複数タスクを並行させたときの整理に効く

拡張機能との差が出るのは3番目と4番目だ。READMEが「拡張はエージェントがネイティブに使う20以上の組み込みツールを同梱できない」と書いているのは、この層をブラウザ本体側に置けるかどうかの話をしている。ブラウザの持ち物と作業領域そのものをツールとして扱えるかは、フォークだからこそ取れた設計だと言える。

なお「40以上のアプリ連携」（Gmail・Slack・GitHub・Linear・Notionなど）はこれとは別の層で、外部サービスとの接続にあたる。ブラウザ操作ツールが「画面をどう触るか」を担い、アプリ連携が「どのサービスのデータに届くか」を担う二層構成になっている。

定期タスクという機能が意味するもの

機能一覧の中で、ブラウザとして異質なのが定期タスクだ。「時間単位・分単位でエージェントを回す」という機能は、ブラウザというより常駐エージェントの領域にある。裏を返せば、ブラウザを開いている間はそのタスクが動き続け、モデルの呼び出しが継続的に発生するということでもある。クラウドモデルのAPIキーを設定している場合、この機能の使い方が費用に直結する。公式ドキュメントは頻度の設定方法を示しているが、費用の見積もりまでは扱っていないので、自分で監視する前提で使うのが安全だ。

モデルの持ち込み方は4通り｜ローカルLLMまで公式対応

BrowserOSがComet・Atlasと最も違うのがモデルの扱いだ。READMEは「Bring your own keys, use OAuth for your existing subscriptions, or run models locally」と書き、11以上のプロバイダに対応するとしている。認証方式で分けると4通りある。

READMEに掲載されている「最もよく使われる6プロバイダ」の表を、そのまま引くと以下になる。

既定がKimiである点は目を引く。設定不要で使い始められるモデルとしてMoonshot AIのKimiが組み込まれている。Kimi系モデルの設計思想については Kimi K2.6解説｜6エージェントのスウォームで長時間タスクを回すオープンウェイトモデル で扱っている。

ローカル運用が公式サポート対象になっている点は、AIブラウザというカテゴリでは珍しい。リポジトリのtopicsにも ollama と lmstudio が入っている。ただし「動く」ことと「実用になる」ことは別問題だ。ブラウザ操作エージェントはページ構造の読み取りと多段の手順計画を同時に要求されるため、モデルの能力差が結果に出やすい領域だ。公式ドキュメントもローカルモデルを選択肢として提示するのみで、精度については何も約束していない。既定のクラウドモデルで挙動を把握したうえで、同じタスクがローカルモデルで再現できるかを自分で確かめる順序が現実的だろう。

ターミナルとClaude Codeから動かす｜browseros-cli と MCPサーバー

BrowserOSは「人が使うブラウザ」だが、開発者向けの入口も用意されている。Go製のCLI browseros-cli（別名 bos）と、MCPサーバー機能だ。CLIはBrowserOSのMCPサーバーに JSON-RPC 2.0 / StreamableHTTP で接続し、主要な自動化ツールをコマンドに割り当てる。

インストールは公式のスクリプト経由だ。

# macOS / Linux
curl -fsSL https://cdn.browseros.com/cli/install.sh | bash

# Windows（PowerShell）
irm https://cdn.browseros.com/cli/install.ps1 | iex

ソースからビルドする場合は Go 1.25 以降が必要で、packages/browseros-agent/apps/cli で make を叩く。

make            # バイナリをビルド
make install    # $GOPATH/bin へインストール

接続の初期設定と疎通確認までの流れは、CLIのREADMEに次の順序で示されている。

# BrowserOSが起動していない場合は先に立ち上げる（サーバー待機まで面倒を見る）
browseros-cli launch

# BrowserOSの設定画面に表示されるサーバーURLを渡す
browseros-cli init http://127.0.0.1:9000/mcp

# 疎通確認
browseros-cli health

エージェントに操作させる場合の作法として、READMEは「open か tabs でページIDを取得し、以降は -p で明示的に渡す」ことを推奨している。またCLI自身が browseros-cli --llm-txt でエージェント向けのガイドを出力でき、これはバイナリから印字されるためインストール済みバージョンと必ず一致する、という設計になっている。ドキュメントとバイナリのバージョンずれを避ける工夫として、素直に良い作りだ。

MCPクライアント側から見ると、BrowserOSは普通のMCPサーバーとして振る舞う。Claude CodeやCursorから接続すれば、CDP経由のブラウザ操作ツール群（タブ、ナビゲーション、入力、スクリーンショット、ブックマーク、履歴、コンソール、DOM、タブグループ、ウィンドウなど）が使える。ここは「人間用のブラウザ」でありながら「エージェント用の実行環境」としても顔を出す部分で、前述のBrowserClawとの境界が少し滲む領域でもある。

図のとおり、人間の指示・MCPクライアント・CLIという3つの入口が同じサーバーに集まり、そこからChromiumへCDPで下りていく。BrowserOSが「人間用の製品」であると同時に「エージェントの実行基盤」でもあるのは、この構造から来ている。

AGPL-3.0・プライバシー・限界｜Comet/Atlasとの構造的な違い

READMEには開発元が作った比較表が載っている。BrowserOS・Chrome・Brave・Dia・Comet・Atlas の6つを、オープンソースか、AIエージェントがあるか、MCPサーバーになるか、Cowork、定期タスク、キー持ち込み、ローカルモデル、ローカルファーストなプライバシー、MV2広告ブロックの9項目で並べたものだ。当然ながらBrowserOSが全項目に丸が付いている。

こうした自作の比較表は「事実の証明」ではなく「何を売りにしているという宣言」として読むのが正しい。ただしその中で、第三者が検証可能な項目が1つある。オープンソースかどうかだ。

・リポジトリのLICENSEは AGPL-3.0 の全文（FSFが公開している661行の条文そのまま）。著作権表記は Felafax, Inc.
・公開範囲にChromiumパッチとビルドシステムが含まれる。packages/browseros/chromium_patches/ と packages/browseros/build/ があり、C++が約956KB・Pythonが約1.3MB計上されている
・つまり配布バイナリを信用しない場合でも、原理的には自分でビルドして同じものを作れる建付けになっている（ただし前述のとおり約100GBのディスクが必要）

この点は、似た領域のプロジェクトと比べると差がはっきりする。たとえば ego lite はリポジトリがMITだが、README自身が「MITなのはリポジトリの内容で、ブラウザ本体は別配布」と明記している。BrowserOSは逆に、ライセンスがより強いAGPL-3.0である代わりに、ブラウザ本体を作るための材料がリポジトリに入っている。「ライセンス名の緩さ」と「公開されている範囲の広さ」は別の軸だという良い例だ。

プライバシーの主張はどこまで確認できるか

「Local-only」「Your data stays yours」といった主張のうち、公開情報から確認できる範囲と、そうでない範囲を分けておく。

BrowserClaw側については、READMEが具体的に踏み込んでいる。セッション・スクリーンショット・履歴・設定は ~/.browserclaw/ 配下に置かれアップロードされない、一方で匿名の製品利用イベント（エージェントの接続と切断、バージョン、OS）は送信され、URL・ページ内容・プロンプト・ツール結果・スクリーンショットは送らない、設定のトグル1つで無効化できる——とある。ここまで書いてあるのは good practice だ。

BrowserOS側については、READMEは「runs on your machine with your AI keys」というレベルの記述で、テレメトリの具体的な項目までは同じ粒度で書かれていない。またクラウドモデルのAPIキーを設定した場合、当然ながらそのプロバイダにはリクエストが飛ぶ。「ローカルで完結する」と言えるのはOllamaやLM Studioを選んだ場合の話だ。プライバシーを理由に検討しているなら、この区別を押さえておく必要がある。

導入前に見ておきたい限界

公開情報から読み取れる注意点を挙げる。

・モデル費用は自己負担：本体は無料でもクラウドモデルを使えばAPI課金が発生する。定期タスクを短い間隔で回すと積み上がる
・ローカルモデルの精度は保証されていない：公式は選択肢として提示するのみ。ブラウザ操作は多段の手順計画を要求するため、小さいモデルでは途中で崩れやすい
・Chromiumフォークの追従リスク：上流の変更に追い続ける必要がある。特にMV2サポートは上流の動向次第で維持コストが上がる
・内部構成が動いている：直近2週間でREADMEの製品構成の書き換え（2026-07-13）、BrowserClawサーバーのRust移行（2026-07-21）、ツール数の記述修正（2026-07-22）が入っている。nightlyビルドも日次で出ており、機能の細部は流動的
・エージェントにログイン済みブラウザを触らせること自体のリスク：これはBrowserOSに限らない話だが、閲覧するページの内容によってはプロンプトインジェクションの経路になりうる。任せるアカウントの範囲は自分で決める必要がある

結局どういう人に噛み合うのか

読者の判断材料として、3つの軸で整理しておく。

このOSSは何ができるか：日常のブラウザとして使いながら、ページの要約・調査・操作代行・データ抽出・定期実行をエージェントに任せられる。加えて自分自身をMCPサーバーとして公開し、Claude CodeやCursorからも操作できる。

何を解決するか：AIブラウザを使うためにベンダーのクラウドへサインインし、閲覧内容とプロンプトを預けるという前提を外す。モデルの選択権とデータの通り道を利用者側に戻す。

何を代替できるか：Perplexity Comet・ChatGPT Atlas・Dia といった商用AIブラウザの位置に置ける。ただし代替できるのは「AIブラウザという製品カテゴリ」であって、それぞれの独自機能や仕上がりが同じという意味ではない。逆に、CIで回したい・サーバー上のLinuxでヘッドレス実行したいといった用途は、そもそもこの製品の担当範囲ではない。そこはライブラリ型（browser-use など）の領分だ。

エージェント内蔵のブラウザという形が定着するのか、それとも既存ブラウザの機能に吸収されるのかは、まだ決まっていない。ただ「Chromiumをフォークしてエージェントを組み込み、モデルは利用者に選ばせ、パッチまで含めてAGPL-3.0で公開する」という構成が実際に動いて12,755スターを集めている事実は、この領域の選択肢を1つ増やしている。

参照ソース

・browseros-ai/BrowserOS（公式リポジトリ・README） — 製品構成・機能一覧・LLMプロバイダ表・比較表・FAQ・アーキテクチャ。2026-07-27 参照
・browseros-cli README — CLIのインストール手順・init/health・エージェント向けの操作作法。2026-07-27 参照
・BrowserOS Agent モノレポREADME — サーバー構成とポート、CDP接続の向き。2026-07-27 参照
・LICENSE（GNU Affero General Public License v3.0） — 条文全文。2026-07-27 参照
・BrowserOS 公式ドキュメント — 機能別ドキュメントおよび比較ページ。2026-07-27 参照
・ungoogled-chromium — READMEのCreditsで一部パッチの取り込み元として挙げられているプロジェクト