Puppeteer は、ヘッドレス Chrome をスクリプトで操作するための Node.js ライブラリです。ナビゲーションのコードを書き、セレクタを調整し、対象サイトがデザインを変えるたびにスクリプトを修正する必要があります。
ego (lite) はスクリプトを書く工程そのものを省きます。エージェントがログイン済みの Chrome を直接読み取り、自ら JavaScript を書くことで、タスク全体を Puppeteer より 3〜4倍速く完了させます。
単発のスクレイピング、フォーム入力、テスト、バックオフィス業務では、スクリプトを書く作業こそが一番コストのかかる部分でした。書いては、ページが変わるたびに直す。ego (lite) は、この作業をオープンソースの ego-browser シェルを通じて、すでに使っているエージェント(Claude Code、Codex、Cursor など)に任せます。
Puppeteer の issue tracker には、要素が確かに DOM 上に存在するにもかかわらず発生する waitForSelector のタイムアウトが山ほど報告されています。それが自分のコードのバグではなくタイミングの問題だと証明するだけで、午後の時間が丸ごと消えていきます。
ego (lite) は、待っては確認するという一連のやり取りを省きます。エージェントはページが読み込まれた瞬間に圧縮された Snapshot として内容を読み取り、即座に行動に移ります。しかも複数のステップを 1 回の JavaScript 呼び出しにまとめて実行します。その結果、タスク全体が Puppeteer より 3〜4倍速く完了します。
1 本のスクリプトから一歩進んだ Puppeteer 開発者は、並列処理を実現するには自前のプールを運用する必要があると気づきます。起動オプション、ブラウザコンテキスト、そして puppeteer-cluster のようなキューライブラリを組み合わせ、Chrome が RAM を使い尽くす前に同時実行数を制限しなければなりません。
ego (lite) では、プールのサイズを気にする必要はありません。すべてのタスクは 1 つのブラウザの中で独自の Space を持ち、好きなだけ開くことができます。それぞれがインポートされた独自の Chrome プロファイル上で動作するため、どのタスクも今使っているタブに触れることはなく、どの Space もいつでも見守ったり引き継いだりできます。
素の Puppeteer スクリプトはトークンを消費しません。そもそもモデルを一切呼び出さないからです。コストが発生するのは、Puppeteer MCP のリファレンス実装のような MCP サーバーを介してエージェント向けにラップした瞬間です。ラップされたアクションはそれぞれ個別のツール呼び出しとなり、そのたびにコンテキストをモデルへ送り直します。しかもアクセシビリティ Snapshot を取得するツールがないため、自分の作業を確認するのにスクリーンショットに頼ることになります。
ego (lite) のエージェントは、1 ターンあたり数行の JavaScript に複数のアクションをまとめます。これに Snapshot による入力が重なることで、同じタスクをタスク単位で見て全体としてはるかに少ないトークンで完了できます。
Puppeteer が起動するのは、Cookie もセッションも持たないまっさらな Chrome です。そのためログインが必要な操作では認証フローそのものをスクリプトで実装し、見覚えのないブラウザに対してサイトが CAPTCHA や 2 段階認証を出さないことを祈るしかありません。この「空のプロファイル」という壁こそ、開発環境では動くスクリプトが本番サイトで失敗する最も一般的な原因です。
Chromium をベースに構築された ego (lite) は、ワンクリックで Chrome の環境をまるごとインポートします。エージェントはログイン情報や Cookie、拡張機能をそのまま引き継ぐため、途中で行き詰まることがありません。
| 機能 | ego lite | Puppeteer |
|---|---|---|
| 作業の進め方 | タスクを説明するだけで、エージェントがブラウザを操作 | Node.js スクリプトを書いて保守する |
| ページの変化への対応 | エージェントがSnapshotを再取得して適応する | セレクタが壊れ、スクリプトを修正する |
| ログイン済みサイト (SSO、2FA) | 実際のChromeプロファイルとセッションをそのまま継承 | 空のプロファイル。ログインをスクリプト化し、Cookie をエクスポート |
| セットアップ | アプリをインストールし、エージェントで /ego-browser を実行 | Node プロジェクト、npm install、起動設定 |
| 並列タスク | Space が 1 つのブラウザ内でタスクを分離。プールのサイズ調整は不要 | ブラウザプール、コンテキスト、メモリを自分で管理 |
| AI エージェントとの連携 | そのために作られている: ego-browser経由でClaude Code、Codex、Cursorに対応 | 標準では非対応。MCP ラッパーや独自のつなぎ込みが必要 |
| 日常使いブラウザ | 対応: 人間とエージェントが 1 つのブラウザを共有し、Space で分離 | いいえ、ヘッドレスの自動化ツールです |
| CI のテストスイートに最適 | いいえ: 対話的なエージェントタスクであり、コミット済みのテストコードではない | 対応: 決定論的でスクリプト化しやすく、CI との相性も良い |
| 再利用可能なスキル (近日公開) | 成功した実行を再利用可能なスキルへと蒸留し、エージェントが繰り返すほど複雑なタスクで最大5倍高速化 (限定ベータ) | 標準機能としては非搭載 |
| 価格 | 無料、サブスクリプションなし | 無料、オープンソース |
Puppeteer のスクリプトを ego (lite) に移植するわけではありません。そもそも書くのをやめるのです。スクリプト化していたタスク、あるいはスクリプト化を諦めていたタスクを、そのままエージェントに任せましょう。
ego (lite) をダウンロードし、Chrome のプロファイルをインポートしましょう。これまでスクリプトでは突破できなかったログインも、そのまま引き継がれます。
エージェントに貼り付ける
/ego-browser ego.appを開き、コンソールエラーがないかページを確認する
Claude Code、Codex、Cursor で /ego-browser を実行します。
リスティングページのスクレイピングやバックオフィスのフォーム入力など、普段スクリプトを書いて対応しているタスクを 1 つ選び、それを 1 文でエージェントに伝えましょう。
決定論的な CI スイートや大量のスケジュールジョブなど、スクリプトが本当に強みを発揮する場面では Puppeteer を使い続けましょう。ego (lite) は、毎週のように変化する対話的なブラウザ作業を担います。
無料で Mac 上で動作し、ワンクリックで Chrome のプロファイルをインポートできます。Claude Code、Codex、Cursor、コードを書くあらゆる CLI エージェントに対応しています。
まだ検討中ですか? Puppeteer が同じ領域の他のツールとどう比較されるかをご覧ください。
Puppeteer は Chrome チームが開発する Node.js の自動化ライブラリで、DevTools Protocol と WebDriver BiDi を通じて Chrome と Firefox を操作します。成熟していて高速、無料であり、Chrome 専用のスクレイパーや PDF 生成、ヘッドレステストをスクリプトで書く開発者に広く選ばれています(もっとも、テストフレームワークとしての採用では Playwright が先行しつつあります)。Puppeteer 自身の issue tracker には、ナビゲーションや再接続に伴う waitForSelector の実際の不安定さが数多く報告されており、大規模に運用するチームはブラウザプールやコンテキスト、メモリを手動で管理することになります。それでも、CI で動く手作りの決定論的な自動化コードにおいては、Puppeteer は依然として優れた選択肢です。以下の比較は、スクリプトではなく AI エージェントがブラウジングを担当した場合に何が起きるかについてです。
AI エージェントが操作するブラウザ作業においては、その通りです。スクリプトの層を完全に取り除き、実際のログイン済み Chrome の中でタスクを実行するため、さらなるスクリプト作成ではなくエージェントのために作られた数少ない Puppeteer 代替の 1 つになっています。一方、CI で動く決定論的な自動化コードにおいては、依然として Puppeteer の方が優れたツールです。多くの開発者は両方を使い分けています。パイプラインには Puppeteer を、結局スクリプト化しなかったあらゆる作業には ego (lite) を、という具合です。
3 つとも、スクリプトを土台とする自動化ライブラリです。Playwright vs Puppeteer や Puppeteer vs Selenium のどちらを選ぶかは、通常は何を何の言語でテストするかで決まります。Chrome 専用で Node を使い、軽量な DevTools レベルの API が欲しい場合は Puppeteer が有利です。新しいテストスイートでは、マルチブラウザ対応、自動待機、より強力なテストランナーを備える Playwright が一般的に一歩リードします。Selenium vs Puppeteer はより僅差で、Selenium と Puppeteer のどちらが優れているかは、生の機能というよりも言語や CI 環境で決まることがほとんどです。Selenium の強みは W3C WebDriver 標準と、最も幅広い言語・レガシーブラウザのサポートですが、その分ボイラープレートは増えます。ego (lite) はこの議論そのものに参加しません。ego (lite) はエージェントブラウザであり、3 つのどれかがスクリプトを書く代わりに AI エージェントがブラウジングを担うからです。ego (lite) vs Playwright および ego (lite) vs Selenium の比較ページもあわせてご覧ください。
Puppeteer を包む MCP ラッパーは、エージェントにブラウザへのアクセスを与えます。しかしアクションのたびにモデルとの間で個別のツール往復が発生し、ブラウザ自体は依然として空のプロファイルのままです。ego (lite) はアクションを JavaScript にまとめて実行し、実際のログイン状態をそのまま引き継ぐため、タスクあたりのトークンコストは低く抑えられ、ラッパーが突破できない SSO の壁にエージェントがぶつかることもありません。
セレクタは、クラス名や DOM の順序、ARIA 構造といったページの正確なマークアップに結びついています。対象サイトのリデザイン、A/B テスト、フレームワークのアップグレードによってそのマークアップが変わると、waitForSelector の呼び出しはタイムアウトし始めます。しかも多くの場合は断続的にです。これはまさに Puppeteer 自身の issue tracker で繰り返し報告されている類の不安定さです。ego (lite) のエージェントは、そもそも固定されたセレクタを保持しません。毎回そのときのページを Snapshot として読み取り、実際に何があるかを推論します。そのため、リデザインはスクリプトを壊すものではなく、次の実行で適応するだけの出来事になります。
いいえ。Puppeteer を 1 本のスクリプトの先へスケールさせるには、通常 puppeteer-cluster や generic-pool、あるいは自作のキューでプールを構築し、Chrome のメモリ使用量が手に負えなくなる前に同時実行数を制限する必要があります。ego (lite) の Space は、すでに開いている 1 つのブラウザプロセスの中で動作します。そのため、5 つのタスクを同時に実行しても、面倒を見るべきブラウザインスタンスが 5 つに増えるわけではありません。
はい。コードを書く CLI エージェントであれば、MIT ライセンスの ego-browser シェルを通じてどれでも接続できます。Claude Code、Codex、Cursor、Gemini CLI、OpenCode、そして独自に構築したエージェントも対応します。
はい。無料でサブスクリプションも不要、そして ego-browser シェルはオープンソースです。