browser-use は、この二年で最も話題になったブラウザエージェントのライブラリの一つです。一文でタスクを伝えると、自分でブラウザを開き、ページを読み、ボタンを押し、フォームに入力して、結果を返します。自動化の到達点のように聞こえますが、実際に使うと、歩数ごとに課金される賢い研修生のような存在で、仕事はできても落とし穴を一つずつ踏んでいきます。
公式リポジトリ情報
プロジェクトは GitHub 上にあり、組織名は browser-use、リポジトリ名も browser-use、ライセンスは MIT、Python 製で、スター数は十万を超えています。土台は Playwright で実ブラウザを操作し、エージェントのループがページを理解して次の行動を決めます。接続できるモデルは OpenAI、Anthropic、Google など各社のほか、ローカルモデルも使えます。運営側は有料のクラウドブラウザサービスも提供していますが、それはこのオープンソースのライブラリとは別物で、ライブラリ自体のセルフホストは無料です。
仕組みがそのまま料金の構造になる
一「歩」はこう進みます。今のページ構造をテキスト化して大規模モデルに渡し、モデルがどこを押すか何を入力するか判断し、実行後に新しいページを見て、を繰り返します。数サイトで価格を比べて表に入力するような単純そうな仕事でも、二十から三十歩、つまりモデル呼び出しが二十から三十回にすぐなります。旗艦モデルでは一回のタスク料金が想像より一桁高くなることもあり、安いモデルに替えると判断ミスが増えて歩数が膨らみ、結局高くつきます。節約の正攻法は、実タスクで一回あたりの費用を測ってから規模を決めることです。
導入コスト：入れるのは簡単、育てるのは大変
ローカル導入のハードルは高くありません。Python 環境に Playwright とブラウザ本体があれば動きます。初回はダウンロード量と依存関係の手間が中心です。大変なのは継続運用で、サーバー上のヘッドレスブラウザはフォント、ポップアップ、タイムアウト、メモリ回収への対処が必要で、サイトのリニューアル一度で昨日まで動いたタスクが壊れることもあり、誰かが見続けて直す体制が要ります。一回きりのスクリプトなら問題ありませんが、本番システムとして使うならサービスを運用するつもりで人を配置してください。
四つの本当の落とし穴
第一に、ログインの壁と認証。ログイン、SMS 認証、人間確認が必要なサイトでは頻繁に止まります。自分の実ブラウザのログイン状態を流用すれば一部は回避できますが、アカウントを自動化プログラムにさらすことになり、リスクは自己負担です。第二に、ウェブページからのプロンプト注入。ページの文字はモデルの文脈になるため、悪意あるページが誤クリックや情報漏えいを誘導し得ます。支払いやアカウント操作のタスクは特に隔離が必要です。第三に、成功率の不安定さ。同じタスクが今日成功し明日失敗するのは珍しくなく、注文や申込みのようなやり直しの利かない仕事を無人で回すのには向きません。第四に、遅さ。各歩でモデルの応答を待つため、一タスク数分は普通で、まとめて回すと時間と API 料金が一緒に膨らみます。
向いているのは、流れが変わり続けてスクリプトに固定できないウェブの雑務です。競合の巡回確認、フォームの転記、ページ内容の構造化などで、そばに結果を確認する人がいる場合です。流れが固定の仕事なら、Playwright のスクリプトを書くか従来の RPA のほうが安くて安定します。
