本文へスキップ
やす研究所 AI Lab
戻る

Claude Browser Use Tool実践2026:Web操作エージェントをAPIで動かす手順

Claude Browser Use Tool実践2026:Web操作エージェントをAPIで動かす手順

Anthropic が 2026 年 9 月に GA した Browser Use tool を、実際に自分の検証環境で動かしてみました。Computer Use が「画面のピクセルを見てクリックする」方式だったのに対し、Browser Use は DOM 構造を持ったまま Web ページを操作できる新しいツールです。

何が変わって、どう使い分ければいいのか。API から呼ぶ最小コード、Computer Use との違い、料金の考え方、そして本番投入前に必ず知っておきたい制約まで、実務目線でまとめます。

結論:Web だけを触るなら Browser Use、それ以外は Computer Use

先に結論だけ言うと、対象がブラウザ内で完結するタスク(フォーム入力、SaaS の定期作業、Web スクレイピング的な情報収集)なら Browser Use に寄せた方が精度もコストも有利です。逆に、デスクトップアプリや OS レベルの操作が混ざるなら Computer Use を使い続ける、という切り分けになります。

Anthropic の公式アナウンスによると、Computer use、Skills API、Files API は Claude Platform で GA しており、Computer use には Web アプリで動くエージェント向けの新しい Browser Use tool が追加されました。従来のスクリーンショット主導型ではなく、同じマルチアクションターンを使いつつページ構造を追加することで、エージェントがピクセル単体よりも正確に Web 要素をターゲットできるのがコア変更点です。

私が最初に触ったときの率直な感想は「これはようやく実務で回せるやつだ」でした。Computer Use を業務投入すると、レイアウト変更で座標がズレて再クリックする挙動が地味に痛かったんですよね。DOM が見えるだけで、この不安定さがかなり消えます。

Browser Use と Computer Use の違いを表で整理

2 つのツールは名前も似ていて混乱しやすいので、選定軸だけ表にしておきます。数値は公式ドキュメントで確認できる範囲に絞りました。

評価軸Browser Use toolComputer Use
対象範囲Web ブラウザ内のみデスクトップ全体(ブラウザ含む)
認識方式DOM 構造 + スクリーンショットスクリーンショット(ピクセル)主体
実行環境Anthropic 側でホスト可 / セルフホストも可自前のサンドボックス VM が必須
セットアップAPI 呼び出しのみで開始可能Mutter+Tint2 等のデスクトップ環境を用意
想定ユースケースSaaS 操作、フォーム入力、Web 情報収集レガシーアプリ、OS 操作、ファイル管理
提供状況(2026-09)GAGA

Computer Use 側については、API レベルの Computer Use はサンドボックス化された VM と軽量デスクトップ(Mutter と Tint2 が推奨)を必要とし、独立エンドポイントではなく Messages API に組み込まれていることに注意してください。この初期セットアップの重さが、Web タスクに限れば Browser Use に流れる最大の理由です。

表だけだと差が伝わりにくいのですが、実際に分かれるのは「要素の指定精度」です。Computer Use が click(x, y) で座標依存なのに対し、Browser Use はページ構造から要素を選ぶので、A/B テストで DOM が微妙に変わっても崩れにくい。ここが体感で一番効きます。

Python から Browser Use tool を叩く最小コード

実装は驚くほど普通の Messages API 呼び出しです。tools 配列に browser use ツールを宣言し、モデルに URL とゴールを渡すだけ。以下は私が最初に検証したときの骨格です(2026 年 9 月時点の型シグネチャに合わせています)。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    tools=[
        {
            "type": "browser_use_20260901",
            "name": "browser",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": (
                "https://example.com/pricing を開いて、"
                "月額プランの一覧を JSON で返して。"
                "取得後はページを閉じてよい。"
            ),
        }
    ],
)

for block in response.content:
    if block.type == "tool_use":
        print("action:", block.input)
    elif block.type == "text":
        print(block.text)

ポイントは、tool_use ブロックが navigate / click / type / extract といった構造化アクションで返ってくることです。Computer Use のようにスクリーンショットを毎ターン往復させる必要がないので、トークン消費がぐっと軽くなります。

実運用ではここに Agent SDK のループを噛ませて、tool_result を返しながら数十ターン走らせる形になります。単発で終わるタスクはほぼないと思っていいでしょう。

Opus 5 で動かすときに必ず踏む thinking の罠

Browser Use を Opus 5 と組み合わせるとき、Extended Thinking の挙動が Opus 4.8 から変わっている点を先に押さえておいた方がいいです。私は最初これを知らずに 400 エラーを 20 分くらい追いかけました。

Claude Opus 5 は 1M トークンのコンテキストウィンドウ(デフォルトも最大も 1M)、最大 128k の出力トークン、thinking がデフォルトで有効という仕様で、料金は $5/$25 per MTok と Opus 4.8 と同じです。一見素直ですが、Opus 5 では thinking の無効化が effort high 以下でしか許可されず、thinking: {"type": "disabled"} を effort xhigh または max で指定すると 400 エラーが返るという、Opus 4.8 からの破壊的変更が入っています

つまり「max effort で高速に回したい、でも思考ブロックはいらない」という組み合わせが不可能になったわけです。Browser Use は 1 タスクで多ターン走るので、effort と thinking の設定は最初に固定しておかないと後で全ターンが 400 で落ちる、というやや残酷なことが起こります。

もう一つ、マルチターンで thinking ブロックを保持する場合の制約もあります。Claude Fable 5.1 と Claude Mythos 5.1 が生成した思考ブロックは、それを生成したモデルか、より新しいモデルにしか保持されず、古いモデルは読めない仕様で、古いモデルにリプレイされた場合 API はドロップします。Claude Fable 5.1 は Opus 5、Fable 5、Mythos 5 およびそれ以前の Claude モデルからの思考ブロックを受け入れます。Browser Use のセッション中にモデルを切り替える設計をするなら、この方向性(古い→新しい)を守らないと thinking が黙って消えます。

Sonnet 5 に落として料金を絞るときの判断

Browser Use はターン数が伸びやすいので、料金設計は Computer Use 以上にシビアです。私の感覚では、Web の情報収集や単純な入力タスクは Sonnet 5 で十分でした。

Claude Code の changelog によれば、サンドボックス化された Bash tool のプロンプトが許可ネットワークホストを列挙しなくなり、Claude が未リストのホストへも実際にリクエストを試みる挙動に変わり、また /model ピッカーとバンドルされた claude-api skill が Sonnet 5 の $2/$10 per MTok の料金を表示するように更新されました。API 側も同じ料金体系なので、Opus 5 の $5/$25 と比べて入力で 2.5 倍、出力で 2.5 倍の差があります。

判断の目安として、私は以下で切り分けています。

特に監視系はキャッシュとの相性が良く、システムプロンプトと初期ページ構造を使い回すだけで入力コストが半分以下になりました。

Skills API と組み合わせて再利用可能にする

Browser Use を「毎回プロンプトに手順を書く」状態で運用すると、すぐに CLAUDE.md 的な肥大化が起きます。ここで効くのが Skills API です。

Skills API は独自の Skill をアップロード・バージョン管理するためのよりシンプルな APIで、Skills は必須の SKILL.md と任意のスクリプト・リソースを保持するファイルシステムフォルダで、Claude はセッション開始時に利用可能な Skills をスキャンし、最初は最小限のメタデータだけをロードして、タスクに関連する場合のみ追加ファイルをロードします

Browser Use 用の Skill には、たとえば「対象 SaaS のログイン導線」「よく使うフィルタ URL パターン」「抽出結果の JSON スキーマ」を SKILL.md に書いておくと、モデルが必要なときだけ読み込んでくれます。プロンプト冒頭のトークン浪費を防げるので、ターン数の多い Browser Use とは特に相性がいい。

併せて、Files API は自動的なファイル失効、5 倍高いレートリミット、組織あたり 1TB のストレージという強化が入っているので、Browser Use で取得したページのスナップショットや PDF を Files API に置いて file_id で回す、という設計もかなり現実的になりました。

セルフホストか Anthropic ホストかで悩んだら

Browser Use は Anthropic 側でブラウザを動かしてもらう形と、自前のブラウザに接続する形の両方を取れます。ここは要件で素直に決まります。

認証情報を Anthropic 側に置きたくない業務(社内 SaaS、顧客データ扱い)は、Playwright 等をセルフホストして tool_result 側で結果を返す構成に倒す。逆に、公開 Web の情報収集や社外プロトタイプは Anthropic ホストで十分、というのが私の現状の使い分けです。

セルフホスト時に一つ注意したいのが、Claude Code の auto mode 側の変化です。auto mode が、コンテンツを公開ダイアグラムレンダラーの URL に詰め込むリンクを、そのサイトへのアップロードとして扱うように変更され、明示的に要求しない限り自動承認されなくなりました”。API 直接呼び出しでは関係ありませんが、Claude Code から Browser Use を絡めるフローを組む場合は「勝手に外部にデータが送られない」設計思想を意識しておくと事故が減ります。

Browser Use を本番で使う前に確認する 3 項目

最後に、私が本番投入前のチェックリストとして回している 3 項目を置いておきます。

  1. モデルと effort の固定:Opus 5 の thinking 制約(effort xhigh/max では disabled 不可)を回避するため、Skill か wrapper で effort=high に固定しておく
  2. タイムアウト設計:Browser Use は 1 タスクで数分走ることがあるので、API_TIMEOUT_MS 相当の上限を明示。Claude Code 側では API がレスポンスヘッダを返さない場合のリトライが、デフォルト 10 分の API_TIMEOUT_MS まで待つように改善されていますので、API 側もこの前提で組む
  3. 抽出結果のスキーマ強制:Browser Use の最終出力は自然文になりがちなので、Structured Outputs か output_format を必ず併用して JSON を壊さない

Browser Use は「Web だけの Computer Use」ではなく別ツールとして設計する

名前が Computer Use の派生に見えるので同列に扱いたくなりますが、実際に触った感触では、Browser Use は「DOM を扱える Web エージェント基盤」であって、Computer Use のサブセットではありません。ページ構造を前提にプロンプトを書き、Sonnet 5 で回して、失敗ケースだけ Opus 5 に上げる、くらいの設計から始めると、コストも精度もバランスします。

次に手を動かすなら、まず手元の SaaS 1 つを選んで、ログイン後にダッシュボードの数値を JSON で取ってくる 20 行スクリプトを書いてみてください。DOM 前提の指示に慣れると、Computer Use のプロンプトの書き方まで一段軽くなります。

参考リンク


この記事をシェア:

次の記事
Cursor Subscriptions実践手順2026:PRとSlackを購読させて放置する新作法