ego lite とは｜AIエージェントにログイン状態を渡すブラウザの使い方・無料の範囲・macOS制約

AIエージェントにWebを触らせようとすると、たいてい同じ壁に当たる。ログインが必要なページで止まるのだ。ego lite（citrolabs/ego-lite）は、この問題に対して「ライブラリを配る」のではなく「ブラウザ本体を配る」という答えを出したプロジェクトで、2026年4月の公開から約3か月半でGitHubスターは約5,970に達している。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月30日時点でスター約5,970・フォーク296、直近の正式リリースは7月17日の v1.2.5、mainのコミットは7月27日まで続いている。3か月半で約6,000スターという伸び方と、Trendshiftのバッジがリポジトリ冒頭に貼られている点から、英語圏では一定の注目を集めていると見てよい。

伸び方の実感としては、当サイトが最初にこの記事を出した7月25日時点のスターが約2,650だったので、5日で倍以上になっている。PR番号の進み方も速く、7月17日の v1.2.5 リリースノートに含まれるPRが #71 前後だったのに対し、7月27日のコミットは #164 のマージである。10日で90本超のPRが流れており、コードもドキュメントも動いている最中のプロジェクトだと見ておいたほうがよい。この「動いている最中」であることが後述するスキル定義の食い違いにもつながっている。

ここで押さえておきたいのが、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/ にソースがあり、公式サイトは駆動できるエージェントとして Claude Code・Codex・Cursor・Kiro・Hermes Agent・OpenClaw と「コードを書ける他のエージェント全般」を挙げている
・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の料金は無料か：READMEの「Zero cost」とToSの条項を突き合わせる

「オープンソースか」とは別に、「無料か」という質問がある。ego liteはここで公式の書きぶりに温度差があるので、両方を並べておく。

まず現時点の実態としては無料だ。公式サイトのダウンロードボタンは「Download for Mac (yes, free)」と、わざわざ括弧で無料であることを補足している。GitHubのリポジトリ説明文も Zero cost, zero config. で、READMEの比較表では「Free」の行にego lite・browser-use・agent-browserの3つにチェックが入り、ChatGPT Atlas・Perplexity Cometには入っていない。実際に本体の .dmg は cdn.ego.app からアカウント登録も支払い情報の入力もなしに取得でき、lite.ego.app に ego lite の価格ページは存在しない（/pricing は404を返す）。

一方で、本体の利用条件を定める公式Terms of Service（最終更新2026年5月25日）を読むと、無償前提とは読めない条項が並んでいる。

・ライセンス付与の条項は「本規約および適用される料金の支払いを条件として（Subject to these Terms and payment of any applicable fees）」という書き出しで始まる
・「これらの料金および税金の支払いを怠ると、有料サービスへのアクセスが終了する場合がある」
・サブスクリプションの購入、支払い方法の保存と継続課金、上位プランへのアップグレード／ダウングレード、決済代行事業者（Payment Service Providers）への支払い情報の提供——といった有料前提の記述がひとまとまりで置かれている
・そして料金条項の末尾に、こう書かれている。「当社は無料プランを提供する場合があるが、その義務を負わない（We may, but are not obligated to, provide a free Plan.）」
・加えて「無料プランの利益を得るために複数のアカウントを作成してはならない」「無料プランを誠実に利用していないと当社が判断した場合、サービスへのアクセス提供を停止することがある」という制限も付く

この読み方を補強する材料が公式サイト側にある。トップページとロードマップの見出しは「ego (lite) is just a browser, ego is your personal agent across devices」となっており、ego lite とは別に ego という製品が待機リスト（Join waitlist）付きで置かれている。グローバルナビには Enterprise の項目もあり、こちらはページが実在する。つまり商用のレイヤーは別に用意されている構造で、ego liteはその手前に置かれた無償クライアントという位置づけになる。ego lite自体が課金対象になると公表されているわけではないが、事業としての収益源が別にあることは公開情報から読み取れる。

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でページを開き、スナップショットを読み、操作して結果を返す。

ego liteのインストールでつまずく箇所と対処：PATH・Gatekeeper・対応OS

同梱の references/install.md には公式のトラブルシューティング節があり、実際に詰まりやすい箇所がそのまま列挙されている。ここは推測せずに公式記述と scripts/install.sh の実装をそのまま整理しておく。

PATH起因かどうかは、この2行で切り分けられる。

command -v ego-browser || export PATH="$HOME/.local/bin:$PATH"
command -v ego-browser && node -v   # コネクタの engines は node >=22

node -v を併記しているのは、コネクタの package/ego-browser/package.json が engines で node >=22 を要求しているためだ。なお同梱のSKILL.mdは、エージェントに対して事前チェックをするなと指示している点が面白い。「ユーザーが明示的にego-browserを使えと言った場合は、ego-browser もリポジトリのランタイムも準備済みだと仮定せよ。which ego-browser や node -v、パッケージのメタデータやhelp出力を先回りして確認するな。最初の実行がエラーを返したときだけ環境を調べよ」という趣旨である。往復回数を削るという設計思想が、環境チェックの扱いにも一貫している。

もうひとつ、エラーに見えるが対処してはいけないものがある。ユーザーがブラウザの操作権を握っている状態でエージェントが操作しようとすると、コネクタは「user is controlling」という趣旨のエラーを返す。SKILL.mdはこれを「回避すべき障害ではなくハードストップ（hard stop）」と定義し、リトライも自力での操作権奪取も禁じている。同様に「inactive」「エージェントに割り当てられていない」系のtask spaceエラーも同じ扱いだ。ログが赤くなっていてもツールの不具合ではなく、設計どおりの停止であることがある。

ego-browserスキルとコネクタのAPI表記のズレを確認する

ここは2026年7月末時点でいちばん引っかかりやすい箇所なので、独立した節にしておく。同梱スキルが案内するAPI表記と、コネクタが実際に公開している表記が食い違っている。

経緯はリポジトリの履歴から追える。6月末から7月上旬にかけて、ego-browser はPlaywright風の名前空間型APIへ寄せる作業が続いていた（refactor(ego-browser): continue Playwright helper alignment・Improve Playwright-style ego-browser helpers など）。ところが2026年7月25日、PR #147「Restore v1.2.3 SKILL.md text」がマージされ、skills/ego-browser/SKILL.md の本文だけが v1.2.3-beta.5 のテキストへ差し戻された（150行追加・141行削除）。PR本文は差し戻しの方針をこう書いている——「現在の 1.2.6 のメタデータと 2026-07-20 の日付は、バージョニングを前進させるために維持する」。

結果として、参照先によって案内される表記が変わる状態になっている。

対応関係は概ね1対1で、名前の付け方が違うだけだ。

手元のスキルがどちらの表記かは、この手順で確認できる。

# 1. 手元の ego-browser スキルの実体を探す（エージェントごとにスキルディレクトリが異なる）
find ~/.claude ~/.codex ~/.cursor -name SKILL.md -path '*ego-browser*' 2>/dev/null

# 2. 見つかったパスを S に入れて、どちらの表記かを数える
S="$HOME/.claude/skills/ego-browser/SKILL.md"
grep -c 'taskSpaces\.useOrCreate' "$S"   # 1以上なら 名前空間型
grep -c 'useOrCreateTaskSpace'   "$S"    # 1以上なら フラット型（差し戻し後のテキスト）
grep -n 'version:' "$S"                  # 差し戻し後も 1.2.6 のまま

コネクタ側が実際にどちらを公開しているかは、ego liteをインストール済みなら次のスクリプトで直接確かめられる。リポジトリ同梱のe2eテストの記述からは、名前空間型が入っていて旧フラットグローバルは入っていない——つまり function / undefined / undefined が出る——ことが期待値として読み取れる。

ego-browser nodejs <<'EOF'
console.log('taskSpaces.useOrCreate :', typeof taskSpaces?.useOrCreate)
console.log('useOrCreateTaskSpace   :', typeof globalThis.useOrCreateTaskSpace)
console.log('click (旧フラット)      :', typeof globalThis.click)
EOF

タイムアウトの単位にも同じ食い違いがある。差し戻し後のSKILL.mdは「wait(...) と timeout の値は秒で、末尾が Ms のパラメータだけがミリ秒」という一律のルールを書いている。ところがコネクタのソースを見ると、単位はヘルパーによって分かれている。src/driver/waits.ts は「timeout・pollingはミリ秒」と注記し、コードも options.timeout ?? 10000 をそのままミリ秒として扱う。src/driver/nav.ts も「timeout と settle はミリ秒」と明記する。一方 waitForAgentControl は「interval・timeoutは秒（既定20秒／600秒）」で、実装も timeout * 1000 と秒からミリ秒へ変換している。

つまり一律のルールとしては成立していない。実務上の危険は数字を取り違えたときの桁だ。ミリ秒前提で timeout: 20000 と書いた値が秒として解釈されれば約5.5時間、逆に秒前提の timeout: 20 がミリ秒として解釈されれば20ミリ秒になる。どちらも「なぜか止まる／なぜか即座に失敗する」という形で現れる。呼ぶヘルパーごとに、SKILL.mdの一律ルールではなく該当ソースの注記を確認するのが確実だ。

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

制約面も整理しておく。

公開ロードマップの現在の項目は7件で、Reusable Skills / Browser ACP That Hosts Any Harness Agent / ブラウザ操作ツールの追加強化 / Side Tab Pane の4件が「In progress」、Electron・ネイティブアプリ操作 / Windows・Linux対応 / Refined Space Interaction の3件が「Planned」となっている。エージェント側の接続方式（ACP）にまで手を伸ばそうとしている点は、コネクタ1本で外部エージェントを受けるという現在の形から広げる意図に見える。

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

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

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

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

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

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

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

・LinuxサーバーやCIで回したい（macOS専用）
・ブラウザ本体のソースを監査したい、あるいはフォーク可能性を要件にしている
・自分のアプリケーションのコードにライブラリとして組み込みたい
・無料であることが契約上の前提になっている（ToSは無料プランの提供を義務としていない）
・APIが固まっていることを重視する（同梱スキルとコネクタの表記が現在食い違っている）

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

参照ソース

・citrolabs/ego-lite（公式リポジトリ・README） — 機能一覧、競合比較表、ベンチマーク図、ライセンス表記。2026-07-30参照
・ego lite 公式サイト（lite.ego.app） — 「Download for Mac (yes, free)」表記、駆動できるエージェントの一覧、ego の待機リスト。2026-07-30参照
・ego lite 公式ドキュメント（lite.ego.app/document/） — チュートリアル、ツールリファレンス、連携ガイド。2026-07-30参照
・ego lite 公開ロードマップ — In progress 4件・Planned 3件の内訳（Windows/Linux対応・Reusable Skills・Browser ACP等）。2026-07-30参照
・ego lite Terms of Service — CITRO LABS PTE. LIMITED による利用条件（最終更新2026-05-25）。第3条のライセンス付与条項と料金・無料プランに関する条項。2026-07-30参照
・PR #147「Restore v1.2.3 SKILL.md text」 — SKILL.md本文を v1.2.3-beta.5 へ差し戻し、1.2.6 のメタデータと 2026-07-20 の日付を維持した旨のPR記述（2026-07-25マージ）。2026-07-30参照
・package/ego-browser/scripts/real-browser-e2e/cases/helper-surface.mjs — コネクタの公開面e2eテスト。名前空間型ファサードの存在と、旧フラットグローバル非公開のassert。2026-07-30参照
・skills/ego-browser/SKILL.md・skills/ego-browser/references/install.md・package/ego-browser/src/（helpers.ts / driver/waits.ts / driver/nav.ts / ego-errors.ts・リポジトリ同梱） — 実行モデル、Space所有権、インストール手順、タイムアウトの単位、実行時エラー文の一次記述。2026-07-30参照
・GitHub REST API（/repos/citrolabs/ego-lite・/contributors・/releases・/commits・/pulls） — スター数5,971、フォーク296、コントリビューター5名、v1.2.5（2026-07-17）、main最終コミット2026-07-27等の実測値。2026-07-30取得（公開当初は2,654スター・フォーク125）