Browser Agent とは何か?AI がブラウザを自分で操作し始めた理由

"OpenAI の Computer Use ドキュメントは、ループ、ブラウザ/VM 分離、安全要件を説明しています。"
AI に 3 つのサイトを開かせて、機能と料金を比較し、リンク付きの表を返させる。Browser Agent が効いてくるのは、まさにこういう場面です。クローラーはページを取れますが、操作はしません。RPA はデスクトップの流れを再生できますが、ページの意味は理解しません。Playwright の固定スクリプトは精密でも、selector が変われば壊れます。
Browser Agent はその隙間を埋めます。モデルがページ状態を読み、動作を決め、ブラウザが実行し、次の変化を確認します。
この文章ではまず境界をはっきりさせます。Browser Use、Playwright MCP、Stagehand、ホスト型ブラウザ基盤、安全ルールは、それぞれ別の後続記事で扱います。
Browser Agent とは何か?
作業定義
Browser Agent は業界で統一された正式名称ではありません。Computer Use、Browser Automation Agent、AI Web Agent など、製品ごとに呼び方が違います。
このシリーズでは、次の作業定義を使います。Browser Agent = モデルの判断 + ブラウザツール + 実行環境。
核心は単純です。AI モデルがスクリーンショットや構造化データなどのページ状態を受け取り、click / type / scroll のような UI 動作を返し、ホスト側のコードがそれを実行し、更新後の状態を観察します。
コアのループ
Browser Agent の流れはこうです。
目的(ユーザーが自然言語でタスクを渡す)
↓
観察(スクリーンショット or accessibility snapshot)
↓
判断(モデルが UI 動作を返す: click/type/scroll)
↓
実行(ホストコードがブラウザで動作を行う)
↓
新しい状態(ページが変わり、再び観察する)
従来スクリプトとの違いは明確です。スクリプトは .submit-btn のような selector を固定します。フロントエンドが aria label や class を変えると壊れます。AI agent はページの意味から対象を探し直せるので、selector が変わっても進めます。
近い概念との違い
-
クローラーではない: クローラーは静的ページを取得するだけです。動作はせず、動的コンテンツやクライアント描画のページは苦手です。
-
RPA ではない: RPA は録画したデスクトップ手順を再生します。ページの意味を理解しないので、動的 UI が壊れやすいです。
-
Playwright スクリプトだけでもない: スクリプトは決定論的ですが、保守コストが高いです。class 名が 1 つ変わるだけで失敗します。
-
Computer Use はもっと広い: デスクトップ全体を扱います。Browser Agent はそのうちブラウザに絞った部分です。デスクトップ側の詳細は別記事にあります。Computer-Use Agent: AI に PC を操作させる。
Browser Agent と従来ツールの比較
このサイトにはすでに OpenClaw、Computer Use、MCP プラグイン、クローラー系の記事があります。読者は境界を混同しやすいので、ここで一度整理します。
次の表で、Browser Agent、クローラー、RPA、Selenium/Playwright スクリプト、Computer Use の違いをまとめます。
| 種類 | 核心的な特徴 | セマンティクスを理解するか | 保守コスト | 適した用途 | 代表ツール |
|---|---|---|---|---|---|
| クローラー | 静的ページを取得するだけで、操作しない | しない | 中(selector が脆い) | 静的ページのデータ取得 | Scrapy、Puppeteer、Cheerio |
| RPA | 録画したデスクトップ手順を再生する | しない | 低いが、動的 UI で壊れやすい | デスクトップ自動化、固定フロー | UiPath、Automation Anywhere |
| Selenium/Playwright スクリプト | コードが決定的 | しない | 高い(class が変わるだけで壊れる) | フロントエンドテスト、固定フロー自動化 | Selenium、Playwright、Cypress |
| Computer Use | デスクトップレベルの操作 | する | 中(モデルの適応性あり) | デスクトップアプリ自動化、クロスアプリフロー | Claude Computer Use、OpenAI Computer Use |
| Browser Agent | モデル判断によるブラウザ操作 | する | 低め(selector が変わっても再探索できる) | クロスサイト調査、API のないバックエンド、動的ページ | Browser Use、Stagehand、Playwright MCP |
説明
-
クローラー: 静的ページを取得するだけで、操作はしません。selector は脆く、class が変わるとルールが壊れます。
-
RPA: 録画再生のデスクトップフローです。ページの意味を理解しないため、動的 UI に弱く、固定フロー向きです。
-
Selenium/Playwright スクリプト: 決定性は高いですが、保守コストも高いです。class や aria label が変わるだけで壊れます。フロントエンドテストや固定自動化には向いています。
-
Computer Use: ブラウザより広いデスクトップ領域です。Browser Agent はそのブラウザ部分です。別記事はこちら。Computer-Use Agent: AI に PC を操作させる。
-
Browser Agent: 自然言語でページの意味を理解するので、selector が変わっても対象を再探索できます。ただし、実行環境、状態確認、安全な承認は必要です。クロスサイト調査、API のないバックエンドフォーム、動的ページに向きます。
サイト内の関連記事
- OpenClaw のブラウザ自動化コマンド: AI に文書を読ませる OpenClaw ブラウザ自動化実践ガイド。具体的なコマンドと安全な使い方に絞っています。
- デスクトップ級 Computer Use: Computer-Use Agent: AI に PC を操作させる。RPA との違いもここで扱います。
- MCP プラグインのブラウザ部分: MCP プラグイン完全ガイド: AI にツールチェーンを任せる。Playwright ブラウザ自動化 MCP の段落があります。
なぜブラウザ操作が必要なのか?
開発者はよく「API を直接呼べばいいのでは?」と聞きます。
公式 API があるなら、まず API を使うべきです。API は安定していて、監査しやすく、権限管理もしやすいです。
API がない、または API が不完全なときに、Browser Agent が穴を埋めます。
判断表
| 状況 | API を優先 | Browser Agent を優先 |
|---|---|---|
| 公式 API があり、しかも完全 | はい。安定していて監査しやすく、権限管理もしやすい | いいえ |
| API がない、または不完全 | いいえ。呼ぶものがない | はい。バックエンド、クロスプラットフォーム、内部ツールに向く |
| 人の体験に近い流れが必要 | いいえ。API はデータだけ返す | はい。E2E テスト、フォーム送信、UI 検証に向く |
| ログイン状態が必要 | いいえ。API 認証が複雑なことがある | はい。セッション再利用が可能 |
| 大規模な並列収集 | はい。API の方が効率的 | いいえ。ブラウザコストが高い |
| 機微なアカウント、支払い、権限 | はい。API は権限を制御しやすい | いいえ。厳格な承認が必要 |
典型的な場面
-
クロスサイト調査: GitHub release、公式ドキュメント、価格ページを順番に開かせ、リンク付きの比較表を出させる。
-
API のないバックエンドフォーム: 社内システム、レガシーシステム、クロスプラットフォーム連携は、Web 画面しかないことが多いです。
-
E2E フロントエンドテスト: ただの静止画ではなく、実際の操作を確認します。
-
ログイン状態が必要な操作: 管理画面やデータ入出力。ただし安全境界の中でのみ扱います。
-
動的コンテンツ収集: クライアント描画のページは、クローラーでは取りこぼしやすいです。
具体例
ボタンが .submit-btn から aria label に変わると、従来の Playwright スクリプトは壊れます。AI browser agent はページの意味から対象を再探索できます。
バックエンドフォームが MFA や CAPTCHA で止まったら、agent は無理に押し切るのではなく、人に引き継いで止まる必要があります。
Browser Agent の五層スタック
Browser Use、Stagehand、Playwright MCP、Browserbase を聞いても、それぞれどの層を解いているのか分かりにくいことがあります。
この図で 5 層に分けて整理します。
| 層 | 核心的な特徴 | 代表ツール/プラットフォーム | 適した場面 |
|---|---|---|---|
| モデル能力層 | スクリーン認識 → 動作生成 → 宿主実行 | OpenAI Computer Use、Gemini Computer Use、Claude Computer Use | デスクトップ自動化、クロスアプリフロー |
| MCP ツール層 | Model Context Protocol でブラウザ能力を公開、通常は structured accessibility snapshot を使う | Playwright MCP | VS Code、Cursor、Claude Code などの MCP client から呼ぶ |
| 自律型 agent 層 | 完全な autonomous browser agent。ローカルでもクラウドでも動く | Browser Use | 自律型 agent、クラウド実行、大規模運用 |
| コード + AI ハイブリッド層 | スクリプトが精度を、agent が柔軟性を担当 | Stagehand | 制御性と適応性の両方が必要な工程向け |
| クラウド基盤層 | 実行環境、セッション、可観測性を持つ Browser-as-a-Service | Browserbase、Cloudflare Browser Run | ホスト型ブラウザ、セッション管理、可観測性 |
モデル能力層(Computer Use)
OpenAI、Google、Anthropic はすべて Computer Use を提供しています。
仕組みは同じです。モデルがスクリーンショットを見て、click / type / scroll のような UI 動作を返し、宿主コードがそれを実行し、次の状態を観察します。
公式ドキュメントでは、3 つの harness が明記されています。内蔵 computer tool、カスタム Playwright/Selenium/VNC/MCP harness、コード実行 harness です。
ブラウザ / VM 環境は分離が必要です。ページ、ツール出力、PDF、メール、チャットはすべて信頼できない入力として扱うべきです。
ローカルの試作は Playwright か Selenium から始められます。より完全なデスクトップ環境なら VM や container を使います。
変わりやすいのはモデル版本や API フィールドなので、この記事では仕組みと安全境界だけを書き、具体的な model ID は公式文書に委ねます。
MCP ツール層(Playwright MCP)
Playwright MCP は Model Context Protocol を通じて、LLM にブラウザ自動化機能を公開します。
スクリーンショットだけに頼らず、structured accessibility snapshot を使います。LLM は要素 ref を使ってクリック、入力、選択を行います。
VS Code、Cursor、Windsurf、Claude Code、Claude Desktop、Codex などの MCP client と連携できます。
操作範囲は、ナビゲーション、クリック、入力、スクリーンショット、キーボード / マウス、tabs、dialogs、ネットワーク監視、mock、storage state まで含みます。
安全警告: browser_run_code_unsafe のような直接コード実行機能は RCE 相当です。信頼できる client にだけ許可してください。
この記事ではインストール手順は扱いません。Playwright MCP の詳細ガイドは別記事で扱います。
自律型 agent 層(Browser Use)
Browser Use は自らを “The Way AI uses the web” と位置づけ、Browser Harness、Hosted Web Agents、Custom Models、Cloud を提供します。
ローカルでもクラウドでも動く、完全な autonomous browser agent です。
公式サイトには anti-detect、CAPTCHA、proxy という表現があります。ただしこの記事は CAPTCHA 回避、bot 対策回避、プラットフォーム規約の回避を勧めません。これらは後続の安全・合規記事の境界説明にとどめます。
変わりやすいのは価格、benchmark、反検出の主張、クラウド機能なので、ここでは掘り下げません。
コード + AI ハイブリッド層(Stagehand)
Stagehand は browser agents 向けの SDK と位置づけられており、ブラウザ agent をより resilient、readable、production-ready にします。
主要プリミティブは act()、extract()、observe()、agent() です。
公式のメッセージは明快です。scripts が精度を、agents が柔軟性を担い、その中間に Stagehand がいます。完全なブラックボックスでも、純 selector スクリプトでもありません。
ローカル実行も Browserbase のクラウドブラウザ接続もできます。
この記事では API チュートリアルは扱いません。Stagehand の実践記事で扱います。
クラウド基盤層(Browserbase + Cloudflare)
Browserbase はブラウザを agent が使える基盤にし、Browsers、Search/Fetch APIs、Runtime、Identity、Models、Observability を提供します。
用途はログイン、動的コンテンツ、複雑な対話、テスト、調査、フォーム、データ移動です。
Browserbase と Stagehand は「ローカル開発 + クラウド実行/観測/アイデンティティ」の組み合わせになります。
Cloudflare Browser Run は headless Chrome を実行し、browser automation、web scraping、testing、content generation に使えます。
Quick Actions と Browser Sessions を提供し、Puppeteer、Playwright、CDP、Stagehand をサポートします。
公式の利用例には AI agent browsing として Playwright MCP や CDP with MCP clients が直接載っています。
session reuse、edge 実行、Markdown / screenshot / PDF / snapshot / links / structured data / crawl などの出力もサポートされます。
つまり、Browser Agent の工程はモデルだけではありません。実行環境、セッション、可観測性も必要です。
変わりやすいのは価格、制限、命名なので、ここでは深掘りしません。
どんなタスクが Browser Agent に向くか?
判断表で素早く選べるようにします。
判断表
| 向いている | 向いていない |
|---|---|
| クロスサイト調査・比較 | 安定した API があるシステム |
| API のないバックエンドフォーム送信 | 大規模な並列スクレイピング |
| E2E フロントエンドテスト | 機微なアカウント、支払い、権限 |
| 安全境界つきのログイン操作 | 自動化を明示的に禁止しているプラットフォーム |
| クライアント描画の動的コンテンツ収集 | 高頻度の繰り返し作業で API やスクリプトが向く場合 |
実行ステップの例
Browser Agent に向く典型的な流れはこうです。
-
ユーザーが自然言語でタスクを渡す: 「5 つの SaaS の価格と機能を比べて」
-
Browser Agent が公式 docs、価格ページ、機能ページを開く
-
agent がスクリーンショットまたは accessibility snapshot を読む
-
モデルがページを理解し、次の動作を決める(クリック、スクロール、入力)
-
CAPTCHA や MFA に当たったら、人の助けを待つ
-
最後に構造化された比較表を返す
もう一度、具体例
ボタンが .submit-btn から aria label に変わると、従来の Playwright スクリプトは壊れます。AI browser agent はページの意味から対象を再探索できます。
バックエンドフォームが MFA / CAPTCHA で止まったら、agent は無理に押し切るのではなく、人に引き継いで止まる必要があります。
安全とコンプライアンス
Computer Use / Browser Agent は、機微な操作、prompt injection、アカウント権限を扱います。
境界を明確にし、プラットフォーム規約の回避を勧めないことが重要です。
安全チェックリスト
| リスク | 対応 |
|---|---|
| Web コンテンツは信頼できない(prompt injection) | ページ、ツール出力、PDF、メール、チャットはすべて untrusted input とみなす |
| ネット接続時のリスクが高い | 低権限の VM/container、domain allowlist、機微データの制限を使う |
| 高影響の操作(ログイン、支払い、送信) | 人の確認を必須にする |
| 自動ログインや CAPTCHA 回避を勧めない | この記事は境界だけを説明し、回避手順は書かない |
| 監査ログ | すべての動作を記録し、追跡可能にする |
| 最小権限 | 必要な権限だけを与え、root/admin アカウントは避ける |
| 分離環境 | ホスト上で直接動かさず、Docker か VM を使う |
リスクの説明
ページ、ツール出力、PDF、メール、チャットはすべて信頼できない入力であり、prompt injection を通じてモデルの挙動に影響する可能性があります。
ネットに接続するとリスクはさらに上がります。低権限の VM/container、domain allowlist、機微データの制限を使ってください。
ログイン、支払い、送信のような高影響操作は、人の確認が必須です。
自動ログイン、CAPTCHA 回避、規約回避は勧めません。
監査ログ、最小権限、分離環境は必須です。
Anthropic の Computer Use ドキュメントも、ページや画像に含まれる指示が prompt injection のリスクになると明言しています。だからこそ、分離と確認が必要です。
次に読むもの
この記事はシリーズの入口であり、後続の単独記事の代わりにはなりません。
サイト内の関連記事
-
AI に文書を読ませる OpenClaw ブラウザ自動化実践ガイド: OpenClaw Browser Skills のコマンドと安全な使い方に集中します。
-
Computer-Use Agent: AI に PC を操作させる: デスクトップ級 Computer Use と RPA の違いを扱います。
-
MCP プラグイン完全ガイド: AI にツールチェーンを任せる: Playwright ブラウザ自動化 MCP の段落を含みます。
このシリーズの今後のテーマ
今後は次のテーマを отдельに扱います。
-
Browser Use 実践: ローカルでもクラウドでも動く完全自律型 browser agent。
-
Playwright MCP ガイド: structured accessibility snapshot を使って MCP でブラウザ機能を公開する方法。
-
Stagehand 実践: 決定論的なコードと AI の柔軟性を両立する、現場向けの流れ。
-
ツール比較と選定: Browser Use vs Stagehand vs Playwright MCP vs Computer Use。
-
Web scraping 実践: 動的コンテンツ収集と client-rendered ページ。
-
調査比較実践: クロスサイトのデータ比較と表生成。
-
フォーム送信実践: API のないバックエンドフォームとクロスプラットフォーム連携。
-
ログイン状態の扱い: session 管理、管理画面フロー、データ入出力。
-
リトライと安定性: selector 変更、動的 UI、エラー処理。
-
フロントエンドテスト実践: E2E テストと UI 検証。
-
Codex 検証: Codex の Computer Use / 内蔵ブラウザ。
-
飛書シート自動化: 飛書でのバックエンド表とデータ移動。
-
クラウド基盤選定: Browserbase、Cloudflare Browser Run、ホスト型ブラウザ。
-
コンプライアンス境界: プラットフォーム規約、アンチボット、CAPTCHA。
-
セキュリティ実践: prompt injection、分離環境、監査ログ。
-
AgentScout: OSS ツールの実践。
おすすめの次の一歩
すぐに始めたいなら、OpenClaw のブラウザ自動化実践か Computer-Use Agent の記事から読むのがよいです。
1 つの技術路線を深掘りしたいなら、次の別記事で Playwright MCP、Stagehand、Browser Use をそれぞれ詳しく扱います。
最小の Browser Agent を正しい順番で組む
タスクを定義し、ブラウザ環境を整え、ページを観察し、動作を実行し、結果を検証し、高リスク操作は人に渡します。
- 1
ステップ 1: タスクを定義する
目的、許可サイト、禁止操作、出力形式をはっきりさせます。 - 2
ステップ 2: 環境を整える
分離されたブラウザセッション、テスト用アカウント、観測可能なログを用意します。 - 3
ステップ 3: ページを観察する
スクリーンショット、accessibility snapshot、構造化されたページ状態を読み取ります。 - 4
ステップ 4: 動作を実行する
現在のページ状態に応じてクリック、入力、スクロール、移動を行います。 - 5
ステップ 5: 結果を検証する
一度押しただけでなく、タスクが本当に完了したかを確認します。 - 6
ステップ 6: 人の承認を求める
ログイン、支払い、送信、削除、機密データ操作の前で止めます。
FAQ
Browser Agent とは何ですか?
Browser Agent とクローラーの違いは何ですか?
Browser Agent と RPA の違いは何ですか?
Browser Agent は必ず vision model が必要ですか?
Browser Use、Stagehand、Playwright MCP はどう選べばいいですか?
Browser Agent でログインや CAPTCHA は扱えますか?
8分で読めます · 公開日: 2026年9月4日 · 更新日: 2026年9月4日
ブラウザ自動化 Agent 実践ガイド: Playwright、browser-use、Computer Use
このページはシリーズの最初の記事です。次の記事へ進むか、シリーズ全体ページで全体像を確認できます。



コメント
GitHubアカウントでログインしてコメントできます