Claude Code の Computer Use を本気で検証したら、ブラウザ操作には別ツールが必要だった話
Claude Code の Computer Use を本気で検証したら、ブラウザ操作には別ツールが必要だった話
Claude Code の Computer Use を本気で検証したら、ブラウザ操作には別ツールが必要だった話
バイブコーディングの副作用
最近、バイブコーディング（AIにコードを書かせる開発スタイル）で開発スピードが劇的に上がった。自分の場合はNext.js + Supabaseの会員管理システムを、VSCode上のClaude Codeで開発している。「この機能追加して」でコードが出てくるので、書くスピードは以前の何倍にもなった。
ただ、困ったことが一つ。
テストが追いつかない。
コードの変更が多いぶん、「ちゃんと動くか」の確認が膨大になる。Playwrightでテストコード書く？ そのテストコード自体がメンテ対象になるし、書く時間がもったいない。
そんな中、Claude Codeに Computer Use（PC操作機能）が搭載された。AIが自分のマシンを直接操作してくれる機能。これを使えばテスト作業そのものをAIに丸投げできるんじゃないか、と期待した。
社内でも「Computer Use本格的に調べてほしい」と依頼があったので、実務プロジェクトで腰を据えて検証することにした。結論から言うと、想定とはだいぶ違うゴールに着いた。
検証の仕切り直し
今回はComputer Use単体の実力を測りたかったので、Claude Codeに「他の手段へのフォールバック」を明示的に禁止した。
テスト対象は、実務で使っているTFCプロジェクト（Next.js + Supabase）。過去1ヶ月分の変更をカバーする10カテゴリ56項目のテスト仕様書を用意した。
ところが、開始5分で想定が崩れた。
セットアップで3時間溶けた話
地雷①：MCPサーバーが起動しない
/mcp でcomputer-useを確認すると、いきなり ✘ failed。
ネイティブモジュールの初期化に失敗している。最初はmacOSの権限を疑った。システム設定でVSCodeに3つの権限（アクセシビリティ/画面収録/入力監視）を付与してVSCodeを完全終了して再起動。それでも動かない。
地雷②：Nodeが2年前のバイナリだった
原因を追ってたらこれに辿り着いた。
2024年3月の公式インストーラー版が居座ってた。しかも /usr/local/bin/ と /opt/homebrew/bin/ の両方にパスが通ってて、Homebrew側のNodeと混線する状況。
意を決して古いのを消して、Homebrewで入れ直し。
sudo rm /usr/local/bin/node /usr/local/bin/npm /usr/local/bin/npx brew install node # → v25.9.0 npm install -g @anthropic-ai/claude-code # → v2.1.89 → v2.1.116 に更新
VSCode再起動して /mcp 叩くと、今度は ✔ connected。勝った、と思った。
地雷③：Claudeが「ツールがない」と言い張る
接続は通ったのに、スクリーンショット頼んでも「このツールは使えません」と返してくる。/mcp で確認したらあるのに、だ。
原因は、同じセッション内の前のターンで「使えません」と答えた履歴を引きずっていたこと。AIのメタ認知バグ。「これは利用可能です、/mcp で確認済みです」と明示してやると動き出した。
ここまでで3時間。当初の見積もり「1〜2時間で検証完了」が完全に吹き飛んだ。
動いた！と思ったら、次の壁が
環境が整って、ようやく最初のスクリーンショットを撮ったら、結果は想像以上だった。
スクリーンショットを撮影しました（DELL S2425HSモニター）。
デスクトップに多数のスクリーンショット画像
Finderウィンドウ2つ: 左側「デスクトップ」、右側「yomitoku-test」フォルダ
時刻: 4月21日(火) 10:51
もう1つのモニター「Built-in Retina Display」も検出
モニターの型番、開いてるフォルダ名、時刻、サブディスプレイの存在まで。画面を完全に読めている。これがComputer Useの実力か、と感動した。
勢いに乗って「ではChromeでlocalhost:3000を開いて、ログインしてテストして」と頼んだ。そこでClaudeが冷静に返してきた。
ChromeはComputer Useで「read」tierに制限されています。 screenshotでの画面読み取りは可能ですが、left_click / type は harness 側でブロックされます。
実演してもらった。URLバーに対する left_click → ブロック。type でURL入力を試行 → ブロック。
Computer Useは、ブラウザのクリックも文字入力もできない。
これが今日一番の発見だった。ブラウザは「read tier（見るだけ）」として扱われてて、操作しようとすると仕組みとして拒否される。Finderやデスクトップ、ネイティブアプリなら動くけど、ブラウザは別枠。
Anthropicは別の答えを用意してた
ここでClaudeから案内があった。
ブラウザ操作には、別の拡張 Claude in Chrome が用意されています。
Anthropicが出しているChrome拡張で、DOMを理解してブラウザを直接操作する専用ツール。2025年12月から Max/Pro プランでベータ提供されてて、Claude Codeとの連携も公式サポートされている。
Chrome Web Storeで検索したら、なんと 既にインストール済みだった。いつ入れたか記憶にないけど、過去のどこかで試したやつが残ってたらしい。ツールバーにピン留めしてサイドパネル開いて、Claude.aiアカウントでサインイン。
TFCプロジェクトのログイン画面にこう指示した。
返ってきた報告。
ステップ1：メールアドレスの入力 ログイン画面のメールアドレス欄に y.fujita@visk.co.jp を入力しました。
ステップ2：パスワードの入力 パスワード欄にPassword123!を入力しました。マスク表示（●●●●●●●●●●●）で正しく反映。
ステップ3：ログインボタンのクリック 「→ ログイン」ボタンをクリックしました。
ステップ4：ログイン後の画面確認 ログインに成功し、/protected/members ページへ遷移しました。
動いた。コードも書かず、日本語で頼んだだけでブラウザが操作された。
調子に乗って10カテゴリ56項目を全部投げた。結果、60分で56項目完走。裏で337ステップが自律実行。PASS 43件、要確認8件、FAIL 1件。しかもテスト項目には無かった Application Error (500) のバグまで発見してきた。Dialogコンポーネントのnamed importとdefault importの混在が原因、と行番号まで指摘してきた。
結論：使い分けが正解だった
1日ハマって複数のツール触ってわかったのは、Anthropicが用途別に手段を分けて設計してるということ。ひとつで全部やろうとしてない。
ツール | 得意領域 | 今回の評価 |
|---|---|---|
Computer Use MCP | macOSネイティブアプリ、Finder、デスクトップ操作、スクショ | 画面認識はすごい。ただしブラウザ操作は構造的に不可 |
Claude in Chrome | ブラウザのDOM操作、Web UIテスト、フォーム入力 | Webアプリのテストはこっちで完結 |
Playwright経由 | CI/CDでの反復テスト、回帰テスト | スクリプト化されるので再現性高い |
ブラウザにはDOMという構造情報があるから、座標ベースで殴るよりセマンティックに理解させた方が精度出る。だから専用のClaude in Chromeがある。一方、Finderやデスクトップアプリには DOMがない。そこはComputer Useが座標ベースで拾う。毎晩同じテストを回したいなら、AIの判断に頼らずPlaywrightでコード化する。
「ひとつの万能ツールを探す」んじゃなくて、「用途に応じた最適なツールを当てる」。これが今回の検証で得た答えだった。
実務導入の判断材料
検証結果をまとめるとこう。
Computer Use MCPの実用性
使える用途
macOSのネイティブアプリ操作
デスクトップ/Finderの自動化
スクリーンショット撮影と画面認識
画面上の情報を読み取って他システムに渡す橋渡し
使えない用途
ブラウザの click / type / 画面遷移（tier制限でブロック）
Chrome、Safari、Firefox含むブラウザ全般
コストとハードル
Max/Proプランに含まれてて追加料金なし
セットアップは環境次第で30分〜3時間
macOS限定
結論
ブラウザテストが主目的ならComputer Useは合わない → Claude in Chromeを使う
ネイティブアプリ操作の自動化が目的なら導入価値あり
Maxプラン保持者なら試すコストはほぼゼロ
セットアップの地雷マップ
同じ道を通る人のために、詰まったポイントと対処法をまとめておく。
症状 | 対処 |
|---|---|
MCPが | Nodeを最新LTSに差し替え（古いバイナリが原因） |
| 古い方を削除してHomebrew一本化 |
VSCodeでComputer Useが動かない | アクセシビリティ/画面収録/入力監視の3権限を付与 |
権限付与しても動かない | VSCodeを完全終了（Cmd+Q）して再起動 |
Claudeが「ツールない」と言い張る | 「 |
ブラウザ操作がブロックされる | 仕様。Claude in Chromeに切り替え |
まとめ
Computer Use MCPはネイティブアプリ操作には強い。でもブラウザ操作は構造的にできない
ブラウザテストを自動化したいなら Claude in Chrome を使う（別プロダクト）
反復テスト・回帰テストには Playwright が向く
Max/Pro プラン保持者ならこれら全部追加料金なしで試せる
バイブコーディングで「作る」は爆速になった。テストをどう回すかも、適材適所の選び方が見えてきた。
無料で使えるもんは、一旦使ってみましょう。
Claude Code の Computer Use を本気で検証したら、ブラウザ操作には別ツールが必要だった話
バイブコーディングの副作用
最近、バイブコーディング（AIにコードを書かせる開発スタイル）で開発スピードが劇的に上がった。自分の場合はNext.js + Supabaseの会員管理システムを、VSCode上のClaude Codeで開発している。「この機能追加して」でコードが出てくるので、書くスピードは以前の何倍にもなった。
ただ、困ったことが一つ。
テストが追いつかない。
コードの変更が多いぶん、「ちゃんと動くか」の確認が膨大になる。Playwrightでテストコード書く？ そのテストコード自体がメンテ対象になるし、書く時間がもったいない。
そんな中、Claude Codeに Computer Use（PC操作機能）が搭載された。AIが自分のマシンを直接操作してくれる機能。これを使えばテスト作業そのものをAIに丸投げできるんじゃないか、と期待した。
社内でも「Computer Use本格的に調べてほしい」と依頼があったので、実務プロジェクトで腰を据えて検証することにした。結論から言うと、想定とはだいぶ違うゴールに着いた。
検証の仕切り直し
今回はComputer Use単体の実力を測りたかったので、Claude Codeに「他の手段へのフォールバック」を明示的に禁止した。
テスト対象は、実務で使っているTFCプロジェクト（Next.js + Supabase）。過去1ヶ月分の変更をカバーする10カテゴリ56項目のテスト仕様書を用意した。
ところが、開始5分で想定が崩れた。
セットアップで3時間溶けた話
地雷①：MCPサーバーが起動しない
/mcp でcomputer-useを確認すると、いきなり ✘ failed。
ネイティブモジュールの初期化に失敗している。最初はmacOSの権限を疑った。システム設定でVSCodeに3つの権限（アクセシビリティ/画面収録/入力監視）を付与してVSCodeを完全終了して再起動。それでも動かない。
地雷②：Nodeが2年前のバイナリだった
原因を追ってたらこれに辿り着いた。
2024年3月の公式インストーラー版が居座ってた。しかも /usr/local/bin/ と /opt/homebrew/bin/ の両方にパスが通ってて、Homebrew側のNodeと混線する状況。
意を決して古いのを消して、Homebrewで入れ直し。
sudo rm /usr/local/bin/node /usr/local/bin/npm /usr/local/bin/npx brew install node # → v25.9.0 npm install -g @anthropic-ai/claude-code # → v2.1.89 → v2.1.116 に更新
VSCode再起動して /mcp 叩くと、今度は ✔ connected。勝った、と思った。
地雷③：Claudeが「ツールがない」と言い張る
接続は通ったのに、スクリーンショット頼んでも「このツールは使えません」と返してくる。/mcp で確認したらあるのに、だ。
原因は、同じセッション内の前のターンで「使えません」と答えた履歴を引きずっていたこと。AIのメタ認知バグ。「これは利用可能です、/mcp で確認済みです」と明示してやると動き出した。
ここまでで3時間。当初の見積もり「1〜2時間で検証完了」が完全に吹き飛んだ。
動いた！と思ったら、次の壁が
環境が整って、ようやく最初のスクリーンショットを撮ったら、結果は想像以上だった。
スクリーンショットを撮影しました（DELL S2425HSモニター）。
デスクトップに多数のスクリーンショット画像
Finderウィンドウ2つ: 左側「デスクトップ」、右側「yomitoku-test」フォルダ
時刻: 4月21日(火) 10:51
もう1つのモニター「Built-in Retina Display」も検出
モニターの型番、開いてるフォルダ名、時刻、サブディスプレイの存在まで。画面を完全に読めている。これがComputer Useの実力か、と感動した。
勢いに乗って「ではChromeでlocalhost:3000を開いて、ログインしてテストして」と頼んだ。そこでClaudeが冷静に返してきた。
ChromeはComputer Useで「read」tierに制限されています。 screenshotでの画面読み取りは可能ですが、left_click / type は harness 側でブロックされます。
実演してもらった。URLバーに対する left_click → ブロック。type でURL入力を試行 → ブロック。
Computer Useは、ブラウザのクリックも文字入力もできない。
これが今日一番の発見だった。ブラウザは「read tier（見るだけ）」として扱われてて、操作しようとすると仕組みとして拒否される。Finderやデスクトップ、ネイティブアプリなら動くけど、ブラウザは別枠。
Anthropicは別の答えを用意してた
ここでClaudeから案内があった。
ブラウザ操作には、別の拡張 Claude in Chrome が用意されています。
Anthropicが出しているChrome拡張で、DOMを理解してブラウザを直接操作する専用ツール。2025年12月から Max/Pro プランでベータ提供されてて、Claude Codeとの連携も公式サポートされている。
Chrome Web Storeで検索したら、なんと 既にインストール済みだった。いつ入れたか記憶にないけど、過去のどこかで試したやつが残ってたらしい。ツールバーにピン留めしてサイドパネル開いて、Claude.aiアカウントでサインイン。
TFCプロジェクトのログイン画面にこう指示した。
返ってきた報告。
ステップ1：メールアドレスの入力 ログイン画面のメールアドレス欄に y.fujita@visk.co.jp を入力しました。
ステップ2：パスワードの入力 パスワード欄にPassword123!を入力しました。マスク表示（●●●●●●●●●●●）で正しく反映。
ステップ3：ログインボタンのクリック 「→ ログイン」ボタンをクリックしました。
ステップ4：ログイン後の画面確認 ログインに成功し、/protected/members ページへ遷移しました。
動いた。コードも書かず、日本語で頼んだだけでブラウザが操作された。
調子に乗って10カテゴリ56項目を全部投げた。結果、60分で56項目完走。裏で337ステップが自律実行。PASS 43件、要確認8件、FAIL 1件。しかもテスト項目には無かった Application Error (500) のバグまで発見してきた。Dialogコンポーネントのnamed importとdefault importの混在が原因、と行番号まで指摘してきた。
結論：使い分けが正解だった
1日ハマって複数のツール触ってわかったのは、Anthropicが用途別に手段を分けて設計してるということ。ひとつで全部やろうとしてない。
ツール | 得意領域 | 今回の評価 |
|---|---|---|
Computer Use MCP | macOSネイティブアプリ、Finder、デスクトップ操作、スクショ | 画面認識はすごい。ただしブラウザ操作は構造的に不可 |
Claude in Chrome | ブラウザのDOM操作、Web UIテスト、フォーム入力 | Webアプリのテストはこっちで完結 |
Playwright経由 | CI/CDでの反復テスト、回帰テスト | スクリプト化されるので再現性高い |
ブラウザにはDOMという構造情報があるから、座標ベースで殴るよりセマンティックに理解させた方が精度出る。だから専用のClaude in Chromeがある。一方、Finderやデスクトップアプリには DOMがない。そこはComputer Useが座標ベースで拾う。毎晩同じテストを回したいなら、AIの判断に頼らずPlaywrightでコード化する。
「ひとつの万能ツールを探す」んじゃなくて、「用途に応じた最適なツールを当てる」。これが今回の検証で得た答えだった。
実務導入の判断材料
検証結果をまとめるとこう。
Computer Use MCPの実用性
使える用途
macOSのネイティブアプリ操作
デスクトップ/Finderの自動化
スクリーンショット撮影と画面認識
画面上の情報を読み取って他システムに渡す橋渡し
使えない用途
ブラウザの click / type / 画面遷移（tier制限でブロック）
Chrome、Safari、Firefox含むブラウザ全般
コストとハードル
Max/Proプランに含まれてて追加料金なし
セットアップは環境次第で30分〜3時間
macOS限定
結論
ブラウザテストが主目的ならComputer Useは合わない → Claude in Chromeを使う
ネイティブアプリ操作の自動化が目的なら導入価値あり
Maxプラン保持者なら試すコストはほぼゼロ
セットアップの地雷マップ
同じ道を通る人のために、詰まったポイントと対処法をまとめておく。
症状 | 対処 |
|---|---|
MCPが | Nodeを最新LTSに差し替え（古いバイナリが原因） |
| 古い方を削除してHomebrew一本化 |
VSCodeでComputer Useが動かない | アクセシビリティ/画面収録/入力監視の3権限を付与 |
権限付与しても動かない | VSCodeを完全終了（Cmd+Q）して再起動 |
Claudeが「ツールない」と言い張る | 「 |
ブラウザ操作がブロックされる | 仕様。Claude in Chromeに切り替え |
まとめ
Computer Use MCPはネイティブアプリ操作には強い。でもブラウザ操作は構造的にできない
ブラウザテストを自動化したいなら Claude in Chrome を使う（別プロダクト）
反復テスト・回帰テストには Playwright が向く
Max/Pro プラン保持者ならこれら全部追加料金なしで試せる
バイブコーディングで「作る」は爆速になった。テストをどう回すかも、適材適所の選び方が見えてきた。
無料で使えるもんは、一旦使ってみましょう。
