投稿

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 ...

AIエージェント入門 第六章!プラグインの基本と導入前に知っておきたいリスク

  ここまでスキル(第二章)・フック(第三章)・エージェント(第四章)・MCP(第五章)と、エージェントを拡張する仕組みを順に見てきました。「便利な設定を作ったから、チーム全員にも配りたい」と思ったとき、これらを   まとめて配布するためのバンドル機構   が   プラグイン   です。 スキル単体・フック単体を Git で配るのは面倒ですが、プラグインなら「このリポジトリを追加して」の一言で済みます。ただし、プラグインの仕組みは3ツールでサポート状況も思想も大きく異なります。 第六章では、バンドル範囲・配布エコシステム・バージョン管理・チーム配布といった機能面を3ツールで比べたうえで、プラグインだからこそ気をつけないといけない  サプライチェーンリスクやプラグイン衝突  の問題にも踏み込んでいきます。便利さに飛びつく前に、安全に導入するためのポイントをセットでお届けします。 プラグインとは何か プラグインは、第二章〜第五章で見てきたスキル・ルール・フック・コマンド・MCP サーバー・エージェント定義などを  1つのバンドルにまとめて配布する仕組み  です。受け取った側はワンコマンド(または管理者ポリシー経由)で全部入りで導入できます。 たとえば、チームで「コード変更後に必ずセキュリティレビューを通す」というワークフローを運用したい場合。レビュー用のスキル + コード編集後に自動実行するフック + 脆弱性データベースに繋ぐ MCP サーバーを1つのプラグインにまとめて、チーム全員に  /plugin install security-review@team-tools  してもらうだけで導入完了、という使い方ができます。 3ツールのサポート状況は次のとおりです。 ツール プラグイン機構 代替手段 Claude Code ✅ ネイティブ対応 — Cursor ✅ ネイティブ対応 — Antigravity ❌ 非対応 MCP Store・VS Code 拡張で部分的に補う Antigravity には現時点でプラグイン相当の機構がなく、MCP サーバーは MCP Store から、エージェントの定義は  .agents/agents.md  ...