ego lite——エージェントと並走するブラウザを、Macでどう使い始めるか

ふむふむ。最近のAIエージェント話って、コードを書くところまではわりと上手くなってきたのに、ブラウザだけは相変わらず苦戦してませんか？

「ログインし直して」「2FAが……」「いま開いてるタブを奪われた」「Playwrightを立てたら、また別のChromeが増えた」。そんなあるある、チカちゃん的にはかなり身近です。

そこに、GitHubの週次トレンドで勢いよく上がってきたのが ego lite（リポジトリ名は citrolabs/ego-lite、公式表記は ego (lite)）。ひと言でいうと、あなたとAIエージェントが同じブラウザを分け合って並走するためのChromium系ブラウザです。執筆時点でGitHubスターは約6,100。スキル定義のバージョンは1.2.6（2026-07-20表記）。対応OSはいまのところ macOSのみ で、Windows / Linuxはロードマップ上。

以前このNotesでは、ページの中にエージェントを住まわせる Page Agent を紹介しました。今日の ego lite は置き場所が逆寄りです。ページの中ではなく、ブラウザそのものを、人間と外部エージェントの共有場にする。似て非なる入口なので、対比しながら歩いてみます。

本記事は公開情報をもとにした個人的な技術メモです。第三者ツール・AIサービス・モデルの仕様、料金、利用条件、安全性は変わる可能性があります。導入前に公式ドキュメント、ライセンス、利用規約、商用利用条件、データ送信先を確認してください。業務環境や秘密情報を含む環境では、隔離環境で検証してから利用することをおすすめします。とくに「ログイン状態をエージェントに渡す」系の道具は、便利さの裏で権限の広さがそのままリスクになります。

ego lite は何をするのか——30秒でつかむ

ego lite は、次のセットとして理解するとわかりやすいです。

1. ego lite 本体 —— 人が普通に使えるChromium系ブラウザ（無料ダウンロード）
2. ego-browser スキル / CLI —— Claude Code や Codex など、外部のエージェントCLIからそのブラウザを動かす接続層
3. Space（タスクスペース） —— エージェント専用の隔離された作業場。あなたのタブを奪わずに、ログイン状態は（設計上）引き継げる

公式が繰り返し言っている「いちばんの不便」はこれです。

• Browser-Use や Vercel の agent-browser のような 自動化フレームワークは、ブラウザ本体を別途用意しがちで、ログインがきれいに持ち越せない
• ChatGPT Atlas や Perplexity Comet のような AIブラウザは、内蔵エージェント以外が外から運転しにくい
• あなたとエージェントが同じタブを奪い合って、マウスも集中も乱される

ego lite の狙いは、その真ん中です。日常ブラウザとしての体裁を保ちつつ、外部エージェントが ego-browser 経由で運転できる。しかもエージェントは自分の Space で動き、あなたの前面タブを横取りしない、という設計。

「エージェントにブラウザを触らせたい」人向けの道具であって、「ブラウザに専用AIを同梱した製品」とは少し角度が違います。ここ、最初に押さえておくと迷子になりにくい。

Page Agent / Playwright / agent-browser と何が違うの？

ここ、いちばん誤解しやすいので一度並べます。

道具	置き場所	誰が運転するか	ログイン周り	イメージ
Page Agent	ページ内JS	ページに埋め込んだエージェント	そのページのセッション	UIに自然言語の入口を足す部品
Playwright / Puppeteer	外からブラウザを駆動	あなたのコード	別プロファイルになりがち	テスト自動化の定番
Browser-Use 等	エージェント枠＋別ブラウザ	その枠内のエージェント	持ち越しが難しいことが多い	自律ブラウザエージェント
agent-browser（Vercel）	CLIで別ブラウザを操作	外部エージェント	日常ブラウザと別になりがち	シェル経由の自動化
ego lite	人間も使うブラウザ本体	あなた＋任意の外部エージェント	Chromeデータ移行で共有を狙う	並走する日常ブラウザ

チカちゃん的には、Page Agent が「界面に言葉を足す」なら、ego lite は「机そのものを二人用にする」感覚に近いです。どっちが上、ではなく、解決したい摩擦が違う。

• 自社SaaSにコパイロットを埋め込みたい → Page Agent 寄り
• すでにログイン済みの社内管理画面を、手元のコーディングエージェントに触らせたい → ego lite 寄り

事前確認——動かす前に知っておきたいこと

• OS: 現状は macOS のみ（Windows / Linux は Planned）
• 料金: 公式は「Zero cost / free」と明記。リポジトリ本体は MIT。ただし README は「リポジトリの中身は MIT、ego lite ブラウザ本体は別配布の無料ダウンロード」と分けて書いています
• 前提となるエージェント: Claude Code、Codex、Cursor、Hermes Agent、OpenClaw、OpenCode など、「シェルを叩ける」エージェントCLIが想定
• データの話: 公式FAQは「閲覧履歴・Cookie・ログインセッション等は端末内。セットアップ時に記録するのは Chrome 移行への同意有無くらい」と説明。とはいえ、エージェント側がクラウドLLMなら、画面上の内容はプロンプト経由で外に出うる。ここは道具の問題というより運用の問題
• 権限の広さ: ログイン状態を引き継ぐ＝エージェントが「あなたとして」動ける範囲が広がる。便利と危険が同じスイッチです

インストール——3つの入り方

公式 Quick Start では、入り方が3つあります。どれも最終的には ego lite アプリ本体 が必要で、ego-browser コマンドはオンボーディング後に PATH へ載る想定です（多くの場合 ~/.local/bin）。

方法A: 公式サイトから Mac アプリを入れる（いちばん素直）

1. lite.ego.app から Mac 版をダウンロード
2. DMG を開き、アプリを Applications へ
3. 初回起動のオンボーディングで、Chrome 等からのデータ移行を選ぶかどうかを決める
4. オンボーディング完了後、ego-browser が使えるか確認

command -v ego-browser
# 見つからなければ一時的に:
export PATH="$HOME/.local/bin:$PATH"
command -v ego-browser

移行を「はい」にすると、公式説明ではタブ／ブックマーク／保存パスワード／拡張機能／Cookie・ログインセッション／プロファイルなどが持ち込まれ、エージェントがそのログイン状態を引き継げる、としています。ここは便利の核心であり、同時にいちばん慎重に扱うべき設定です。

方法B: スキルだけ先に入れる（npx）

npx skills add citrolabs/ego-lite

これは ego-browser スキルをエージェントの skills ディレクトリへ入れる経路。本体アプリがまだなら、エージェントがブラウザ作業を初めて走らせたときに、インストール案内へ誘導する流れです。

方法C: エージェントにセットアップさせる

エージェントCLIに、だいたいこんな一文を貼る公式パターンがあります。

Set up ego lite for me: https://github.com/citrolabs/ego-lite

Read `skills/ego-browser/references/install.md` and follow the steps to install ego lite.

install.md 側の手順はざっくりこうです。

1. スキル同梱の scripts/install.sh を実行（macOS のみ）
2. CPU（arm64 / x64）に合う DMG を取得し、/Applications（だめなら ~/Applications）へ配置
3. quarantine 属性を外して Gatekeeper の初回ブロックを緩和
4. アプリを起動し、ユーザーが GUI でオンボーディング完了
5. ego-browser の疎通確認

# スキル配置先に合わせてパスは読み替え
sh skills/ego-browser/scripts/install.sh

# オンボーディング後
command -v ego-browser
ego-browser nodejs <<'EOF'
console.log('ego-browser ready')
EOF

ego-browser ready が出れば、環境としては最低ラインOK。

Gatekeeper に止められたら、System Settings → Privacy & Security から手動許可、というのが公式トラブルシュートです。

最初のタスク——自然言語から入る

いちばん軽い使い方は、エージェントCLIで /ego-browser に続けてやりたいことを書くこと。

/ego-browser follow @ego_agent on x.com for me

（公式READMEの例。X上のフォロー操作は、アカウントや利用規約の都合で失敗・制限されうるので、まずは公開ページの閲覧や自前サイトの確認から試すのが無難です。）

エージェントはスキルを拾い、専用 Space でページを開き、Snapshot を読み、操作して報告する——その間、あなたの前面タブは触られない、というのが売り文句です。

もう一段深い使い方——ego-browser の heredoc

自然言語だけでも動きますが、How-toとして押さえておきたいのは CLI経由の Node ヘルパーです。エージェントは「シェルコマンドを1つずつ叩いて様子を見る」より、1本のJSに複数操作を書いて一気に走らせる設計になっています。公式はこれを「Code base, not CLI base」と呼び、複雑な作業で最大およそ2.5倍速・トークン削減、といったベンダー計測を出しています（サイト側には最大3.45x表記もあり、条件で数字が揺れます。自環境の再現値ではない前提で読んでください）。

最小の観察スクリプトはこんな感じです。

ego-browser nodejs <<'EOF'
// タスク全体で同じ Space 名を使い回す
const task = await useOrCreateTaskSpace('inspect example page')
cliLog('task space id: ' + task.id)

await openOrReuseTab('https://example.com', { wait: true, timeout: 20 })

cliLog(await snapshotText())
EOF

ポイントだけ抜き出します。

• heredoc の中は Node.js。ページ内DOMを触るコードは js(...) の中へ
• 結果の出力は基本 cliLog(...)。ここを通さないとエージェント側に返りにくい
• useOrCreateTaskSpace(name) を各ラウンドの冒頭で呼ぶ。heredoc が終わるたびにランタイム状態は消えるので、Space の再利用が継続作業の鍵
• wait / timeout の単位は秒（末尾が Ms の引数だけミリ秒）
• タスクが本当に終わったら、最後の heredoc で completeTaskSpace(nameOrId, { keep })。デフォルト方針は { keep: false }（閉じる）

よく使うヘルパー（覚える優先度つき）

系統	代表API	何をするか
Space	useOrCreateTaskSpace, listTaskSpaces, handOffTaskSpace, takeOverTaskSpace, completeTaskSpace	作業場の作成・引き継ぎ・終了
タブ	openOrReuseTab, listTabs, switchTab, gotoAndWait, closeTab	移動とタブ管理
観察	snapshotText, captureScreenshot, pageInfo	意味木スナップショット／画面／状態
操作	click, fillInput, typeText, pressKey, scrollBy	クリック・入力・スクロール
高度	js, cdp, browserFetch	ページ内JS評価、CDP直叩き

snapshotText() は、ページをテキストモデル向けの意味木として返し、[ref=N, loc=...] のような印を付けます。クリックはだいたいこう書けます。

await click('@21', { label: 'check login status' })
await fillInput('@7', 'hello')

ただし @N は直近の snapshotText() に出たものだけが有効。呼び直すたびに refMap が組み直されます。長く安定して指したい要素は、loc=... か普通のCSSセレクタ側へ逃げるのが公式の注意書きです。

3つのワークフロー——ページの種類で切り替える

スキル定義は、操作の基本方針を3つに分けています。

1. Semantic（既定） —— snapshotText() → @N / loc で click / fill
   普通のフォーム、リンク、表、管理画面向き
2. Visual —— captureScreenshot() → 座標クリック + キーボード
   Notion / Google Docs / Sheets / Figma など、canvasや仮想化が強い画面向き
3. Direct DOM / CDP —— js(...) / cdp(...)
   データ抽出、独自DOM走査、ヘルパー外のプロトコル操作

リッチエディタでは「DOM上の隠しinputに文字が入って、本体キャンバスには何も起きない」罠があるので、本番投入の前に小さな書き込みプローブ → スクショ確認、というのが公式推奨です。ここ、飛ばすと「成功したつもり」事故が起きやすい。

人間に戻す／エージェントに戻す——handoff が本番運用の肝

ブラウザ自動化でいちばん人間くさいのが、ログイン・CAPTCHA・SMS・社内SSOです。ego lite はここを Space の所有権ハンドオフ としてモデル化しています。

• エージェントが行き詰まったら handOffTaskSpace(...) でユーザーへ制御を渡す
• ユーザーがブラウザGUIで取り上げることもできる（同じ効果）
• 「user is controlling」系のエラーは、迂回せず止めてユーザーに確認するのが正しい動き
• 続行の明示（チャットで continue 等）があって初めて takeOverTaskSpace(...)

チカちゃん的には、ここがかなり大事です。完全自動を夢見て、2FAを力技で突破しようとするより、「ここは人間の仕事」と境界を切る道具として読んだ方が健全。自動化の完成度より、中断と再開の作法の方が、現場では効くことが多いんですよね。

向いていること／向いていないこと

向いていそう

• すでにログイン済みのSaaS・社内ツールを、コーディングエージェントに読ませたい／定型操作させたい
• Playwright一式をメンテしたくないが、エージェントCLIはもう使っている
• 複数タスクを並列にブラウザで回したい（Spaceごとの並走が売り）
• 自分の前面作業を止めずに、裏で調査やフォーム入力を進めたい

向いていない／まだ早い

• Windows / Linux メインの人（現状 Planned）
• ヘッドレスCIだけで完結させたい人（日常ブラウザ共有がコンセプトの中心）
• 「ログイン状態をエージェントに絶対渡したくない」方針の組織（売りそのものがリスク）
• 利用規約で自動化が禁じられているサイトへの乱用
• ベンダーベンチの倍速数字を、そのまま自社KPIにしたい人（条件依存が大きい）

注意点——すごいの隣にあるトゲ

1. ログイン共有は権限共有
   Cookieとセッションを渡すのは、鍵束を渡すのに近い。個人の趣味用途と、顧客データを含む業務ブラウザでは、危険度が段違いです。まずは別プロファイル／検証用アカウントから。

2. ブラウザ本体とリポジトリの境界
   GitHub上のスキル・スクリプトはMITで読めます。一方、ブラウザアプリ自体は別配布。セキュリティレビューするなら、DMGの入手経路（公式サイト／公式CDN）と署名・Gatekeeper挙動を確認したい。第三者ミラーや、出所不明の .dmg 直リンクは避けた方がいい。

3. インストールが「実行ファイルを取ってくる」行為であること
   スキル経由の install は DMG を落として配置します。便利ですが、企業端末では許可ポリシーに引っかかることも。IT方針がある人は先に確認。

4. ベンダー計測の読み方
   「最大2.5×」「最大3.45×」「トークン大幅減」は公式比較の数字。タスク選定・失敗定義・モデル差で変わります。「速い設計思想」として受け取り、「保証スペック」としては受け取らないのが安全。

5. Coming soon を現在形で書かない
   再利用スキルの蓄積（成功操作の蒸留）や、Windows/Linux、Electron/ネイティブ操作などはロードマップ上。いまの価値は「並走できるブラウザ＋外部エージェント接続」に置くのが誠実です。

6. エージェントのミスは、ログイン済みだと破壊力が増える
   誤クリック1回が、公開投稿や本番設定変更になり得る。危険操作の前には handoff で人を挟む、Keepを残して目視する、検証環境を使う——地味ですが効きます。

チカちゃん的な見立て——「共有」は信頼の設計問題

ちょっと待って。ここで一度、機能一覧から顔を上げます。

長いあいだ、ブラウザ自動化の物語は「どうやってDOMを安定して掴むか」でした。セレクタが壊れる、iframeが深い、Shadow DOMが闇、みたいな話。ego lite が面白いのは、その上にもう一枚、「誰のブラウザを、誰と分けるか」という問いを正面に出しているところです。

ログインを引き継ぐ。タブは分ける。制御は一度に片方だけ。行き詰まったら人に返す。これって技術というより、共同作業の礼儀に近い。

チカちゃん的には、ego lite の一番おいしい読み方は「最速ブラウザ」より 「エージェントと机を並べるための作法が入ったブラウザ」 です。速さの数字は宣伝の顔。本体は Space と handoff の設計かもしれない。

反対側の見方も置いておきます。ログイン共有は、便利さの勾配が急すぎて、利用者の警戒心を溶かしやすい。『データはローカル』と言われても、エージェントがクラウドモデルなら、見えた文字は外へ行きます。道具が誠実でも、運用が雑なら意味がない。ここは疑っていいところです。

以前の Page Agent の話にも通じますが、近いほど便利で、近いほど漏れる。界面が言葉に戻る時代に、私たちは「どこまでを共有知にして、どこからを一人の手に残すか」を、毎回設計し直す必要がありそうです。

まとめ——まず並走、でも鍵は分け方

ego lite は、

• 人と外部エージェントが同じブラウザを分け合うための macOS 向けブラウザ
• ego-browser スキル／CLI で Claude Code や Codex などから運転できる
• Space でタブを分離しつつ、ログイン状態の共有を狙う
• 複数操作をJSにまとめて走らせる設計（ベンダー計測では高速・低トークンを主張）
• 便利さの核心が権限共有なので、検証アカウントと handoff 運用が本体

という道具です。

「すごい！」だけで終わらせず、まず検証用ログインで試す、危険操作の前に人へ返す、OS対応とロードマップを確認する——この3つだけでも、かなり事故が減ります。

で、最後にひとつだけ問いを置いておきます。

あなたのエージェントにブラウザを渡すとき、それは「面倒なクリックを減らすため」ですか。それとも「自分でも把握していない業務手順を、エージェントに肩代わりさせるため」ですか。

どっちの気持ちもわかります。でも長く健全なのは、たぶん前者で、後者はしばらくすると「誰も画面を読めない現場」になります。

技術の話から始まって、最後は「共有の境界をどこに引くか」に戻ってくる。チカちゃん的には、そこが一番おいしいところです。思索は冒険です。今日の話も、その入口のひとつでした。

関連記事

Page Agent——Webページの中に住むGUIエージェントを、一行から始める → /notes/94-page-agent-in-page-gui

参考URL

ego lite（GitHub） → https://github.com/citrolabs/ego-lite

公式サイト → https://lite.ego.app/

ロードマップ → https://lite.ego.app/roadmap

ego-browser SKILL.md → https://github.com/citrolabs/ego-lite/blob/main/skills/ego-browser/SKILL.md

install.md → https://github.com/citrolabs/ego-lite/blob/main/skills/ego-browser/references/install.md

LICENSE（MIT） → https://github.com/citrolabs/ego-lite/blob/main/LICENSE

GitHub Trending（weekly） → https://github.com/trending?since=weekly