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	Playwright
主導	Google	Microsoft
ブラウザ対応	主にChrome / Chromium	Chromium、Firefox、WebKit
言語対応	主にJavaScript / TypeScript	JavaScript / TypeScript、Python、Java、.NET
自動待機	明示的な待機が多い	Locatorとauto-waitingが強い
コンテキスト分離	対応しているが中心機能ではない	BrowserContextが強力
ツールチェーン	シンプルで成熟	Codegen、Trace Viewer、レポートが充実
典型用途	Chrome自動化、スクリーンショット、PDF、軽量取得	クロスブラウザE2Eテスト、複雑なフロントエンド自動化

ブラウザ対応

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にブラウザ操作能力を与える。

browser-harnessとは

構造として、browser-harnessは手動操作用のブラウザ拡張というより、Agent用のブラウザランタイムに近い存在です。

中心となる考え方は次の通りです。

ChromeまたはChromiumに直接接続する。
CDP WebSocketでページを操作する。
スクリーンショット、座標クリック、DOM、ネットワークリクエスト、raw CDPを組み合わせる。
タスク用helperを agent-workspace/agent_helpers.py に置く。
サイト固有の知見を agent-workspace/domain-skills/ に残す。
コアを薄く保ち、大きな自動化プラットフォームにしない。

READMEによると、コア構成はおよそ4つの主要ファイル、約1000行のコードで、install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py、agent-workspace/domain-skills/ が中心です。

重要なのは、あらゆるサイトの機能を内蔵することではありません。実際のブラウザに近い操作層をAgentに渡し、具体的なタスクの中で足りない能力を補わせることです。

従来のブラウザ自動化との違い

従来のブラウザ自動化は、Playwright、Selenium、Puppeteerのようなテストフレームワークを中心に発展してきました。ページを開き、要素を探し、クリックし、結果を検証するような決定的なスクリプトに向いています。

browser-harnessが対象にするのは別の種類のタスクです。ユーザーが目標を伝えると、Agentがページを探索し、状態を判断し、ポップアップを処理し、helperを追加し、サイトの知見を再利用します。重視しているのは、対話の途中で適応する力です。

違いは次のように整理できます。

Playwrightは人がスクリプトを書き、Agentがそれを実行する場面に向いている。
browser-harnessはAgentがページを見ながら行動する場面に向いている。
従来の自動化は固定フロー寄り。
browser-harnessはオープンなタスク寄り。
従来のスクリプトはselectorに依存しやすい。
browser-harnessはまずスクリーンショットを見て、必要に応じてDOMやCDPへ戻る。

これはPlaywrightを置き換えるという意味ではありません。安定したテストではPlaywrightの方が成熟しています。browser-harnessの価値は、実際のWebページをAgentが操作できる環境に変える点にあります。特にページ構造が複雑で、手順が固定されず、その場の判断が必要なタスクに向いています。

なぜ実際のChromeを重視するのか

多くのブラウザAgentツールは、隔離されたヘッドレスブラウザを使います。デプロイは簡単でバッチ処理にも向いていますが、実務で使っているログイン状態、拡張機能、履歴、ブックマーク、普段のブラウザ環境をそのまま使えるとは限りません。

browser-harnessはローカルChromeとBrowser Use cloud browserをサポートします。ローカルブラウザでは主に2つの方法があります。

chrome://inspect/#remote-debugging で現在のChromeインスタンスへの接続を許可する。
--remote-debugging-port=9222 --user-data-dir=... で隔離profileを起動する。

実アカウント内の作業をAgentに任せたい場合、ドキュメントは前者を推奨しています。普段のChromeのログイン状態、拡張機能、ブックマークを再利用できるからです。無人運用やポップアップに邪魔されたくない場合は、隔離profileやクラウドブラウザの方が扱いやすいです。

つまり、実際のChromeはユーザーのワークフローに近い一方で、セキュリティ境界はより敏感です。隔離ブラウザは制御しやすい一方、ログインや環境構築をやり直す必要があります。

編集可能なhelperとdomain skills

browser-harnessで面白いのは、「Agentが何を学ぶか」がプロジェクト構造に組み込まれている点です。

agent-workspace/agent_helpers.py には、タスク中に追加されたhelperを置きます。たとえばファイルアップロードに既存機能が足りない場合、Agentは安定したアップロード用関数を追加できます。次に似たページに出会ったとき、ゼロから始める必要がありません。

agent-workspace/domain-skills/ には、サイト単位の知見を置きます。READMEではLinkedIn outreach、Amazon注文、経費精算システムなどが例に挙げられています。これらのskillは手書きするより、実際のタスクからAgentに生成させることが推奨されています。その方が実際のページ挙動に近くなるからです。

この考え方はブラウザ自動化に合っています。難しいのは「ボタンをどう押すか」ではなく、たとえば次のような点です。

ログイン後にどのページへ遷移するか。
どのポップアップが主フローを妨げるか。
どのselectorが安定しているか。
アップロード、ダウンロード、iframe、shadow DOM、クロスオリジン部品をどう扱うか。
特定の管理画面にどんな非同期状態や待ち時間があるか。

こうした知見が一回のログにしか残らないと、すぐ失われます。domain skillsとして残すことで、Agentが次第に扱いやすくなります。

向いている場面

browser-harnessが向いているのは次のようなタスクです。

実際のWeb管理画面を操作する。
APIのないシステムで繰り返し作業を行う。
ログイン状態への依存が強い個人または企業のWebタスク。
スクリーンショットでページ状態を判断する複雑な操作。
実行中にAgentがツールやサイト知識を追加する必要があるタスク。
複数のサブAgentが独立したブラウザを使うタスク。
ブラウザAgentのランタイム設計の研究。

具体例としては、Web表の整理、社内フォームの送信、請求書のダウンロード、ファイルアップロード、経費精算、注文状況の確認、SaaS管理画面の設定、ログイン後ページからの情報抽出などがあります。

静的ページの取得だけなら、ブラウザは不要かもしれません。プロジェクトの SKILL.md でも、静的ページはHTTPでまとめて取得できることが多いと説明されています。ブラウザは、ページ状態、ログイン状態、操作が本当に必要な場面に残すべきです。

注意すべきリスク

AI Agentに実際のChromeを操作させるのは強力ですが、危険もあります。

第一に、権限境界を明確にする必要があります。実際のChromeにはメール、決済管理画面、クラウドコンソール、社内システム、個人アカウントが含まれるかもしれません。Agentがブラウザを操作できるなら、それらのWeb権限の一部を持つことになります。

第二に、認証情報をモデルに渡さないことです。ログイン、支払い確認、二段階確認などの敏感な手順はユーザーが処理すべきです。Agentはログイン完了を待てますが、スクリーンショットからパスワード、確認コード、支払い情報を読み取ったり入力したりすべきではありません。

第三に、自動化は委任と同じではありません。単純に見えるWeb作業でも、誤クリック、データ削除、一括送信、取り消せない操作が含まれることがあります。まずは読み取り専用、低リスク、巻き戻せる作業から始めるのが安全です。

第四に、domain skillsにプライバシーを漏らさないことです。サイト知識は共有できますが、アカウント、内部URL、顧客データ、座標ログ、一回限りの作業詳細を書くべきではありません。

第五に、ブラウザ接続方式は慎重に選ぶべきです。普段のログイン状態を使うなら現在のChromeが便利です。長時間の自動化では、隔離profileやクラウドブラウザの方が制御しやすいです。

AI Agentツールとしての意味

browser-harnessは、Agentツールの実用的な方向性を示しています。大きなプラットフォームを作るより、モデルが実環境に直接触れるインターフェースを渡すという考え方です。

多くのAgentは両端で失敗します。一方ではモデルが推論できても実際のページに触れない。もう一方では自動化フレームワークが強力でも、人がフローを固定して書く必要がある。browser-harnessはこの2つをつなごうとしています。ブラウザが現実の状態を持ち、Agentが観察し、判断し、必要なツールを足します。

「self-improving harness」の意味もそこにあります。Agentが魔法のように賢くなるという話ではありません。再利用できる操作経験をプロジェクト構造に置き、次のタスクで同じ遠回りを減らすということです。

開発者にとっての価値は主に3つあります。

個人Agentのブラウザ制御層。
ブラウザ自動化とAgentワークフローを研究するためのサンプル。
Webフローを再利用可能なskillに変える実験基盤。

すべてのブラウザ自動化問題への答えではありませんが、方向性は明確です。Agentが本当に人の作業を助けるなら、ツール層はAPIを呼ぶだけでなく、人が毎日使うWeb画面を理解し操作できる必要があります。

domain skillsとは

domain skills は、Agent向けのサイト操作マニュアルと考えるとわかりやすいです。

通常のユーザードキュメントでも、一回限りのスクリプトでもありません。実測済みのサイト知識に近いものです。

そのサイトはブラウザ操作に向いているか。
APIがあるなら、どのAPIを優先すべきか。
Web操作が必要なら、どのURLから入るべきか。
どのDOM構造、aria-label、ボタン挙動が確認済みか。
どの一般的な方法が失敗するか。
どの場面で停止し、人間の介入を求めるべきか。

この内容は人間がレビューでき、Agentもタスク中に読めます。現場での手探りを、保守できる経験に変える仕組みです。

盲目的にクリックさせるものではない

良いブラウザAgentは、すべての問題をWebページを開き、スクリーンショットを見て、ボタンを押す作業に変えるべきではありません。

domain skills の重要な経験の一つは、いつブラウザを使わないかをAgentに伝えることです。

たとえばArXivでは、論文検索、メタデータ、要約をAtom APIやHTML metaタグから直接取得できます。HTTPリクエストの方がブラウザを開くより速く、安定し、解析もしやすいです。

GitHubも似ています。リポジトリ、ユーザー、releaseデータはREST APIを優先します。ファイル内容は raw.githubusercontent.com を優先します。GitHub Trendingのように等価なAPIがないページだけ、ブラウザ操作が必要になります。

つまりbrowser-harnessの考え方は「ブラウザ万能」ではありません。API、HTTP、静的ページで解決できないときに、実ページ操作をAgentに任せるということです。

サイト単位の知識を記録する

従来の自動化スクリプトは、よく一つのタスクを中心に書かれます。

1

ページを開く -> キーワードを入力 -> ボタンをクリック -> ファイルをダウンロード

このスクリプトはタスクを完了できますが、経験はコードの中に散らばりがちです。サイトが変わるとスクリプトが壊れ、別のタスクでは経験を再利用しにくくなります。

domain skills の粒度は、サイト単位の知識ベースに近いです。関心があるのは次のような点です。

Amazon検索結果でどのコンテナselectorが安定しているか。
GitHubのどのデータをREST APIで取るべきか。
LinkedIn招待管理ページのボタンの aria-label がどう違うか。
Shopify Adminのどのページがembedded appか。
Shopify Polarisの入力欄が普通のJS value設定だけでは動かない理由。
Browser Use Cloudのブラウザインスタンスをどう作成、一覧、清理するか。

これらは一回のタスク手順ではなく、多くの今後のタスクで使う判断材料です。

例：Amazonの商品検索

Amazonの商品検索で重要なのは、どう検索するかだけではなく、どの経路が安定しているかです。

信頼しやすい方法は、毎回トップページを開いて入力を模擬するのではなく、検索URLを直接使うことです。検索結果は [data-component-type="s-search-result"] のようなコンテナから取得できます。タイトル、価格、評価、レビュー数、スポンサー表示も、それぞれ安定しやすいDOMの取得元があります。

この経験はAgentにとって価値があります。なければAgentはスクリーンショットからボタンを推測し、selectorを何度も試すかもしれません。あれば、より安定した抽出経路に直接進めます。

さらに、skillは罠も記録できます。使えそうに見えるselectorが、スポンサー枠や関連推薦で誤読することがあります。これは実測して初めてわかる種類の問題です。

例：LinkedInの招待管理

LinkedInのようなサイトは実アカウントのワークフローに近く、リスクも高くなります。

招待管理ページでは、AcceptとIgnoreボタンの aria-label 形式が異なります。一方からもう一方を単純に推測することはできません。招待カードによってはAcceptが <button> ではなく <a> としてレンダリングされ、通常のCDPクリックで受諾が発火しないこともあります。

これは、実Web自動化が「要素を見つければ終わり」ではないことを示しています。ボタンラベル、イベントバインディング、ソフトナビゲーション、コンポーネント実装が、操作の成否に影響します。

Agentにとって、この経験には安全上の意味もあります。ソーシャルアカウント、招待、メッセージ、投稿に関わる操作は完全委任すべきではありません。skillは経路と罠を記録できますが、招待の一括承認、外部への送信、アカウント情報変更は人間の確認を残すべきです。

例：Shopify Admin

Shopify Adminは、バックエンド管理画面が単一ページではなく、embedded appと複雑なコンポーネントの集合であることを示します。

多くのShopify appはiframe内で動作します。Polaris React入力欄、Web Components、embedded appはそれぞれ操作方法が異なります。一部の入力欄は element.value = ... だけでは反映されず、実際のキーボード入力に近いCDP keystrokesが必要です。

この種のskillの価値は、Agentがまず現在のUI種類を判断し、その上で適切な操作方法を選べる点にあります。

Shopifyの経験は「ブラウザを使わずに済むなら使わない」ことも強調します。

読み取り専用の商品や在庫データはStorefront APIを優先する。
Admin API tokenがあるならAdmin APIを優先する。
テーマコード編集はShopify CLIを優先する。
APIがない、一回限りの設定、管理画面探索の場合だけブラウザを使う。

これが成熟したAgentのツール選択です。

例：Browser Use Cloud

domain skills はWebページのクリックだけを扱うものではありません。ブラウザランタイム周辺のAPI経験も記録できます。

Browser Use Cloudの経験では、REST APIでcloud browserを作成し、稼働中ブラウザを一覧し、zombie browserを清理し、liveUrl や cdpUrl を取得する方法などを記録できます。

つまりskillは「あるWebボタンをどう押すか」に限られません。安定した方法がある反復タスクなら、skillにできます。

API呼び出し方式。
認証ヘッダー形式。
リクエストとレスポンス構造。
検証済みステータスコード。
よくある失敗パターン。
リソース清理と回収方法。

Agentにとって、これらはすべて再利用可能な能力です。

なぜ場当たり推論より信頼できるのか

多くの人は、大きなモデルが毎回Webページを自分で理解できると期待します。しかし実タスクでは、場当たり推論だけでは安定しません。

理由は単純です。

Web UIはよく変わる。
同じボタンに複数の実装がある。
見えていることとクリックできることは違う。
クリックできても操作が本当に成功したとは限らない。
そもそもAPIを使うべきタスクもある。
人間の確認が必要な操作をモデルだけで決めるべきではない。

これらの経験をファイルにすることで、次の利点があります。

人間がレビューできる。
間違った経験を修正できる。
同じサイトの知識を継続的に蓄積できる。
新しいAgentが過去の経験を継承できる。
一時的な発見を長期知識にできる。

すべてをpromptやチャット文脈に詰め込むより安定します。

チームでの使い方

チームでbrowser-harnessを使うなら、domain skills は軽量な自動化知識ベースになります。

記録に向いている内容は次の通りです。

社内管理画面のログイン後パス。
レポート出力フロー。
よくあるポップアップ処理。
どのボタンに人間の確認が必要か。
どのページにAPI代替があるか。
実測済みの信頼できるselector。
Agentに自動実行させてはいけないタスク。

最初から完全である必要はありません。現実的には、低リスク、高頻度、巻き戻し可能なフローから始めます。読み取り、ダウンロード、整理、確認のようなタスクを先に任せ、安定したら経験をskillにします。

チーム管理者にとって、skillファイルは自動化の境界を可視化します。Agentが何を知り、何をでき、どこで止まるべきかを確認できます。

注意すべき境界

domain skills はAgentの成功率を高めますが、高リスク操作を完全自動化するためのものではありません。

守るべき境界は次の通りです。

パスワード、Cookie、token、顧客データ、内部の機密URLを記録しない。
支払い、削除、一括送信、アカウント変更、外部公開には人間の確認を残す。
skillには検証日と適用範囲を書く。
サイト改版後はskillが失効することを前提に再検証する。
風控回避やプラットフォーム制限の回避を目的にしない。

つまり、domain skillはAgentをより安定させるためのもので、無制限に行動させるためのものではありません。

3つの比較

観点	Puppeteer	Playwright	browser-harness
対象	エンジニア	エンジニアとテストチーム	AI Agent
主目的	Chromeを制御する	安定したクロスブラウザ自動化	Agentに実ブラウザを操作させる
スクリプト方式	手書きJS/TS自動化	スクリプト + テストフレームワーク	ユーザーが目標を出し、Agentが実行
要素定位	CSS、XPath、DOM API	Locator、テキスト、role、CSS	スクリーンショット、座標、DOM、CDP
待機	手動制御が多い	自動待機が強い	Agentが観察して調整
ブラウザ環境	通常は自動化用ブラウザ	通常はテスト用ブラウザ	実際のChromeに接続することが多い
向いている用途	Chromeスクリプト、スクリーンショット、PDF、軽量取得	E2Eテスト、クロスブラウザ検証、複雑なSPA	AIアシスタント、開かれたWebタスク、実アカウントのワークフロー

コードの感触

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/