【Browser Automation × AI】 Stagehandを試してみよう

2026/03/12開催 第142回NearMe技術勉強会 資料

「UI変更でスクリプトがすぐ壊れる（Playwright等）」
「AIエージェントに任せると挙動が制御不能でデバッグできない」
そんな従来のブラウザ自動化のジレンマを解決するオープンソースフレームワーク「Stagehand」の検証・実践レポートです。

命令型の確実性とLLMの柔軟性をいいとこ取りしたアーキテクチャや、主要なAPI（act, extract, observe, agent）の使い方を解説。さらに、トークン消費を抑えるCDP（Chrome DevTools Protocol）の活用やキャッシュの仕組み、セキュリティ対策についても触れています。

#Stagehand #E2E #テスト自動化 #Playwright #AI #QA #LLM #NearMe

Transcript

1. 0 【Browser Automation × AI】 Stagehandを試してみよう 2026-03-12 第142回NearMe技術勉強会 Ryo Omori
2. 1 従来のBrowser Automationの苦しみ 1. 命令型：壊れやすい (Too Brittle) • Playwright / Puppeteer など 命令型 • サイト UIが変わるとスクリプトが動かなくなる • セレクタ 修正に追われる 2. AIエージェント型：自由奔放すぎる (Too Agentic) • プロンプト みで動く自律型エージェント • 挙動が予測しずらい • 失敗した時 デバッグが不可能 「壊れやすいスクリプト」と「制御不能な AI」 板挟みになっている。
3. 2 Stagehand とは？ 命令型 「確実性」 × LLM 「柔軟性」 壊れやすい部分 だけをAIに任せる
4. 3 Stagehand とは？ 1. AIとコード 自由な使い分け • コードを書く : 操作対象が明確で、100%確実な挙動が必要なとき • AIを使う: 未知 ページや、UIが複雑でナビゲーションが面倒なとき • メリット: 「AIに丸投げ」で なく、エンジニアが主導権を握ったまま自動化できる 2. 機能的役割 による要素特定 • Before : CSS/XPathなど 「構造・実装」に依存 • After : 「ログインボタン」という「意味・役割」で特定 • メリット : UI変更しても自己修復する 3. キャッシュによる実行時最適化 • 初回 実行 : AIが最適な操作方法を推論しセレクタやアクションをキャッシュ • 2回目以降 : キャッシュされたセレクタでPlaywrightとして動作 • メリット : AI 柔軟性を持ちつつ、安定した動作とコスト節約を実現
5. 4 Stagehand とは？ • act：「実行する」 （クリック、入力、選択） • extract：「抽出する」 （構造化データ 取得） • observe：「観察する」 （現在 状態や要素 特定） • agent：「任せる」 （ゴールに向けた自律的な推論と実行）
6. 5 Stagehand とは？ act : 指示ベース アクション 従来： Stagehand： メリット： セレクタ、スクロール、待機、すべてAIとCDPが自動でハンドリング。
7. 6 Stagehand とは？ extract : 構造化データ 抽出 従来： DOMをパースして、ループで回して、オブジェクトに詰め替える。 Stagehand： メリット： 複雑なDOM構造を解析する必要なし。Zodで型安全なデータが即座に手に入る。
8. 7 Stagehand とは？ observe : アクション可能な要素 発見 従来： Stagehand： メリット： 上記例より複雑なアサーションをシンプルに
9. 8 Stagehand とは？ agent : 複雑なタスクを agentに任せる Stagehand： act 「1つ ステップ」を指示する。 agent 「ゴール」を指示する。
10. 9 実演 ```bash git clone git@github.com:majent/my-stagehand-app.git cd my-stagehand-app npm install cp .env.example .env && nano .env # Add ANTHROPIC_API_KEY npx tsx test/agent.ts ```
11. 10 ページ情報をどのようにLLMに渡しているか CDP(Chrome DevTools Protocol) Accessibility.getFullAXTree でアクセシビリティツリーを取得。情報削ぎ落とし操作可能な要素を抽 出 CDP DOM.getDocument で DOM構造を取得 AXTreeだけで 不足する情報を補うため、 DOMから必要なエッセンス だけを抽出して AXTreeにマージ。 IDでLLMとやり取りする。 参考: https://www.browserbase.com/blog/taming-iframes-a-stagehand-update
12. 11 LLMの実⾏からブラウザ操作の流れ 参考: https://www.browserbase.com/blog/stagehand-v3 Context Building： 前ページ 最適化された構造と命令（act）をプロンプトに統合 LLM Reasoning： 「こ ボタン（ID: 42）がログインボタンだ」と判断し、次にすべきアクションを決定。 そ 要素を指し示す**「頑丈な一時的セレクタ（XPath等）」**を生成して返します。 Execution： • Chrome DevTools Protocol (CDP) を直接叩き、クリックや入力を実行 V2で Playwrightに依存していたが、V3で CDPを直接実行することでPlaywrightへ 依存が減りパフォー マンスが44%改善したと こと。
13. 12 キャッシュと再学習 参考: https://www.browserbase.com/blog/stagehand-caching 初回実行時 指示 テキストとそ 時 DOM 状態を組み合わせたキャッシュを生成 1. 機能的役割 による要素特定 • 2回目以降 AIを呼 ずに「普通 Playwright（的な動作）」として動く
14. 13 セキュリティ 1. variables LLM Providerへ 共有されないため、氏名やパスワードに variablesを使う 2. HTMLをそ まま送信するわけで ない 前述 通り AXTree + DOM 必要な属性だけをLLMに送信する 3. LLM Provider 選定。契約・設定 見直し AWS Bedrock、Google Vertex AIなど マネージドなサービス 利用 Ollamaなど ローカルLLM 利用 4. そもそもテストに顧客情報を利用しない
15. 14 コスト⾯ 1. トークン消費 最適化 前述 通り AXTree + DOM 必要な属性だけをLLMに送信することでHTMLそ ままと比較して80%節 約 2. LLM 利用 初回だけ 初回成功したらそ パターンをキャッシュに保存。次回以降LLM推論なしでキャッシュから通常 スクリプ トとして実行される 3. Browserbase 料金体系 Stagehand自体 オープンソースで、Browserbase 実行環境を提供するクラウドサービス • Free ($0)： 月1時間、1台 • Developer ($20)： 月100時間、並列25台 • Startup ($99)： 月500時間、並列100台 • Scale (要問合せ)： 250台以上 並列実行と、SSOやHIPAA等 https://www.browserbase.com/pricing
16. 18 Thank you