最近、社内の自動化スクリプトを整理していて、ふと「これPlaywrightで書くの、しんどくなってきたな」と思っていた。
そんなタイミングでBrowser-Useを知った。
Playwrightで何かスクレイピングしようとすると、XPathやCSSセレクタを一字一句正確に書かないといけない。
サイト側のHTML構造が変わった瞬間に壊れる。
その度に直すのが地味に消耗する。
Browser-Useのアプローチはシンプルで、LLMがブラウザの画面内容を判断しながら自然言語の指示通りに操作を実行する。
クリック・入力・検索を人間がやるのと同じ感覚でこなしてくれる。
コードで操作手順を書く必要がない。
Gigazineの記事で実際にデモが紹介されていた。
Geminiに「GIGAZINEの試食カテゴリ最新3件のタイトルを教えて」と聞くと、「ピザポテト」「マックフルーリー」「麻婆たまご丼」という、ハルシネーション全開の回答が返ってきた。
実際の最新記事は「二代目ベビーボティーバーガー」「絶品牛重」「マルちゃんでかまるバリシャキ辛もやし味噌ラーメン激辛」だった。
LLMに直接聞いてもリアルタイム情報は取れない、というのを改めて実感する。
Browser-Useに同じ指示を渡すと、リモートブラウザが実際に起動して画面をスクロールしながら情報を取得してくれる。
正しいタイトルが返ってくる。
これは素直に「使える」と思った。
クラウド版の統計として「78.0%の成功率」という数字が出ている。
正直、プロダクションで使うには心もとない数字ではある。
ただ、Botブロックを回避するために人間らしい動きをするリモートブラウザを使っているという設計思想は面白い。
自分の用途で考えると、毎日回すような監視系のスクリプトには向かない。
でも「週1で特定ページの情報を確認したい」「社内ツールのE2Eテストを自然言語で書きたい」みたいなケースなら十分ありだと思う。
2割失敗しても人間が確認するフローを挟めばいい。
PythonでBrowser-Useをローカルに入れる場合はこんな感じで動く。
あとはエージェントにtaskを渡すだけ。
PlaywrightでXPathを書いていた時間が、プロンプトを書く時間に変わる感覚だ。
ライブラリ選定の観点で言うと、Browser-UseはOSSで開発されていてGitHubで公開されている。
コードを読める安心感があるし、カスタマイズもしやすい。
SeleniumやPlaywrightを完全に置き換えるものではないと思うけど、「LLMが判断できるならコードは最小限でいい」という発想は、これからの自動化スクリプトの書き方を変えそうだ。
ただ一点、使う前に確認しておきたいのがサイトの利用規約。
自動データ収集を制限しているサービスは少なくない。
そこを無視してBot判定を回避する設計で使うのはリスクがある。
自分が対象にするサービスの規約は必ず読んでおくべきだ。
来週、社内で動かしている定期レポート用のPlaywrightスクリプトをBrowser-Useに書き換えてみるつもりだ。
HTMLの構造変更に振り回されなくなるなら、それだけで十分ペイする。
そんなタイミングでBrowser-Useを知った。
Playwrightで何かスクレイピングしようとすると、XPathやCSSセレクタを一字一句正確に書かないといけない。
サイト側のHTML構造が変わった瞬間に壊れる。
その度に直すのが地味に消耗する。
Browser-UseはLLMが画面を「見て」操作する
Browser-Useのアプローチはシンプルで、LLMがブラウザの画面内容を判断しながら自然言語の指示通りに操作を実行する。
クリック・入力・検索を人間がやるのと同じ感覚でこなしてくれる。
コードで操作手順を書く必要がない。
Gigazineの記事で実際にデモが紹介されていた。
Geminiに「GIGAZINEの試食カテゴリ最新3件のタイトルを教えて」と聞くと、「ピザポテト」「マックフルーリー」「麻婆たまご丼」という、ハルシネーション全開の回答が返ってきた。
実際の最新記事は「二代目ベビーボティーバーガー」「絶品牛重」「マルちゃんでかまるバリシャキ辛もやし味噌ラーメン激辛」だった。
LLMに直接聞いてもリアルタイム情報は取れない、というのを改めて実感する。
Browser-Useに同じ指示を渡すと、リモートブラウザが実際に起動して画面をスクロールしながら情報を取得してくれる。
正しいタイトルが返ってくる。
これは素直に「使える」と思った。
成功率78.0%という数字をどう読むか
クラウド版の統計として「78.0%の成功率」という数字が出ている。
正直、プロダクションで使うには心もとない数字ではある。
ただ、Botブロックを回避するために人間らしい動きをするリモートブラウザを使っているという設計思想は面白い。
自分の用途で考えると、毎日回すような監視系のスクリプトには向かない。
でも「週1で特定ページの情報を確認したい」「社内ツールのE2Eテストを自然言語で書きたい」みたいなケースなら十分ありだと思う。
2割失敗しても人間が確認するフローを挟めばいい。
PythonでBrowser-Useをローカルに入れる場合はこんな感じで動く。
pip install browser-use
pip install langchain-google-genaiあとはエージェントにtaskを渡すだけ。
PlaywrightでXPathを書いていた時間が、プロンプトを書く時間に変わる感覚だ。
ライブラリ選定の観点で言うと、Browser-UseはOSSで開発されていてGitHubで公開されている。
コードを読める安心感があるし、カスタマイズもしやすい。
SeleniumやPlaywrightを完全に置き換えるものではないと思うけど、「LLMが判断できるならコードは最小限でいい」という発想は、これからの自動化スクリプトの書き方を変えそうだ。
ただ一点、使う前に確認しておきたいのがサイトの利用規約。
自動データ収集を制限しているサービスは少なくない。
そこを無視してBot判定を回避する設計で使うのはリスクがある。
自分が対象にするサービスの規約は必ず読んでおくべきだ。
来週、社内で動かしている定期レポート用のPlaywrightスクリプトをBrowser-Useに書き換えてみるつもりだ。
HTMLの構造変更に振り回されなくなるなら、それだけで十分ペイする。