この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。
ブラウザでページを開いて内容を確認する——そんな単純な繰り返し作業、Claude Codeに任せられないか。Computer Useはスクリーンショットを読み取ってマウスやキーボードを操作するプレビュー機能で、テキストでは触れない画面操作をカバーする。公開ページの閲覧と比較を実際に頼んでみたところ、読み取りは安定している一方で、スクロール先やポップアップの処理には人の目が欠かせない場面があった。
この記事で確かめること
Computer Useを使って、ブラウザ上の確認作業がどこまで自動化できるかを検証する。具体的には、公開Webページを開いて内容を読み取り、別のページと見比べて違いを報告する——という1本のシナリオを最後まで通す。
「テキストで指示する操作」と「画面を見ながら操作する」の違いが体感できる構成にした。依頼文を出して結果を見て、修正指示を出して再度結果を見る流れで進める。
検証環境
- OS: Windows 11
- ブラウザ: Chrome
- Claude Code: インストール済み（導入手順は別記事「Claude CodeをWindowsにインストールする手順」を参照）
- 利用形態: Claude Desktopアプリ内のClaude Codeセッションから自然文で依頼（Computer UseはPro/Max向けのresearch previewで、Claude Desktopアプリ内のCoworkおよびClaude Codeから利用できる。macOSとWindowsに対応。API経由でもComputer Use betaを利用可能）
- 前提: Computer Useが使えるプラン（Pro/Max）であること（Team・Enterpriseプランでは利用不可）。プランの詳細は公式サイトを確認
判定基準
- 指示どおりのページに到達できたか
- 必要な情報を正しく読み取れたか
- 操作ミスがなかったか
- 人の確認が必要だった箇所はどこか
今回試さないこと: ログイン必須ページ、個人情報入力、決済操作、CAPTCHAや2FAが必要な操作は扱わない。
今回の検証シナリオ
Computer Useは「まず使う機能」ではなく、APIやコマンドでは触れない画面操作向けの手段だ。テキスト操作で済むならそちらが速く正確なので、画面操作が必要な場面に限定して使うのが実務的な考え方になる。
速さと正確さはテキスト操作より落ちやすい。画面のスクリーンショットを読んで位置を判断する仕組み上、レイアウトの変化やポップアップの影響を受けやすく、読み取りミスや押し間違いも起きる。
今回の検証フローは次の1本道。
- 公開Webページを開いて内容を読む
- 別のページも開いて、2つのページを見比べて違いを報告する
フォーム操作は主軸にしない。入力ミスが事故につながりやすいため、今回は「試さなかったこと」として振り返りで触れる。
Computer Useの概要は用語集記事「Computer Useとは」を、ブラウザ拡張としての利用は「Claude in Chrome」の記事も参考になる。
Step 1: 最初の依頼（公開ページを開いて内容を報告させる）
一番シンプルなブラウザ操作を頼んでみる。Computer Useがどう動くかを見るため、ページの種類と目的を具体的に指定した。
依頼文は次のとおり。
Claude Codeのリリースノートの公開ページを開いて、最新の更新内容の要約を報告して。
この依頼文にした理由は2つある。まず「リリースノート」というページの種類を指定することで、Claude Codeが開くべきページの性質を明確にした。リリースノートは見出しと箇条書き中心で構造が読み取りやすく、最初の検証対象として適している。次に「最新の更新内容の要約」と目的を添えることで、単に開くだけでなく読んで整理するまでを一連の動作として指定した。
Claude Codeの動きは次のようになった。まずブラウザを起動してリリースノートページのURLを開き、スクリーンショットを撮る。その画像からテキストを読み取り、見出し構造と本文の要点を整理して報告文を出力した。
Step 2: 最初の結果（良かった点・足りなかった点）
判定基準に照らして評価する。
良かった点
ページの主要な見出しと本文の要点は正しく読み取れていた。報告文を見る限り、ページの構造（リリースバージョンの見出し、更新項目の箇条書き）を把握できている。たとえば次のような出力が返ってきた。
検証時点で確認したリリースノート（Week 13, March 23–27, 2026）では、Windows向けのPowerShellツール追加、パス解決の改善などが記載されていました。主な更新項目は次のとおりです。
– Windows gets a native PowerShell tool alongside Bash
– Claude can run cmdlets, pipe objects, and work with Windows-native paths
構造を捉えている点は確認できた。
足りなかった点
ページ下部の補足情報が抜けていた。スクロールが必要な位置にあった内容が報告に含まれていない。画面に見えている範囲の読み取りには強いが、スクロール先の情報は別途指示しないと拾えない。
面白い発見があった。Cookie同意バナーが画面に被さっていたにもかかわらず、Claude Codeはバナーの下に見えているテキストを部分的に読み取っていた。バナー自体は「閉じる」操作を追加で指示しないと消えなかったが、隙間から拾える情報は拾っていた。
人が確認したポイント: Claudeが読み取った見出しテキストを実際のブラウザ画面と見比べた。見出しは一致していたが、箇条書きの数（「3つ」の部分など）は目視で確認しないと確実とは言えない。
Step 3: 修正指示（別ページとの見比べ）
Step 1の結果を見て、より実務に近い操作を頼むことにした。
修正指示は次のとおり。
もう1つ別のリリースノートのページも開いて、2つのリリースノートの更新内容を見比べて、違いを報告して。
単一ページの閲覧から「複数ページの比較」にステップアップした。ブラウザ操作としては、タブを切り替える・2つの情報を照合する・違いを整理して報告する、という複数の動作が入る。
この修正を出した理由は、実際の確認作業でよくある「前回のリリースと今回のリリースを比べる」場面を再現したかったためだ。リリースノート同士なら項目の構造が似ているため、差分が読み取りやすいと考えた。
Step 4: 修正後の結果
複数ページの比較はどうなったか。
何が変わったか
2つのリリースノートをそれぞれ開き、更新項目ごとに違いを整理して報告してきた。「Week 13ではPowerShellツールの追加が記載されているが、Week 12では記載されていない」という形式で、項目ごとの差異をリスト化して出力された。
何が改善されたか
単一ページの読み取りに比べて、情報の対比という複雑な指示に対応できていた。Step 2では見落としがあった補足情報も、今回は「違い」として拾われている。
残った問題
タブの切り替えで一瞬スクロール位置がずれ、片方のページの末尾付近の情報が読めていなかった。スクロール位置の管理は画面操作特有の難しさで、テキストベースの操作では起きない問題だ。
興味深かったのは、タブを切り替えても前のページの文脈を維持できていたことだ。「Week 13の内容」と「Week 12の内容」を混ぜずに、それぞれを別々の情報として整理していた。Computer Useは画面を見ながら操作しているとはいえ、内部ではテキストベースの記憶も併用している印象を受けた。
修正前後の違いをざっくり書くと、Step 2では「1ページの内容を要約」に留まっていたのが、Step 4では「2ページの差分を項目別に整理」に進んでいる。指示を具体的にした分、出力も一段階細かくなった。
Step 5: どこまで頼むだけでできた？（AIと人の分担）
検証の結果をAIが出した部分と人が判断した部分に分ける。
AIだけでできたこと: ページ内容の読み取り、複数ページの比較報告。テキストベースで完結する範囲の報告は頼むだけで進んだ。
到達しなかったこと: フォーム操作は安全のため除外した。動的コンテンツ（自動更新される情報やアニメーション）の追従は試していない。複雑なレイアウト（多段カラムやモーダル内の情報）の正確な操作も今回の検証対象外だ。
人が確認・修正すべきだったこと: 比較結果の妥当性チェック、読み取り漏れの補完。特に数値や固有名詞の正確さは、実際の画面と見比べないと保証できない。
危険度の3段階で整理する。
- 比較的任せやすい: 公開ページの閲覧、テキスト情報の読み取りと報告
- 条件付きで使える（人の確認前提）: 複数ページの比較、スクロールが必要な長いページの読み取り
- 必ず人が確認すべき: フォーム入力、ログイン後の操作、個人情報や決済に関わる画面
この検証の振り返り
全体で2往復のやり取りだった。最初の依頼→結果確認→修正指示→結果確認の4ステップ。
依頼文のコツ
Computer Useでは、URLを具体的に示すかページの種類と目的を含めると結果が安定する。今回の検証では「リリースノートの公開ページ」と指定したが、URLが決まっていれば依頼文に含めるのが良い。
「テキストでできる操作はテキストで、画面操作が必要な時だけComputer Use」——この使い分けが実務上しっくりくる。Computer UseはAPIやコマンドで触れない画面向けの手段であり、テキストベースで済むならそちらが速く正確だからだ。
今回試さなかったこととして、フォーム操作とログイン後の操作がある。これらを試す場合は、対象ページが公開範囲かどうか、入力内容に個人情報が含まれないかを事前に確認した上で、必ず人が結果を目視する前提で進める必要がある。
この構成が向いているのは、公開ページの確認作業を繰り返し行う人だ。一方、ログイン後の画面や複雑なアプリケーションの操作が主な用途の場合は、Playwright MCPなど別の手段も併用して検討した方が良いかもしれない。
次に試すなら
関連記事として、Computer Use用語集（機能の詳しい解説）、Claude in Chrome（ブラウザ拡張としての利用）、MCPサーバ連携（テキストベースのブラウザ自動化）の記事が参考になる。
自分で試すときのコツを2つ挙げる。まずシンプルな公開ページから始めること。画面操作に慣れるまでは、ログイン不要でテキスト中心のページが扱いやすい。それから、操作結果は必ず人が最終確認すること。Computer Useの報告をそのまま信用せず、少なくとも数値や固有名詞は実際の画面と照らし合わせる。
ブラウザで確認作業をする場面では、ページを開いて内容を読んで報告する——という繰り返し作業が減らせる可能性がある。骨組みは頼むだけで進むので、合わない部分だけ後から直す運用が現実的だ。
なお、Computer Useはプレビュー機能で、環境やバージョンによっては今後さらに改善される可能性がある。関連記事「Claude Codeにプラグインを入れて機能を増やす手順」も、拡張機能の活用方法を確認する参考になります。
今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。