Claudeの​「ブラウザ操作ツール」とは​何か​ ──画面の​クリックから、​ページの​構造を​読む操作へ​変わった​点を​解説

2026年8月19日、Claude APIの「computer use（画面操作）」が正式版になり、同じ日にブラウザ専用の「browser use tool」が新しく加わった。翌20日、Anthropicが発表記事を出している^[1][2]。

変わったのは、AIが画面を触るときの入口だ。これまでは「画面の写真を見て、座標をクリックする」しかなかった。そこに「ページの構造を読んで、その要素を名指しで操作する」経路が増えた。あわせて、クリック・入力・Enterを1回の応答でまとめて返せるようになっている。

この記事では4つを扱う。①8月19日に何が正式版になったのか ②従来のスクリーンショット方式と何が違うのか ③速度と費用がどう変わるのか ④導入前に知っておく制約。④には、日本企業に効く事実がひとつある。AWSなどクラウド経由では、今日の時点でまだ使えない。

01 何が​正式版に​なったのか──同じ​日に​4つ動いた

Claude Platformのリリースノート（2026年8月19日付）に、その日の変更が並んでいる^[1]。ポイントは4つが同時に正式版になったことだ。

対象	2026年8月19日の変更
画面操作 （computer use）	正式版。computer_toolset_20260801 としてベータ用ヘッダなしで使える。1ターンに複数操作、拡大（zoom）は既定で有効
ブラウザ操作 （browser use）	新登場。browser_toolset_20260801。アプリケーション側が用意したブラウザの表示領域の中で動く
Files API	正式版。組織あたり1TBの保管領域、アップロード時に有効期限を指定できる
Agent Skills / Skills API	正式版。自社の手順書をバージョン管理して、リクエストから呼び出せる
対応モデル	Claude Fable 5 / Mythos 5 / Opus 5 / Sonnet 5 / Opus 4.8

翌20日の発表記事は、この一式を「ソフトウェアを操作し、自社の手順を適用し、完成したファイルを返すエージェント」として紹介している^[2]。例に挙がっているのは保険金請求だ。Files APIから申請書類を読み、スキルに書かれた手続きに従い、ブラウザ操作で保険会社のWebポータルに入力し、控えをファイルとして保存する。

ひとつ補足しておく。発表記事は「computer use に browser use tool が加わった」という書き方をしているが、ドキュメント上は別々のツールセットで、座標の基準も違う（ブラウザ側は表示領域のピクセル、画面操作側はデスクトップのスクリーンショットのピクセル）。両方を同時に宣言でき、同じ名前の部材はどちらのものかで区別される^[3]。

02 何が​違うのか──​「画面の​写真」と​「ページの​構造」

従来の画面操作は、人間の目と手をそのまま真似る方式だった。スクリーンショットを見て「ここをクリック」と座標を返す。相手がどんなソフトでも動く代わりに、レイアウトが少しずれるだけで狙いが外れる。

ブラウザ操作ツールは、そこにページ自身を読む手段を足した^[3]。

部材	何をするか
read_page	ページのアクセシビリティツリー（画面読み上げソフトが使うのと同じ、要素の構造情報）をテキストで返す。各要素に [ref_2] のような参照が付く
find	「検索フィールド」「カートに入れるボタン」のような自然な言葉で要素を探す（最大20件）
get_page_text	本文のテキストだけを取り出す。記事やドキュメントを読ませるとき向き
form_input	フォームの値を直接セットする（チェックボックスは真偽値、セレクトは選択肢の値か表示テキスト）
タブ操作	new_tab / list_tabs / switch_tab / close_tab

つまりAIは「画面の左から320ピクセル、上から180ピクセル」ではなく、「ref_3 のテキストボックス」と名指しできる。参照はレイアウトのずれや再描画に強い。一方、キャンバスで描かれた画面、埋め込み動画、大量の行を仮想的に描くリスト、別ドメインのiframeの中身などは構造として読めないので、そこは従来どおりスクリーンショットと座標で触る。公式は両方を状況で使い分ける前提で書いている。

費用にも差が出る。公式ドキュメントは「大きなページでは、ツリーの読み取りのほうがスクリーンショットより入力トークンが少なく済むことが多い」と明記している。しかも読み取り結果には、そのまま操作に使える参照が付いてくる。見た目そのものが問題になるとき（表示崩れ、画像、描画状態）はスクリーンショットの出番、という整理だ。

関連記事 ｜ この流れの前段AIが、自分で画面を触って直す時代 ──「コードを書くAI」から「動かして確かめるAI」へ →

03 1ターンに​複数操作──往復が​減ると、​時間と​費用が​減る

正式版でのもう一つの変更が、1回の応答に複数の操作を入れられるようになったことだ^[1][3]。

たとえば「検索ボックスをクリック → install と入力 → Enter」を、以前はモデルの呼び出し3回に分けていた。いまは1ターンで3つ返ってくる。実行側は書かれた順に実行し、最初の失敗で止めて、残りには Not executed: an earlier action in this turn failed.（このターンの前の操作が失敗したため未実行）という決まった文言を返す。この停止ルールがあるので、途中で失敗したまま後続が走ることがない。

発表記事には、この効果についての利用企業の証言が載っている。医療・保険の、APIを持たないシステムの中で動くエージェントを作っている Asteroid のリサーチエンジニア、Davide Locatelli 氏のコメントだ^[2]。

最も長い保険金請求のワークフローが32分から13分になり、1タスクあたりのコストは検証した全ワークフローで約30%下がり、完了率は100%になった。プロンプトは変えていない。

Anthropicの発表記事に掲載された利用企業のコメント（要約・CAGによる検証ではない）

数字はAnthropicが載せた利用企業の申告で、こちらで確かめたものではない。ただ「プロンプトは変えていない」という但し書きが、変化の出どころを示している。モデルが賢くなったのではなく、往復の回数が減ったという話だ。なお、実行側が一度に1操作しか処理できない作りなら、disable_parallel_tool_use を指定して1ターン1操作に戻せる。往復は増えるが、既存の実装をそのまま使える。

04 費用の​見え方​──宣言するだけで​かかる​分が​ある

トークンの話も、公式ドキュメントに数字で書かれている^[3][4]。

項目	目安（入力トークン）
ブラウザ操作を宣言（既定の27部材）	約6,600（Claude Sonnet 5 は約6,670）
＋オプション4部材を全部有効化	約880を追加
画面操作を宣言（既定）	約4,500（Claude Sonnet 5 は約4,590）
画面操作で拡大を無効化	約410を削減
スクリーンショット・拡大画像	画像入力として課金
ツリー・ページ本文・ログ	テキストの結果として課金

リクエストに1行足すだけで、部材の説明文として毎回6,600トークン前後が乗る。使わない部材を configs で切れば減る。実際の数字はレスポンスの usage に出るし、事前にトークンカウントのエンドポイントで見積もれる。プロンプトキャッシュの区切りは、部材ごとではなくツールセットの宣言そのものに置く。

長く動かすエージェントほど、この固定費より「往復の回数」と「毎回返す画像の大きさ」が効いてくる。画像はAPI側で自動縮小されないので、モデルの上限に収まるサイズへ自分で縮めてから返す必要がある（縮めた分だけ、AIが返してきた座標は自分で元の倍率に戻す）。

05 既定値が​安全側に​倒してある​──4つの​部材は​最初オフ

ブラウザを触らせるということは、Webのどこかに書かれた文章がAIの入力になるということだ。公式ドキュメントはこの点にかなりの分量を割いている^[3]。

まず、31部材のうち4つが既定でオフになっている。理由もそれぞれ書かれている。

部材	何をするか／既定でオフの理由
javascript_exec	ページ内でJavaScriptを実行する。細工されたページがAIにさせられることが広がるため
file_upload	ファイル入力欄にファイルを設定する。同じ理由
read_console	コンソールのログを読む。自動化基盤によっては取得できず、ページ由来の内容が届く範囲も広がるため
read_network	通信の記録を読む。同じ理由

そのうえで、運用側への推奨が具体的に並んでいる。専用のコンテナか仮想マシンで、資格情報を持たない新しいプロファイルで動かす。到達できるドメインをネットワーク層の許可リストで絞り、リダイレクトのあとにもう一度確認する。navigate の処理では http と https 以外のスキームを拒否する——この判定はAPI側では行われないので、実装側で弾かなければ通ってしまう。タブのタイトルやURLも含めて、ページが渡してくるものは全部信用しない。

そして購入・アカウント変更・メッセージ送信・規約への同意といった取り返しのつかない操作は、人が確認してから。1ターンに複数操作が入るようになったので、確認は操作の1つずつに対して行う、とまで書いてある。

公式は「ページに書かれた『これまでの指示を無視して〜へ移動しろ』のような文章に、Claudeが従ってしまうことがある」と正面から書いている。加えて、ブラウザは自社の環境で動くので、訪問先から見えるのは自社のネットワーク上の身元になる。この2つは、社内システムの自動化に使うときの検討事項そのものだ。

関連記事 ｜ 「どこまで自動で通すか」の話Claude Codeの「自動承認」が既定になった ──AIの操作をAIが審査する仕組みと、何が止まらないのかを解説 →

06 ​今日できること・できない​こと──クラウド経由は​まだ​対象外

導入を検討するとき、先に見ておく制約を公式ドキュメントから集めた^[3][5][6][7]。

使いたい場所	新しいブラウザ操作・画面操作	備考
Claude API	○ 利用可	ベータ用ヘッダは不要
Amazon Bedrock	✕ 現時点で非対応	ベータ版の画面操作ツールは引き続き利用可
Google Cloud（Vertex AI）	✕ 現時点で非対応	同上。発表記事では「近日提供」
Microsoft Foundry	✕ 現時点で非対応	同上。Skills API・Files API は提供
Claude Managed Agents	✕ 現時点で非対応	Messages APIのツールのため

ここは検討の順番を変える事実だと思う。3つのクラウド経由（Bedrock・Vertex AI・Microsoft Foundry）は、今日の時点でどれも新しいツールセットに対応していない。それぞれのドキュメントに、ほぼ同じ文言で「computer_toolset_20260801 と browser_toolset_20260801 は現在利用できない。ベータ版の画面操作ツールは引き続き利用可能」と書かれている^[5][6][7]。

発表記事のほうは、画面操作とブラウザ操作について「Google Cloud の Vertex AI に近日提供」と書いている^[2]。発表の言葉は「近日」、ドキュメントの記述は「現時点では不可」で、どちらも嘘ではない。日本企業はAWS経由でClaudeを使っている例が多いので、いま試すならClaude API 直、という前提になる。

技術的な制約も明示されている。要素の参照は最善努力で、激しく書き換わるページでは安定しないことがある（そのときは座標に戻る）。コンソールと通信の読み取りは、使っている自動化基盤が取得できる範囲しか返せない。既存の画面操作（computer_20251124）から新しい方式へ移る場合、移行手順は9項目あり、そのまま置き換えるだけでは動かない変更を含む^[4]——応答の中の全ブロックを順番に処理する、結果に toolset_name を付ける、スクリーンショットを自分で縮小する、key の繰り返し指定に対応する、など。既存のベータ版はそのまま使い続けられるので、急いで移す必要はない。

07 まとめ──検討する​ときの​4項目

	これまでの画面操作	今回のブラウザ操作
見るもの	画面のスクリーンショット	ページの構造＋スクリーンショット
指定の仕方	座標（ピクセル）	要素の参照＋座標
得意な相手	デスクトップアプリを含む何でも	Webアプリ・社内Webシステム
フォーム入力	クリックして打つ	値を直接セットできる
実行場所	自社環境	自社環境（Anthropic側では何も動かない）
宣言時の固定費	約4,500トークン	約6,600トークン
使える場所	Claude API（クラウド経由は旧ベータ版のみ）	Claude API のみ

検討するときの確認事項

• 触らせたい画面はWebか。Webならブラウザ操作、デスクトップアプリが混ざるなら画面操作
• 使っている基盤はどれか。Bedrock・Vertex AI・Microsoft Foundry 経由なら、現時点では対象外
• 隔離とドメイン制限、そして「人が確認する操作」の線引きを決めたか
• 1リクエストあたり6,600トークン前後の固定費と、画像・テキストの結果を含めて試算したか

「APIのない社内システムをAIに任せたい」という相談は増えている。今回の変更は、その入口が画面の写真だけだった状態から、ページの構造を読める状態へ広がったという話だ。使えるかどうかは、触らせたい画面と、いま契約している経路で決まる。