BrowserOS を採用する前に読む: 2つのブラウザ構成と AGPL-3.0 の境界

BrowserOS が解こうとしている問題は「ログイン済み状態の不在」である

README は、既存のエージェント用ブラウザの弱点を3種類に分けて説明している。第一が Playwright や agent-browser のようなヘッドレスドライバで、毎回新しい Chrome サブプロセスを起動するためログイン状態を持たない。README はこれを「CI には向くが、受信トレイを読むような実務には使えない」と表現している。第二が browser-use や browserbase に代表されるクラウドブラウザで、データセンターの IP からログインするため Twitter や LinkedIn にブロックされやすい。第三が Atlas、Comet、Dia のような特定ベンダーの AI に閉じたブラウザである。

BrowserOS の対象読者は、この3つのどれかに引っかかった人だ。具体的には、社内 CRM の更新、経費精算、メールの整理のように、認証済みセッションがなければ自動化できない作業を抱えている個人や小規模チームになる。逆に、認証不要の公開ページからデータを抜くだけのスクレイピングは、この製品の守備範囲ではない。

neo と本体は別物: リポジトリ構造から読み取れる二重構成

README は「Two browsers: one for your agents, one for you.」と書き、2つの製品を1つのリポジトリに同居させている。1つ目が BrowserOS neo で、サブタイトルは「the browser for your agents」。エージェント専用のセカンドブラウザであり、README は明示的に「NOT a Chrome replacement」と断っている。Chrome の隣に置く補助ブラウザという位置づけだ。2つ目が BrowserOS 本体で、Chromium フォークの AI ブラウザ。新しいタブにエージェントが組み込まれ、20以上の組み込みツールと40以上のアプリ連携を使うと説明されている。

リポジトリの構成もこの分離を裏づける。画像パスは `packages/browseros/resources/browserclaw/icons/` と `packages/browseros/resources/browseros/icons/` に分かれ、リリースも `ext-agent/v0.0.154.0`、`agent-server/v0.0.162`、`agent-server/v0.0.161` というように拡張とサーバーで別々のバージョン系列を持つ。つまり neo 側はエージェント拡張とローカルサーバーの組み合わせとして更新され、本体の Chromium フォークとはリリースサイクルが独立している。この分離は、本体を触らずにエージェント側だけ更新する運用を可能にする一方、両者のバージョン整合を利用者が自分で管理する必要があるということでもある。

動作の仕組み: MCP 接続、タブ分離、`~/.browserclaw/` への記録

README とドキュメントのリンクから確認できる範囲では、処理の流れは次のようになる。利用者が Claude Code、Codex、Cursor、VS Code、OpenClaw、Hermes といったハーネスを one-click connect で接続する。接続は MCP 経由で行われ、docs.browseros.com/neo/mcp にインストールボードの説明がある。エージェントにタスクを渡すと、各エージェントは専用のタブで並列に動く。利用者は新しいタブのライブダッシュボードから、どのサイトで何をしているかを眺められる。

記録の扱いも README に明記されている。セッション、スクリーンショット、履歴は `~/.browserclaw/` 配下に保存され、マシンの外に出ない。各セッションはディスク上のスクラブ可能な動画として保存され、ステップごとのアクションタイムラインと一緒に巻き戻せる。ここで注目したいのは、記録が「動画」であるという設計だ。テキストの操作ログだけでは、クリック位置や描画のタイミングが再現できない。動画として残す判断は、監査と再現性を優先した結果であり、その分だけディスクを消費する。README は容量の見積もりには触れていない。

トークン消費について README は「For the same task, BrowserOS neo consumes significantly less tokens compare to other solutions (like Claude's chrome extension, Codex browser).」と主張している。ただし具体的な数値、比較条件、測定方法は提示されていない。この点は導入前に自分で確かめるしかない。

導入手順: インストーラ、Chrome インポート、MCP 接続

README が示す手順は3段階である。まず BrowserOS neo をインストールし、Chrome からログイン情報、ブックマーク、拡張機能をワンクリックでインポートする。配布物は macOS 向けが `https://cdn.browseros.com/download/BrowserOS_neo.dmg`、Windows 向けが `https://cdn.browseros.com/download/BrowserOS_neo_installer.exe`。Linux はトピックに含まれているが、README のダウンロードボタンには macOS と Windows しか並んでいない。

次にエージェントの検出。README は「It finds your agents.」と書き、Claude Code、Codex、Cursor、VS Code、OpenClaw、Hermes を one-click で接続できるとしている。3段階目がタスクの投入で、例として「Book me the cheapest flight to London.」が挙げられている。

本体側の BrowserOS には別の導線がある。新しいタブのエージェントに要約、クリック操作、データ抽出、スケジュールタスクを頼む形で、自分の AI キーを持ち込むか、Ollama でローカル実行する。トピックには lmstudio と ollama が含まれているため、ローカル推論サーバー経由の構成が想定されていることがわかる。ただし README の抜粋には Ollama の具体的な設定キーやエンドポイントは書かれていない。ここは docs.browseros.com/neo 側を確認する必要がある。

AGPL-3.0 であることの実務的な意味

ライセンスは AGPL-3.0。GPL 系の中でもっとも義務が広い部類で、ネットワーク越しに利用者へ機能を提供する場合にもソース提供の義務が及ぶ点が GPL との違いである。BrowserOS はローカルで動くアプリなので、通常の社内利用であれば配布が発生せず、義務は生じにくい。

問題になるのは改変して再配布する場合だ。たとえば neo のエージェント拡張に独自機能を足して顧客に配る、あるいはホスト型サービスとして提供する場合、対応するソースの提供が求められる。Chromium フォークという性質上、本体側にはすでに多数のサードパーティコードが含まれている。自社の改変部分と元からある部分の切り分けを後からやるのは手間がかかるため、フォークして手を入れる予定があるなら最初から差分を管理する前提で臨むべきだ。ここに書いたのは一般的な理解であり、個別の法的判断は専門家に確認してほしい。

向かないケース: ヘッドレス CI と単一ベンダー統合

README 自身が「Not a headless driver.」と書いている。Playwright や agent-browser は毎回まっさらな Chrome を起動する。ログイン状態が不要で、再現性と並列度を重視するテストやバッチ処理では、こちらのほうが素直に動く。BrowserOS neo はログイン状態を保持することが目的なので、状態を持たないことが利点になる場面では逆に重荷になる。

クラウドブラウザとの比較も単純な優劣ではない。browserbase のようなサービスはデータセンターで動くため、手元のマシンを占有しない。ノート PC を閉じている間もタスクを走らせたいなら、クラウド側に軍配が上がる。BrowserOS neo は `127.0.0.1` で動く以上、マシンが起きている必要がある。

もうひとつの境界はハーネスの対応範囲だ。README は特定のハーネス名を列挙しているが、MCP に対応していれば何でも繋がるとは書かれていない。インストールボードに載っていないツールを使っているなら、接続できるかは事前に確認するしかない。

更新コストとリリースの刻み方

リリース一覧を見ると、`agent-server` は v0.0.161 と v0.0.162 が同じ日に出ており、`ext-agent` は v0.0.154.0 が別の日に出ている。パッチ番号が 0.0 台で、日単位で版が動く。Chromium フォークは上流のセキュリティ修正を取り込む必要があるため、本体側の追従コストはフォーク一般の水準でかかる。neo 側は拡張とローカルサーバーという比較的小さい単位で更新されるので、追従の負担は本体より軽いと見られる。

ただし、この更新速度は安定版を待つ運用と相性が悪い。バージョンを固定して検証してから展開する組織なら、どの版を基準にするかを決める必要がある。リポジトリはアーカイブされておらず、最終 push は 2026-09-09 で、同日に複数のリリースが出ている。活発に動いているという事実は確認できるが、それが安定性を意味するわけではない。

編集部の結論

導入を検討すべきなのは、ログイン済みの社内ツールや CRM、メールをエージェントに操作させたいが、認証情報をデータセンターに置けない個人や小規模チームだ。逆に、CI でヘッドレスに回したいだけの用途、Atlas や Comet のような単一ベンダー統合で足りる用途、AGPL-3.0 のソース開示義務を社内ポリシーで吸収できない組織には向かない。最初に確認すべきは、docs.browseros.com/neo/privacy に書かれた保存範囲が `~/.browserclaw/` の外に出ないこと、AGPL-3.0 の下で自社改変版を配布する予定がないこと、そして接続したいハーネスが MCP のインストールボードに載っていることの3点である。

公式情報源

1. browseros-ai/BrowserOS on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases