Stagehand:壊れるコードか予測不能なAIか、二択を終わらせるブラウザ自動化

月500万件を超えるレシート処理をAIが肩代わりし、財務エージェント全体で月あたり約4,200時間もの手作業を減らす——米国の支出管理サービス Ramp(ランプ)の事例だ(数値は開発元の公式事例による)。調達のエージェントを立ち上げたのは、わずか3人のチームだった。

相手のサイトに API(プログラムから操作する公式の窓口)が無く、人手に頼るしかなかった業務を、ブラウザを操作するAIが肩代わりし始めている。

主役は2つ。AIにブラウザを操作させるオープンソースのSDK Stagehand(ステージハンド)と、それを本番規模で動かす基盤 Browserbase だ(米Browserbase社製)。Stagehandは、ブラウザ操作を自動化するツール Playwright を土台にした AIブラウザ自動化 の道具で、似た仕組みは10年以上前からある。なぜ今やっと本番に乗ったのか——鍵はその設計にある。

「壊れやすいコード」か「予測不能なAI」か

本番で使うブラウザ自動化には、長く2タイプの道具があり、どちらも弱点を抱えていた。

ひとつは、コードで書くタイプ。Selenium(セレニウム)や前述のPlaywrightは、操作対象を セレクタ(button:nth-child(3) のような、HTML上の「住所」)で指定する。だからUIが少し変わるだけで住所がずれ、昨日まで動いたスクリプトが今日は止まる。「壊れたセレクタを直し続ける保守」になりがちだった。

もうひとつは、AIに丸ごと任せるタイプ。完全自律型のエージェント(OSSの Browser Use が代表)は柔軟だが、毎回その場で考えるぶん 動きが読めず、実行のたびにブレ、デバッグが難しい。公式リポジトリも、既存ツールは「低レベルなコードか、予測不能なエージェントか」だと言う。正確だが壊れやすいコードか、柔軟だが読めないAIか——長年の二択だ。

AIに任せる量を、開発者が1行ずつ決める

Stagehandはこの二択をなくす。公式いわく「コードで書く部分と自然言語で書く部分を、開発者が選べる」。決まった操作はコードで、初見のページはAIに——その使い分けを同じ枠組みで混ぜられる。中心にあるのが4つの プリミティブ(操作の基本単位)で、AIに委ねる度合いが小さい順に並ぶ。

• act() ——「このボタンを押す」のような1操作を自然言語で指示する最小の単位。
• extract() —— ページから構造化データを抜き出す。欲しい形(型)を渡すと、その型で返る。
• observe() —— 操作できる要素を「下見」し、何にどんな操作ができるかの一覧を返す。
• agent() —— 複数ステップをまとめて任せる、最も自律度の高い操作。

肝は、この4つが段階的なグラデーションになっている点だ。全部任せるのでも全部書くのでもなく、委ねる量をコードで調整できる。Playwrightとも純エージェントとも違うこの「中間解」こそ、本記事の主役である。

二度目は、AIに聞かない

この設計は本番で 壊れにくさ と コスト に効く。AIに判断させる操作はそのつどLLM(大規模言語モデル)を呼ぶため、回数ぶん時間も料金もかさむ。Stagehandは アクションキャッシュ と self-healing(自己修復) で応える。一度 observe() で要素を特定すれば結果を覚え、次回からは記憶のまま実行する——繰り返しでLLMを呼ばないので速く、安い。公式ドキュメントは、この再利用が効く場面では毎回AIに聞くより2〜3倍速いとする。記憶した場所が通じなくなったときだけAIが画面を見て直す——これがself-healingだ。

ただしAIの直しが常に正しいとは限らない。observe() で実行前に妥当性を確かめる(validate-before-act)など、誤操作を防ぐ余地も設計側にある。

Rampは「財務エージェントの群れ」を動かしている

洗練された仕組みも、本番で効かなければ意味がない。冒頭のRampは、これを「autonomous finance(自律ファイナンス)」と呼ぶ。鍵は、1つの万能AIではなく、調達やレシート処理など 役割ごとに分けた財務エージェントの群れ を、APIの無いサイトに走らせている点だ。

少人数のチームでこれを内製できたのは、まさに「AIに任せる量を絞る」設計があってこそだ。月に何百万件もの定型操作を回す規模では、毎回AIに判断させていてはコストも時間も持たない。決まった巡回はキャッシュで安く速く回し、サイトが変わったときだけAIが直す——この配分が、そのまま運用設計になる。

どこで使い、どこで使わないか

万能ではない。キャッシュが効かない「毎回違う操作」ばかりの用途では LLMコストが膨らむ。他社サイトの自動操作が 利用規約や法令に触れうる 点も、使う側の責任だ。繰り返す業務はStagehand、使い捨ての探索は純エージェント という住み分けが現実的だろう。

4つのプリミティブを、1つの流れで読む

最後に、4つのプリミティブと「下見してから繰り返す」流れを最小コードで見る。API名は公式リポジトリと公式ドキュメント(v3)に準拠する。同じことはPython版でも書ける。

import {
  Stagehand,
}
from "@browserbasehq/stagehand";
import {
  z,
}
from "zod"; // Zod = 欲しいデータの「形(型)」を宣言するライブラリ

const stagehand = new Stagehand({
  env: `BROWSERBASE`,
}); // クラウドブラウザで実行
await stagehand.init();

const page = stagehand.context.pages()[0];
await page.goto("https://github.com/browserbase");

// ① act():1つの操作を自然言語で指示する(= AIに任せる最小単位)
await stagehand.act("click on the stagehand repo");

// ② extract():ページから構造化データを取り出す。
//    z.object(...) で「欲しいデータの形」を宣言する。
//    describe(...) の文はAIへの説明書きで、宣言した型のまま結果が返る。
const { author, title } = await stagehand.extract(
  "extract the author and title of the latest PR",
  z.object({
    author: z.string().describe(`PR作成者のユーザー名`),
    title: z.string().describe(`PRのタイトル`),
  }),
);

// ③ observe()→act():まず操作できる要素を「下見」し、その結果を使って実行する。
//    下見の結果を繰り返し使えば、2回目以降はLLMを呼ばない(plan-then-execute)。
const actions = await stagehand.observe("find all the navigation links");
for (const action of actions) {
  // 記憶した要素が見つからない時だけ、AIが画面を見て探し直す(self-healing)。
  // 通常はLLM推論なしで実行されるので、速く低コスト。
  await stagehand.act(action);
}

// ④ agent():複数ステップのタスクを丸ごとエージェントに任せる(最も自律度が高い)
const agent = stagehand.agent();
await agent.execute("Get to the latest PR and summarize it");

act() から agent() へ進むほどAIに委ねる量が増える。なかでも observe() → act() の組み合わせが、本記事の中核「AIで下見し、繰り返しはコードで確実に」を体現する。StagehandはMITライセンスのOSSで、npx create-browser-app を実行すればすぐに試せる。

APIを待たずに、Webを操作する時代へ

Stagehandは、ブラウザ自動化の「壊れやすいコードか、予測不能なAIか」という二択を、委ねるAIの量を開発者が選べる設計 で終わらせた。あなたの職場にも、APIが無いというだけの理由で人手に頼る業務は、残っていないだろうか。

参考文献

1. Browserbase (Stagehand) 公式リポジトリ - GitHub: browserbase/stagehand: https://github.com/browserbase/stagehand
2. Stagehand 公式ドキュメント - Observe(observe()/act()・plan-then-execute・サーバ側キャッシュ): https://docs.stagehand.dev/basics/observe
3. Browserbase 公式事例 - How Ramp built its new finance agents(autonomous finance / Agent Identity): https://www.browserbase.com/blog/case-study-ramp
4. Browserbase 公式事例 - ShopVision(12億データポイント / fan-out): https://www.browserbase.com/blog/case-study-shopvision
5. Browserbase 公式事例 - How Amplitude transformed sales demos with browser automation: https://www.browserbase.com/blog/how-amplitude-transformed-sales-demos-with-browser-automation
6. Browserbase 公式事例 - Parcha(金融コンプライアンス審査の自動化): https://www.browserbase.com/blog/case-study-parcha
7. Browserbase 公式事例 - Vercel(社内Web/BIシステム Prism): https://www.browserbase.com/blog/case-study-vercel
8. Browser Use 公式リポジトリ(対比対象の完全自律型エージェント) - GitHub: browser-use/browser-use: https://github.com/browser-use/browser-use
9. Cloudflare 公式ブログ - Web Bot Auth(Agent Identity / 署名による正体証明): https://blog.cloudflare.com/web-bot-auth/