Browser Use CLIとは|AIエージェントがブラウザを自動操作するOSSの実践ガイド

この記事の結論

ブラウザ前の「人がやるしかない作業」を、AIエージェントに渡す。自動化の対象を、APIの外側まで広げる。

ブログ目次

記事の内容を、そのまま実務に落とし込みたい方向け

HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。


ブラウザ前の「人がやるしかない作業」を、AIエージェントに渡す。自動化の対象を、APIの外側まで広げる。

「競合3社の料金ページを毎月見に行って、スプレッドシートに転記している」「管理画面のダッシュボードはAPIで取れないから、結局スクリーンショットを手で貼っている」「スクレイピングのスクリプトを書いたが、サイトのHTMLが変わるたびに壊れて誰も直せない」——。私たちがCRMや業務データの相談をいただく現場では、こうした「ブラウザの前に座らないと終わらない作業」が、驚くほど多く残っています。

Browser Use CLIは、AIエージェントがChromiumブラウザを自動操作するオープンソースのコマンドラインツールです。 自然言語で指示を出すだけで、Webサイトの閲覧・操作・データ抽出をAIが実行します。本記事では、仕組みとセットアップから、実務での活用パターン、そして「使わない方がよいケース」までを解説します。

本記事は「Claude Code実践ガイド|AI開発の生産性を高める運用設計」シリーズの一部です。


この記事でわかること

自然言語の指示だけでブラウザを自動操作できるオープンソースツール「Browser Use CLI」について、仕組みの理解から実務での運用設計までを一気通貫で解説します。

  • Browser Use CLIの仕組みとアーキテクチャ — LLMがDOM構造を解析してアクションを決め、Playwright経由でChromiumを操作する流れを図解します。従来のスクレイピングとの構造的な違いがわかります。
  • セットアップと基本的な使い方 — pipでのインストール、LLMのAPIキー設定、CLI・Pythonの両方からの実行方法を手順で示します。
  • 実務でのユースケースと自動化の優先順位 — 競合調査、管理画面の定型操作、フォーム入力、データ抽出の4パターンと、どれから手をつけるべきかの判断軸を整理します。
  • 他ツールとの使い分けと向かないケース — Claude Computer Use・Manus My Computerとの比較表、そしてBrowser Use CLIを使うべきでない場面を率直に書きます。
  • 安全に運用するための設計 — 認証情報の扱い、ステップ数・タイムアウトの制限、人間が確認すべきポイントの切り分け方を示します。

ブラウザ操作の自動化やデータ収集を効率化したいエンジニアの方、AIエージェントツールを比較検討している情報システム・マーケティング担当の方に向けて書いています。最後まで読むと、自社のどの業務から自動化を始めるべきかを判断し、小さく試して段階的に広げる設計ができるようになります。


Browser Use CLIとは何か

Browser Useは、LLM(大規模言語モデル)をバックエンドとして、ブラウザの自動操作を実現するPythonベースのOSS(オープンソースソフトウェア)です。CLI版では、コマンドラインから自然言語のタスク指示を入力し、AIがブラウザを操作して結果を返します。ここではまず、その内部構造と「従来のスクレイピングと何が違うのか」を押さえておきます。

アーキテクチャ:DOMを読むのはLLM、操作するのはPlaywright

Browser Useの処理は、大きく4つの層に分かれます。

[ユーザーの指示(自然言語)]
  ↓
[Browser Use Agent(LLM)]
  ↓ DOM解析 + アクション決定
[Playwright / Chromium]
  ↓ ブラウザ操作実行
[結果の取得・出力]

Browser UseはPlaywright(ブラウザ自動化フレームワーク)の上に構築されており、DOMの構造を解析してAIがクリック・入力・スクロールなどのアクションを決定します。ここで重要なのは、「どこをクリックするか」を決めるのが人間の書いたコードではなくLLMであるという点です。従来のスクリプトが「CSSセレクタで指定した要素をクリックする」という固定的な命令だったのに対し、Browser Useは「料金プランのページに移動する」という目的をLLMが受け取り、その時点のDOMを見て最適な要素を選びます。

主な特徴

特徴 説明
オープンソース GitHub上で公開。カスタマイズ・拡張が自由
LLMバックエンド Claude、GPT-4、Geminiなど複数のLLMに対応
DOM認識 スクリーンショットではなくDOM構造を直接解析
CLI対応 コマンドラインから直接操作可能
Pythonベース pip installで簡単にインストール

DOM解析型である点は、実務上の使い勝手に直結します。スクリーンショット認識型のエージェントは「画面に見えているもの」しか判断材料にできませんが、DOMを直接読む場合は、スクロールしないと見えない要素や属性情報も判断に使えます。

「壊れないスクレイピング」を目指す設計思想

従来のスクレイピング(BeautifulSoup等)では、サイト構造の変更に伴うメンテナンスが必要でした。Browser UseはDOM構造を動的に認識するため、サイト変更への耐性が高いという利点があります。

この違いは、運用を続けるほど効いてきます。手書きのスクレイパーは「作った人しか直せない」状態になりがちで、担当者が異動した瞬間に止まります。Browser Useのように自然言語でタスクを定義しておけば、指示文を読めば何をしているかが誰でもわかるため、引き継ぎの難易度が下がります。個人の力量ではなく、仕組みで回すという観点では、この可読性そのものが価値です。

ただし、耐性が高いことと、無条件に動き続けることはイコールではありません。LLMが介在する以上、同じ指示でも実行ごとに挙動が揺れる可能性があります。この点は後段の「向かないケース」で改めて整理します。


セットアップ手順

ここからは実際に動かすまでの手順です。Pythonが動く環境であれば、インストールから初回実行まではごく短いステップで到達できます。まずは自分のローカル環境で、影響のない公開サイトを相手に一度動かしてみるのがおすすめです。

1. インストール

# pipでインストール
pip install browser-use

# Playwrightのブラウザをインストール
playwright install chromium

Playwrightのブラウザ本体は別途ダウンロードが必要です。ここを忘れると、実行時にブラウザが見つからずエラーになります。

2. 環境変数の設定

使用するLLMのAPIキーを設定します。

# Claudeをバックエンドにする場合
export ANTHROPIC_API_KEY="your-api-key"

# OpenAIをバックエンドにする場合
export OPENAI_API_KEY="your-api-key"

APIキーはシェルの設定ファイルに直書きせず、環境変数管理の仕組みに寄せておくと、チームで共有する際の事故を減らせます。

3. 基本的な実行

from browser_use import Agent
from langchain_anthropic import ChatAnthropic

# Claudeをバックエンドに設定
llm = ChatAnthropic(model="claude-sonnet-4-20250514")

# エージェントを作成してタスクを実行
agent = Agent(
    task="HubSpotの公式サイトで料金プランを確認し、各プランの価格と主要機能をまとめてください",
    llm=llm
)

result = await agent.run()
print(result)

CLI経由での実行

# コマンドラインから直接タスクを指示
browser-use "HubSpotの公式サイトで料金プランを確認し、比較表を作成してください"

CLIから直接叩けるため、シェルスクリプトやcronに組み込みやすいのが利点です。逆に、複雑な条件分岐や結果の後処理が必要な場合は、Pythonで書いた方が制御しやすくなります。最初はCLIで感触をつかみ、定常運用に載せる段階でPythonスクリプトに移す、という順序が実務的です。


実務ユースケース:どこから自動化するか

ブラウザ自動化は、やろうと思えばほとんどのWeb操作に適用できてしまいます。だからこそ、最初に手をつける対象の選び方が成果を分けます。ここでは代表的な4パターンを、自動化の適性とあわせて整理します。

ユースケース1: 競合調査とデータ収集

agent = Agent(
    task="""
    以下の3つのCRMツールの公式サイトにアクセスし、
    それぞれの料金プラン(月額・年額)と主要機能を調査して、
    Markdown形式の比較表にまとめてください:
    1. HubSpot (hubspot.com)
    2. Salesforce (salesforce.com)
    3. Zoho CRM (zoho.com/crm)
    """,
    llm=llm
)

複数サイトを巡回しての情報収集を自動化します。手作業で数時間かかるリサーチをAIに委託できます。定期的に同じ観点で見に行く調査ほど、自動化の効果が出やすい領域です。

ユースケース2: SaaS管理画面での定型操作

agent = Agent(
    task="""
    HubSpotのダッシュボードにログインし、
    今月の新規コンタクト数と取引パイプラインの概要をスクリーンショットで取得してください
    """,
    llm=llm
)

APIで取得しにくいダッシュボードのビジュアル情報を、ブラウザ操作で直接取得するパターンです。ただし、APIが提供されている処理は、原則APIを使うべきです。ブラウザ操作は画面の変更に影響を受けますし、実行時間もAPIより長くなります。「APIで取れないものだけをブラウザ操作で補う」という線引きを最初に決めておくと、後の保守が楽になります。

ユースケース3: フォーム入力の自動化

agent = Agent(
    task="""
    以下のCSVデータの各行について、
    https://example.com/contact-form にアクセスし、
    名前・メール・会社名のフォームに入力して送信してください
    """,
    llm=llm
)

CSVを手作業で1行ずつフォームに転記する、といった作業を置き換えられます。送信を伴う操作は取り返しがつかないため、後述のとおり、まずは送信直前までを自動化して人が最終確認する形から始めることをおすすめします。

ユースケース4: Webデータの抽出

agent = Agent(
    task="""
    https://example.com/blog の記事一覧から、
    最新10件の記事タイトル・公開日・URLを抽出し、
    JSON形式で出力してください
    """,
    llm=llm
)

出力形式を指示できるため、後続の処理に渡しやすい構造化データとして受け取れます。JSONで受けてそのまま社内のデータ基盤に流す、といったパイプラインが組みやすくなります。

自動化の優先順位をどう決めるか

4つのユースケースは、リスクと効果が同じではありません。私たちがお客様と自動化の対象を決めるときは、次のような順番で考えます。

優先度 対象となる業務の条件 例
高 読み取りのみ・繰り返し頻度が高い・失敗しても元に戻せる 競合サイトの定点調査、記事一覧の抽出
中 読み取り中心だが認証が必要・週次程度の頻度 管理画面のレポート取得、スクリーンショット収集
低 書き込みや送信を伴う・外部に影響が及ぶ フォーム送信、外部サービスへの登録

まずは「読み取りだけ」「失敗しても誰にも迷惑がかからない」タスクから始めて、安定して動くことを確認してから書き込み系に広げていくのが安全な順序です。最初から基幹業務の自動化に挑むと、失敗したときの影響が大きく、「AIは使えない」という結論になってしまいがちです。小さく回して成功体験を積む方が、結果として適用範囲は広がります。


他ツールとの比較・使い分け

ブラウザやPCを操作するAIエージェントは複数あり、それぞれ得意領域が異なります。ここでは特性を事実ベースで並べたうえで、選び方の軸を整理します。どれが優れているかではなく、何を自動化したいかで決まる、というのが結論です。

特性の比較

比較項目 Browser Use CLI Claude Computer Use Manus My Computer
ターゲット ブラウザ操作に特化 デスクトップ全般 PC全般
認識方式 DOM解析 スクリーンショット エージェント型
オープンソース はい いいえ(API) いいえ
カスタマイズ性 高い(Pythonで拡張) API制御 GUIベース
対応LLM 複数(Claude, GPT-4等) Claudeのみ Manus固有
ブラウザ外の操作 不可 可能 可能

使い分けの判断基準

  • ブラウザ操作だけを自動化したい: Browser Use CLIが適しています
  • デスクトップアプリも含めて自動化したい: Claude Computer Use(DD-32)またはManus My Computer(DD-39)
  • OSSとして自由にカスタマイズしたい: Browser Use CLIが向いています
  • 非エンジニアが使いたい: Manus My Computerも手軽な選択肢の一つです

判断の起点は「自動化したい作業がブラウザの中で完結するかどうか」です。ブラウザ内で完結するならBrowser Use CLI、ローカルファイルの操作やデスクトップアプリをまたぐならデスクトップ全般を扱えるツール、という切り分けになります。

Browser Use CLIが向かないケース

正直にお伝えすると、次のようなケースではBrowser Use CLIは第一候補になりません。

状況 理由と代替の考え方
公式APIが用意されている処理 APIの方が高速で安定します。ブラウザ操作は最後の手段と考えます
ミリ秒単位の応答速度が求められる処理 LLMの推論が挟まるため、リアルタイム処理には不向きです
ブラウザ外のデスクトップアプリ操作 仕様上ブラウザ外は操作できません
Pythonの実行環境を用意できない組織 運用の主担当を置けない場合、GUIベースのツールの方が定着します
毎回まったく同じ操作を厳密に再現したい処理 LLMが判断する以上、実行ごとの揺れを完全には排除できません

特に最後の点は、導入前に認識しておきたいところです。「毎回同じ手順を寸分違わず実行する」ことが要件なら、従来型の決め打ちスクリプトの方が適しています。Browser Useが強いのは、多少の画面変更を吸収しながら目的を達成するという柔軟さの方です。


Claude Codeとの統合と仕組み化

単発でブラウザを操作するだけでは、作業がAIに置き換わっただけで終わります。価値が出るのは、取得したデータが後続の処理に自動で流れていく形を作ったときです。ここではClaude Codeと組み合わせて、継続的に回る仕組みにする考え方を整理します。

Claude Codeから呼び出す

Browser Use CLIはPythonベースのため、Claude Codeのバッチ処理パイプラインに組み込むことが可能です。

# Claude Codeから呼び出す例
claude "browser-useのPythonスクリプトを作成して。
HubSpotのブログから最新5記事のタイトルとURLを取得し、
JSON形式で output/hubspot_articles.json に保存する処理を実装して。"

バッチ・並列処理(DD-9)と組み合わせることで、複数サイトの同時巡回やデータ収集の並列化も実現できます。

「収集」で止めず「活用」までつなぐ

ブラウザ自動化を業務に定着させるには、次の一連の流れとして設計するのが有効です。

  1. Browser Use CLIでWeb上の情報を収集する
  2. JSONなど構造化された形式で出力する
  3. 出力をCRMや社内のデータ基盤に取り込む
  4. レポート・ダッシュボードとして可視化する
  5. 結果を見て、収集する項目や頻度を見直す

CRM運用の現場では、「競合のWebサイトを調査」「管理画面からデータを取得」「フォームへの一括入力」など、ブラウザ操作が必要な業務は日常的に発生します。これらで得た情報を、コンタクトや取引のレコードに紐づく形で蓄積できれば、営業・マーケティングの判断材料になります。逆に、収集したデータがローカルのファイルに溜まるだけでは、スプレッドシートが増えた状態と大きくは変わりません。一元管理されたデータベースに戻す設計まで含めて考えることが、仕組み化の要になってきます。

属人化させないための運用ルール

自動化スクリプトは、放っておくと「作った人しかわからないブラックボックス」になります。そうならないために、最低限これだけは決めておくとよい、というポイントを挙げます。

  • タスクの指示文(自然言語プロンプト)をコードと一緒にバージョン管理する
  • 実行ログと出力ファイルの保存先を統一し、失敗時に追跡できるようにする
  • 実行が失敗したときの通知先と、一次対応の担当を決めておく
  • 新しいタスクを追加するときのレビュー手順を1つ決めておく

これらはいずれも大げさな仕組みではありませんが、担当者が変わっても運用が続くかどうかを分けます。


安全に運用するための設計

ブラウザ自動化は、ログイン済みのセッションや入力フォームを扱う以上、設定を誤ると実害につながります。ここでは押さえておきたいリスクと、具体的な制限のかけ方を整理します。導入前に一度、チームで確認しておくことをおすすめします。

主なリスクと対策

リスク 対策
認証情報の漏洩 ブラウザのプロファイルを分離。自動入力にパスワードマネージャーを使わない
不正サイトへのアクセス URLホワイトリストで巡回先を制限
個人情報の外部送信 LLMへのリクエストに機密データが含まれないよう注意
操作の暴走 タイムアウト設定、最大ステップ数の制限

実行範囲を制限する

エージェントが想定外の動きをしたときに、被害を最小化するための設定です。

# 安全な設定例
agent = Agent(
    task="...",
    llm=llm,
    max_steps=50,           # 最大ステップ数を制限
    max_time=300,           # 5分でタイムアウト
)

ステップ数と実行時間に上限を設けておくと、LLMが目的を達成できずに同じ操作を繰り返し続ける、といった状態を防げます。最初は上限を小さめに設定して実行し、タスクの実態に合わせて調整していく方が安全です。

AIに任せること/人が判断すること

ブラウザ操作の自動化でも、すべてをAIに委ねるべきではないと考えています。特に外部に影響が及ぶ操作は、人間の確認を挟む設計が前提です。

AIに任せやすい 人が判断すべき
公開情報の閲覧・巡回 送信・申込など取り消せない操作の実行可否
ページからのデータ抽出・整形 機密情報をLLMに渡してよいかの線引き
複数サイトの横断的な情報収集 巡回先のホワイトリストの設計
定型レポート画面のスクリーンショット取得 取得したデータの解釈と意思決定

フォーム送信のような不可逆な操作は、まず「入力までを自動化し、送信は人が押す」形から始め、十分な実績が積み上がってから送信まで自動化する、という段階を踏むのが現実的です。

なお、こうした「AIに任せる範囲を明示的に設計する」という考え方は、ブラウザ自動化に限った話ではありません。たとえばHubSpotのAI機能であるBreezeでも、エージェントの振る舞いはガイドラインとして事前に定義します。以下の画面は、Breezeのカスタマーエージェントでトーンや応答スタイルを設定する画面で、入力欄が空の初期状態です。どこまでをAIに委ね、どう振る舞わせるかを先に決めておく点は、ツールを問わず共通しています。

Breezeカスタマーエージェント ガイドライン設定画面


導入をどう進めるか:スモールスタートの設計

最後に、実際に社内に取り入れる際の進め方を整理します。ツールの性能よりも、どこから始めてどう広げるかの設計が定着を左右します。私たちがAI活用のご相談をいただく際も、まず対象業務を絞ることから始めています。

段階的に広げる3ステップ

段階 やること 確認するポイント
第1段階 公開サイトの読み取りタスクを1つ自動化する 期待どおりのデータが安定して取れるか
第2段階 認証が必要な管理画面の定型取得を追加する 認証情報の管理方法とログ追跡ができているか
第3段階 出力をデータ基盤やCRMに連携し、定期実行にする 失敗時の検知と一次対応の担当が決まっているか

いきなり全社的な自動化基盤を目指すのではなく、1つのタスクが安定して回ることを確認してから次に進む方が、結果的に早く広がります。

自社に合わせて設計する

どの業務から自動化すべきかは、企業様によって最適な形は異なります。営業チームが競合情報のリサーチに時間を取られている会社と、バックオフィスが複数SaaSの管理画面を巡回している会社とでは、最初に手をつけるべき対象がまったく違います。次の観点で、自社の状況を棚卸ししてみてください。

  • その作業は月に何回発生しているか(頻度が低ければ自動化の優先度は下がります)
  • 公式APIで代替できないか(代替できるならAPIを優先します)
  • 失敗したときに誰に影響が及ぶか(社外に影響するなら人の確認を挟みます)
  • 担当者が不在でも回す必要があるか(属人化解消が目的なら優先度は上がります)

この4つを並べると、自動化の候補は自然と順位づけされます。全部を一度に進めるのは難しいので、効果が出そうなものから優先順位をつけてトライいただければと思います。AI活用のさらなる事例は、経営データBI支援やコンテンツマーケティング支援のページもご覧ください。


よくある質問

Q1. Browser Use CLIは従来のスクレイピングツール(BeautifulSoup等)と何が違いますか?

従来のスクレイピングツールはHTMLの構造をハードコーディングして解析するため、サイト構造が変更されるとスクリプトの修正が必要でした。Browser Use CLIはAIがDOM構造を動的に認識してアクションを決定するため、サイト変更への耐性が高いです。また、自然言語でタスクを指示できるため、スクレイピングのコーディング工数を抑えられます。一方で、毎回まったく同じ操作を厳密に再現したい場合は、従来型の決め打ちスクリプトの方が適しています。

Q2. Browser Use CLIのバックエンドにはどのLLMを使うのがおすすめですか?

Claude、GPT-4、Geminiなど複数のLLMに対応しています。Claude Codeと併用する場合はAnthropicのClaude(Sonnetモデル)をバックエンドに設定すると、API管理が統一できて効率的です。タスクの複雑さや要件に応じてモデルを選択してください。まずは1つのモデルで挙動を確認し、必要に応じて切り替える形が扱いやすいかと思います。

Q3. Browser Use CLIとClaude Computer Use、Manus My Computerはどう使い分けますか?

ブラウザ操作だけを自動化したい場合はBrowser Use CLIが適しています。デスクトップアプリも含めて自動化したい場合はClaude Computer UseまたはManus My Computerを選択してください。OSSとして自由に拡張したい場合はBrowser Use CLIが向いており、Pythonで処理を組み込める点が強みです。逆に、Pythonの実行環境を社内に用意しづらい場合は、GUIベースのツールの方が定着しやすい傾向があります。

Q4. フォーム送信のような操作も最初から自動化してよいのでしょうか?

送信や申込など取り消せない操作は、最初から全自動にすることはおすすめしていません。まずは入力までを自動化し、送信ボタンは人が押す形から始めて、期待どおりに動くことを確認してから範囲を広げる方が安全です。あわせて最大ステップ数やタイムアウトを設定し、想定外の動作が続かないようにしておきます。

Q5. 収集したデータはどう管理すればよいですか?

ローカルのファイルに溜めるだけでは、スプレッドシートが増えた状態と大きく変わりません。JSONなど構造化された形式で出力し、CRMや社内のデータ基盤に取り込んで、コンタクトや取引のレコードに紐づく形で蓄積すると、営業・マーケティングの判断材料として使えるようになります。出力先と保存ルールは、最初のタスクを作る段階で決めておくのがおすすめです。


まとめ

本記事では、Browser Use CLIの仕組みと、実務で使うための運用設計について解説しました。

  • Browser Use CLIは、AIエージェントがChromiumブラウザを自動操作するオープンソースのコマンドラインツールで、自然言語での指示だけでWeb操作を実行できます
  • DOM解析による操作、複数LLM対応、Pythonベースの拡張性が特徴で、サイト構造の変更にも柔軟に対応しやすい設計です
  • 競合調査、管理画面の定型操作、フォーム入力、データ抽出が代表的な用途ですが、公式APIがある処理はAPIを優先し、ブラウザ操作は補完として位置づけるのが実務的です
  • 送信など不可逆な操作は人が判断し、AIには収集・整形を任せるという役割分担を設計に織り込みます
  • 収集したデータをCRMやデータ基盤に戻すところまで設計して、はじめて仕組みとして回り始めます

最初の一歩としては、公開サイトの情報を1つだけ読み取るタスクから始めるのがおすすめです。具体的には、次の3ステップで進めてみてください。

  1. ローカル環境にBrowser Use CLIをインストールし、公開サイトを対象に1回実行して挙動を確認する
  2. 自社で月に何度も発生している「読み取りだけの調査作業」を1つ選び、自然言語のタスク指示に書き起こす
  3. 出力形式と保存先を決め、実行ログが追えるようにしたうえで、週次など定期実行に載せる

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

Claude Codeの全コマンド一覧はClaude Codeチートシートをご覧ください。AI活用の全体像はAI活用完全ガイドで解説しています。


あわせて読みたい


株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化(ERP/CRM/SFA/MAの導入)」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

関連キーワード:

サービス資料を無料DL

著者情報

7-1

今枝 拓海 / Takumi Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。