ego lite解説｜AIエージェントに自分のログイン状態を渡すブラウザをbrowser-useと比較

AIエージェントにWebを触らせようとすると、たいてい同じ壁に当たる。ログインが必要なページで止まるのだ。ego lite（citrolabs/ego-lite）は、この問題に対して「ライブラリを配る」のではなく「ブラウザ本体を配る」という答えを出したプロジェクトで、2026年4月の公開から約3か月でGitHubスターは約2,650に達している。Claude CodeやCodexといった手元のエージェントCLIから、自分がログイン済みのブラウザをそのまま操作させることを狙っている。

AIエージェントの実行基盤としてどんな選択肢があるかを俯瞰したい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 が全体地図になる。本記事はその地図のうち「ブラウザという実行環境をどう与えるか」の一角を、ego liteという具体例で掘り下げるものだ。

ego liteとは：AIエージェントに「ブラウザ本体」を渡すという設計

ego liteを一言でいえば、AIエージェントと人間が並行して使うことを前提に設計されたChromiumベースのブラウザである。開発元はシンガポール法人のCITRO LABS PTE. LIMITED。GitHubリポジトリ citrolabs/ego-lite は2026年4月16日に作成され、2026年7月25日時点でスター約2,650・フォーク125、直近のリリースは7月17日の v1.2.5、コミットは7月24日まで続いている。3か月で2,600スターという伸び方と、Trendshiftのバッジがリポジトリ冒頭に貼られている点から、英語圏では一定の注目を集めていると見てよい。

ここで押さえておきたいのが、ego liteは「フレームワーク」ではないという点だ。READMEは自らの立ち位置をこう説明している。browser-useやagent-browserは「ブラウザ自動化フレームワーク」であり、駆動対象となるブラウザを別に用意する必要がある。そのためログイン状態がきれいに引き継がれず、人間とエージェントが同じタブを取り合うことになる——ego liteは最初から両者が共有する前提の「1つのブラウザ」として設計されている、というものだ。

この違いは抽象論ではなく、実際に手を動かすときの手触りに直結する。ライブラリ型では「どのブラウザを、どのプロファイルで、どう起動するか」を自分で決める必要があり、ログイン状態を持ち込むならCookieやストレージの受け渡しを自分で設計することになる。ego liteはその層ごと製品として引き受けているので、ユーザーがやるのはアプリのインストールと初回オンボーディングだけになる。

構成要素は大きく3つに分かれる。

・ego lite本体：Chromiumベースのブラウザアプリ（macOS用 .dmg）。Space（後述）の管理や、エージェントに渡すページのスナップショット生成を担う
・ego-browser：エージェントCLIとego lite本体をつなぐコネクタ。TypeScriptで書かれ、CDP（Chrome DevTools Protocol）経由でブラウザを操作する。リポジトリの package/ego-browser/ にソースがある
・ego-browser スキル：Claude Code・Codexなどが読み込むスキル定義（skills/ego-browser/SKILL.md）。エージェントに「どう使うべきか」を教える指示書にあたる

リポジトリを実際に開くと、この3番目が想像以上に作り込まれていることがわかる。skills/ego-browser/ 配下には、サイトごとの操作ノウハウを蓄えた learnings/ ディレクトリがあり、現時点ではGoogleとX（x-com）の2サイトぶんが入っている。X向けには投稿抽出（extract-post.js）・タイムライン取得（timeline.js）・ユーザー検索（search-users.js）といったスクリプトと、タイムラインの挙動を書いたノートが同梱されている。これは「エージェントが毎回ゼロからページ構造を探る」のを避けるための作り置きで、READMEが coming soon として挙げている「経験の蓄積」機能の土台にあたる部分だ。

なお、この経験蓄積による高速化（READMEでは同種タスクが最大5倍速くなるとされる）はまだ提供されていない機能として明記されている。公開ロードマップ上も「Reusable Skills」は In progress の段階にある。現時点で評価できるのは、あくまで手動で置かれた learnings/ の中身までだ。

MITなのはどこまでか：ego liteのライセンスと配布形態を正確に読む

ego liteを紹介する際に最も誤解されやすいのがライセンスの範囲である。GitHubのリポジトリ表示は「MIT License」となっており、これだけを見れば「オープンソースのブラウザ」に見える。だがREADMEの末尾には、はっきりとこう書かれている——このリポジトリの内容はMITライセンスで公開されており、ego liteブラウザは別個の無償ダウンロードである、と。

実際にリポジトリのファイル一覧を確認すると、この線引きは明確だ。含まれているのは package/ego-browser/（コネクタのTypeScriptソースとテスト）、skills/ego-browser/（スキル定義・learnings・インストールスクリプト）、spec/agent-skills-spec.md、各種ドキュメントとCI設定である。Chromiumを改変したブラウザ本体のソースコードは含まれていない。本体はREADMEのバッジから cdn.ego.app 上の .dmg を直接ダウンロードする形になっており、ビルド手順も置かれていない。

では本体の利用条件はどうなるのか。公式サイトのTerms of Service（最終更新2026年5月25日）を読むと、CITRO LABS PTE. LIMITEDが利用者に対し「全世界を対象とする、限定的・非独占的・取消可能・サブライセンス不可・譲渡不可の、サービスへのアクセスおよび利用のライセンス」を付与する、という一般的なSaaS型の条項が置かれている。MITのような永続的・無制限の権利ではない。

つまり整理するとこうなる。

なお、この構成自体は珍しいものではない。ブラウザ製品では本体がプロプライエタリで周辺ツールだけOSS、という形はよくある。問題は、GitHubのライセンスバッジだけを見て全体がMITだと受け取ってしまうことだ。導入判断で法務確認が必要な組織ほど、ここは最初に潰しておきたい。

ego liteの仕組み：Spaceの分離と「JavaScriptを書かせる」実行モデル

ego liteが「ブラウザ本体を作る」路線を選んだ理由は、2つの仕組みに現れている。人間とエージェントの作業領域を分けるSpaceと、エージェントにコマンドでなくコードを書かせる実行モデルである。順に見ていく。

Spaceの所有権：エージェントと人間がタブを奪い合わない

ego liteの中核概念がSpace（タスクスペース）である。Spaceは独立したブラウジングコンテキストで、それぞれが自分のタブ群を持ち、ユーザーのログイン状態を引き継ぐ。人間は手前のSpaceで普段どおりブラウジングし、エージェントは自分のSpaceで作業する。互いのタブには干渉しない。

面白いのは、Spaceに所有権（ownership）の概念が入っていることだ。公式のSKILL.mdによれば、各Spaceは agent / agentDelegatedToUser / user のいずれかの状態を持ち、操作によって扱いが変わる。

・エージェントは taskSpaces.useOrCreate(名前) で自分のSpaceを作る、または再利用する
・taskSpaces.switch はエージェント所有のSpaceしか切り替えられない。ユーザー所有のSpaceに対して呼ぶと例外になる
・ユーザー所有のSpaceで作業したい場合は taskSpaces.claim(id) で所有権を明示的に移す必要がある
・taskSpaces.handOff で人間に作業を引き渡せる。ログインや二段階認証など、人間がやるべき操作を戻す用途にあたる

この設計から読み取れるのは、「エージェントが暴走して人間の作業領域を触る」ことを構造的に防ぎたい、という意図だ。SKILL.mdには、対象のSpaceがユーザー所有だった場合は選択するだけで操作は止まり、ユーザーの明示的な確認を得てからclaimに進むこと、という指示まで書かれている。エージェント側のプロンプトで行儀を期待するのでなく、ブラウザ側で境界を作っている点が、この製品が「ブラウザ本体を作る」路線を選んだ理由のひとつだろう。

もうひとつのポイントが並列性だ。Spaceは複数を同時に走らせられるため、READMEは「Claude Codeが10件のリードを10個のSpaceで並行処理し、その裏でCodexが5サイトを別のSpaceで巡回する」といった使い方を挙げている。人間のマウス位置もタブも影響を受けない、というのが売り文句だ。ここは実機で回していないため断定はできないが、Spaceがブラウジングコンテキストとして分離されている以上、設計上は妥当な主張に見える。

Spaceのライフサイクルは、SKILL.mdでかなり厳密に規定されている。1つのユーザー目的につき1つのSpaceを useOrCreate で開始し、その task.id を保持したまま作業を続け、目的が達成されたと確認できてから初めて taskSpaces.complete(...) を呼ぶ。しかも「まだ達成判定の途中にある実行の中でcompleteを呼んではならない」「部分的な結果や、リトライを使い切った状態、フォールバックの試行は完了の証拠にならない」と、完了判定を甘くしないための条件が並ぶ。エージェントが「たぶんできた」で作業を閉じる失敗パターンを、スキル側で潰しにいっている。

なぜCLIでなくJavaScriptを書かせるのか

ego liteが技術的に最も主張している点が、エージェントにCLIコマンドを叩かせるのでなくJavaScriptを書かせるという実行モデルだ。READMEはこれを「Code base, not CLI base」と表現している。

一般的なブラウザ操作ツールでは、エージェントは「ページを開く」「スナップショットを取る」「ボタンをクリックする」を個別のツール呼び出しとして実行する。1操作ごとに結果がコンテキストへ戻り、それを読んで次の操作を決める。手順が10あれば10往復し、そのたびにページのスナップショットがコンテキストへ積まれていく。

ego-browserは、ブラウザの機能をJavaScriptの関数として公開する。エージェントは次のように、ヒアドキュメントでスクリプトを丸ごと流し込む。

ego-browser nodejs <<'EOF'
const task = await taskSpaces.useOrCreate('inspect example page')
await browser.openOrReuseTab('https://example.com', { wait: true, timeout: 20000 })

const heading = await page.getByRole('heading').first().innerText()
const info = await page.info()
if (!heading || !('url' in info)) throw new Error('Example page was not ready')

console.log(JSON.stringify({ taskSpaceId: task.id, heading, url: info.url }, null, 2))
EOF

APIの見た目はPlaywrightに寄せてある。page.locator(...)・page.getByRole(...)・page.waitForResponse(...) といった呼び名と形がそのまま使えるため、Playwrightを書いたことがあれば読める。そのうえで taskSpaces・site・fetch・cdp がego lite固有の機能として足されている。

SKILL.mdの指示で重要なのは、「ヒアドキュメントはJavaScriptの入れ物にすぎず、実行の単位はBash呼び出しのほうだ」と明言している点だ。1つの await は内部の1操作であって、ステップの区切りではない。したがってブラウザ作業は原則として1回のBash呼び出しで完結させる。途中結果を眺めるためだけに実行を打ち切るな、とまで書かれている。抽出→選択→クリック→検証→後片付けを1本のスクリプトに収め、外に出るのは最終結果の console.log だけ、という設計思想だ。

この方式が効くのは、往復のたびに発生するコストが消えるからだ。中間のスナップショットはスクリプト内の変数として消費され、LLMのコンテキストには載らない。分岐やリトライもJavaScriptの制御構文で書けるので、判断のためにモデルを呼び戻す必要がない。

一方で、この設計にはトレードオフもある。エージェントは実行前に手順を予測して書き切る必要があるため、ページ構造が想定と違ったときはスクリプトごと失敗する。SKILL.mdがタイムアウト値の扱い（waitFor* 系はタイムアウト時にfalsy値を返すので必ず結果を確認しろ）や、失敗時の方針（同じようなセレクタを繰り返すな、1回の観察で戦略を変えろ）を細かく規定しているのは、この失敗モードを織り込んでいるからだろう。ライブラリ型のツールと比べて、うまく動くかどうかがスキル定義の質に強く依存する構造になっている。

導入手順：npx skills add から最初のブラウザタスクまで

導入経路は3つ用意されている。いずれも最終的には「ego lite本体のインストール」と「ego-browser スキルの配置」の両方が必要になる。

経路1：スキルだけ先に入れる。エージェントのスキルディレクトリに ego-browser を追加する。

npx skills add citrolabs/ego-lite

この状態で最初にブラウザタスクを投げると、エージェントがego lite本体のインストール手順へ案内する流れになる。

経路2：macOSアプリを先に入れる。README冒頭のバッジ（Apple Silicon / Intel）から .dmg をダウンロードして開く。公式の説明では、アプリのインストール時にマシン上の各エージェントのスキルディレクトリへ ego-browser スキルが追加される。

経路3：エージェント自身にやらせる。リポジトリに同梱された skills/ego-browser/references/install.md を読ませて実行させる。スクリプトの実体は次のとおりで、CPUアーキテクチャに応じた .dmg を取得し、/Applications（不可なら ~/Applications）へ配置し、Gatekeeper対策のquarantine属性を外してからアプリを起動する。

sh skills/ego-browser/scripts/install.sh

どの経路でも、最後はアプリ側の初回オンボーディングを人間が完了させる必要がある。ここでChromeなど既存ブラウザのデータを取り込むかを聞かれ、取り込むを選ぶとエージェントは既存のログイン・Cookie・拡張機能・ブックマークを引き継ぐことになる。オンボーディングは同時に ego-browser コマンドをPATH（通常は ~/.local/bin）に登録する。

導入後の確認はこの2つで足りる。コマンドが見えない場合はPATHが通っていないことがほとんどで、~/.local/bin を追加すれば解決する。

command -v ego-browser
export PATH="$HOME/.local/bin:$PATH"   # 見つからない場合

ego-browser nodejs <<'EOF'
console.log('ego-browser ready')
EOF

ego-browser ready が出れば実行環境は整っている。あとはエージェントCLIで /ego-browser に続けて日本語なり英語なりで用件を書けばよい。READMEの例は「ego-browser follow @ego_agent on x.com for me」というもので、エージェントはスキルを読み、自分のSpaceでページを開き、スナップショットを読み、操作して結果を返す。

browser-use・agent-browserとの住み分けと、公式ベンチマークの読み方

ここが実務上いちばん知りたいところだろう。READMEにも競合比較表が載っているが、これは開発元が自社製品と他社製品を採点したもので、競合側の列はほぼ全項目が「—」になっている。そのまま鵜呑みにするのは避けたい。

そこで、公開情報から誰でも確認できる軸だけで整理し直したのが次の表である。優劣ではなく性質の違いとして読んでほしい。

この表から言えるのは、3つは競合というより層が違うということだ。

・ライブラリ型（browser-use・agent-browser）：自分のコードに組み込む。CIやサーバー上のLinuxで回せる。ブラウザの選択と状態管理は自分の責任範囲。当サイトでは Browser-Useの使い方｜AIに実ブラウザを操作させるOSSの仕組み・導入・他ツール比較【2026】 と agent-browser入門：VercelがOSS公開したAIエージェント向けRust製ブラウザ自動化CLI でそれぞれ扱っている
・ブラウザ本体型（ego lite）：手元のmacOSで、自分のログイン状態ごとエージェントに渡す。外部のエージェントCLIから駆動できる
・AIブラウザ型（Atlas・Comet）：エージェントが製品に組み込まれている。日常のブラウザとして使えるが、自分のClaude CodeやCodexから駆動する用途ではない

選び方はシンプルで、「サーバーで回すのか、手元で回すのか」と「どのエージェントに操作させたいのか」の2軸でほぼ決まる。CIに載せたい、Linuxで動かしたい、コードの一部として書きたい——ならライブラリ型。自分がログイン済みのサービスを、自分が普段使っているエージェントCLIに触らせたい——ならego liteの発想が噛み合う。エージェント用の隔離環境そのものが欲しい場合は、neko徹底解説｜Dockerで動くWebRTC仮想ブラウザをAIエージェントの隔離環境に で扱ったコンテナ型の仮想ブラウザという第4の選択肢もある。

公式ベンチマークをどう読むか：自己申告値の扱い

READMEは、Vercelのagent-browserとの比較ベンチマークを掲載している。数字が具体的なので、条件を明示したうえで紹介する。

図に記載された条件は、同一モデル（gpt-5.5・medium effort・エージェントは pi）で4つのWebタスクを実行し、各5回の中央値を取る、というものだ。結果は次のように示されている。

読むときに注意したい点を挙げておく。

・開発元が自社製品について公表した値であり、第三者による再現検証ではない。数値そのものより「どういう条件で測ったか」を明示している点を評価すべきものだ
・比較対象は1製品（agent-browser）のみ。browser-useや他のアプローチとの比較ではない
・4件目は速度差ではない。agent-browser側がボット検知でブロックされたため、そもそも比較が成立していない。「4タスクすべてで勝った」と読むと実態からずれる
・n=5の中央値であり、Webサイト側の状態変動を考えると幅は小さくない
・READMEの本文は「最大2.5倍高速」と書いているが、図の最大値は2.6倍で、わずかに表記が揺れている

そのうえで、方向性としては実行モデルから説明がつく数字ではある。往復回数が減ればトークンも待ち時間も減る、というのは前述のとおり構造的な話であり、複雑なタスクほど差が開くという主張とも整合する。ただし「どの程度の差が自分のタスクで出るか」は、対象サイトの構造とスキル定義の当たり外れに左右されるはずで、この4件の数字をそのまま自分の環境に当てはめるのは無理がある。

なお、READMEには「市場で最も強力なページスナップショット」といった性能を断定する表現も含まれるが、これは比較可能な形で検証された主張ではないため、本記事では紹介にとどめる。深くネストしたiframeの扱いに強い、という具体的な記述については、確かにブラウザ本体を作っている以上、外部からCDPだけで操作するアプローチより手を入れられる余地は大きいだろう、という程度に読んでおくのが妥当だ。

ログイン状態を渡すことの意味と、現時点の制約

ego liteの利便性は「自分のログイン状態をエージェントが使える」ことから来ている。そしてリスクも同じ場所から来る。ここは製品の欠陥ではなく、この設計を選んだ以上避けられない性質として理解しておきたい。

初回オンボーディングでChromeデータの移行に同意すると、エージェントのSpaceはあなたがログイン済みのサービスに到達できる状態になる。メール、SNS、社内ツール、クラウドコンソール——移行したプロファイルに入っているものが対象だ。ego lite側の緩和策として、前述のSpace所有権モデルがある。エージェントは自分のSpaceでしか自由に動けず、ユーザー所有のSpaceへは claim という明示的な操作なしには入れない。SKILL.mdもユーザーの確認を取ってからclaimに進むよう指示している。

一方で、次の点は利用者側の判断に委ねられている。

・どのプロファイルを移行するか。仕事用と個人用を分けているなら、どちらをエージェントに見せるかは初回の選択で決まる
・エージェントが開くページの内容は制御できない。Webページのテキストがそのままエージェントのコンテキストに入る以上、ページ側に仕込まれた指示文がエージェントの挙動に影響する経路（プロンプトインジェクション）は原理的に存在する。ログイン済みのブラウザでこれが起きると、影響範囲は「読める情報」だけでなく「実行できる操作」にまで及ぶ
・操作の取り消しは自動では効かない。エージェントがフォームを送信したりメッセージを投稿したりする種類のタスクでは、実行前の確認をワークフロー側で用意する必要がある

この論点はego lite固有のものではなく、ログイン状態を持つブラウザをエージェントに触らせるアプローチ全般に共通する。ただし「ログインの手間がない」ことを売りにしている以上、その裏返しとして意識しておく価値はある。実務的には、重要度の高いアカウントが入ったプロファイルを移行しない、あるいはエージェント用に別プロファイルを用意するあたりが現実的な線引きになるだろう。

制約面も整理しておく。

コントリビューターが5名という規模は、2,600スターの注目度に対して小さい。ブラウザ本体が非公開である以上、外部からの貢献はコネクタとスキル定義に限られるので、この数字自体は構造的なものでもある。裏を返せば、プロジェクトの継続性は開発元の事業判断に依存するということでもあり、業務フローに深く組み込む前に考慮しておきたい点だ。

なお本記事は、公式リポジトリ・公式ドキュメント・公開ロードマップ・Terms of Service、およびGitHub APIで取得したリポジトリの実測値をもとに構成している。ego lite本体はmacOS専用アプリのため、編集部での実行による動作確認は行っていない。掲載した数値のうちベンチマークは開発元の公表値である。

まとめ：どんなときにego liteを検討するか

ego liteは「AIエージェントにWebを触らせる」という課題に対して、ライブラリではなくブラウザ本体を配るという解き方を選んだプロジェクトだ。その結果として、ログイン状態の再利用という実務でいちばん面倒な部分が製品側に吸収されている。Spaceによる人間とエージェントの分離、所有権モデルによる境界、JavaScriptを一括実行させる実行モデルは、いずれもこの路線から自然に導かれた設計に見える。

検討する価値があるのは、次のような場合だろう。

・手元のmacOSで、自分がログイン済みのサービスをエージェントに操作させたい
・Claude CodeやCodexなど、既に使っているエージェントCLIからブラウザを駆動したい
・エージェントに作業させている間も、自分のブラウジングを止めたくない

逆に、次の条件があるなら現時点では合わない。

・LinuxサーバーやCIで回したい（macOS専用）
・ブラウザ本体のソースを監査したい、あるいはフォーク可能性を要件にしている
・自分のアプリケーションのコードにライブラリとして組み込みたい

ライブラリ型と比べて優れているという話ではなく、解いている問題が違う。サーバーサイドの自動化ならライブラリ型が引き続き適するし、手元のログイン済み環境を渡す用途ならego liteのような発想が噛み合う。ブラウザをエージェントの実行環境としてどう与えるかという問いに、選択肢がもう一つ増えたと捉えるのが実態に近い。

参照ソース

・citrolabs/ego-lite（公式リポジトリ・README） — 機能一覧、競合比較表、ベンチマーク図、ライセンス表記。2026-07-25参照
・ego lite 公式ドキュメント（lite.ego.app/document/） — チュートリアル、ツールリファレンス、連携ガイド。2026-07-25参照
・ego lite 公開ロードマップ — Windows/Linux対応・Reusable Skills等の進行状況。2026-07-25参照
・ego lite Terms of Service — CITRO LABS PTE. LIMITED による利用条件（最終更新2026-05-25）。2026-07-25参照
・skills/ego-browser/SKILL.md・skills/ego-browser/references/install.md（リポジトリ同梱） — 実行モデル、Space所有権、インストール手順の一次記述。2026-07-25参照
・GitHub REST API（/repos/citrolabs/ego-lite・/contributors・/releases） — スター数2,654、フォーク125、コントリビューター5名、v1.2.5（2026-07-17）等の実測値。2026-07-25取得