---
title: "Browser Automationとは？ブラウザ操作を自動化する4つの方式と選び方【2026年】"
url: "https://www.issoh.co.jp/tech/details/9129/"
published: 2025-10-02
updated: 2026-09-27
categories: ["自動化"]
publisher: "株式会社一創"
---

# Browser Automationとは？ブラウザ操作を自動化する4つの方式と選び方【2026年】

Browser Automation（ブラウザオートメーション）は、人がブラウザで行うクリック・入力・ページ移動をプログラムやAIに代わりに実行させることです。E2Eテストやデータの定期取得のために昔からある技術ですが、2025年以降は「自然言語で指示するとAIがブラウザを操作する」製品が相次ぎ、同じ言葉で指す範囲が広がりました。この記事では、ブラウザ操作の自動化を4つの方式に分け、それぞれの仕組みと壊れ方の違い、作業に合った方式の選び方を整理します。Microsoft Foundry に追加された「Browser Automation」ツールの位置づけもここで扱います。

## まとめ：手順を決める主体で分かれるブラウザ自動化の4方式

- ブラウザ操作の自動化は、手順をコードに書く方式、操作を記録するRPA・ノーコード方式、AIエージェントが手順を決める方式、AI機能つきのブラウザやアシスタントに頼む方式の4つに分かれます。
- 毎回同じ手順を繰り返す作業は、コード（Playwright・Selenium・Puppeteer）に向きます。手順を固定でき、止まったときはどの行で失敗したかを追えるうえ、実行のたびにAIの利用料もかかりません。
- AIエージェントは、手順を事前に書けない作業に向きます。代わりにモデルが毎回手順を決め直すため同じ操作になるとは限らず、悪意あるページに誘導されるリスクもあるため、決済や認証情報を扱う操作は人の確認を挟みます。
- AIが画面を読む方法は、アクセシビリティツリーをテキストで渡す方式（Playwright MCP など）と、スクリーンショットを見て座標をクリックする方式（Microsoft Foundry の Browser Automation ツールや各社の Computer Use）の2系統です。
- Microsoft Foundry の Browser Automation ツールは、2026年9月時点でパブリックプレビューです。実行基盤は一般提供済みの Playwright Workspaces で、ブラウザの実行時間はそちらで課金されます。

## Browser Automationの4つの方式と向いている作業

方式の違いは、操作の手順を「いつ・誰が」決めるかにあります。コードとRPAは人が事前に手順を固定し、AIエージェントは実行のたびにモデルが次の一手を決めます。4つ目の「AIアシスタント内蔵」は、AIエージェントの仕組みを一般向けの製品に組み込んだもので、この記事では使い手の違いから分けています。

| 方式         | 手順を決めるのは   | 代表例                                  | 向く作業             |
| ---------- | ---------- | ------------------------------------ | ---------------- |
| コード（スクリプト） | 開発者が事前に    | Playwright／Selenium／Puppeteer        | E2Eテスト、定期のデータ取得  |
| 記録・RPA     | 業務担当者が事前に  | Power Automate for desktop           | 社内システムへの定型の転記    |
| AIエージェント   | モデルが実行のたびに | Browser Use／Stagehand／Playwright MCP | サイトごとに手順が違う調査・入力 |
| AIアシスタント内蔵 | モデルが実行のたびに | ChatGPT のブラウザ機能／Claude in Chrome     | 個人の単発の作業         |

検索で「Browser Automation」と調べたときに出てくる情報が噛み合わないのは、この4つが同じ言葉で語られているためです。テスト自動化の文脈ならコード方式、業務効率化の文脈ならRPA、2025年以降のAI製品の文脈ならAIエージェント方式を指していることがほとんどです。

## コードで書く方式：Selenium・Playwright・Puppeteerの違い

コード方式は、開発者がライブラリを使って「このページを開き、この欄に入力し、このボタンを押す」と手順を書く方法です。代表的な3つはいずれもオープンソースで、ライセンス費用はかかりません。2026年9月27日時点の最新版は次のとおりです。

| ライブラリ      | 最新版     | 公開日        | 対応言語                                   |
| ---------- | ------- | ---------- | -------------------------------------- |
| Selenium   | 4.49.0  | 2026-09-09 | Java／Python／C#／JavaScript／Ruby         |
| Playwright | 1.63.0  | 2026-09-04 | TypeScript／JavaScript／Python／Java／.NET |
| Puppeteer  | 25.12.0 | 2026-09-23 | JavaScript／TypeScript                  |

版と公開日は各プロジェクトの GitHub Releases と npm・PyPI のレジストリで確認した値です。それぞれの詳しい使い方は[SeleniumのWebDriverの仕組みと4系の実行手順](/tech/details/17435/)、[Playwrightの仕組みとSeleniumとの違い](/tech/details/3167/)、[Puppeteerの仕組みと使い方](/tech/details/3844/)にまとめています。ここでは選ぶときに差が出る2点、ブラウザとの通信経路と、画面の改修に強い書き方を見ていきます。

### ブラウザとの通信経路：WebDriver・CDP・WebDriver BiDi

ライブラリがブラウザに命令を送る経路のうち、代表的なのは次の3つです。

| 経路                            | 性格                    | 主な利用者                            |
| ----------------------------- | --------------------- | -------------------------------- |
| WebDriver Classic             | W3C標準。命令を1つずつ送る       | Selenium（従来の方式）                  |
| CDP（Chrome DevTools Protocol） | Chromium系の独自プロトコル。双方向 | Puppeteer（Chromeでの既定）            |
| WebDriver BiDi                | W3Cで標準化中の双方向プロトコル     | Puppeteer（Firefox）、Selenium（移行中） |

Playwright はこの表に収まりません。Chromium は CDP で操作し、Firefox と WebKit には Playwright 側でパッチを当てた専用ビルドを使います（Firefox 用の独自プロトコルは Juggler と呼ばれます）。

いま動いているのは WebDriver BiDi への移行です。W3Cの仕様は2026年9月24日付の Working Draft が最新で、勧告にはまだ至っていません。それでも Puppeteer は23.0.0以降、Firefox を WebDriver BiDi で、Chrome を CDP で操作しています。Selenium も WebDriver Classic から WebDriver BiDi へ実装全体を移している最中で、`webSocketUrl` capability を有効にすると BiDi 接続を使えます。

実務で影響が出るのは Firefox です。Firefox のリモートエージェントは141で CDP への対応を終え、そこで使えるプロトコルは WebDriver BiDi だけになりました。CDP で Firefox を動かしていた古い設定は、ブラウザを更新した時点で動かなくなります。geckodriver 経由の WebDriver Classic はこれとは別の実装で、引き続き使えます。

ドライバーの準備も以前より簡単になっています。Selenium は4.6以降、Rust製の Selenium Manager を同梱しており、ドライバーを指定しなければ必要なものを自動で検出・ダウンロードします。「ChromeDriver のバージョンが合わない」というかつての定番トラブルは、ドライバーのパスを自分で指定する古い書き方のまま残っているコードで起きやすくなります。

### id指定と役割・名前指定の比較：画面改修後も動くロケーター

コード方式が壊れる典型的な原因は、画面の改修で要素の指定先が変わることです。Playwright 1.63.0 と同梱の Chromium で、id で指定した場合と、役割（ボタン・入力欄）と表示名で指定した場合を比べました。v1 のページのボタンは `id="submit-btn"`、v2 は見た目の改修で `id="btn-primary-2"` に変わり class が付いただけで、ボタンの文言は同じです。比較に使った v1.html は次のとおりです。

```
<!doctype html><html lang="ja"><meta charset="utf-8"><title>申込フォーム</title>
<form id="f"><label for="mail">メールアドレス</label><input id="mail" name="mail" type="email">
<button id="submit-btn" type="submit">送信する</button></form><p id="msg"></p>
<script>document.getElementById('f').onsubmit=e=>{e.preventDefault();setTimeout(()=>{document.getElementById('msg').textContent='受付番号 A-1024';},800);};</script></html>
```

スクリプトは次のとおりです。`npm install playwright@1.63.0` と `npx playwright install chromium` を済ませ、2つの HTML と同じフォルダに置いて `node demo.mjs` で実行しました。

```
import { chromium } from 'playwright';
const browser = await chromium.launch();
for (const v of ['v1', 'v2']) {
  const page = await browser.newPage();
  await page.goto(`file://${process.cwd()}/${v}.html`);
  await page.getByLabel('メールアドレス').fill('taro@example.com');
  // 1) id で指定：画面改修で id が変わると壊れる
  try {
    await page.locator('#submit-btn').click({ timeout: 2000 });
    console.log(v, 'id指定: OK');
  } catch (e) {
    console.log(v, 'id指定: 失敗', e.name);
  }
  // 2) 役割と名前で指定：見た目の実装が変わっても同じボタンを掴む
  await page.goto(`file://${process.cwd()}/${v}.html`);
  await page.getByLabel('メールアドレス').fill('taro@example.com');
  await page.getByRole('button', { name: '送信する' }).click();
  // 0.8秒後に出る表示を自動で待つ（sleep を書かない）
  console.log(v, 'role指定:', await page.locator('#msg').filter({ hasText: '受付番号' }).textContent());
  await page.close();
}
await browser.close();
```

実行結果は次のとおりです。

```
v1 id指定: OK
v1 role指定: 受付番号 A-1024
v2 id指定: 失敗 TimeoutError
v2 role指定: 受付番号 A-1024
```

id 指定は v2 で2秒待って TimeoutError になり、役割と名前での指定は両方で通りました。送信後に0.8秒遅れて出る受付番号も、待機時間を書かずに取れています。`filter({ hasText: '受付番号' })` で「受付番号という文字を含む状態」を条件として書いたので、Playwright のロケーターはその状態になるまで自動で再試行します。業務処理が終わったかどうかをライブラリが判断するわけではないため、何をもって完了とするかはこのようにコードで指定します。コード方式でメンテナンスの手間を減らしたいなら、まず要素の指定を `getByRole` や `getByLabel` に寄せるのが最初の一手です。

## 記録・RPA方式：Power Automate for desktop と Chrome の Recorder

コードを書かずに自動化したい場合は、操作を記録して再生する方式が入口になります。Windows なら Microsoft の Power Automate for desktop が代表例です。公式ドキュメントでは、組み込みの Automation browser に加えて Microsoft Edge・Google Chrome・Mozilla Firefox・Internet Explorer の4つに対応しています。Edge・Chrome・Firefox で使うには、Power Automate のブラウザ拡張機能か WebDriver の追加設定が必要です。v2.27以降は3ブラウザ分の拡張機能がインストールに同梱され、v2.26以前はEdgeとChrome向けの旧版の拡張機能を使います。できることと導入の判断は[Power Automate Desktopでできることと導入判断](/tech/details/15088/)で詳しく扱っています。

Chrome には、開発者ツールに Recorder パネルがあります。ブラウザでの操作を記録して再生でき、JSON のほか Puppeteer のスクリプトとして書き出せます。記録した手順をそのままコード方式へ移せるので、「最初は記録で作り、壊れにくく直したくなったらコードで保守する」という段階的な進め方ができます。Playwright にも同じ役割の `npx playwright codegen` があり、操作を記録してテストコードを生成します。

RPA方式の弱点はコード方式と同じで、画面の構成が変わると記録した手順が止まります。記録で作ったフローも、要素の指定が id や画面上の位置に依存していないかを確認しておくと長持ちします。

## AIエージェント方式：自然言語でブラウザを操作させる仕組み

AIエージェント方式では、「このサイトで今週の空き枠を調べて」のように目的だけを伝え、どのリンクを押しどの欄に入力するかはモデルが画面を見ながら決めます。手順を事前に書けない作業、サイトごとに画面構成が違う作業を自動化できるのが強みです。

### AIが画面を読む2つの方法：アクセシビリティツリーとスクリーンショット

モデルがページの状態を知る方法は2つあります。1つは、ページのアクセシビリティツリー（読み上げソフト向けに整理された要素の一覧）をテキストで渡す方法です。Playwright MCP は「構造化されたアクセシビリティスナップショット」でモデルにページを操作させると説明しており、スクリーンショットを必須としません。Chrome DevTools MCP の `take_snapshot` も同じくアクセシビリティツリーからテキストを作り、要素ごとに操作用の uid を振ります。先ほどの v2 のページを Playwright の `ariaSnapshot()` で出力すると、アクセシビリティツリーの表現は次のようになります。

```
- text: メールアドレス
- textbox "メールアドレス"
- button "送信する"
- paragraph
```

466バイトの HTML が4行になり、id やクラス名は含まれません。Playwright MCP が実際にモデルへ返すスナップショットには、これに加えて操作対象を指す ref が付きます。モデルは「送信する」という名前のボタンとして要素を扱うため、前の章で見た id の変更には影響されません。

もう1つは、スクリーンショットを撮ってモデルに見せ、クリックする X／Y 座標を返させる方法です。Anthropic・OpenAI・Google がそれぞれ提供する Computer Use 系の機能と、後述する Microsoft Foundry の Browser Automation ツールがこの方式です。画像しか手がかりがない canvas 描画の画面や、アクセシビリティ情報が整っていないサイトでも操作できる反面、モデルとの間でやり取りするのはテキストでなく画像になります。往復の単位は製品で違い、Foundry のツールは操作のたびにスクリーンショットを撮り直してモデルに返し、OpenAI の computer use は1回の応答に複数の操作をまとめて返せる設計です。

### 開発者向けの主なAIブラウザ操作ツール

自前のアプリケーションにAIのブラウザ操作を組み込むときの主な選択肢です（2026年9月27日時点のレジストリの最新版）。

| ツール                 | 形態           | 最新版     | ライセンス      |
| ------------------- | ------------ | ------- | ---------- |
| Browser Use         | Python ライブラリ | 0.13.10 | MIT        |
| Stagehand           | npm パッケージ    | 4.1.0   | MIT        |
| Playwright MCP      | MCP サーバー     | 0.0.82  | Apache-2.0 |
| Chrome DevTools MCP | MCP サーバー     | 1.10.1  | Apache-2.0 |

Browser Use は目的を渡すと手順までエージェントに任せる作りで、Stagehand は `act`・`extract` などのメソッドで、スクリプトの一部だけを自然言語の指示に置き換える作りです（v3で Playwright への依存を外し、CDP を直接操作するエンジンに変わりました）。違いと実装例は[Browser Useの使い方とPlaywright MCPとの違い](/tech/details/4743/)と[StagehandとPlaywrightの違い](/tech/details/5281/)を参照してください。Claude Code や Cursor などのAIエージェントにブラウザを操作させるなら、[Playwright MCPの設定と使い方](/tech/details/6172/)か[Chrome DevTools MCPの導入手順](/tech/details/17749/)が入口になります。

モデル側の機能としては、Anthropic の Computer Use（現行は `computer_toolset_20260801`。beta ヘッダー不要）、OpenAI API の computer use、Gemini API の Computer Use（Preview）があります。いずれもモデルは「次に何をするか」を返すだけで、ブラウザやデスクトップの実行環境は利用者の側で用意します。Anthropic の実装は[Claude Computer Useの対応モデルと実装手順](/tech/details/4002/)で扱っています。

### Microsoft Foundry の Browser Automation ツール（プレビュー）

「Browser Automation」という名前の機能として検索されやすいのが、Microsoft Foundry Agent Service の Browser Automation ツールです。2026年9月時点でパブリックプレビューで、SLA はなく、Microsoft は本番ワークロードでの利用を推奨していません。

仕組みは、エージェントへの依頼を受けると、利用者が用意した Playwright Workspaces 上に隔離されたブラウザセッションを立ち上げ、モデルが返すアクション（スクリーンショット、座標指定のクリックなど）を実行し、結果のスクリーンショットをモデルへ返す、というループです。Playwright Workspaces は Azure App Testing の一機能として一般提供済みで、旧サービスの Microsoft Playwright Testing は2026年3月8日に退役しました。ツールは MCP ツールとして提供され、Foundry の「toolbox」に登録してエージェントから呼び出します。公式ドキュメントの Azure Developer CLI の例では、toolbox を次の YAML で定義します。

```
description: Browser Automation toolbox
tools:
  - type: browser_automation_preview
    project_connection_id: my-browser-conn
```

接続の認証方式は API キー、プロジェクトのマネージド ID、エージェント ID の3種類から選べます。Foundry プロジェクトのマネージド ID には、Playwright Workspace のリソース単位で Playwright Workspace Contributor ロール（または必要な権限だけのカスタムロール）を付与します。実行中のセッションを見る Live View、終わったセッションを動画とログで振り返るセッション記録、人が途中で操作を引き取る Take control も用意されています。

公式ドキュメントの制限事項には、信頼できるサイトだけで使うこと、認証情報や支払いを求めるページを避けること、レイアウトやラベルの変更で失敗しうること、JavaScript の多い SPA は正しく描画されない場合があることが書かれています。ブラウザの実行時間は Playwright Workspaces の利用として課金され、最初の30日間は、クラウドブラウザの実行時間100分（test minutes）までが無料です。Foundry Agent Service 全体の料金と移行は[Foundry Agent Serviceの移行と料金・実装手順](/tech/details/4297/)で扱っています。

## 作業の性質で決まる方式の選び方：定型の繰り返しと判断を伴う作業

方式選びで最初に見るべきは、作業の手順が毎回同じかどうかです。

- **毎回同じ手順で、失敗を検知したい**：コード方式を選びます。E2Eテスト、決まったページからの定期取得、社内システムへの定型入力はこれに当たります。手順が固定されるので、失敗したらどの行で止まったかを追えます。
- **手順は同じだが、書ける人がいない**：Windows 環境なら Power Automate for desktop、Chrome の操作なら Recorder で記録から始めます。
- **サイトごとに手順が違う、事前に書けない**：AIエージェント方式を選びます。複数の取引先ポータルから請求情報を集める、構成の違う多数のサイトで同じ種類の情報を探す、といった作業です。
- **個人が単発で頼みたい**：ChatGPT のブラウザ機能や[Claude in Chrome](/tech/details/10373/)のような、アシスタントに内蔵された機能で足ります。

AIエージェントを採用すべきでないのは、同じ手順で毎日回す業務を「コードを書くのが面倒だから」という理由で任せる場合です。実行のたびにモデルの利用料がかかり、モデルが毎回手順を決め直すので、同じ依頼でも同じ操作になるとは限りません。この場合は、AIエージェントや codegen・Recorder で一度手順を探り、確定した手順をコードに落として定期実行するほうが、費用も失敗時の調査も軽く済みます。

## AIにブラウザを任せるときのリスク：誘導・認証情報・利用規約

Microsoft は Foundry の Browser Automation ツールの説明（[Microsoft Learn「Automate browser tasks with the Browser Automation tool」](https://learn.microsoft.com/ja-jp/azure/foundry/agents/how-to/tools/browser-automation)）で、重大なセキュリティリスクがあると明記しています。

> The Browser Automation Tool comes with significant security risks. When you use the Browser Automation Tool, an AI spins up remote browsers sessions to perform actions and can use credentials you explicitly share with the agent, such as to email, financial accounts, social networks, and enterprise systems. The AI agent may make mistakes and may be fooled by malicious data it may encounter on the Internet.

要点は2つです。エージェントに渡した認証情報は、エージェントが誤った操作をしたときにもそのまま使われます。そして、ページに埋め込まれた文章がモデルへの指示として読まれ、意図しない操作に誘導される可能性があります（プロンプトインジェクション）。Google も Gemini API の Computer Use について、Preview のためエラーやセキュリティ上の脆弱性を含みうると注意書きしています。

対策としては、エージェント用に権限を絞った専用アカウントを用意し、送金・購入・削除のような取り消せない操作の前には人の承認を挟みます。承認は、MCP クライアントのツール実行前の承認設定などを使い、該当する操作の前で必ず止まるようにワークフロー側で組みます。Foundry の Take control は人が途中でブラウザ操作を引き取るための機能で、止まる位置を保証するものではありません。Playwright MCP 固有の注意点は[Playwright MCPのセキュリティ対策](/tech/details/6077/)にまとめています。

自動化してよいかどうかは、技術とは別に確認が要ります。相手サイトの利用規約が自動アクセスを禁じていないか、集めるデータに著作権や個人情報の制約がないかを先に確かめます。他社サイトからデータを集める場合の法務面の判断は[スクレイピングの実装と法務の判断](/tech/details/13414/)を確認してください。

## よくある質問

### ブラウザ操作の自動化は無料でできますか？

できます。Selenium・Playwright・Puppeteer は Apache-2.0、Browser Use と Stagehand は MIT のオープンソースで、ライブラリ自体は無料です。費用が発生するのは、AIエージェント方式で使うモデルの API 利用料と、Playwright Workspaces のようなクラウド上のブラウザを使う場合の実行時間です。

### Chromeで操作を自動化するにはどうすればいいですか？

コードを書かないなら、開発者ツールの Recorder パネルで操作を記録して再生するのが最も手軽です。記録は Puppeteer のスクリプトとして書き出せます。定期実行やテストに使うなら Playwright・Puppeteer・Selenium のいずれかでスクリプトを書きます。Edge は Playwright と Selenium が公式に対応しているので、同じ書き方で操作できます。

### Power Automateでブラウザ操作を自動化するには？

Power Automate for desktop をインストールし、使うブラウザ（Edge・Chrome・Firefox）で Power Automate のブラウザ拡張機能を有効にします。v2.27以降は拡張機能がインストールに同梱されています。拡張機能の代わりに WebDriver で動かす方法もあります。フローでは Launch Browser 系のアクションで新しいブラウザを起動し、ページ上の要素に対する入力やクリックのアクションを並べます。拡張機能が要らない組み込みの Automation browser も用意されています。

### Cursorの「Browser Automation」とは何ですか？

Cursor のエージェントがブラウザを開いて操作する機能です。1.7でベータとして入り、2025年10月29日の Cursor 2.0 で一般提供になりました。個人利用なら外部ツールの導入なしで使え、チャットで `@browser` を付けると起動します。設定と使い方は[Cursorの「Connect to Browser」の仕組みと設定](/tech/details/10297/)で解説しています。

### Browser Automation Studioとは何ですか？

Bablosoft が提供する、ブラウザ操作の自動化ツールの製品名です。プログラミングなしで操作をビジュアルエディタで組み立て、並列実行やスケジュール実行、Windows 向けの単体実行ファイルへの書き出しができます。無料版があり、有料の Premium は1年80米ドルです。この記事で扱っている一般名詞としての Browser Automation とは別物です。

## 関連記事

- [Playwrightとは｜仕組み・できること・Seleniumとの違いを解説](/tech/details/3167/)
- [Browser Useとは？使い方・料金・Playwright MCPとの違いまで実装ガイド【2026年版】](/tech/details/4743/)
- [Playwright MCPとは？設定・使い方からDify連携まで実務ガイド【2026年版】](/tech/details/6172/)
- [Cursorの「Connect to Browser」とは？AIがブラウザを操作する仕組み・設定・使い方【Cursor 2.0以降】](/tech/details/10297/)
- [Power Automate Desktopとは？無償RPAでできること・使い方・導入判断を解説](/tech/details/15088/)

---

出典: [Browser Automationとは？ブラウザ操作を自動化する4つの方式と選び方【2026年】](<https://www.issoh.co.jp/tech/details/9129/>)（株式会社一創）