Claude の Python / TypeScript SDK に browser use・computer use のクラスが追加。ツールループと承認フローが SDK 側へ移る
Claude の Python SDK と TypeScript SDK に、browser use tool と computer use tool 用のクラスがベータとして追加された。提供されたクラスをサブクラス化し、ツール1つにつき1メソッドを自分のブラウザ自動化・デスクトップ自動化の実装に対して書くだけでよく、ツールループの実行、ブラウザに設定した URL ポリシーとファイルポリシーの適用、承認コールバックの呼び出しは SDK 側が担う。これまでアプリ側で書く必要があった定型処理が SDK へ寄せられた形である。ツール定義のトークン量は従来どおり大きく、browser_toolset_20260801 の既定メンバーで約 6,600 入力トークン、computer_toolset_20260801 で約 4,500 入力トークンがリクエストに乗る。
ニュース原文を読む ↗要約
Anthropic が2026年10月7日、Claude の Python SDK と TypeScript SDK に browser use tool と computer use tool 用のクラスをベータとして追加しました。
使い方はシンプルです。 提供されたクラスをサブクラス化し、ツール1つにつき1メソッドを、自分のブラウザ自動化・デスクトップ自動化の実装に対して書きます。 その上で SDK 側が次の3つを担います。
- ツールループの実行 — モデルからツール呼び出しを受け、結果を返す往復
- ブラウザに設定した URL ポリシーとファイルポリシーの適用
- 承認コールバックの呼び出し
つまり、これまでアプリ側で書く必要があった「モデルの指示を解釈してループを回し、許可されない URL を弾き、人間の承認を挟む」という定型処理が SDK へ寄せられました。開発者が書くのは、実際に Playwright などを操作する部分だけになります。
ここが実務上いちばん効くところです。 ブラウザ操作エージェントを自前で作ると、だいたい次の順で苦労します。まずツールループを書く。次に「想定外の URL に飛んだ」事故が起きて URL の許可リストを後付けする。そして「勝手に送信ボタンを押した」事故が起きて承認フローを後付けする。この2つの後付けが、SDK 標準として最初から入っているということです。
トークン量は従来どおり大きいままです。 browser_toolset_20260801 の既定メンバーで約 6,600 入力トークン、computer_toolset_20260801 の既定メンバーで約 4,500 入力トークンがリクエストに乗ります。browser 側はオプションメンバーを4つ全部有効にするとさらに約 880 トークン増え、configs でメンバーを無効化すると減ります（computer 側は zoom を無効化すると約 410 トークン減）。正確な値はレスポンスの usage に出るほか、token counting エンドポイントで事前に見積れます。
なお、同日公開された Claude Haiku 5.5 では computer use に computer_toolset_20260801 が必須で、旧 computer_20250124 はエラーになります。Haiku 5.5 で computer use を使うなら、ツール版数の差し替えが前提です。
何が変わったか
- Python SDK と TypeScript SDK に browser use tool / computer use tool 用のクラスを追加（ベータ）
- 提供クラスをサブクラス化し、ツール1つにつき1メソッドを自分の自動化実装に対して書く
- SDK 側がツールループを実行する
- SDK 側がブラウザの URL ポリシーとファイルポリシーを適用する
- SDK 側が承認コールバックを呼び出す
browser_toolset_20260801の既定メンバーで約 6,600 入力トークン（オプション4つ全部で +約 880）computer_toolset_20260801の既定メンバーで約 4,500 入力トークン（zoom無効化で −約 410）configsでメンバーを無効化するとトークン量が減る- 正確なトークン数はレスポンスの
usage、事前見積りは token counting エンドポイント - スクリーンショット・zoom 画像は画像入力として別途課金、テキストのツール結果（アクセシビリティツリー、ページテキスト、コンソール / ネットワークエントリ）も入力に乗る
- Haiku 5.5 では computer use に
computer_toolset_20260801が必須（旧computer_20250124は不可）
業務インパクト（一般企業向け）
統制部分が既製品になったことが、企業導入では一番の価値です。 ブラウザ操作エージェントを情シス審査に通すとき、必ず聞かれるのが「どこまでアクセスできるのか」と「人間が止められるのか」です。URL ポリシーと承認コールバックが SDK 標準として提供されていれば、「自社で実装しました」ではなく「SDK の標準機能です」と説明できます。 審査における説明の重みが違います。自前実装は「テストしていない分岐が残っていないか」を問われますが、ベンダー提供の標準機能はその議論を回避できます。
ただしベータです。 本番の業務プロセスに載せる前段としては使えますが、契約上の SLA や恒久的な仕様を前提にした設計は避けてください。 検証フェーズ（対象業務を2つ程度に絞り、数週間で挙動を実測する）に向いた段階です。
トークンの固定費を見積りに入れてください。 browser use で約 6,600 トークン、computer use で約 4,500 トークンが毎リクエストに乗ります。 これはツール定義だけの話で、実際にはスクリーンショットが画像入力として、アクセシビリティツリーやページテキストがテキスト入力として追加で乗ります。「1回の操作でいくらかかるか」を事前に把握しないと、PoC の請求額で驚くことになります。 Sonnet 5.5（入力 $2 / MTok）で 6,600 トークンなら1リクエスト約0.013ドル、1タスク20往復なら約0.26ドル。ここにスクリーンショットが加わります。token counting エンドポイントで事前に見積れるので、PoC の前に1回計算しておくのが安全です。
configs でメンバーを無効化できる点は、コスト最適化の手段として押さえてください。 使わないツールを落とせばトークンが減ります。zoom を無効化するだけで約 410 トークン減るので、画面の細部を読む必要がない業務なら素直に落とす価値があります。
Haiku 5.5 で computer use を使う場合は、ツール版数の差し替えが必須です。 同日公開の Haiku 5.5 は旧 computer_20250124 を受け付けません。「安い Haiku でデスクトップ自動化を回す」という構成は価格的に魅力的ですが、既存コードをそのまま向けるとエラーになります。 移行作業として見積りに入れてください。
副業・個人活用視点
「作るのに一番時間がかかる部分」が省けるようになりました。 ブラウザ操作エージェントは、デモを動かすまでは速いのに、実用に耐える形にするまでが長い類のものです。その長い部分（ループの堅牢化、URL の制限、承認の差し込み）が SDK に入ったので、個人開発でも「動くデモ」から「人に渡せるもの」までの距離が縮まりました。自分が書くのは Playwright の操作部分だけです。
受託案件では「承認フローが標準」が提案の武器になります。 中小企業にブラウザ自動化を提案すると、ほぼ必ず「勝手に変なことをしないか」と聞かれます。「人間が承認するまで実行しません。これは Claude の SDK の標準機能です」と言えるかどうかは、受注率に効きます。自前実装だと「本当に止まるのか」の説明責任が自分に来ますが、SDK 標準ならベンダーの仕様として示せます。
向いている案件は、定型のデータ入力・転記です。 公式が挙げている想定用途にもフォーム入力とデータ入力があります。「古い業務システムに手打ちしている作業を自動化したい」という相談は中小企業で非常に多く、API のない Web システムが相手でもブラウザ操作なら届きます。 Haiku 5.5 の単価（10万トークン以下で入力 $0.10 / MTok）と組み合わせれば、価格面でも提案しやすくなりました。ただし computer use には computer_toolset_20260801 が必須です。
コストの見積りは案件の採算に直結するので、先に計算してください。 6,600 トークンの固定費に加えてスクリーンショットが毎回乗ります。「1件処理するのにいくら」を出さずに月額固定で請け負うと赤字になり得ます。 token counting エンドポイントで実際のプロンプトを測り、1件あたりの原価を出してから見積りを作るのが安全です。ベータであることも、クライアントには伝えておくべき前提です。