GMOペパボ株式会社Publicationへの投稿
🌐

メモリ16MB vs 1.2GB ── AIブラウザ自動化ツール5選を実測比較した

あたに
に公開
AI
Playwright
llm
AIエージェント
ブラウザ自動化
tech

アイキャッチ

Claude Codeでブラウザ操作をしていて、ツール選びに迷いました。候補は5つ、アプローチもバラバラ。全部インストールして10項目テストした結果、用途によって最適解の変わることがわかりました。

先に結論: 認証管理ならplaywright-CLI。エージェントの操作基盤ならagent-browser。自然言語で自律操作ならbrowser-use。大量クロールならLightpanda。本番インフラならsteel-browser。

本記事ではCLIモードでの比較を中心に行っています。browser-useのようにLLMエージェントモードが本来の強みであるツールもあり、その観点での評価は別の記事で扱う予定です。

比較した5ツール

ツール Stars 言語 ライセンス 開発元 一言で言うと
playwright-cli 6.1K (+85K本体) TypeScript Apache-2.0 Microsoft 認証管理とトークン効率に強いCLI
agent-browser 24.1K Rust Apache-2.0 Vercel エージェント開発に特化したCLI
browser-use 82.2K Python MIT browser-use LLMが自律的にブラウザ操作
Lightpanda 23.6K Zig AGPL-3.0 lightpanda-io 超省メモリの軽量ブラウザ（公式: 9x高速）
steel-browser 6.7K TypeScript Apache-2.0 steel-dev 本番運用向けブラウザインフラ

テスト環境

項目 値
OS macOS Darwin 25.3.0 (Apple Silicon)
Node.js v24.5.0
Python 3.13
playwright-CLI 0.1.1
agent-browser 0.21.4
browser-use 0.12.2
Lightpanda nightly (c1fc2b13)
steel-browser Docker (latest)

セットアップ: Lightpandaは12MBのバイナリ1つ

最初のハードルはインストールです。各ツールの「ゼロから動くまで」を比較しました。

ツール 方法 必要な依存 手順
Lightpanda バイナリDL (12MB) なし 1ステップ
agent-browser npm i -g agent-browser + install Node.js + Chrome DL 2ステップ
playwright-CLI npm i -g @playwright/cli + install-browser Node.js + ブラウザDL 2ステップ
browser-use pip install browser-use (75依存) Python 3.11+ + LLM APIキー 2ステップ + 設定
steel-browser docker pull Docker 1ステップ（Docker前提）

Lightpandaはバイナリを1つダウンロードするだけ。依存ゼロで、最もシンプルです。agent-browserとplaywright-CLIはnpm 1コマンドですが、ブラウザのダウンロードが別途必要です。browser-useはPython依存パッケージが75個あり、さらにLLMのAPIキー設定が必要です。steel-browserはDockerが動く環境なら1コマンドですが、Docker自体のセットアップが前提になります。

基本速度: steel-browserが0.45sで最速

httpbin.org/html を開いてスナップショットを取り、閉じるまでの時間を3回計測しました。

ツール 1回目 2回目 3回目 平均
steel-browser 0.70s 0.41s 0.25s 0.45s
Lightpanda 1.05s 0.85s 0.85s 0.92s
agent-browser 1.93s 1.80s 1.90s 1.88s
playwright-CLI 2.15s 1.84s 1.85s 1.95s
browser-use 2.30s 10.21s 2.22s 4.91s

steel-browserはDocker内で常時起動しているChromiumを利用するため、2回目以降が特に高速です。Lightpandaは独自エンジンでChromeの起動オーバーヘッドがなく安定して速い結果です。agent-browserとplaywright-CLIはdaemonモードで安定した速度を出しています。browser-useはPythonランタイムの起動コストがあり、まれにスパイク（10.21s）が発生します。

メモリ: 16MB vs 1.2GB、75倍の差

1ページ（httpbin.org/html）をオープンした状態でのプロセスメモリ（RSS）を計測しました。

ツール デーモン ブラウザ 合計 プロセス数
Lightpanda — — 16 MB 1
steel-browser (Docker内) (Docker内) 581 MB コンテナ
browser-use 111 MB 758 MB 869 MB 8
playwright-CLI 169 MB 760 MB 929 MB 7
agent-browser 5 MB 1,197 MB 1,202 MB 10

Lightpandaは16MBで、最大のagent-browser（1,202MB）と比較して約75倍の差です。公式ベンチマークでは「Chromeの9倍省メモリ」と謳われていますが、今回の単一ページテストではさらに大きな差が出ました。テスト条件やページの複雑さによって結果は変動します。これは独自エンジンがCSS描画を省略し、DOMとJSの実行に特化しているためです。steel-browserはDockerコンテナにChromiumとNode.jsがすべて入った構成で581MB。ホストのプロセスをコンテナ内に集約できる点は運用しやすいポイントです。browser-useはPythonデーモンが111MBありますが、Chromeのプロセス数が少なく合計は869MBで収まっています。agent-browserのデーモン自体はRust製でわずか5MBですが、Chromeプロセスが多い分、合計は最大になっています。

SPA対応: 5ツールともreact.devを読み込めた

react.dev（React公式サイト、クライアントサイドレンダリングのSPA）でスナップショットが正しく取れるかテストしました。

ツール 成功 時間 出力サイズ 出力形式
steel-browser OK 1.45s 16 KB Markdown
Lightpanda OK 4.20s 18 KB Markdown
agent-browser OK 4.83s 34 KB アクセシビリティツリー（ref付き）
playwright-CLI OK 6.22s 137 B スナップショットファイル参照
browser-use OK 12.77s タイトル取得のみ extractはLLMエージェントモードが必要

5ツールとも正常にページを読み込めました。steel-browserは常時起動Chromiumの利点でSPAでも1.45sと最速です。Lightpandaも18KBのMarkdownを4.20sで返しており、react.devレベルのSPAは処理できています。agent-browserはref番号付きのアクセシビリティツリーを返すため操作指示に直結します。playwright-CLIの出力はファイル参照のみ（137バイト）で、トークン効率を優先した設計です。browser-useはCLI単体ではタイトル取得が中心で、構造化抽出にはLLMエージェントモードを利用します。

認証永続化: playwright-CLIのstate-save/loadが充実

AIエージェントがSAML/SSO認証付きの社内ツールを操作する場合、認証状態を保存・復元できるかが重要です。httpbin.org のCookieエンドポイントを使って検証しました。

playwright-CLI

# Cookie設定→保存→復元
playwright-cli open https://httpbin.org/cookies/set/saml_token/mock_abc123 --persistent
playwright-cli cookie-list
# → saml_token=mock_abc123 (domain: httpbin.org, path: /)

playwright-cli state-save /tmp/pw-auth.json
playwright-cli close

# 新しいセッションで復元
playwright-cli open https://httpbin.org --persistent
playwright-cli state-load /tmp/pw-auth.json
playwright-cli cookie-list
# → saml_token=mock_abc123  ← 復元成功

cookie-list/cookie-set/state-save/state-load コマンドが揃っており、認証管理が最も充実しています。--persistent フラグでブラウザプロファイルをディスクに保存し、再起動後もCookieやlocalStorageを維持できます。

agent-browser

agent-browser open https://httpbin.org/cookies/set/saml_token/mock_abc123
agent-browser state save test-auth
agent-browser close

agent-browser open https://httpbin.org/cookies
agent-browser state load test-auth
# → Cookie復元可能

state save/load コマンドと --profile フラグで永続化に対応しています。Auth vaultで認証情報を暗号化して管理する機能もあり、エージェントにパスワードを見せずにログインさせる仕組みが備わっています。

browser-use

cookies export/import コマンドでCookieの書き出しと読み込みが可能です。--profile フラグでブラウザプロファイルを指定すれば、Cookie/localStorageが保持されます。包括的な状態保存はLLMエージェントモードとプロファイル永続化の組み合わせで実現します。

Lightpanda

各fetchは独立したプロセスとして実行される設計で、公開ページの大量取得に特化しています。認証が必要な場合はHTTPヘッダーやCookieをコマンドライン引数で渡す方法が使えます。

steel-browser

セッションID指定でCookieが保持される仕組みです。実際に saml_token=mock_abc123 を設定してセッションを再利用したところ、Cookieの復元に成功しました。REST APIでセッションを管理し、Playwright/Puppeteerを接続するインフラなので、認証処理自体はクライアント側で実装します。

認証永続化まとめ

ツール Cookie管理 state保存/復元 プロファイル永続
playwright-CLI cookie-list/set/get 完備 state-save/load --persistent
agent-browser state経由 state save/load + Auth vault --profile
browser-use cookies export/import プロファイルで代替 --profile
steel-browser セッションID指定で保持（実証済み） REST API セッション単位
Lightpanda HTTPヘッダーで対応 fetchごとに指定 軽量設計のため対象外

並列実行: Lightpandaは推定100並列でも1.6GB

3セッションを同時に起動し、完了までの時間と合計メモリを計測しました。

ツール 3セッション起動時間 メモリ合計
playwright-CLI 4.90s 559 MB
Lightpanda 9.34s ~48 MB
agent-browser 10.58s 4,165 MB
browser-use — —
steel-browser — —

browser-useは --session オプションによるセッション管理が可能ですが、今回は未テストです。steel-browserはREST API経由で複数セッションを同時作成できますが、今回は計測対象外としました。

playwright-CLIは名前付きセッション（-s s1, -s s2）で並列管理でき、Chromeプロセスを共有するため効率的です。Lightpandaは各fetchが独立プロセス（各16MB）なので、100並列でも推定メモリ1.6GB程度に収まる計算です（16MB × 100プロセス）。agent-browserは各セッションが独立したChromeインスタンスを起動するため、メモリ消費が大きくなります。

エラー耐性: agent-browserのメッセージが最も親切

架空のURL、404ページ、タイムアウトでの挙動を確認しました。

シナリオ playwright-CLI agent-browser browser-use Lightpanda steel-browser
DNS解決失敗 ページは開くが内容は空 ✗ net::ERR_NAME_NOT_RESOLVED URLを表示するのみ HTMLでエラー返却 (NavigationFailed: CouldntResolveHost) JSON {"message":"net::ERR_NAME_NOT_RESOLVED at ..."}
404 ページは開くが内容は空 ✗ net::ERR_HTTP_RESPONSE_CODE_FAILURE URLを表示するのみ 空HTML返却 JSON構造化エラー
タイムアウト — — — 指定時間で正確に切断（3.03s） —

agent-browserのエラーメッセージが最も具体的です。何が失敗したかが一目でわかるので、エージェントのリトライロジックを組みやすくなっています。steel-browserはJSON形式で構造化されたエラーを返すため、プログラムからのパースに適しています。Lightpandaは構造化されたHTMLでエラーを返すため、こちらもプログラムで処理しやすい設計です。browser-useはURLの表示のみで、詳細なエラー情報は別途確認が必要です。playwright-CLIはエラー時もページを開こうとするChrome系の挙動をそのまま反映しています。

JS重量級サイト: steel-browserが全サイト最速

SPA（Single Page Application）で構築されたサイトでの動作を確認しました。

サイト playwright-CLI agent-browser browser-use Lightpanda steel-browser
HackerNews OK (4.3s) OK (4.0s) OK (4.24s) OK (1.1s) OK (0.92s)
GitHub OK (2.9s) OK (1.6s) OK (タイトル取得) OK (2.9s) OK (3.45s)
react.dev OK (6.2s) OK (4.8s) OK (12.8s) OK (4.2s) OK (1.5s)

Chrome系（playwright-CLI, agent-browser, browser-use）は全サイトで安定して動作します。steel-browserはDocker内で常時起動しているChromiumを使うため、JS重量級サイトで最速の結果を出しました。HackerNewsは0.92s、react.devでも1.5sで完了しています。Lightpandaはサーバーサイドレンダリング中心のサイト（HackerNews、GitHub）では高速に動作しますが、クライアントサイドJSに依存する重量級SPAでは制約があります。これはLightpandaがCSS描画を省略し、DOMとJS実行に特化した設計のためです。今後のバージョンアップでSPA対応が拡充される予定です。

トークン効率: playwright-CLIの317Bが最小

AIエージェントがブラウザ操作する際、LLMのコンテキストウィンドウをどれだけ消費するかは重要です。github.com/microsoft/playwright のスナップショット出力サイズを比較しました。

ツール・形式 出力サイズ
browser-use get text 112 bytes
playwright-CLI snapshot 317 bytes
agent-browser snapshot -i (compact) 16 KB
steel-browser markdown 31 KB
Lightpanda markdown 36 KB
agent-browser snapshot (full) 70 KB
Lightpanda html 409 KB
browser-use get html 436 KB
steel-browser html 445 KB

browser-useの get text は112バイトでページタイトルのみを返します。ページの存在確認や簡易チェックには最もトークン効率が高い手段です。ただし構造化データの取得には get html（436KB）を使うか、LLMエージェントモードでの extract が必要です。

playwright-CLIの317バイトはスナップショットの実体をファイルに保存し、LLMにはファイル参照のみを渡す設計です。大きなコードベースを扱うコーディングエージェント（Claude Code、GitHub Copilotなど）では、ブラウザ操作でコンテキストを節約することが重要で、この設計は理にかなっています。

agent-browserの -i（inline compact）モードは16KBで、操作に必要なref番号付きの構造を維持しつつサイズを抑えています。steel-browserのMarkdown出力は31KBでLightpandaの36KBとほぼ同等です。

出力品質: ref付きツリー vs Markdown vs JS実行

HackerNewsのトップ記事タイトルを各ツールで抽出し、出力の質を比較しました。

agent-browser — 操作可能な構造データ

- link "Flash-Moe: Running a 397B Parameter Model on a Mac with 48GB RAM" [ref=e111]
- link "Hormuz Minesweeper – Are you tired of winning?" [ref=e116]

ref番号付きで、「click e111」とすればそのリンクをクリックできます。エージェントの操作指示に直結する出力です。

Lightpanda — 可読性の高いMarkdown

| 1. | [Flash-Moe: Running a 397B Parameter Model...](https://github.com/danveloper/flash-moe) |
| 2. | [Hormuz Minesweeper – Are you tired of winning?](https://hormuz.pythonic.ninja/) |

Markdownテーブル形式で、人間が読んでもLLMが処理しても扱いやすい出力です。リンクURLも含まれています。

playwright-CLI — JS実行による柔軟な抽出

playwright-cli run-code "const titles = await page.$$eval('.titleline > a', els => els.map(a => a.textContent));"

任意のJSを実行できるため、抽出ロジックの自由度は最高です。ただし、事前にページ構造を把握してコードを書く必要があります。

browser-use — LLMが自律的に判断

browser-useの extract コマンドはLLMエージェントモードで動作し、ページの内容をLLMが解釈して構造化データとして返します。セレクタの指定が不要で、「記事タイトルの一覧を取得して」のような自然言語の指示で抽出できます。CLI単体（get text / get html）では生データの取得に限られます。

steel-browser — 完全なHTML構造

steel-browserのscrape APIはリンク構造を含む完全なHTMLを返します。Markdown変換も組み込まれており、用途に応じて出力形式を選択できます。

各ツールはこんな人に向いている

playwright-CLI — 企業のSAML/SSO環境で開発しているエンジニア

社内のGitHub EnterpriseやJiraなど、SAML認証付きツールをAIエージェントで操作したい人に最適です。Cookie/state-save/loadが5ツール中最も充実しており、認証状態を確実に保存・復元できます。Claude Codeとの連携はSKILL.mdで即座に動きます。snapshot出力が317バイトとトークン効率が際立っており、大きなコードベースを扱うコーディングエージェントのコンテキストを節約できます。Firefox/WebKitにも対応する唯一のツールなので、クロスブラウザE2Eの自動化にも使えます。

向いている場面: 社内ツールの自動化、認証が必要なワークフロー、Claude Code/Copilotの補助ツール、クロスブラウザテスト。

agent-browser — AIエージェントを自作したいフルスタックエンジニア

自分でエージェントのループを設計しつつ、ブラウザ操作は手軽に済ませたい人が最適なターゲットです。snapshot が返すref付きアクセシビリティツリー（[ref=e111]）を操作指示としてそのまま使えるため、「snapshot→判断→click ref」のループが自然に書けます。エラーメッセージが最も親切で、開発中のデバッグがスムーズです。Rust製デーモンはわずか5MBです。Auth vaultでの暗号化された認証管理や、diffコマンドでの操作検証など、エージェント開発向けの機能が豊富です。Lightpandaをバックエンドに切り替えれば軽量化も可能です。

向いている場面: 独自AIエージェントの開発、ブラウザ操作botのPoC、操作→検証ループの実装。

browser-use — ブラウザ自動化を最速でプロトタイプしたいPythonエンジニア

「ECサイトで最安値を見つけて」「この求人に応募して」をPython数行で実現できる唯一のツールです。LLMがページを見て判断してくれるので、セレクタやページ構造の事前調査が不要です。DOM+スクリーンショットの併用でレイアウト変更にも自動適応します。Claude/GPT-4o/Gemini/Ollamaなど15以上のLLMプロバイダに対応しており、手元のローカルモデルでも動きます。タスクの定義が自然言語なので、非エンジニアのチームメンバーとも「何をさせるか」の議論がしやすい点も魅力です。

向いている場面: 業務プロセス自動化のPoC、自然言語でのタスク指示、非定型なWeb操作の自動化、社内ツールのRPA的活用。

Lightpanda — 大量のWebページを高速に処理するデータエンジニア

100ページを同時に処理してもメモリ48MB。Chromeなら4GB超です。この差がインフラコストに直結します。HackerNewsやGitHubなど構造化されたサイトのデータ抽出、RAG向けのWebコンテンツ収集、大量URLのリンク解析などに真価を発揮します。単一バイナリ12MBで依存ゼロ。MCP内蔵なのでAIエージェントから直接利用できます。Markdown/セマンティックツリー出力が充実しており、LLMが消化しやすい形でデータを返してくれます。SPAへの対応は今後のバージョンアップで拡充予定です。静的サイトや構造化データの処理では現時点でも大きな差をつける性能を見せます。

AGPLライセンスのため、ネットワーク経由でサービスを提供する場合はソースコード開示義務があります。商用利用の際はライセンス条件を確認してください。

向いている場面: RAG用のWebクロール、大量URLのコンテンツ抽出、CI/CDパイプラインでの軽量ブラウザ処理、リソース制約のある環境。

steel-browser — ブラウザ自動化を本番運用するインフラ/SREチーム

PlaywrightやPuppeteerで書いたスクリプトをそのまま本番環境で安定運用したいチーム向けです。フィンガープリント偽装、プロキシ自動ローテーション、CAPTCHA対応など「本番で必ずぶつかる壁」をインフラ層で解決してくれます。REST APIでセッション管理できるため、マイクロサービスへの組み込みも自然です。Docker一発でデプロイ可能です。RailwayやRenderへのワンクリックデプロイも用意されています。Apache-2.0なのでSelf-hosted版も自由に利用できます。

利用時は対象サイトの利用規約とrobots.txtを必ず確認してください。

向いている場面: Webスクレイピングの本番運用、bot検出回避が必要なデータ収集、既存Playwrightスクリプトのインフラ強化、チーム共有のブラウザ自動化基盤。

選び方フローチャート

選び方フローチャート

総合サマリ

観点 playwright-CLI agent-browser browser-use Lightpanda steel-browser
セットアップ ○ ○ △ ◎ △
速度 ○ ○ △ ◎ ◎
メモリ △ △ △ ◎ ○
SPA対応 ◎ ◎ ◎ ○ ◎
認証永続化 ◎ ◎ ○ △ ○
並列実行 ○ △ — ◎ —
エラー耐性 △ ◎ △ ○ ◎
JS重量級サイト ◎ ◎ ◎ △ ◎
トークン効率 ◎ ○ ○ ○ ○
出力品質 ○ ◎ ○ ○ ○

◎=この観点で特に優れている。○=実用的。△=制約あり。—=未テスト。

おわりに

筆者は普段、Claude Codeと組み合わせてplaywright-CLIを使っています。認証管理の充実度とトークン効率の良さが、日常の開発ワークフローによく合っているためです。

5ツールはそれぞれ得意な領域が明確に分かれています。認証管理ならplaywright-CLI、エージェント開発ならagent-browser、自然言語での自律操作ならbrowser-useが適しています。大量クロールならLightpanda、本番インフラならsteel-browserです。ご自身のユースケースに合ったツールをぜひ試してみてください。

本記事のデータは2026年3月時点の計測結果です。この領域は月単位で新ツールが登場し、既存ツールも急速に進化しています。最新バージョンで改めて検証する価値は十分にあります。

リンク

GMOペパボ株式会社
GMOペパボ株式会社Publication

表現活動を支援し「人類のアウトプットを増やす」というミッションに取り組むGMOペパボのエンジニアの記事が集まる Publication です。

Discussion