browser-harness、Playwright、Puppeteerの選び方：ブラウザ自動化ツール比較

ブラウザ自動化と自動テストの分野では、Playwright と Puppeteer がよく比較されます。どちらもブラウザを制御し、ページをクリックし、コンテンツを取得し、スクリーンショットやPDFを生成できます。また、どちらもChrome DevTools Protocolと深い関係があります。

そこに browser-use/browser-harness を加えると、問題は「どのテストフレームワークが強いか」だけではなくなります。比較対象は2種類のツールになります。

• Playwright / Puppeteer：人間のエンジニアが決定的なスクリプトを書くためのツール。
• browser-harness：AI Agentが実際のブラウザを操作するためのツール。

前者はテスト、スクレイピング、工程化された自動化に向いています。後者はClaude Code、Codex CLI、GeminiのようなAgent向けのブラウザ制御層に近いです。

PlaywrightとPuppeteerの関係

Puppeteer はGoogle Chromeチームから生まれ、ChromiumとChrome自動化に自然に最適化されています。APIは簡潔で、エコシステムも成熟しており、Chromeを中心にスクリーンショット、PDF生成、ページ取得、軽量自動化を行うのに向いています。

Playwright はMicrosoftが保守しており、初期のPuppeteerに関わる流れとも深い関係があります。Puppeteerから得られた経験を取り込みつつ、クロスブラウザ対応、自動待機、コンテキスト分離、テストレポート、デバッグツールをより充実させています。

簡単に言うと：

• Chrome中心の軽量タスクだけなら、Puppeteer は今でも扱いやすい。
• クロスブラウザE2Eテスト、複雑なSPA自動化、チームでのテスト基盤なら、Playwright の方が向いていることが多い。

主な違い

ブラウザ対応

Puppeteer の強みはChromeです。Chromiumとの結びつきが強く、Chrome制御、PDF生成、スクリーンショット、簡単なスクレイピングが目的なら、学習コストは低いです。

Playwright の強みはクロスブラウザです。Chromium、Firefox、WebKitをネイティブにサポートします。WebKitは特に重要です。Safari固有の問題はChromeだけでは検出できないことがあるからです。デスクトップ、モバイル、複数エンジンをカバーしたいアプリでは、Playwrightが主力になりやすいです。

最初の分岐はここです。ChromeだけならPuppeteerで十分です。クロスブラウザテストを本気で行うなら、まずPlaywrightを検討します。

自動待機と安定性

ブラウザ自動化で面倒なのは、クリック方法そのものより、ページが準備できているかどうかです。要素がまだDOMにない、覆われている、アニメーション中、disabledのまま、ということがよくあります。

Puppeteerでは次のように書くことが多いです。

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

問題はありませんが、待機ロジックはエンジニアが考える必要があります。ページが複雑になるほど、waitForSelector、waitForTimeout、リトライ処理が増えがちです。

PlaywrightのLocatorと自動待機はより完成度が高いです。

1

await page.locator('#submit-btn').click();

クリック前に、Playwrightは要素が表示され、操作可能で、安定しており、覆われていないかを確認し、合理的な時間内でリトライします。React、Vue、Next.jsのように非同期レンダリングが多い現代的なWebアプリでは、flaky testを減らす上で大きな効果があります。

複数アカウントとコンテキスト分離

複数ユーザーを模擬したい場合や、複数タスクで同じブラウザプロセスを共有しながらCookie、LocalStorage、Sessionを分離したい場合、BrowserContext が重要です。

Puppeteerもコンテキスト分離をサポートしますが、Playwrightはそれを中核機能として扱っています。1つのブラウザインスタンス内に、独立したcontextを素早く作れます。それぞれがクリーンなブラウザ環境のように振る舞い、完全なブラウザプロセスを何度も起動する必要がありません。

これは次の場面で役立ちます。

• 複数アカウントの並行テスト。
• 複数ロールのワークフローテスト。
• EC、IM、共同編集ドキュメントなどの複数ユーザー場面。
• Cookieとログイン状態を分離したい取得タスク。

ツールチェーンの違い

Playwrightはより工程化された選択肢です。テスト開発で使う機能が多く内蔵されています。

• codegen：Webページ上の操作からスクリプトを自動生成する。
• Trace Viewer：失敗時のスクリーンショット、DOM、ネットワーク、consoleログを追跡する。
• Test Runner：アサーション、並列実行、リトライ、レポート、プロジェクト行列に対応。
• Locator：テキスト、role、label、test id、CSSなどで要素を定位する。

Puppeteerはより軽量なブラウザ制御ライブラリです。肥大化しておらず、APIが直接的で、スクリプト、サーバー側ジョブ、独自の自動化フローに組み込みやすいです。

企業レベルのテスト基盤を作るなら、Playwrightの周辺ツールが多くの手間を減らします。Node.jsスクリプトでWebページをPDFにしたり定期的にスクリーンショットを撮ったりするだけなら、Puppeteerの方がすっきりします。

browser-harnessの位置づけ

browser-harness はPlaywrightやPuppeteerと同じ種類のツールではありません。

PlaywrightとPuppeteerは主に「人間がスクリプトを書く」ことを前提にしています。エンジニアがselector、待機条件、アサーション、例外処理を決めます。追求するのは決定性です。同じページ状態で同じスクリプトを実行すれば、同じ結果になるべきです。

browser-harnessは主に「AI Agentがブラウザを操作する」ことを前提にしています。巨大な高級APIを提供するのではなく、CDPで実際のChromeに接続し、スクリーンショット、座標クリック、DOM、ネットワークリクエスト、helperをAgentに渡します。Agentはページを観察し、次の手を判断し、足りない能力があればhelperを追加し、サイト経験をskillに変えます。

そのため、次のようなオープンなタスクに向いています。

• 管理画面にログインして請求書をダウンロードする。
• 社内システムでフォームを入力する。
• よく改版されるOAやSaaSページを扱う。
• 固定スクリプトではなく、ユーザーの目的に沿ってページを探索する。
• Claude CodeやCodex CLIにブラウザ操作能力を与える。

3つの比較

コードの感触

PuppeteerはChromeを直接制御している感覚に近いです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

PlaywrightはLocatorと自動待機を強く意識します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harnessの体験はまったく違います。通常は完全なスクリプトを書かず、Agent環境で目標を伝えます。

1

管理画面を開いて、先月の請求書をダウンロードし、経費精算用に整理してください。

Agentはbrowser-harnessを使って次のような流れを繰り返します。

• スクリーンショットを撮り、現在のページを理解する。
• 座標をクリックする、または要素を見つける。
• テキスト入力、ファイルアップロード、ダウンロードを行う。
• ポップアップに遭遇したら閉じ方を判断する。
• helperが足りなければコードを追加する。
• 再利用できる流れをdomain skillにする。

これは従来のテストスクリプトではなく、ブラウザAgentの作業スタイルです。

どう選ぶか

Puppeteer を選ぶ理由は次のような場合です。

• プロジェクトが主にNode.jsで動く。
• ChromeまたはChromiumだけでよい。
• タスクがスクリーンショット、PDF生成、簡単なページ取得、軽量自動化。
• シンプルなAPI、少ない依存、自分で細部を制御したい。
• Chrome DevTools Protocolへの依存が深い。

Playwright を選ぶ理由は次のような場合です。

• 標準的なUI自動化やE2Eテストを行う。
• Chromium、Firefox、WebKitをカバーしたい。
• チームの主言語がPython、Java、C#かもしれない。
• ページが複雑なSPAで、非同期状態が多く、flaky testが起きやすい。
• codegen、Trace Viewer、テストレポート、並列テストが必要。

browser-harness を選ぶ理由は次のような場合です。

• AI Agentを開発または利用している。
• モデルに人間のように実際のブラウザを操作させたい。
• 手順が固定されず、ページを見ながら判断する必要がある。
• 対象サイトがよく変わる、またはポップアップ、iframe、shadow DOMが多い。
• 実際のWebワークフローをClaude Code、Codex CLIなどに任せたい。

まとめ

Playwright と Puppeteer は、人が信頼できるスクリプトを書くためのブラウザ自動化ツールです。Puppeteerはより軽くChromeに近い。Playwrightはより総合的で、クロスブラウザテストや複雑なフロントエンドアプリに向いています。

browser-harness は別の方向です。PlaywrightやPuppeteerでテストを書くことを置き換えるためではなく、AI Agentに実際のブラウザを操作させるためのものです。従来のスクリプトが持つ決定性の一部を手放す代わりに、オープンなタスクへの適応力を得ます。

したがって、答えは三択ではなく、タスクの層で分けるべきです。

• テスト工程：Playwrightを優先。
• Chromeの軽量スクリプト：Puppeteerが合う。
• AI AgentにWeb上の作業をさせる：browser-harnessを見る。

参考資料：

• browser-use/browser-harness：https://github.com/browser-use/browser-harness
• Playwright公式ドキュメント：https://playwright.dev/
• Puppeteer公式ドキュメント：https://pptr.dev/
• Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/