AIエージェント入門 第七章！AIが画面を「見て」「操作する」— ブラウザ連携の仕組みと注意点
AI エージェントにコードを書かせたあと、「画面が崩れてないか見てくれない？」と頼めたら便利ですよね。あるいは「ログインして、このフォームに入力して、送信ボタンを押して」という操作をそのまま自動化できたら。これを実現するのが ブラウザ連携 です。
Claude Code・Cursor・Antigravity の3ツールはいずれもブラウザと連携できますが、アプローチが大きく異なります。組み込みか MCP 経由か、画面を「見る」だけか「触れる」のか、操作を録画できるか。
第七章では、ブラウザ自動化の仕組みをツールごとに比べたうえで、スクリーンショットのトークンコストやブラウザ操作の不安定さといった 実運用の落とし穴 にも踏み込んでいきます。
AI がブラウザを使えると何がうれしいのか
エージェントにブラウザを使わせる最大のメリットは、コードの「結果」を AI 自身が確認できる ことです。
コードを書くだけなら AI は得意ですが、それが画面上でどう見えるかは別の話です。CSS を書き換えたらレイアウトが崩れた、ボタンの配置がずれた、フォントが反映されていない — こういった問題はコードを読んだだけでは分かりません。ブラウザ連携があれば、AI が自分で画面を見て「あ、ここ崩れてる」と気づいて直せます。
具体的なユースケースは以下のとおりです。
- UI の確認：コード変更後にスクリーンショットを撮って、見た目が意図どおりか確認する
- E2E テスト：フォーム入力 → ボタンクリック → 結果確認、という一連の操作を自動で回す
- UI 回帰テスト：変更前後のスクリーンショットを比較して、意図しない見た目の変化を検出する
- アクセシビリティ監査：コントラスト比、ARIA ラベル、キーボードナビゲーションをチェックする
- デザインからコードへの変換：デザインモックと実装を見比べて、差分を修正する
参考リンク
ブラウザ自動化の仕組み — 3ツールのアプローチ
3ツールでブラウザ連携のアーキテクチャが大きく異なります。ここが一番面白いポイントです。
Cursor — 組み込み Browser ツール
Cursor はブラウザが 組み込みツール として最初から使えます。追加のインストールや設定は不要です。
Agent がブラウザを操作するときは、チャット内にスクリーンショットや操作結果が表示され、ブラウザウィンドウ自体もインラインペインまたは別ウィンドウで確認できます。使えるツールは以下のとおりです。
- Navigate — URL へのページ遷移
- Click — 要素のクリック
- Type — テキスト入力
- Scroll — スクロール操作
- Screenshot — スクリーンショット取得
- Console Output — コンソールログの読み取り
- Network Traffic — ネットワーク通信の監視
さらに Design Sidebar という独自機能があり、ブラウザ上で要素の位置・サイズ・色・影・角丸をビジュアルエディタで調整し、「Apply」ボタンを押すとエージェントがコードに反映してくれます。コードとデザインの両方向から作業できるのが Cursor の強みです。
ブラウザのセッション状態（Cookie・localStorage・IndexedDB）はワークスペースごとに保持されるので、ログイン済みの状態でテストを続けることもできます。
Antigravity — 組み込み Browser サブエージェント
Antigravity もブラウザが組み込みですが、Cursor とはアーキテクチャが異なります。ブラウザ操作は 専用の Browser サブエージェント が担当します。
このサブエージェントは、メインエージェントとは 異なるモデル で動き、ブラウザ操作に特化した専用の指示を持っています。メインエージェントが「ブラウザで確認して」と判断すると、自動的に Browser サブエージェントが起動してブラウザを操作します。
操作中はページ上に青い枠のオーバーレイが表示され、ユーザーの操作が一時的にブロックされます（AI の操作と干渉しないようにするため）。ただし、サブエージェントは非アクティブなタブでも操作できるので、ユーザーは別のタブで作業を続けられます。
Antigravity の特徴的な機能として、実際の Chrome ブラウザを使う点があります。内蔵ブラウザではなく、ユーザーのマシンにインストールされた Chrome を 別プロファイル で起動します。Dock に別アプリとして表示され、通常のブラウジングとは完全に分離されます。
Claude Code — MCP サーバー経由
Claude Code にはブラウザの組み込みツールがありません。ブラウザ機能が必要な場合は、MCP サーバー として外部ツールを接続する形です。
代表的な選択肢は以下のとおりです。
- Playwright MCP — Playwright をベースにしたブラウザ自動化。ローカルで動作
- Browserbase MCP — クラウド上のヘッドレスブラウザ。ローカルに Chrome をインストールする必要がない
第五章で説明した claude mcp add コマンドで追加できます。たとえば Playwright MCP なら：
claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest
MCP 経由なので設定の手間はありますが、逆に「どのブラウザ自動化ツールを使うか」を自由に選べるのが Claude Code の柔軟さです。Playwright 以外にも、Puppeteer ベースや Selenium ベースの MCP サーバーを接続することもできます。
3ツールの比較
| Claude Code | Cursor | Antigravity | |
|---|---|---|---|
| ブラウザ統合方式 | MCP サーバー経由 | 組み込みツール | 組み込みサブエージェント |
| 追加設定 | 必要（MCP 追加） | 不要 | 不要 |
| 操作 UI | ツールごとに異なる | チャット内 + インラインペイン | 専用ビュー + オーバーレイ |
| ブラウザエンジン | MCP サーバー依存 | 内蔵 WebView | 実際の Chrome |
| ビジュアルエディタ | なし | Design Sidebar | なし |
参考リンク
スクリーンショット — AI が画面を「見る」
ブラウザ連携でもっとも基本的な機能がスクリーンショットです。AI がコードの結果を「目で見る」ための仕組みです。
Cursor — 画像をコンテキストに直接統合
Cursor のブラウザツールはスクリーンショットをファイル読み取りツールと統合しており、Agent がブラウザの状態を 画像として直接認識 します。テキスト記述に頼るのではなく、実際の画面を「見て」判断できるのが強みです。
Antigravity — スクリーンショットをアーティファクトとして保存
Antigravity の Browser サブエージェントは、ページの状態を確認したいときにスクリーンショットを撮影し、それを 画像アーティファクト として保存します。ユーザーはアーティファクトにコメントを付けてフィードバックを返すことができます。
Claude Code — MCP サーバー依存
Claude Code のスクリーンショット機能は使用する MCP サーバーに依存します。Playwright MCP であれば browser_screenshot ツールでスクリーンショットを取得できます。Claude はマルチモーダル対応なので、取得した画像を直接分析できます。
参考リンク
ブラウザ操作 — AI が画面を「触る」
スクリーンショットで「見る」だけでなく、クリック・入力・ナビゲーションといった操作を自動化できるのが、ブラウザ連携の真価です。
Cursor — フルブラウザコントロール
Cursor の Agent は Navigate・Click・Type・Scroll の4操作に加え、Console Output と Network Traffic の監視もできます。フォーム入力からボタンクリック、リダイレクト追跡まで、E2E テストに必要な操作が一通り揃っています。
開発中の Web アプリをテストするときは、Agent が実行中の開発サーバーを自動検出して正しいポートを使ってくれます。「ポート番号を間違えて別のサーバーに接続してしまう」という地味な問題を避けられます。
Antigravity — 専用モデルによるブラウザ操作
Antigravity の Browser サブエージェントは、クリック・スクロール・入力・コンソールログ読み取りなどのツールを持ち、DOM キャプチャ・スクリーンショット・Markdown パースでページ内容を理解します。
メインエージェントとは異なるモデルで動作するため、ブラウザ操作に最適化された判断ができます。操作中はページ上にアクションの説明が表示されるので、AI が何をしているか視覚的に分かります。
Claude Code — MCP ツールで操作
Claude Code は MCP サーバーが提供するツールでブラウザを操作します。Playwright MCP なら browser_click・browser_type・browser_navigate などのツールが使えます。操作の種類は接続する MCP サーバー次第です。
参考リンク
操作録画 — 操作の記録と再利用
Antigravity — Browser Recordings
Antigravity 独自の機能として Browser Recordings があります。Browser サブエージェントがブラウザを操作するたびに、その操作を 録画 して後から再生できるようにします。
録画は Browser ステップ UI の下部に表示され、アーティファクトとしても保存されます。「AI がどんな操作をしたか」を視覚的に振り返れるので、テスト結果の確認やチームへの共有に便利です。
Cursor と Claude Code には同等の録画機能はありませんが、Cursor はチャット内にブラウザ操作のログが表示されるので、テキストベースで操作履歴を追うことはできます。
参考リンク
ブラウザ分離とセキュリティ
AI にブラウザを使わせるということは、「あなたの代わりに Web ページにアクセスさせる」ということです。ここにはセキュリティ上の考慮が必要です。
Cursor — 多層セキュリティ
Cursor のブラウザは セキュアな WebView として動作し、MCP サーバーとして制御されます。セキュリティ面では以下の仕組みが入っています。
- トークン認証：ブラウザセッション開始時に毎回ランダムなトークンを生成
- タブ分離：各タブに固有のランダム ID を付与し、タブ間の干渉を防止
- 操作承認：デフォルトでブラウザ操作は毎回ユーザーの承認が必要。Manual approval / Allow-listed actions / Auto-run の3段階から選択可能
- Allow / Block リスト：信頼するアクションを許可リストに、危険なアクションをブロックリストに設定可能
Enterprise 向けには Origin Allowlist 機能があり、管理者が Agent のナビゲート先ドメインを制限できます。たとえば http://localhost:3000 と https://internal.example.com だけを許可する、という運用が可能です。
Antigravity — 別プロファイルと URL 制御
Antigravity はブラウザを 別の Chrome プロファイル で起動します。通常のブラウジングと完全に分離されるので、ログイン済みのセッションや Cookie が AI に漏れることはありません。
URL アクセスには2段階のセキュリティが入っています。
- Denylist：Google の BadUrlsChecker サービスで危険/悪意ある URL をサーバーサイドでブロック。サーバーが利用不可の場合はデフォルトで拒否
- Allowlist：ローカルのテキストファイルで明示的に信頼する URL を管理。初期状態は
localhostのみ。未許可の URL にアクセスしようとすると「always allow」ボタンが表示され、ユーザーが許可すると追加される
Denylist は常に Allowlist より優先されます。Denylist に載っている URL は、Allowlist に追加しても開けません。
Claude Code — MCP サーバー次第
Claude Code はブラウザのセキュリティも使用する MCP サーバーに依存します。Playwright MCP ならローカルで動くのでネットワーク越しのリスクは低いですが、Browserbase のようなクラウドサービスを使う場合はデータがクラウドを経由します。
いずれの場合も、第五章で説明した MCP ツールの承認フロー（デフォルトで毎回承認）が適用されるので、意図しない操作を勝手に実行される心配は少ないです。
参考リンク
ブラウザ連携の落とし穴
ブラウザ連携は便利ですが、実際に使ってみると予想外のハマりどころがあります。
スクリーンショットのトークンコスト
スクリーンショットは画像としてモデルのコンテキストに入ります。1枚あたり数百〜数千トークンを消費するため、「操作するたびにスクリーンショットを撮る」を繰り返すとコンテキストがあっという間に埋まります。
Cursor はこの問題を意識した設計をしていて、ブラウザログをファイルに書き出して Agent が grep で必要な行だけ読む仕組みになっています。毎回の操作後に全ログを要約するのではなく、関連部分だけを選択的に読むことでトークン消費を抑えています。
対策としては、スクリーンショットは要所だけ撮る（操作のたびに撮らない）、操作完了後にまとめて1枚撮る、という使い方が無駄を減らせます。
ブラウザ操作の不安定さ
AI によるブラウザ操作は、手で書いた E2E テストと比べると不安定です。よくあるパターンは以下の3つです。
- タイミング問題：ページの読み込みが完了する前にクリックしようとして失敗する
- 動的 DOM：SPA のクライアントサイドルーティングで DOM が変わり、セレクタが見つからない
- ポップアップやモーダル：Cookie 同意バナーなど予期しない要素がクリックを妨げる
Cursor の「開発サーバー自動検出」や Antigravity の「操作中のページ干渉防止（オーバーレイ）」は、こういった問題を軽減するための設計です。それでも完璧ではないので、ブラウザ操作が失敗したら「もう一度試して」と言い直すことはよくあります。
「見えている」と「正しい」は違う
AI がスクリーンショットを「見て」判断するとき、人間なら一目で分かる問題を見逃すことがあります。
- 微妙な色の違い（デザインシステムの色指定が1段階ずれている）
- フォントの違い（Web フォントが読み込まれていない状態のスクリーンショット）
- レスポンシブの崩れ（特定の画面幅でだけ起きる問題）
スクリーンショットによる UI 確認はあくまで 「明らかな崩れを検出する」ためのもの で、デザインの完全一致を保証するものではありません。ピクセル単位の精度が必要なら、専用のビジュアル回帰テストツール（Percy・Chromatic など）を併用するのが現実的です。
参考リンク
まとめ
ブラウザ連携は「AI がコードを書く」から「AI がコードの結果を確認する」へと一歩進む仕組みで、3ツールでアプローチが大きく異なります。
Cursor は 組み込みブラウザ + Design Sidebar で、セットアップなしですぐ使える上にビジュアルエディタまで備えています。ブラウザのセキュリティも多層設計（トークン認証・タブ分離・操作承認・Origin Allowlist）で、Enterprise 向けの管理機能も充実しています。「ブラウザ連携をすぐ試したい」人にとって一番手軽な選択肢 です。
Antigravity は 専用の Browser サブエージェント + 実際の Chrome という独自路線です。別プロファイルで起動する Chrome を専用モデルが操作し、操作録画（Browser Recordings）まで自動生成してくれます。Denylist（サーバーサイド）+ Allowlist（ローカル）の2段階 URL 制御も特徴的です。操作の可視化と記録を重視する ユースケースに向いています。
Claude Code は MCP サーバー経由 でブラウザに接続するアプローチです。組み込みではない分セットアップが必要ですが、Playwright・Browserbase など好きなブラウザ自動化ツールを自由に選べます。既存のテスト基盤と統合したい 場合や、クラウド上のヘッドレスブラウザを使いたい 場合に柔軟です。
そしてどのツールを使うにしても、スクリーンショットのトークンコスト・操作の不安定さ・AI の画像認識の限界 は意識しておく必要があります。ブラウザ連携は「完璧な UI テスト自動化」ではなく、「明らかな問題を早期に検出するためのセーフティネット」として活用するのが、現時点での現実的な使い方です。
