Open Browser徹底解説｜自然言語でブラウザを自動操作するTypeScript製AIエージェント基盤

「Webスクレイピングのセレクタが壊れた」「フォーム入力のテスト自動化スクリプトが動かなくなった」——ブラウザ自動化で最も消耗するのは、DOM変更への追従作業だ。Open Browserは自然言語でタスクを記述するだけで、AIエージェントがクリック・入力・ナビゲーション・データ抽出を自律的に完了するTypeScript製フレームワークだ。GitHubスター数は9,300を超え、v1.0で本番環境対応を正式に宣言している。

本記事では、Open Browserの仕組み・導入手順・ライブラリ統合・サンドボックス実行・競合比較までを公式リポジトリとREADMEをベースに日本語で体系的に解説する。TypeScript/Node.jsスタックでブラウザ自動化を検討しているエンジニアが「今日から評価を始められる」レベルまで具体的に踏み込んでいく。

Androidアプリ側の安全性・権限については当サイトでは検証していないので、Google Playの各ストアページと権限一覧を直接確認してほしい。

この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。

Open Browserとは：Playwright + LLMのAIブラウザ自動化基盤

Open Browserは、Playwrightをブラウザ制御層に使い、その上にLLM（大規模言語モデル）を載せたAIエージェントフレームワークだ。従来のセレクタベースの自動化と異なり、「Hacker Newsのトップ記事を要約して」のような自然言語命令でタスクを実行できる。

最大の特徴は、プロンプトを書くだけでCSSセレクタ指定・DOM待機・再試行ロジックがすべて不要になる点だ。LLMが現在のページ状態を観測して次のアクションを自己判断するため、ページの改修でスクリプトが壊れても自動で追従する。

リポジトリはモノレポ構成で、3つのパッケージに分かれている。

AIエージェントによるブラウザ操作という点では、OpenHandsのようなAIコーディングエージェントとコンセプトが近い。ただしOpen Browserはブラウザ操作に特化しており、Webスクレイピング・フォーム入力・E2Eテストなどのユースケースに最適化されている点が異なる。

動作フローはシンプルだ。ユーザーがタスクを記述すると、Agentが現在のページ状態とタスクをLLMに送信する。LLMが次に実行すべきコマンド（click、type、navigate等）を決定し、Playwrightブラウザ上で実行する。結果を観測してストール検出を行い、タスク完了までループする。

「セレクタの保守を辞めて、タスクをLLMに描写させる」——これがOpen Browserが示す新しいブラウザ自動化のパラダイムだ。

インストールと基本的な使い方：bunとAPIキーだけで動く

セットアップはシンプルで、bunとAPIキーがあれば数分で動かせる。Node.jsでも動作するが、READMEはbunを推奨している。

# リポジトリをクローン
git clone https://github.com/ntegrals/openbrowser.git
cd openbrowser

# 依存関係をインストール
bun install

# APIキーを設定
cp .env.example .env
# .envファイルを編集してOpenAI/Anthropic/GoogleのAPIキーを入力

環境変数の設定例はこちら。プロバイダーは最低1つ設定すれば動作する。

# LLMプロバイダーのAPIキー（最低1つ必要）
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_GENERATIVE_AI_API_KEY=...

# ブラウザ設定
BROWSER_HEADLESS=true
BROWSER_DISABLE_SECURITY=false

# 録画・デバッグ
OPEN_BROWSER_TRACE_PATH=./traces
OPEN_BROWSER_SAVE_RECORDING_PATH=./recordings

基本的なエージェント実行は、たった1行のコマンドだけで完結する。

# AIエージェントでタスクを実行
bun run open-browser run "Find the top story on Hacker News and summarize it"

# フォーム入力
bun run open-browser run "Sign up for the newsletter on example.com with [email protected]"

# 複数ステップのワークフロー
bun run open-browser run "Go to GitHub, find the open-browser repo, and star it"

CLIには豊富なオプションが用意されており、モデル選択・ヘッドレス切替・ステップ上限などが柔軟に調整できる。

ライブラリ組み込み：TypeScriptアプリにAgentを埋め込む

Open Browserの強みは、CLIだけでなくTypeScriptライブラリとしてアプリケーションに直接組み込める点にある。LangChainのようなLLMフレームワークと組み合わせれば、RAGパイプラインにWebブラウジング機能を追加することも可能だ。

import { Agent, createViewport, createModel } from 'open-browser'

const viewport = await createViewport({ headless: true })
const model = createModel('openai', 'gpt-4o')

const agent = new Agent({
  viewport,
  model,
  task: 'Go to example.com and extract the main heading',
  settings: {
    stepLimit: 50,
    enableScreenshots: true,
  },
})

const result = await agent.run()
console.log(result)

createViewport と createModel を分離しているため、同じViewport上で複数のAgentを順次動かす・モデルだけ切り替える、といった柔軟な運用が可能だ。

Agent設定で挙動を細かく制御

Agent設定で細かく制御することも可能だ。コンテキストウィンドウの予算・連続失敗での停止条件・スクリーンショットのON/OFFなどが宣言的に記述できる。

コスト追跡とストール検出

Agentは実行中に使用したトークン数とLLM料金を内部で計測しており、result.usage から取得できる。これにより1ジョブあたりのコストを可視化し、予算オーバーでジョブを自動停止するガードレールを組み込める。さらに同じアクションを繰り返し実行し続けるストール状態を検出し、自動で別経路へ切り替えるリトライ戦略も標準搭載されている。

ForgeCodeのようなAIコーディングツールでブラウザ操作用のTypeScriptコードを生成し、その中にOpen BrowserのAgentを組み込むというワークフローも実用的だ。

サンドボックス実行：本番運用のためのリソース制限

本番環境で外部ユーザーからのタスクを受け付ける場合、リソース暴走やドメイン逸脱を防ぐサンドボックスが不可欠だ。@open-browser/sandboxパッケージで、CPU/メモリ制限・タイムアウト・ドメイン制限付きの安全な実行環境を構築できる。

import { Sandbox } from '@open-browser/sandbox'

const sandbox = new Sandbox({
  timeout: 300_000,        // 5分タイムアウト
  maxMemoryMB: 512,        // メモリ上限
  allowedDomains: ['example.com'],  // ドメイン制限
  stepLimit: 100,
  captureOutput: true,
})

const result = await sandbox.run({
  task: 'Complete the checkout form',
  model: languageModel,
})

console.log(result.metrics)  // steps, URLs visited, CPU time

サンドボックスの真価は、マルチテナントSaaSでユーザー毎のジョブを安全に隔離できる点にある。allowedDomainsでドメインを絞り、timeoutで暴走を止め、maxMemoryMBでOSレベルのリソース枯渇を防ぐ。

サンドボックス設定の指針

インタラクティブREPLとブラウザコマンド：デバッグの強力な武器

Open BrowserにはインタラクティブREPLモードがあり、ライブブラウザセッション上でコマンドを直接入力できる。デバッグ、プロトタイプ開発、Web探索で非常に便利だ。

# REPLモードを起動
bun run open-browser interactive

# REPLセッションの例
# browser> open https://news.ycombinator.com
# browser> extract "top 5 stories with titles and points"
# browser> click .morelink
# browser> screenshot front-page.png

REPLの利点は、LLM呼び出しを最小化しながら挙動を検証できることだ。セレクタが正しく効くか、ページが正しくロードされるか、スクリーンショットで確認しながら一手ずつ進められる。

CLI単体でも個別のブラウザ操作コマンドを実行できる。これらはLLMを使わない決定的な操作であり、CI/CDパイプラインのステップとしても使いやすい。

open-browser open <url>              # URLを開く
open-browser click <selector>        # 要素をクリック
open-browser type <selector> <text>  # 入力フィールドにテキスト入力
open-browser screenshot [output]     # スクリーンショット取得
open-browser eval <expression>       # ページ上でJavaScript実行
open-browser extract <goal>          # コンテンツをMarkdownで抽出
open-browser state                   # 現在のURL・タイトル・タブを表示
open-browser sessions                # アクティブなセッション一覧

extractコマンドは特にユニークで、「商品名と価格のテーブル」のような自然言語ゴールを渡すと、LLMが該当データを構造化Markdownで返す。スクレイピングのセレクタを書かずに済むのはこのコマンドの威力だ。

競合ツール比較：Selenium・Playwright・Browser Use・agent-browserとの違い

ブラウザ自動化ツールは選択肢が多い。Open Browserの立ち位置を理解するために、主要ツールとの比較表を整理した。

Open Browserの差別化ポイントは3つある。

1. サンドボックス実行でリソース制限・ドメイン制限をかけた安全な本番運用が可能な点
2. インタラクティブREPLでブラウザセッションをリアルタイムに操作しながらデバッグできる点
3. LLM利用コストの追跡が内蔵されており、運用コストの可視化が容易な点

一方で、Pythonエコシステムに統合したい場合はBrowser Useのほうが適しているし、Rust製の軽量CLIが欲しい場合はVercelのagent-browserが候補になる。

対応LLMモデルとプロバイダー切替

Open BrowserはVercel AI SDKを基盤に、3社のLLMプロバイダーをフラグ1つで切り替えられる。

# Anthropicモデルに切り替えて実行
bun run open-browser run "Extract all product prices from example.com" \
  -p anthropic -m claude-sonnet-4-5-20250929

# Google Geminiで実行
bun run open-browser run "Summarize the latest blog post" \
  -p google -m gemini-2.5-pro

モデル選択はタスクの複雑さとコストのバランスで決める。単純なデータ抽出ならgpt-4o-miniやgemini-2.0-flashで十分だが、複数ステップのワークフローではgpt-4oやclaude-sonnet-4-5-20250929のほうが精度が高い。

ユースケース実例：どんなタスクが現実的に自動化できるか

公式READMEとコミュニティの実装例を参照すると、Open Browserは以下の領域で特に威力を発揮する。

代表的な5つのユースケース

特にE2Eテスト領域でのROIは大きい。従来のセレクタベースE2Eはフロント改修の度に壊れるため、テストの保守コストが開発速度のボトルネックになりがちだった。Open Browserなら「ログイン→商品を選択→カートに追加→購入」のような流れを自然言語で書けば、ボタン位置やclass名が変わっても動き続ける。

「壊れないE2Eテスト」——これはテスト自動化エンジニアにとって長年の願望だった。LLMエージェントがこの夢を現実にしつつある。

運用上の注意点：LLM自動化特有の落とし穴

Open Browserは強力だが、LLMベース自動化ならではの注意点もある。導入前に押さえておきたいポイントを整理する。

非決定性とコスト

LLMは毎回同じ出力を返すとは限らない。同じタスクでも実行パスが変わることがあるため、厳密な決定性が必要な箇所（金額計算や請求処理）ではLLM判断を使わず、個別のブラウザコマンドで決定的に実装すべきだ。

またLLM呼び出しはコストがかかる。1タスクあたり数セント〜数十セントが目安で、1日数千タスクを回すと月額数万円〜数十万円のLLM料金が発生する。サンドボックスのstepLimitとコスト追跡を組み合わせて予算管理することが重要だ。

プロンプトインジェクション対策

ブラウザ経由でWeb上のテキストをLLMに読み込ませるため、悪意あるサイトがLLMへの指示を埋め込むプロンプトインジェクションのリスクがある。対策の基本は以下だ。

• allowedDomainsで信頼できるドメインのみに制限する
• LLMに渡すページテキストを一定長で打ち切る
• 重要な操作（決済・削除）はLLM判断ではなく人間承認を挟む
• サンドボックス実行で副作用の及ぶ範囲を最小化する

ステップ数と失敗閾値のチューニング

stepLimitとfailureThresholdの調整はタスク成功率に直結する。

実運用では、まずデフォルトで動かし、失敗ログを見ながら調整するのが近道だ。

📌 まとめ：Open Browserが変えるブラウザ自動化の開発体験

Open Browserは、従来のセレクタベースのブラウザ自動化が抱えていた「DOM変更への追従コスト」という根本的な課題を、自然言語 + LLMエージェントというアプローチで解決する。MITライセンスのOSSとして完全にオープンであり、APIキーを自前管理できるため、ベンダーロックインの心配もない。

本記事のポイントをもう一度整理する。

• アーキテクチャ：Playwright + LLMのTypeScript製エージェント基盤、モノレポ3パッケージ構成
• 導入：bun installとAPIキーのみで数分で起動、CLI1行で自然言語タスク実行
• 統合：TypeScriptライブラリとしてRAGやSaaSに埋め込み可能
• 本番運用：サンドボックスでリソース制限、コスト追跡・ストール検出が内蔵
• 差別化：REPL・サンドボックス・コスト追跡の3点がBrowser Use等との違い
• 注意点：非決定性とプロンプトインジェクションを意識した設計が必須

TypeScript/Node.jsスタックでブラウザ自動化を検討しているなら、まずはbun installして手元で動かしてみるのが最速の評価方法だ。公式リポジトリのサンプルコードをそのまま実行するだけで、自然言語エージェントの挙動を体感できる。

実測データと開発状況（2026-09-21 時点）

導入判断のため、リポジトリの現況をGitHub APIで確認した。

★9,537と注目は集めた一方、直近pushが約5か月半前で、タグ付きリリースも切られていない（2026-08-14の前回確認から星は+28、pushは増えていない）。READMEが列挙する対応モデルも gpt-4o・claude-sonnet-4-5・gemini-2.0-flash など2025年世代のままで、モデル名の更新すら止まっている。ブラウザ自動化はChromeやPlaywrightの更新に追随し続ける必要がある領域なので、この停止期間は評価に織り込むべきである。

具体的には、依存する Playwright やブラウザ側の変更で動かなくなった場合、上流の修正を待てない可能性が高い。評価目的やスポットの自動化には十分使えるが、継続運用の基盤に据えるなら、フォークして自分で保守する前提か、更新が続いている代替を併せて検討したい。MITライセンスなのでフォーク自体に制約はない。

参照ソース

• Open Browser - Smart & Safe（Google Play・AdPulse INC）

• Open Browser - TV Web Browser（Google Play・MetaX）

• ntegrals/openbrowser - GitHub
• Open Browser README（公式ドキュメント）
• Vercel AI SDK
• Playwright公式ドキュメント