AIエージェント入門 第七章!AIが画面を「見て」「操作する」— ブラウザ連携の仕組みと注意点
AI エージェントにコードを書かせたあと、「画面が崩れてないか見てくれない?」と頼めたら便利ですよね。あるいは「ログインして、このフォームに入力して、送信ボタンを押して」という操作をそのまま自動化できたら。これを実現するのが ブラウザ連携 です。 Claude Code・Cursor・Antigravity の3ツールはいずれもブラウザと連携できますが、アプローチが大きく異なります。組み込みか MCP 経由か、画面を「見る」だけか「触れる」のか、操作を録画できるか。 第七章では、ブラウザ自動化の仕組みをツールごとに比べたうえで、スクリーンショットのトークンコストやブラウザ操作の不安定さといった 実運用の落とし穴 にも踏み込んでいきます。 AI がブラウザを使えると何がうれしいのか エージェントにブラウザを使わせる最大のメリットは、 コードの「結果」を AI 自身が確認できる ことです。 コードを書くだけなら AI は得意ですが、それが画面上でどう見えるかは別の話です。CSS を書き換えたらレイアウトが崩れた、ボタンの配置がずれた、フォントが反映されていない — こういった問題はコードを読んだだけでは分かりません。ブラウザ連携があれば、AI が自分で画面を見て「あ、ここ崩れてる」と気づいて直せます。 具体的なユースケースは以下のとおりです。 UI の確認 :コード変更後にスクリーンショットを撮って、見た目が意図どおりか確認する E2E テスト :フォーム入力 → ボタンクリック → 結果確認、という一連の操作を自動で回す UI 回帰テスト :変更前後のスクリーンショットを比較して、意図しない見た目の変化を検出する アクセシビリティ監査 :コントラスト比、ARIA ラベル、キーボードナビゲーションをチェックする デザインからコードへの変換 :デザインモックと実装を見比べて、差分を修正する 参考リンク Browser — Cursor Docs Browser Subagent — Antigravity Docs ブラウザ自動化の仕組み — 3ツールのアプローチ 3ツールでブラウザ連携のアーキテクチャが大きく異なります。ここが一番面白いポイントです。 Cursor — 組み込み Browser ...