ブラウザ前の「人がやるしかない作業」を、AIエージェントに渡す。自動化の対象を、APIの外側まで広げる。
ブラウザ前の「人がやるしかない作業」を、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」について、仕組みの理解から実務での運用設計までを一気通貫で解説します。
ブラウザ操作の自動化やデータ収集を効率化したいエンジニアの方、AIエージェントツールを比較検討している情報システム・マーケティング担当の方に向けて書いています。最後まで読むと、自社のどの業務から自動化を始めるべきかを判断し、小さく試して段階的に広げる設計ができるようになります。
Browser Useは、LLM(大規模言語モデル)をバックエンドとして、ブラウザの自動操作を実現するPythonベースのOSS(オープンソースソフトウェア)です。CLI版では、コマンドラインから自然言語のタスク指示を入力し、AIがブラウザを操作して結果を返します。ここではまず、その内部構造と「従来のスクレイピングと何が違うのか」を押さえておきます。
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が動く環境であれば、インストールから初回実行まではごく短いステップで到達できます。まずは自分のローカル環境で、影響のない公開サイトを相手に一度動かしてみるのがおすすめです。
# pipでインストール
pip install browser-use
# Playwrightのブラウザをインストール
playwright install chromium
Playwrightのブラウザ本体は別途ダウンロードが必要です。ここを忘れると、実行時にブラウザが見つからずエラーになります。
使用するLLMのAPIキーを設定します。
# Claudeをバックエンドにする場合
export ANTHROPIC_API_KEY="your-api-key"
# OpenAIをバックエンドにする場合
export OPENAI_API_KEY="your-api-key"
APIキーはシェルの設定ファイルに直書きせず、環境変数管理の仕組みに寄せておくと、チームで共有する際の事故を減らせます。
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)
# コマンドラインから直接タスクを指示
browser-use "HubSpotの公式サイトで料金プランを確認し、比較表を作成してください"
CLIから直接叩けるため、シェルスクリプトやcronに組み込みやすいのが利点です。逆に、複雑な条件分岐や結果の後処理が必要な場合は、Pythonで書いた方が制御しやすくなります。最初はCLIで感触をつかみ、定常運用に載せる段階でPythonスクリプトに移す、という順序が実務的です。
ブラウザ自動化は、やろうと思えばほとんどのWeb操作に適用できてしまいます。だからこそ、最初に手をつける対象の選び方が成果を分けます。ここでは代表的な4パターンを、自動化の適性とあわせて整理します。
agent = Agent(
task="""
以下の3つのCRMツールの公式サイトにアクセスし、
それぞれの料金プラン(月額・年額)と主要機能を調査して、
Markdown形式の比較表にまとめてください:
1. HubSpot (hubspot.com)
2. Salesforce (salesforce.com)
3. Zoho CRM (zoho.com/crm)
""",
llm=llm
)
複数サイトを巡回しての情報収集を自動化します。手作業で数時間かかるリサーチをAIに委託できます。定期的に同じ観点で見に行く調査ほど、自動化の効果が出やすい領域です。
agent = Agent(
task="""
HubSpotのダッシュボードにログインし、
今月の新規コンタクト数と取引パイプラインの概要をスクリーンショットで取得してください
""",
llm=llm
)
APIで取得しにくいダッシュボードのビジュアル情報を、ブラウザ操作で直接取得するパターンです。ただし、APIが提供されている処理は、原則APIを使うべきです。ブラウザ操作は画面の変更に影響を受けますし、実行時間もAPIより長くなります。「APIで取れないものだけをブラウザ操作で補う」という線引きを最初に決めておくと、後の保守が楽になります。
agent = Agent(
task="""
以下のCSVデータの各行について、
https://example.com/contact-form にアクセスし、
名前・メール・会社名のフォームに入力して送信してください
""",
llm=llm
)
CSVを手作業で1行ずつフォームに転記する、といった作業を置き換えられます。送信を伴う操作は取り返しがつかないため、後述のとおり、まずは送信直前までを自動化して人が最終確認する形から始めることをおすすめします。
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、ローカルファイルの操作やデスクトップアプリをまたぐならデスクトップ全般を扱えるツール、という切り分けになります。
正直にお伝えすると、次のようなケースではBrowser Use CLIは第一候補になりません。
| 状況 | 理由と代替の考え方 |
|---|---|
| 公式APIが用意されている処理 | APIの方が高速で安定します。ブラウザ操作は最後の手段と考えます |
| ミリ秒単位の応答速度が求められる処理 | LLMの推論が挟まるため、リアルタイム処理には不向きです |
| ブラウザ外のデスクトップアプリ操作 | 仕様上ブラウザ外は操作できません |
| Pythonの実行環境を用意できない組織 | 運用の主担当を置けない場合、GUIベースのツールの方が定着します |
| 毎回まったく同じ操作を厳密に再現したい処理 | LLMが判断する以上、実行ごとの揺れを完全には排除できません |
特に最後の点は、導入前に認識しておきたいところです。「毎回同じ手順を寸分違わず実行する」ことが要件なら、従来型の決め打ちスクリプトの方が適しています。Browser Useが強いのは、多少の画面変更を吸収しながら目的を達成するという柔軟さの方です。
単発でブラウザを操作するだけでは、作業がAIに置き換わっただけで終わります。価値が出るのは、取得したデータが後続の処理に自動で流れていく形を作ったときです。ここではClaude Codeと組み合わせて、継続的に回る仕組みにする考え方を整理します。
Browser Use CLIはPythonベースのため、Claude Codeのバッチ処理パイプラインに組み込むことが可能です。
# Claude Codeから呼び出す例
claude "browser-useのPythonスクリプトを作成して。
HubSpotのブログから最新5記事のタイトルとURLを取得し、
JSON形式で output/hubspot_articles.json に保存する処理を実装して。"
バッチ・並列処理(DD-9)と組み合わせることで、複数サイトの同時巡回やデータ収集の並列化も実現できます。
ブラウザ自動化を業務に定着させるには、次の一連の流れとして設計するのが有効です。
CRM運用の現場では、「競合のWebサイトを調査」「管理画面からデータを取得」「フォームへの一括入力」など、ブラウザ操作が必要な業務は日常的に発生します。これらで得た情報を、コンタクトや取引のレコードに紐づく形で蓄積できれば、営業・マーケティングの判断材料になります。逆に、収集したデータがローカルのファイルに溜まるだけでは、スプレッドシートが増えた状態と大きくは変わりません。一元管理されたデータベースに戻す設計まで含めて考えることが、仕組み化の要になってきます。
自動化スクリプトは、放っておくと「作った人しかわからないブラックボックス」になります。そうならないために、最低限これだけは決めておくとよい、というポイントを挙げます。
これらはいずれも大げさな仕組みではありませんが、担当者が変わっても運用が続くかどうかを分けます。
ブラウザ自動化は、ログイン済みのセッションや入力フォームを扱う以上、設定を誤ると実害につながります。ここでは押さえておきたいリスクと、具体的な制限のかけ方を整理します。導入前に一度、チームで確認しておくことをおすすめします。
| リスク | 対策 |
|---|---|
| 認証情報の漏洩 | ブラウザのプロファイルを分離。自動入力にパスワードマネージャーを使わない |
| 不正サイトへのアクセス | URLホワイトリストで巡回先を制限 |
| 個人情報の外部送信 | LLMへのリクエストに機密データが含まれないよう注意 |
| 操作の暴走 | タイムアウト設定、最大ステップ数の制限 |
エージェントが想定外の動きをしたときに、被害を最小化するための設定です。
# 安全な設定例
agent = Agent(
task="...",
llm=llm,
max_steps=50, # 最大ステップ数を制限
max_time=300, # 5分でタイムアウト
)
ステップ数と実行時間に上限を設けておくと、LLMが目的を達成できずに同じ操作を繰り返し続ける、といった状態を防げます。最初は上限を小さめに設定して実行し、タスクの実態に合わせて調整していく方が安全です。
ブラウザ操作の自動化でも、すべてをAIに委ねるべきではないと考えています。特に外部に影響が及ぶ操作は、人間の確認を挟む設計が前提です。
| AIに任せやすい | 人が判断すべき |
|---|---|
| 公開情報の閲覧・巡回 | 送信・申込など取り消せない操作の実行可否 |
| ページからのデータ抽出・整形 | 機密情報をLLMに渡してよいかの線引き |
| 複数サイトの横断的な情報収集 | 巡回先のホワイトリストの設計 |
| 定型レポート画面のスクリーンショット取得 | 取得したデータの解釈と意思決定 |
フォーム送信のような不可逆な操作は、まず「入力までを自動化し、送信は人が押す」形から始め、十分な実績が積み上がってから送信まで自動化する、という段階を踏むのが現実的です。
なお、こうした「AIに任せる範囲を明示的に設計する」という考え方は、ブラウザ自動化に限った話ではありません。たとえばHubSpotのAI機能であるBreezeでも、エージェントの振る舞いはガイドラインとして事前に定義します。以下の画面は、Breezeのカスタマーエージェントでトーンや応答スタイルを設定する画面で、入力欄が空の初期状態です。どこまでをAIに委ね、どう振る舞わせるかを先に決めておく点は、ツールを問わず共通しています。

最後に、実際に社内に取り入れる際の進め方を整理します。ツールの性能よりも、どこから始めてどう広げるかの設計が定着を左右します。私たちがAI活用のご相談をいただく際も、まず対象業務を絞ることから始めています。
| 段階 | やること | 確認するポイント |
|---|---|---|
| 第1段階 | 公開サイトの読み取りタスクを1つ自動化する | 期待どおりのデータが安定して取れるか |
| 第2段階 | 認証が必要な管理画面の定型取得を追加する | 認証情報の管理方法とログ追跡ができているか |
| 第3段階 | 出力をデータ基盤やCRMに連携し、定期実行にする | 失敗時の検知と一次対応の担当が決まっているか |
いきなり全社的な自動化基盤を目指すのではなく、1つのタスクが安定して回ることを確認してから次に進む方が、結果的に早く広がります。
どの業務から自動化すべきかは、企業様によって最適な形は異なります。営業チームが競合情報のリサーチに時間を取られている会社と、バックオフィスが複数SaaSの管理画面を巡回している会社とでは、最初に手をつけるべき対象がまったく違います。次の観点で、自社の状況を棚卸ししてみてください。
この4つを並べると、自動化の候補は自然と順位づけされます。全部を一度に進めるのは難しいので、効果が出そうなものから優先順位をつけてトライいただければと思います。AI活用のさらなる事例は、経営データBI支援やコンテンツマーケティング支援のページもご覧ください。
従来のスクレイピングツールはHTMLの構造をハードコーディングして解析するため、サイト構造が変更されるとスクリプトの修正が必要でした。Browser Use CLIはAIがDOM構造を動的に認識してアクションを決定するため、サイト変更への耐性が高いです。また、自然言語でタスクを指示できるため、スクレイピングのコーディング工数を抑えられます。一方で、毎回まったく同じ操作を厳密に再現したい場合は、従来型の決め打ちスクリプトの方が適しています。
Claude、GPT-4、Geminiなど複数のLLMに対応しています。Claude Codeと併用する場合はAnthropicのClaude(Sonnetモデル)をバックエンドに設定すると、API管理が統一できて効率的です。タスクの複雑さや要件に応じてモデルを選択してください。まずは1つのモデルで挙動を確認し、必要に応じて切り替える形が扱いやすいかと思います。
ブラウザ操作だけを自動化したい場合はBrowser Use CLIが適しています。デスクトップアプリも含めて自動化したい場合はClaude Computer UseまたはManus My Computerを選択してください。OSSとして自由に拡張したい場合はBrowser Use CLIが向いており、Pythonで処理を組み込める点が強みです。逆に、Pythonの実行環境を社内に用意しづらい場合は、GUIベースのツールの方が定着しやすい傾向があります。
送信や申込など取り消せない操作は、最初から全自動にすることはおすすめしていません。まずは入力までを自動化し、送信ボタンは人が押す形から始めて、期待どおりに動くことを確認してから範囲を広げる方が安全です。あわせて最大ステップ数やタイムアウトを設定し、想定外の動作が続かないようにしておきます。
ローカルのファイルに溜めるだけでは、スプレッドシートが増えた状態と大きく変わりません。JSONなど構造化された形式で出力し、CRMや社内のデータ基盤に取り込んで、コンタクトや取引のレコードに紐づく形で蓄積すると、営業・マーケティングの判断材料として使えるようになります。出力先と保存ルールは、最初のタスクを作る段階で決めておくのがおすすめです。
本記事では、Browser Use CLIの仕組みと、実務で使うための運用設計について解説しました。
最初の一歩としては、公開サイトの情報を1つだけ読み取るタスクから始めるのがおすすめです。具体的には、次の3ステップで進めてみてください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
Claude Codeの全コマンド一覧はClaude Codeチートシートをご覧ください。AI活用の全体像はAI活用完全ガイドで解説しています。
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化(ERP/CRM/SFA/MAの導入)」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。