ASADASHI
バイブコーディング
バイブコーディング2026.11.08·読了 2分·難易度: むずかしい

AIエージェントがブラウザを自動操作する時代へ

朝の出汁版(通勤2分)

  • ポイント1: Vercelの実験的CLIツール「agent-browser」が公開され、AIエージェントがブラウザを自律的に操作する基盤がオープンソースで提供されるようになった(GitHubスター数4.6万超)。
  • ポイント2: 使う側として知っておくべきは、このツールによってフォーム入力・画面遷移・情報収集といった「人がブラウザでやっていた作業」をエージェントに委任できる構造が、個人レベルで実装可能になりつつある点。
  • ポイント3: 触りたい人はGitHub(vercel-labs/agent-browser)のREADMEからCLIのインストール手順を確認し、まず手元の繰り返し操作を一つ自動化する実験から始めるのが入口として現実的。

出汁の素(深読みモード)

スター数4.6万超——Vercelがエージェント向けブラウザ操作CLIを公開した意味

Vercel Labs が公開した「agent-browser」は、AIエージェントがブラウザを自律的に操作するためのCLIツールです。GitHubのスター数は4.6万を超えており、開発者コミュニティの注目度は相当なものです。

これまで「ブラウザを自動操作する」といえば、SeleniumやPlaywrightのような既存ツールが主役でした。ただしそれらは「人間が手順を書いたスクリプトを実行する」構造で、判断はあくまで人間側にありました。agent-browserが違うのは、AIエージェントが状況を読みながら動的に操作を組み立てる、という設計思想にあります。日本でいうと「RPAとAIの間にあった壁を取り払った」イメージに近い。

Vercel Labsというのは、Vercel本体の実験的プロジェクトを公開する場所です。Nextjsを作ったチームが実験的に出しているという事実は、このアプローチが今後のWebインフラに組み込まれる可能性を示唆しています。

「繰り返しブラウザ操作」をエージェントに渡せる構造になってきた

agent-browserがもたらす変化を具体的に整理すると、フォームへの入力、ページ間の遷移、特定条件に合う情報の収集、といった「人がブラウザを使って毎日やっていた反復作業」をエージェント側に委任する構造が、個人レベルでも実装できる段階に入ってきた、ということです。

注目したいのは、Rustで実装されている点。PythonベースのツールよりもCLIとして軽量に動かせる可能性があり、エージェントが大量のブラウザ操作を並行して走らせる用途に向いています。AIエージェントで並行作業、Gitを使い倒す新CLIでも触れたように、エージェントに「並列で仕事をさせる」という設計が各所で整備されつつある流れと重なります。

一方で、これはまだ「Vercel Labsの実験的リポジトリ」です。プロダクション利用を前提にする段階ではなく、むしろ「こういう設計がOSSとして出てきた」という事実を把握しておくフェーズと見るのが現実的でしょう。

コードなしでできること、コードが書けると有利なこと

agent-browserはCLIツールなので、ターミナルが使えることが前提になります。ただし「コードが書けないと何もできない」わけではありません。

コードなしでできる範囲としては、READMEに記載されているサンプルコマンドを実行して動作を確認するところまでは到達できます。自然言語で「このページのフォームに○○を入力してsubmitして」という指示を渡す設計になっているため、エージェントへの指示文自体は日本語でも書けます。

コードが書けると有利なのは、繰り返し操作をスクリプト化してCIに組み込む段階と、取得したデータを別ツールに渡して処理する段階です。たとえば「競合サイトの特定ページを定期的にチェックして変化があったらSlackに通知する」といった組み合わせはコード側の設計が要ります。

なお、同じタイミングでmetaが公開した「astryx」(TypeScript製のUIデザインシステム、スター数1.4万超)はエージェントが操作しやすいコンポーネント設計を提供するもので、agent-browserのようなツールと組み合わせることを意識した設計です。エージェントが「操作する側」に最適化されたUIが標準になる流れも、見えてきています。

まず手を動かすなら——GitHubのREADMEから入る最初の一手

触りたい人への入口を整理します。

リポジトリ: vercel-labs/agent-browser

READMEにCLIのインストール手順とサンプルコマンドが記載されています。最初のステップとしては以下が現実的です。

  1. GitHubのREADMEを読んで「何をコマンドとして渡すか」の設計思想を把握する
  2. 手元に繰り返しブラウザ操作があるか棚卸しする(毎朝開いて確認しているページ、毎週手動で入力しているフォームなど)
  3. その1つをagent-browserのコマンドとして書けるか試す

試す前に押さえたいのは、agent-browserがアクセスするサービス側の利用規約の確認です。自動化を明示的に禁止しているサービスへの適用は避けるのが基本です。

GoogleがAIエージェント基盤をオープンソースに寄贈でも書いたように、エージェントが動ける基盤がOSSとして次々と整備されている状況です。「何ができるか」の全体像を把握しながら、自分のワークフローで使えそうな一点から試すというアプローチが、使いこなしへの最短経路になります。

次の視点——エージェントが動ける「UI設計」が変わり始める

agent-browserのようなツールが普及した先に何が起きるかを考えると、Webサービスのフロントエンド設計自体が変わる可能性があります。metaのastryx(エージェントが操作しやすいUIコンポーネント集)の登場は、その先触れとして読めます。

「人間が見やすいUI」と「エージェントが操作しやすいUI」は、設計原則が部分的に異なります。エージェントはラベルの意味を解釈しながら操作するため、ボタンやフォームの意味が曖昧だと失敗しやすい。今後、フロントエンド設計の評価軸に「エージェント操作性」が加わる展開は十分ありえます。

バイブコーディング(AIを使いながら手を動かす開発スタイル)で自分のツールを作る人にとっては、「自分が作るUIをエージェントが操作することも想定した設計」という視点が、近いうちに実践的な課題になりそうです。

参照ソース