Antigravity (Browserbase) で実行するブラウザエージェント自動化2026

この記事でわかること

  • Browserbase 上の Antigravity を使ったクラウドブラウザエージェントの基本構成
  • 中級者がローカル Playwright から Browserbase へ移行する際の判断基準
  • セッション分離・永続化・Cookie 共有を活用した実用ワークフローの作り方

結論

2026年Q2時点の Browserbase Antigravity は「クラウド側で常駐するヘッドフルブラウザを、API/SDK 経由で AI エージェントから操作する」用途に最適化されたサービスです。中級開発者がスクレイピングや業務RPA を本番運用に乗せる際、ローカル Playwright の運用コストを大きく下げられるのが強みです。執筆時点では従量課金モデルなので、無料 API ベースで動く軽い処理を移すと逆にコスト増になる点だけは注意してください。

本題

Antigravity と Browserbase の関係

混乱しがちですが、執筆時点で「Antigravity」は2系統あります。

  • Google が出している AI IDE「Google Antigravity」
  • Browserbase が提供するブラウザ自動化向けランタイム名としての「Antigravity」

本記事は後者、Browserbase 系の Antigravity を扱います。Browserbase は AWS や GCP のリージョンにヘッドレス/ヘッドフル Chrome を多数並べておき、SDK から「セッションを払い出して操作する」モデルを取っています。

中級者向けに最初に覚えるべき構造は3層です。

  1. エージェント層 (Claude / GPT / 自作 LLM ロジック)
  2. 制御プロトコル (Playwright / Puppeteer / Selenium WebDriver の互換)
  3. ランタイム層 (Browserbase が用意するクラウドブラウザセッション)

エージェント層は変えずに、ローカル Playwright 接続先を Browserbase の WebSocket エンドポイントに差し替えるだけで動くケースが多いのが Browserbase の最大の強みです。

ローカル Playwright から移行すべき判断基準

すべてを Browserbase に寄せる必要はありません。中級者の判断ポイントは次の4つ。

  • 並列度: 同時セッションが10を超えるならクラウド寄り
  • IP多様性: 同一IPでアクセスし続けると弾かれる業務（公開Webスクレイピング・予約系）はクラウド寄り
  • 永続化: 「ログイン状態を翌日まで持ち越したい」ならクラウド寄り
  • コスト: 数分の単発処理だけならローカルのほうが安い

逆に「自社の社内ツールを夜間バッチで叩くだけ」「同じ1サイトに固定IPで張り付くほうが安全」といった用途はローカル運用の方が向きます。

移行のコード例（Playwright）

TypeScript のスニペット。BROWSERBASE_API_KEY と BROWSERBASE_PROJECT_ID だけで切替可能です。

import { chromium } from "playwright-core";

const session = await fetch("https://api.browserbase.com/v1/sessions", {
  method: "POST",
  headers: {
    "x-bb-api-key": process.env.BROWSERBASE_API_KEY!,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ projectId: process.env.BROWSERBASE_PROJECT_ID }),
}).then((r) => r.json());

const browser = await chromium.connectOverCDP(session.connectUrl);
const ctx = browser.contexts()[0];
const page = await ctx.newPage();
await page.goto("https://example.com");
console.log(await page.title());
await browser.close();

ポイントは connectOverCDP を使うこと。ローカル launch 系コードを残したままだと「ローカルで Chrome を立ち上げてしまう」ので、移行時は接続部だけ確実に書き換えます。

Browserbase の便利機能のひとつが Persistent Context（執筆時点ではプロジェクト単位で有効化）です。これを使うとログイン状態をセッションをまたいで保持できるため、毎回ログインフローを通す必要がなくなります。

中級者向けの典型ワークフロー:

  1. 初回: 手動 or プログラム経由でログイン → Cookie/LocalStorage が Browserbase 側に保存
  2. 2回目以降: 同じ context ID で接続 → ログイン済み状態で開始
  3. 期限切れ検知: 「ログインページへリダイレクトされた」を検出したら再ログインジョブをキック

これを LLM エージェントの Tool として包めば、「ログイン状態を維持したまま、人間が見ていないところで複数サイトを巡回する」エージェントが実装できます。

観測性とデバッグ

本番運用で詰まりがちなのが「失敗したセッションが何をしていたか分からない」問題です。Browserbase は各セッションの動画録画/HARログ/コンソールログをダッシュボード経由で確認できるため、エージェントが暴走した時の事後分析が大きく楽になります。

中級者が必ず仕込んでおきたいログ設計:

  • セッションIDを必ずアプリ側ログに残す
  • ステップ単位でスクリーンショット / DOM スナップショット
  • アサーション失敗時に直前のページHTMLを保存

これだけで、原因不明な失敗の調査時間が体感で1/3〜1/5になります。

よくある質問（FAQ）

Q1: ローカル Playwright と比べて費用はどのくらい違いますか？

A1: 執筆時点では Browserbase は分単位の従量課金です。1セッションが数十秒で終わる用途では割高になりがちで、逆に長時間ログイン状態を維持したり並列で大量セッションを回したりする用途ではローカルの運用コスト（OS更新・Chromeアップデート・IP管理）と比較して安くなる傾向があります。最終的な判断は実ワークロードでの試算が必要です。

Q2: Bot 対策の強いサイトには通用しますか？

A2: 2026年Q2時点では、Cloudflare 系の高度な Bot 検知に対しては Browserbase でも普通に弾かれます。ステルス系オプションや Residential プロキシ統合は別途用意されていますが、ターゲットサイトの利用規約とのコンフリクトの方が事業リスクとして大きいので、規約と用途の確認が先です。

Q3: Anthropic の Computer Use と組み合わせられますか？

A3: 組み合わせ自体は可能です。Computer Use 側はピクセル座標で操作する設計なので、Browserbase のヘッドフルセッションを VNC/動画ストリームとして取り出して読ませる構成になります。一方で素直に DOM 操作で済む用途なら、Playwright + LLM の構成のほうが安定するのが執筆時点の感覚です。

まとめ

Browserbase Antigravity は「ブラウザを動かしている時間」をクラウドに切り出すための便利なランタイムです。中級開発者は、ローカル Playwright のコードベースを温存したまま、判定基準（並列度・IP・永続化・コスト）に合うものから順次移行するのが現実的です。観測性まで含めて設計しておくと、エージェント運用の事後分析が圧倒的に楽になります。