私は何年もかけてPuppeteerのスクリプトやSeleniumのテストスイートを作り込んできました。壊れやすいセレクタ、ランダムなタイムアウト、ボタンのクラス名を誰かが変更しただけで、パイプライン全体が崩壊する――お分かりですよね。OpenClawには、ブラウザ自動化のレイヤーが最初から組み込まれていると聞いて、正直疑っていました。「AIがWebをブラウズする」系の、Google検索以上のものではすぐに崩れるデモのまた別でしょう？
違いました。3か月間、毎日使った結果、OpenClawのブラウザツールは、フレームワーク全体でもっとも過小評価されている機能だと言えます。さらに、RunLobsterのようなプラットフォームはインフラをすべて処理してくれるので、Playwrightの設定ファイルに触れる必要すらありません。
実際に何をしてくれるのか、内部ではどのように動いているのか、そしてまだどこが弱いのか――順に説明します。
アーキテクチャ：あなた専用のブラウザを乗っ取らない
まず理解しておくべきことは、OpenClawが日常的に使っているChromeのセッションを乗っ取らないという点です。OpenClawは、独自のユーザーデータディレクトリを持つ、別の分離されたChromiumインスタンスを起動します。つまり、エージェントだけが触れる専用のブラウザだと考えてください。
内部のスタックは次のようになっています：
- 小さなHTTP制御サービスが、ポート18791のループバックにバインドされる
- Chrome DevTools Protocol（CDP）が低レベルのブラウザ通信を担当
- Playwrightが上に乗り、クリック、入力、フォーム記入、PDFエクスポートなどの高度な操作を実現
- Playwrightを入れていなくても、基本操作（スクリーンショット、シンプルなナビゲーション）は動作する
この分離モデルが重要です。あなた個人のブラウザセッション、保存済みパスワード、Cookieは完全に別になります。エージェントには独自のサンドボックスが用意されます。
エージェントが実際にできること
ここからが面白いところです。ブラウザツールは「URLに移動してテキストを読む」だけではありません。完全な対話（インタラクション）レイヤーです。利用できる内容は次のとおりです。
ナビゲーションとタブ：
URLへ移動、新しいタブを開く、タブ間の切り替え、タブを閉じる。エージェントは複数ページを同時に管理できるため、サイト間で価格を比較するようなタスクや、複数のダッシュボードから同時にデータを引き出すような作業に不可欠です。
クリック、タイピング、フォーム：
エージェントは任意の要素をクリックし、入力欄にテキストを打ち込み、ドロップダウンを選択し、メニューにホバーし、ドラッグ＆ドロップし、JSONを使ってフォームを一括で埋められます。参照システムを使っており、まずページのスナップショットを取得し、操作可能な要素に数値IDを割り当て、その後それらを正確にターゲットします。
スクリーンショットとスナップショット：
ビューポート全体のスクリーンショット、ページ全体のスクリーンショット、要素ごとのスクリーンショット、そしてページのアクセシビリティツリーを作成する強力な「snapshot」コマンドが利用できます。スナップショットこそが、AIが実際に読み取り、ページ構造を理解するためのものです。ピクセル解析ではなく、セマンティックなDOMを読み取っています。
ファイル操作：
ファイルのダウンロード、ダウンロード完了までの待機、入力欄へのファイルアップロード。エージェントはファイルのワークフローを最初から最後まで扱えます。
ネットワークと状態の制御：
Cookieの読み取り・設定、ローカル／セッションストレージの操作、オフラインモードのシミュレーション、カスタムHTTPヘッダーの設定、ジオロケーションの偽装、タイムゾーンの変更、デバイスプリセットの切り替え（iPhoneのエミュレーションなど）、ダーク／ライトモードの切り替え。
JavaScriptの実行：
ページのコンテキスト内で任意のJavaScriptを実行します。ネットワークリクエストを検査し、コンソール出力を確認し、JavaScriptエラーを読み取ります。宣言的な操作だけでは足りないときのための抜け道（エスケープハッチ）です。
リファレンスシステム：AIがページを「見る」仕組み
ここが賢い部分です。エージェントがページとやり取りする必要があるとき、snapshotコマンドを実行します。これにより、すべての操作可能要素に数値の参照が割り当てられたアクセシビリティツリーが生成されます。つまり、「送信と書かれた青いボタンをクリックして」と言う代わりに、エージェントは次のようなものとして見ます。
[12] button "Submit"
[13] input "Email address"
[14] link "Terms and Conditions"
そして単に、click 12、または type 13 "hello@example.com"と言うだけです。参照はフレームスコープで、iframeの中でも動作します。注意点は、参照がページ遷移をまたいで安定しないことです。ページが変わると、エージェントは新しいスナップショットを取得する必要があります。
また、よりコンパクトなスナップショットのために、役割（role）ベースの参照システム（e##のようなスタイル参照）もあります。要素が数百もある複雑なページで便利です。
私が実際に回している現場でのユースケース
毎週、ブラウザ自動化に使っていることをいくつか共有します。
競合の価格監視：私のエージェントは毎朝、競合サイトを5つ訪問し、それぞれの価格ページをスナップショットして数値を抽出し、Notionのテーブルに要約を投下します。以前は、この作業に30分かけて手作業でコピペしていました。今は、私が起きる前に終わっています。
APIがないフォーム送信：一部のベンダーポータルは、ログインしてフォームに入力することをまだ求めます。APIも、Webhookも、何もありません。エージェントがログイン（保存済みの認証情報を使用）し、フォームを埋め、送信し、証拠としてスクリーンショットを取り、Slackで私に確認を送ります。
請求書のダウンロード：私の仕入れ先の1つは、メールオプションのないWebポータル経由で請求書を送ってきます。エージェントは毎週ログインし、請求（billing）のセクションへ移動し、PDFをダウンロードして、正しいフォルダに保存します。エージェントの時間は20秒ですが、私の時間は毎週5分かかっていました。
スクリーンショットベースのレポーティング：エージェントに分析ダッシュボードへアクセスさせ、チャートの読み込みを待ち、ページ全体のスクリーンショットを撮って、朝のレポートに埋め込みます。Grafanaのカスタム連携を作ったり、API呼び出しをしたりする必要はありません。すでに存在するページをスクリーンショットするだけです。
RunLobsterが上乗せしてくれるもの
OpenClawを自前でホスティングする場合、ブラウザバイナリ、Playwrightのインストール、CDP設定、そしてすべてのセキュリティ設定を自分で管理する必要があります。サーバー上では、ヘッドレスChrome、表示用のXvfb、そしてブラウザ自動化を面倒にするLinux特有のクセに対処することになります。
RunLobster（www.runlobster.com）がその全部を扱ってくれます。ブラウザツールは、何も考えずに最初から動きます。あなたはエージェントに「壊れたリンクがないか私たちのWebサイトを見に行って」や「先月分の請求書を仕入れ先ポータルからダウンロードして」と伝えるだけで、それをやってくれます。Dockerfileも不要です。Playwrightのインストールスクリプトも不要です。CDPのポート設定も不要です。
さらに、このプラットフォームは安全性のレイヤーも提供します。サンドボックス化された実行、SSRF保護（エージェントが誤って社内ネットワークのリソースをブラウズしてしまわないようにする）、そしてエージェントごとの分離されたブラウザプロファイルにより、セッションがタスク間で混ざり合わないようになっています。
月額49ドルの定額で、ブラウザ自動化だけでも、あなたの時間を食い潰すような反復的なブラウザタスクが2〜3件でもあるなら十分に元が取れる価値があります。
待機（Wait）システムは独立したセクションに値する
OpenClawのブラウザ自動化が本番投入に耐える理由の1つが、waitコマンドです。ブラウザ自動化を書いたことがある人なら誰でも知っている通り、難しいのはボタンをクリックすることではありません。ページが「準備できたタイミング」を知ることです。
OpenClawは、連鎖した待機条件をサポートしています：
URLパターンを待つこと（OAuthのリダイレクトに便利）、networkidleのような特定のロード状態を待つこと、CSSセレクタが表示されるのを待つこと、あるいは window.dataLoaded === true のようなカスタムJavaScript述語を待つことができます。待機呼び出しごとにタイムアウトを設定できます。
つまり、もうsleep(5000)のようなごまかしは不要です。エージェントは、進行する前にまさに適切な条件を待ちます。実際には、この仕組みにより、ハードコードされた遅延を使う手作りのPuppeteerスクリプトよりも自動化の信頼性が大幅に高まります。
Limitations: Where It Still Falls Short
正直に言って、粗い部分について触れないわけにはいきません。
CAPTCHAの解決を標準機能としては行えません。 サイトがCAPTCHAを出すと、エージェントはそこで詰まってしまいます。Browserbaseのように内蔵でCAPTCHA解決を行えるサービス経由でルーティングすることはできますが、追加の依存関係とコストが発生します。
動的ページでは参照が壊れます。 常に再レンダリングされるシングルページアプリでは、エージェントがページを読み取った時点から何かをクリックしようとする時点までの間に、スナップショット参照が無効になることがあります。対処としては、各アクションの前に再スナップショットを行うことですが、その分レイテンシが増えます。
ジオブロックされたサイトは扱いが難しいです。 ブラウザは、サーバーのある場所で動作します。特定の国からアクセスしているように見せる必要がある場合は、プロキシのセットアップが必要ですが、OpenClawはネイティブには対応していません。
重いJavaScriptのサイトは遅くなり得ます。 DOM要素が何千もあるページでは、スナップショットコマンドに時間がかかり、巨大なアクセシビリティツリーが生成されます。複雑なダッシュボードでは、スナップショットの上限に当たることがあります。
マルチブラウザのオーケストレーションに対応していません。 エージェントは、プロファイルごとに一度に1つのブラウザセッションで動作します。複数のサイトを同時に本当に並列で閲覧する必要がある場合は、複数のプロファイルを用意して調整する必要があります。
Should You Use It?
APIが存在しないために手作業で繰り返し行っているブラウザ業務があるなら、はい。もちろんです。ROIは即座に得られます。
Seleniumのテストスイートを丸ごと置き換えようと考えているなら、おそらくまだ早いです。LLMによるブラウザ自動化は、柔軟で人間のようなタスクには強力ですが、回帰テストのための従来のテストフレームワークほど速くも、決定的（deterministic）でもありません。
適した領域は運用の自動化です。データ抽出、フォーム入力、レポート生成、ファイルのダウンロード、モニタリングなどがそれに当たります。これらは、ページをAIが読み取ることによるわずかなオーバーヘッドが、自然言語による指示の柔軟性によって十分に相殺されるようなタスクです。
OpenClawはエージェントに実際のブラウザを与えました。RunLobsterのようなプラットフォームが、それを日常利用として現実的にしました。その組み合わせによって、私の週から約4時間分の手作業のブラウザ作業がなくなりました。最初はデモ機能のように見えていたものとしては、かなり良い結果です。
