Browser Agentとは
Browser Agentとは、AIがブラウザを自律的に操作し、Webページの閲覧やフォーム入力
読み: ブラウザ・エージェント
AIがブラウザを自律的に操作し、Webページの閲覧やフォーム入力、データ取得といった一連の作業を人間の代わりにこなす技術。PlaywrightやPuppeteerといったブラウザ自動化フレームワークをバックボーンとし、LLMが状況判断と操作指示を担う。単純なスクレイピングとは異なり、ページ遷移やログイン処理を含む複雑なワークフローを、指示文ひとつで完遂できる点に特徴がある。
かんたんに言うと
ブラウザの前に座って検索し、クリックし、入力する、その作業員をAIに置き換えたものである。人間が画面を見て判断しながらやっていた操作を、AIが代行する。
LLMとPlaywrightの分業で成り立つBrowser Agentの基本概念
Browser Agentの中核は、実はAIではない。PlaywrightやPuppeteerといったブラウザ自動化ライブラリである。これらがChromiumやFirefoxをヘッドレスで起動し、DOMの読み取りやクリック、スクリーンショット取得を担当する。
AIの役割は「次に何をするか」の判断に限定される。
ページのHTMLを受け取り、目的に照らして次のアクションを決め、Playwrightに指示を出す。この分業構造を理解していないと、AIが直接ブラウザを動かしていると誤解しがちである。実際にはLLMは操作の頭脳であり、手足はあくまでPlaywrightやSeleniumのようなツール群が担っている。
なお、巨大なWebサイトのHTMLをそのままLLMに入力するとトークン制限に引っかかるかコストが跳ね上がるため、実際にはHTMLから不要なタグを削除して圧縮する前処理が介在している。
Browser Agentの処理フロー
Computer Useが変えた前提
2024年にAnthropicがComputer Useを発表し、ブラウザ操作の設計思想が変わった。従来のBrowser AgentはDOM解析に依存していた。HTMLの構造を読み、CSSセレクタやXPathで要素を特定する。だがDOMが複雑なSPAや、iframeが入れ子になった管理画面では、要素の特定だけで苦労する。
Computer Useはアプローチが根本的に異なる。
スクリーンショットを撮影し、画面をピクセル単位で視覚的に理解する。ボタンの位置もテキストの内容も、人間と同じように「見て」判断する。DOM解析が不要になるため、APIもセレクタも存在しないレガシーな社内システムでも操作できる。とはいえ、視覚認識の精度はまだ完璧ではない。小さなアイコンの判別や、ダークモードでのコントラスト不足など、人間なら迷わない場面でAIが誤認するケースは残っている。
加えて、スクリーンショットを頻繁にVLM（Vision Language Model）へ送るため、DOM解析型に比べて実行速度が遅く、APIコストも高くなりやすい。
スクレイピングとの境界線
企業のデータ収集担当者にとって、Browser Agentとスクレイピングの違いは死活問題である。
従来のスクレイピングはHTTPリクエストを投げてHTMLを取得し、パースする。高速で効率的だが、JavaScriptで動的に描画されるページには無力である。HeadlessブラウザでJSを実行するスクレイピングもあるが、あくまで「ページを開いてデータを取る」という一方向の処理にとどまる。
Browser Agentは双方向である。
ログインし、検索条件を入力し、結果をフィルタリングし、CSVをダウンロードする。途中でCAPTCHAが表示されたら回避策を試み、セッションが切れたら再ログインする。この「判断しながら操作し続ける」能力が、定型的なデータ取得ツールとBrowser Agentを隔てる壁である。実際に競合他社の価格調査を自動化しようとしたことがある人なら、ログイン後の画面遷移がいかに厄介かを身をもって知っているだろう。
さらに、Browser Agentにはエラー時の自己修復能力がある。ボタンが見つからなければページをスクロールし、ポップアップが出れば閉じてから再試行する。この自己修復ループこそ、従来の自動化スクリプトとの決定的な差である。
AIにブラウザを渡すリスク
ここまで読むと便利そうに聞こえるが、セキュリティの観点からは頭が痛い。
Browser Agentにログイン情報を渡すということは、AIに社内システムの認証情報を預けることを意味する。エージェントが誤操作でデータを削除したり、意図しないページに機密情報を入力したりするリスクは現実に存在する。さらに、エージェントの操作ログが外部のLLMプロバイダに送信される構成であれば、画面に表示された顧客情報や社内文書がそのままAPIリクエストに含まれてしまう。
対策はある。操作可能なドメインをホワイトリストで制限する。認証情報はエージェントに直接渡さず、セッション管理を分離する。操作ログを全件記録し、監査可能な状態を維持する。そして最も現実的な安全策は、送金や削除など重要な操作の直前に人間が内容を確認して承認ボタンを押すHuman-in-the-loopのフローを組み込むこと。
便利さとリスクは表裏一体であり、導入前にセキュリティポリシーの整備が先決である。ツールを入れてから考えるのでは遅い。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。