browser-use/browser-harness は、AI Agent向けのブラウザ制御ツールです。目的は重い自動化フレームワークをもう一つ作ることではなく、LLMを実際のChromeに直接接続し、CDP経由で閲覧、クリック、スクリーンショット、ダウンロード、アップロード、フォーム操作を行えるようにすることです。
READMEでは、このプロジェクトを「薄く、編集可能なCDP harness」と位置づけています。タスクに必要なhelperが足りない場合、Agentは実行中にコードを追加し、再利用できる経験をdomain skillsとして残せます。
この種のツールが重要なのは、ブラウザが今でも多くの実務の入口だからです。管理画面、SaaSダッシュボード、ECサイト、採用サイト、CRM、経費精算、クラウドコンソール、ドキュメント基盤などは、安定したAPIがなかったり、API権限の取得がWeb画面より難しかったりします。Agentがブラウザを確実に操作できることは、自動化の最後の距離を埋めることに近いです。
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画面を理解し操作できる必要があります。
まとめ
browser-use/browser-harness が注目に値するのは、高度な機能を大量に包んでいるからではありません。実際のChrome、CDP、スクリーンショット駆動、編集可能なhelper、サイトskillの蓄積、ユーザー権限の境界という、ブラウザAgentの重要問題を正面から扱っているからです。
安定したE2Eテストを書くだけなら、PlaywrightやSeleniumで十分です。CodexやClaude CodeのようなAgentに実際のWeb作業を任せたいなら、browser-harnessはAgentの働き方に近い入口になります。
実際に使うなら、低リスクなタスクから始めるのがよいです。まずページを読ませ、スクリーンショットを撮らせ、情報を抽出させる。その後、クリックや送信を少しずつ試す。ページ状態を安定して認識できると確認してから、より長いフローを任せるべきです。
参考資料：