Playwrightは、Microsoftによるスクリプト先行型の自動化フレームワークです。ブラウザコンテキストに対してTypeScriptやPythonでコードを書き、ロケーターを組み上げていきますが、サイトが変わるたびにその修正に追われることになります。
ego liteはスクリプトを書きません。エージェントはページを圧縮されたSnapshotとして読み取り、自らJavaScriptを記述します。すでに実際のChromeにログイン済みの状態で動作するため、タスク全体をPlaywrightより3〜4倍速く完了できます。
Playwrightは現代的なテストフレームワークとしての地位を確立しており、CIでの確定的なE2Eテストスイートにおいては今も最有力の選択肢です。しかし、作業がインタラクティブな場合、このダッシュボードの情報を取得する、あの経費を申請する、昼休み前に3つのフローを確認する、といった場面ではスクリプトはむしろ負担になります。ego liteなら、オープンソースの ego-browserシェルを通じて、すでに使っているコーディングエージェントにその作業を任せられます。
Playwrightのスクリプトは、記録された時点のページとほぼ同じ寿命しかありません。Codegenのロケーターは1つのDOMスナップショットしか捉えていないため、数ヶ月後にリデザインが行われると、新機能のリリースではなくセレクターの修正に時間を取られることになります。
ego liteでは、エージェントは安定した@N参照を持つ圧縮されたSnapshotとしてページを読み取り、自らJavaScriptを記述します。そのため、ページが変化しても壊れることなく適応でき、タスク全体をPlaywrightより3〜4倍速く完了できます。
Playwrightの並列テスト実行は、デフォルトでヘッドレスです。ヘッド付きモードにすると、ワーカーごとに別々のOSウィンドウが散らばり、どれか1つを一時停止して操作を引き継ぐ方法もありません。そのため多くのチームはヘッドレスのままにして、あとからトレースファイルを確認しています。
ego liteでは、開くSpaceの数に上限はありません。それぞれが独自にインポートしたChromeプロファイル上で同時に1つのタスクを実行し、あなたが使っているタブを奪うことは一切ありません。どのSpaceも、いつでもリアルタイムで確認したり、操作を引き継いだりできます。
エージェントからMicrosoft公式のplaywright-cliを使ってPlaywrightを操作しても、結局は1つのアクションごとに1つのコマンドを発行することになります。スナップショットを取り、参照をクリックし、再度スナップショットを取り、結果を読み取り、次のコマンドを決める、という流れです。
ego liteでは、エージェントが1回のターンで複数のアクションを1つのJavaScript呼び出しにまとめ、ページ全体のアクセシビリティダンプではなく圧縮されたSnapshotとして読み取ります。これらが積み重なることで、タスク全体で使うトークン数を大幅に減らせます。
新しいPlaywrightのコンテキストは何もない状態から始まるため、実際の認証を行うにはログイン処理をスクリプト化し、storageStateを保存し、そのトークンがテスト実行中ずっと有効であることを願うしかありません。Auth0がMFA下で行っているようにプロバイダーがリフレッシュトークンをローテーションすると、保存した状態は結局壊れてしまいます。
ego liteはワンクリックでChromeプロファイル全体をインポートします。クッキー、セッション、拡張機能もすべてそのまま引き継がれるため、エージェントは最初から、あなたがログインしているすべての場所にサインイン済みの状態で動作を始められます。
| 機能 | ego lite | Playwright |
|---|---|---|
| 作業の進め方 | タスクを説明するだけで、エージェントがブラウザを操作 | TS/Python/Java/.NETでスクリプトを書き、保守する |
| ページの変化への対応 | エージェントがSnapshotを再取得して適応する | ロケーターが壊れたら、コードを直すのは自分 |
| ログイン済みサイト (SSO、2FA) | 実際のChromeプロファイルとセッションをそのまま継承 | 空のコンテキストから開始。ログインをスクリプト化し、storageStateを管理 |
| セットアップ | アプリをインストールし、エージェントで /ego-browser を実行 | Node/Pythonプロジェクトを用意し、ブラウザをインストールし、設定ファイルを書く |
| AI エージェントとの連携 | そのために作られている: ego-browser経由でClaude Code、Codex、Cursorに対応 | codegen、playwright-cli、または別立てのPlaywright MCPサーバー経由 |
| 並列タスク | 1つの可視ブラウザ内で Space がタスクを分離 | WorkerとContext、基本はヘッドレス |
| 日常使いブラウザ | はい。あなたは自分のSpaceで閲覧し、エージェントは別のSpaceで作業する | いいえ。日常使いのブラウザではなく、自動化ライブラリ |
| CIのテストスイート対応 | いいえ。コミットされるテストコードではなく、対話的なエージェントタスク向け | はい。テストランナーとCIの実績にかけては、群を抜いています |
| 再利用可能なスキル (近日公開) | 成功した実行を再利用可能なスキルへと蒸留し、エージェントが繰り返すほど複雑なタスクで最大5倍高速化 (限定ベータ) | 標準機能としては非搭載 |
| 価格 | 無料、サブスクリプションなし | 無料、オープンソース |
Playwrightのテストを ego liteに移植する必要はありません。そのまま残しておいてください。移ってくるのは、CIの外でスクリプト化していた(あるいはスクリプト化を避けていた)作業のすべてです。一度きりで、ログインが必要で、毎週のように変わるブラウザ作業のことです。
ego liteをダウンロードして、Chromeプロファイルをワンクリックでインポートします。テストコンテキストには一度も持たせたことのなかったログイン情報も、そのまま一緒に引き継がれます。
エージェントに貼り付ける
/ego-browser ego.appを開いて、ナビゲーションバー内のリンクをすべてリストアップする
Claude Code、Codex、Cursorで/ego-browserを実行します。プロジェクトの雛形もplaywright.configも不要です。
普段ならスクリプトを書いていたようなタスクを、一文で説明してエージェントに渡します。ログイン済みダッシュボードから数字を取得する、チェックアウトの流れを一通り進める、といった作業です。
決定的な結果が必要なCIのE2Eスイートには、Playwrightを使い続けてください。対話的なエージェント作業は ego liteが担い、両者はその役割を争うものではありません。
無料で Mac 上で動作し、ワンクリックで Chrome のプロファイルをインポートできます。Claude Code、Codex、Cursor、コードを書くあらゆる CLI エージェントに対応しています。
まだ検討中なら、同じ領域の他のツールとPlaywrightを比較したページも確認してほしい。
PlaywrightはMicrosoftによるオープンソースの自動化フレームワークで、Chromium、Firefox、WebKitに対応し、TypeScript、Python、Java、.NET向けにファーストクラスのバインディングを備えている。テストランナー、自動待機、trace viewer、CI統合はこのカテゴリで最も強力で、コミット対象の決定論的なE2Eテストスイートにおいては最も優れたツールだ。Microsoftはさらに、Claude CodeやCopilotのようなコーディングエージェント向けに、Playwrightチームがトークン効率を意識して開発した相棒的なCLI、playwright-cliの提供も始めている。このページで扱うのはコアフレームワークと、そのスクリプティングおよびCLIワークフローについてであり、エージェント向けの別のMCPサーバーであるPlaywright MCPについては専用の比較ページを用意している。エージェント駆動型のアプローチを選ぶ開発者は、Browser Use vs PlaywrightやStagehand vs Playwrightも比較検討することが多い。この3つはLLM駆動のブラウジングスタックの大半に登場するからだ。
AI エージェント駆動のブラウザ操作であれば、答えはイエスだ。スクリプトは不要で、実際のログイン状態を使え、並行Spacesも使える。スクリプトを増やすのではなく、エージェント専用に作られた数少ないPlaywright代替ツールの一つと言える。一方、CIでコミットするE2Eテストスイートであれば、答えはノーだ。Playwrightのテストランナー、トレース機能、クロスブラウザ対応は本当に優れているので、そのまま使い続けるべきだ。正直な線引きはこうなる。コミットするテストはPlaywright、委任するタスクは ego lite。
この3つはいずれもスクリプトファーストのフレームワークだ。playwright vs puppeteerで検索しても、puppeteer vs playwrightで検索しても同じことになる。新規のテストスイートならPlaywrightが優位だ。最速のランナー、自動待機、TS/Python/Java/.NET対応、3つのエンジンすべてに対応している。Node環境でChrome専用に絞り、DevToolsレベルの軽量なAPIを求めるならPuppeteerが優位だ。W3C WebDriver標準、幅広い言語バインディング、既存のエンタープライズGridが重要ならSeleniumが優位だ。ego liteはまた別の役割を担う。スクリプトの代わりにAI エージェントがブラウジングを行い、保守すべきコードはなく、実際にログイン済みのプロファイルがすでに紐づいている。
Selenium vs Playwrightは、どちらにもトレードオフがある話になる。Playwrightは実行速度が速く、自動待機が組み込まれていて、モダンなテストランナーとtrace viewerやcodegenといったツール群を備えている。その代わりエコシステムはまだ新しい。Seleniumは、W3C WebDriver標準に準拠し、言語対応やレガシーブラウザのカバレッジが最も広く、20年にわたるエンタープライズでの採用実績がある。その代わりコードは冗長になりやすく、待機処理も明示的に管理する必要がある。今からテストフレームワークを選ぶなら、多くのチームはPlaywrightを選ぶ。スクリプトではなくエージェント駆動の作業であれば、ego liteとSeleniumの比較をSeleniumのページで確認してほしい。
どちらも、エージェント利用のために新しいPlaywrightブラウザをラップしたもので、いずれも空のプロファイルで1アクションにつき1コマンドを実行する点は変わらない。Playwright MCPはMCPツールコールとして、playwright-cliはCLI呼び出しとして実行される。一方 ego liteは、1ターンにつき複数のアクションをJavaScriptでバッチ実行し、ページは圧縮されたSnapshotとして読み込み、実際にログイン済みのChromeプロファイルから始められる。そのためタスクごとのトークンコストは低く抑えられ、タスク全体もより速く完了する。詳しい比較は ego lite vs Playwright MCPのページで確認できる。
部分的には可能だ。スクリプトでログインした後にstorageStateを保存する方法や、Chromeのプロファイルディレクトリを指定してpersistent contextを起動する方法があるが、セッションは期限切れになり、2FAやSSOがスクリプトによるログインを妨げ、稼働中のChromeとプロファイルを共有することもできない。ego liteはプロファイルを一度取り込めば、それ以降エージェントが実際のログイン状態を引き継いでくれる。
はい。無料でサブスクリプションもなく、データはローカルに保存される。エージェントが接続する ego-browserシェルは、MITライセンスのオープンソースだ。