Vibium: PlaywrightよりAIエージェントに最適化されたブラウザ自動化ツール

Vibium: PlaywrightよりAIエージェントに最適化されたブラウザ自動化ツール cover image

Seleniumの生みの親Jason Hugginsが、Selenium以来約20年ぶりとなる新しいブラウザ自動化ツールVibium を発表しました。本記事では、Vibiumの設計思想、PlaywrightやPuppeteerとの違い、そしてなぜAIエージェント時代に新たなツールが必要だったのかを解説します。

Vibiumとは何か

Vibiumは、AI エージェント向けに設計されたブラウザ自動化インフラストラクチャです。10MB程度の単一バイナリに以下の機能がすべて統合されています：

ブラウザライフサイクル管理: Chromeの検出と起動
WebDriver BiDiプロキシ: ブラウザとの通信
MCP サーバー: LLMエージェント（Claude Code等）との統合
自動待機: 要素が現れるまで自動的にポーリング
スクリーンショット: ビューポートのPNGキャプチャ

最大の特徴は、Claude Code との統合が1行のコマンドで完了する点です：

1
claude mcp add vibium -- npx -y vibium

この1行で、Claude Codeがブラウザを直接操作できるようになります。Chrome本体も自動でダウンロードされるため、手動セットアップは一切不要です。

SeleniumからVibiumへ：20年の進化

Jason Hugginsは2004年にSelenium を作成し、ブラウザ自動化の世界を切り開きました。その後、業界はSelenium WebDriver、Puppeteer、Playwrightと進化してきましたが、Hugginsが再びツールを作った理由は何でしょうか？

既存ツールの課題

Selenium WebDriver（2011年〜）は成熟していますが、以下の問題があります：

セットアップが複雑（ドライバーの管理、ブラウザのバージョン対応）
要素待機のボイラープレートコードが必要
AIエージェントとの統合が考慮されていない

Playwright （2020年〜）とPuppeteer （2018年〜）は、Chrome DevTools Protocol（CDP）を使用してこれらの問題を解決しました。しかし：

CDPはChrome固有のプロトコル（標準化されていない）
複数ブラウザのサポートには追加の抽象化レイヤーが必要
MCPサーバー機能は別途実装が必要

WebDriver BiDiという選択

VibiumはWebDriver BiDi プロトコルを採用しています。これはW3C標準として策定中で、Selenium WebDriverとCDPの良いところを組み合わせた次世代プロトコルです：

双方向通信: ブラウザ側からのイベントをリアルタイム受信
標準化: Chrome、Firefox、Safariすべてで動作（仕様上）
低レベルアクセス: ネットワーク、コンソール、DOMへの直接アクセス

HugginsはTestGuildポッドキャストのインタビューで次のように述べています：

WebDriver BiDiは、PuppeteerとPlaywrightを素晴らしいものにしたCDPの教訓をすべて学んだプロトコルです。

PlaywrightではなくVibiumを作った理由

では、なぜPlaywrightを使わずに新しいツールを作ったのでしょうか？主な理由は設計思想の違いです。

1. AIエージェント最優先の設計

VibiumはAIエージェント向けに最適化されています：

MCPサーバー内蔵: Claude Code、Gemini、ローカルLLMと即座に統合
stdio通信: LLMエージェントとの通信プロトコル標準に対応
シンプルなAPI: AIが理解しやすい最小限のメソッド

一方、Playwrightは人間のテストエンジニア向けに設計されており、MCP統合は別途実装が必要です。

2. ゼロセットアップ哲学

Vibiumの設計ゴールは「バイナリが見えない」ことです：

1
2
3
4
5
6
7
// npm install vibium だけでこれが動く
const { browserSync } = require('vibium')

const vibe = browserSync.launch()
vibe.go('https://example.com')
vibe.find('a').click()
vibe.quit()

ブラウザのダウンロード、ドライバーの配置、パス設定はすべて自動化されています。これは「まず動かす」ことを重視するAI時代の開発者体験です。

3. 単一バイナリのシンプルさ

Vibiumは10MB程度のGoバイナリ1つですべてを実現します：

┌─────────────────────────────────────────────────────────────┐
│                         LLM / Agent                         │
│          (Claude Code, Codex, Gemini, Local Models)         │
└─────────────────────────────────────────────────────────────┘
                      ▲
                      │ MCP Protocol (stdio)
                      ▼
           ┌─────────────────────┐
           │   Vibium Clicker    │
           │                     │
           │  ┌───────────────┐  │
           │  │  MCP Server   │  │
           │  └───────▲───────┘  │         ┌──────────────────┐
           │          │          │         │                  │
           │  ┌───────▼───────┐  │WebSocket│                  │
           │  │  BiDi Proxy   │  │◄───────►│  Chrome Browser  │
           │  └───────────────┘  │  BiDi   │                  │
           │                     │         │                  │
           └─────────────────────┘         └──────────────────┘

Playwrightは複数のnpmパッケージとブラウザバイナリで構成されており、依存関係が複雑です。Vibiumはシンプルさを選びました。

Vibiumの実践的な使い方

AIエージェントとして使う

Claude Codeに統合した後は、自然言語で指示できます：

「example.comに行って、最初のリンクをクリックして」

Claude Codeは以下のMCPツールを自動的に呼び出します：

ツール	説明
`browser_launch`	ブラウザ起動（デフォルトで可視）
`browser_navigate`	URL遷移
`browser_find`	CSSセレクタで要素検索
`browser_click`	要素クリック
`browser_type`	テキスト入力
`browser_screenshot`	スクリーンショット取得
`browser_quit`	ブラウザ終了

JavaScriptライブラリとして使う

npmパッケージとして直接使用することもできます：

同期API（REPLフレンドリー）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
const fs = require('fs')
const { browserSync } = require('vibium')

const vibe = browserSync.launch()
vibe.go('https://example.com')

const png = vibe.screenshot()
fs.writeFileSync('screenshot.png', png)

const link = vibe.find('a')
link.click()
vibe.quit()

非同期API

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
const fs = await import('fs/promises')
const { browser } = await import('vibium')

const vibe = await browser.launch()
await vibe.go('https://example.com')

const png = await vibe.screenshot()
await fs.writeFile('screenshot.png', png)

const link = await vibe.find('a')
await link.click()
await vibe.quit()

自動待機の仕組み

Vibiumは要素が表示されるまで自動的に待機します：

1
2
3
// これは要素が現れるまで自動的にポーリング
const button = vibe.find('button.submit')
button.click()

PlaywrightやSeleniumでは明示的な待機コードが必要でしたが、Vibiumはデフォルトで賢く待つため、コードがシンプルになります。

プラットフォーム対応

Vibiumは以下のプラットフォームをサポートしています：

プラットフォーム	アーキテクチャ	対応状況
Linux	x64	✅ 対応済み
macOS	x64 (Intel)	✅ 対応済み
macOS	arm64 (Apple Silicon)	✅ 対応済み
Windows	x64	✅ 対応済み

インストール時にプラットフォームに応じたバイナリが自動選択され、Chromeのキャッシュは以下の場所に保存されます：

Linux: ~/.cache/vibium/
macOS: ~/Library/Caches/vibium/
Windows: %LOCALAPPDATA%\vibium\

ロードマップ：v2以降の計画

現在のv1は「AIとブラウザの統合」に焦点を当てていますが、v2ロードマップでは以下の機能がリリース・計画されています：

Pythonクライアント: 2025年12月にリリース済み（pip install vibium）
Javaクライアント: エンタープライズ向けに計画中
Cortex: メモリ・ナビゲーションレイヤー
Retina: レコーディング拡張機能
動画録画: テスト実行の記録
AIロケーター: より賢い要素検索

これらはすべて「AIエージェントがブラウザをより自然に扱う」というビジョンの延長線上にあります。

なぜ今Vibiumなのか

Jason HugginsがSelenium以来、約20年ぶりに新しいツールを作った理由は、AIエージェントの登場というパラダイムシフトにあります。

テストツールからAIツールへ

Seleniumはテスト自動化のために作られました。PlaywrightやPuppeteerも同様です。しかし、Claude Code、Gemini、ChatGPT等のAIエージェントは別の使い方をします：

人間が書いたテストスクリプトを実行するのではなく、AIが動的に判断する
固定のセレクタではなく、視覚的な情報や文脈から要素を特定する
ブラウザ操作はタスク達成の一部であり、最終目標ではない

この新しい使い方に最適化されたツールが必要でした。それがVibiumです。

MCPエコシステムの台頭

Model Context Protocol（MCP）はAnthropic が提唱するAIエージェントとツールの統合標準です。Vibiumは最初からMCPサーバーとして設計されており、Claude Code、Cursor、その他のMCP対応AIエディタと即座に統合できます。

これは「ツールを作ってから統合方法を考える」のではなく、「統合を前提にツールを設計する」という発想の転換です。

シンプルさへの回帰

20年間でブラウザ自動化ツールは高機能化しましたが、同時に複雑になりました。Vibiumは「本当に必要な機能だけ」に絞ることで、シンプルさを取り戻しています：

単一バイナリ
ゼロセットアップ
最小限のAPI
自動待機

この哲学は、exoやdotenvxといった最近のツールに共通する「複雑さの削減」というトレンドと一致しています。

PlaywrightとVibiumのトークン効率比較実験

AIエージェントにとって重要なのは、タスク達成に必要なトークン消費量です。同じタスクを両ツールで実際に実行し、トークン効率を計測してみました。

実験条件

タスク: 「example.comにアクセスして、ページのスクリーンショットを撮る」

OpenCodeのトークンカウンターを使用して、実際のトークン消費量を計測しました。

実測結果：トークン消費量

Vibium の場合

1
2
3
4
5
# 実行したツール呼び出し
1. browser_launch         # ブラウザ起動
2. browser_navigate       # https://example.com に移動
3. browser_screenshot     # スクリーンショット撮影
4. browser_quit          # ブラウザ終了

消費トークン: 240 tokens

各ツールのレスポンス例：

browser_launch: “Browser launched (headless: false)” (7語)
browser_navigate: “Navigated to https://example.com/" (4語)
browser_screenshot: “Screenshot saved to /path/to/file.png” (5語)
browser_quit: “Browser session closed” (3語)

Playwright の場合

1
2
3
# 実行したツール呼び出し
1. browser_navigate       # https://example.com に移動
2. browser_take_screenshot # スクリーンショット撮影

消費トークン: 2,061 tokens

各ツールのレスポンス例：

browser_navigate:
- 実行コードスニペット: await page.goto('https://example.com');
- ページ情報（URL、タイトル）
- アクセシビリティツリー全体（YAML形式、数百〜数千語）
browser_take_screenshot:
- 実行コードスニペット
- スクリーンショット画像データ（Vision APIでトークン消費）

驚きの結果：Vibiumは8.6倍効率的

Playwright: 2,061 tokens (2回のツール呼び出し)
Vibium:       240 tokens (4回のツール呼び出し)

効率比: Vibium は Playwright の 約1/8.6 のトークンで同じタスクを達成

なぜこれほど差が出るのか

Playwrightが多くのトークンを消費する理由:

アクセシビリティツリーの自動送信: browser_navigate が毎回、ページ全体のDOM構造をYAML形式で返す

1
2
3
4
5
6
- generic [ref=e2]:
  - heading "Example Domain" [level=1] [ref=e3]
  - paragraph [ref=e4]: This domain is for use...
  - paragraph [ref=e5]:
    - link "Learn more" [ref=e6]:
      - /url: https://iana.org/domains/example

このデータだけで数百トークンを消費

実行コードの表示: デバッグ用に実際のPlaywrightコードを表示
1 2
await page.goto('https://example.com'); await page.screenshot({...});
画像データ: スクリーンショットが画像として返され、Vision APIで処理される

Vibiumが効率的な理由:

最小限のレスポンス: 成功/失敗のメッセージのみ（平均5語以下）
画像はローカル保存: スクリーンショットはファイルパスのみ返す（トークン消費なし）
コード表示なし: シンプルなステータスメッセージのみ

複雑なタスクでの影響

example.comのような単純なページでも8.6倍の差が出ます。実際のWebアプリケーション（例：ダッシュボード、管理画面）では、この差はさらに広がります：

ページの複雑さ	Playwright消費	Vibium消費	比率
単純（example.com）	2,061 tokens	240 tokens	8.6x
中規模（ブログ記事）	推定 5,000〜10,000	240〜300	16〜33x
複雑（管理画面）	推定 10,000〜50,000	240〜400	25〜125x

結論:

Vibiumは「AIにとって必要な情報だけ」を返す設計
Playwrightは「人間がデバッグするための情報」も含めて返す設計
AIエージェントの運用コスト削減には、Vibiumのアプローチが圧倒的に有利

この実験結果は、VibiumがなぜPlaywrightとは別に作られたかを明確に示しています。AIエージェント時代には、「どれだけ機能が豊富か」ではなく「どれだけ効率的か」が重要になるのです。

PlaywrightとVibiumの使い分け

どちらのツールも優れていますが、ユースケースによって最適な選択は異なります。

Playwrightが向いているケース

以下のような場合は、Playwrightの方が適しています：

1. 人間が書くE2Eテスト

CI/CDパイプラインで実行する固定のテストスクリプト
既存のPlaywrightテストスイートがある場合
デバッグ情報（アクセシビリティツリー、実行コード）が必要

2. クロスブラウザテスト

Chrome、Firefox、Safariすべてで同じコードを実行
ブラウザ間の挙動の違いを検証
モバイルブラウザのエミュレーション

3. 高度なDOM操作

Shadow DOMやiframeの複雑な操作
ネットワークリクエストのインターセプト・モック
ブラウザコンテキストの細かい制御

4. 既存エコシステムとの統合

Playwright Test Runner、Playwright Inspectorなどの公式ツール
TypeScript型定義の恩恵（自動補完、型チェック）
Microsoft公式サポートとコミュニティ

例：複雑なE2Eテストシナリオ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
// Playwrightの強み：詳細な制御
import { test, expect } from '@playwright/test';

test('複雑な決済フロー', async ({ page, context }) => {
  // ネットワークリクエストをモック
  await page.route('**/api/payment', route => {
    route.fulfill({ status: 200, body: '{"success": true}' });
  });
  
  // 複数タブでの操作
  const [newPage] = await Promise.all([
    context.waitForEvent('page'),
    page.click('a[target="_blank"]')
  ]);
  
  // Shadow DOM内の要素操作
  const shadowHost = await page.locator('custom-element');
  const shadowButton = await shadowHost.evaluateHandle(
    el => el.shadowRoot.querySelector('button')
  );
});

Vibiumが向いているケース

一方、以下のような場合はVibiumが最適です：

1. AIエージェントによる自動化

LLM（Claude、Gemini等）がブラウザを操作
自然言語での指示に基づくタスク実行
トークンコストを重視する運用

2. 動的なブラウザ操作

事前に手順が確定していないタスク
ユーザー入力に応じて動作を変える必要がある場合
「とにかくゴールに到達する」ことが重要

3. シンプルなスクリプト・REPL

Node.js REPLで対話的にブラウザ操作
Pythonスクリプトからの直接呼び出し
同期APIでシンプルに書きたい場合

4. ゼロセットアップが必須

CI環境で依存関係を最小化したい
Dockerコンテナサイズを抑えたい
クイックプロトタイピング

例：AIエージェントタスク

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
// Vibiumの強み：シンプルさとAI統合
const { browserSync } = require('vibium');

// REPLフレンドリーな同期API
const vibe = browserSync.launch();
vibe.go('https://example.com');

// AIが次のステップを判断
// 「ログインボタンを探してクリック」
// → 要素が見つからない場合、自動待機
// → それでもダメなら、AIに再判断を依頼

使い分けの判断基準

基準	Playwright	Vibium
実行者	人間が書いたスクリプト	AIエージェント
テストの性質	決定論的（固定手順）	動的（状況に応じて判断）
デバッグの必要性	高い（詳細情報が必要）	低い（結果重視）
トークンコスト	気にしない	重要
クロスブラウザ	必須	Chrome中心でOK
既存資産	Playwrightコードあり	ゼロスタート

実務的な提案：両方使う

多くのプロジェクトでは、以下のように使い分けるのが理想的です：

CI/CDの固定テスト → Playwright（安定性重視）
探索的テスト・デモ → Vibium（柔軟性重視）
AIアシスタント統合 → Vibium（トークン効率重視）

どちらも優れたツールであり、「どちらが良い」ではなく「どちらが適しているか」で判断すべきです。

まとめ

VibiumがPlaywrightではなく新たに作られた理由は、以下の3点に集約されます：

AIエージェント最優先の設計: MCPサーバー内蔵、stdio通信、シンプルなAPI
WebDriver BiDiの採用: 標準化された次世代プロトコル
ゼロセットアップ哲学: 単一バイナリ、自動ブラウザダウンロード、即座に動く

SeleniumからPlaywrightへの進化は「より良いテストツール」を目指したものでした。一方、Vibiumは「AIがブラウザを操作するためのインフラ」という新しいカテゴリを開拓しています。

トークン効率の実験から分かるように、Vibiumは「AIエージェントが視覚的にWebを理解する」という新しいアプローチを取っています。これは、従来のDOM操作中心のツールとは異なる設計思想です。

AIエージェント時代のブラウザ自動化に興味がある方は、ぜひVibiumを試してみてください。

Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新