Playwrightを2倍高速化し、トークン効率を80%改善した

We made Playwright 2x faster and 80% more token efficient

▲ 110wittydeveloper31 HNでの議論

BrowserbaseのStagehandは、Playwrightがテスト向けに設計されているのに対し、エージェント向けに作られたブラウザ自動化SDKだ。TypeScript、Python、Goの3言語に対応し、自然言語によるact、observe、extractでサイトの変更に自己修復しながらデータを抽出する。ハイブリッドなアクセシビリティツリーの刈り込みでトークン効率を高め、ブラウザ隣接の拡張として動作することでラウンドトリップ遅延を削減。Browserbase上ではPlaywrightのクラウド相当より2倍高速に実行できる。

Playwrightはテストのために作られた。Stagehandはエージェントのために作られ、TypeScript、Python、Goで提供される。
原文を読む →HNでの議論RSS

HNでの議論

31
  1. throw03172019

    これは顧客のコンピュータ上でのブラウザ自動化に使えますか？唯一目立つ問題は、LLM用のAPIトークンが露出してしまうことだと思います。

  2. wittydeveloper

    私たちは2年前にStagehandを作り（24kスター、月間npmダウンロード数4M）、最近その最大の欠陥を修正しました。それはラウンドトリップのレイテンシです。

    実行されるすべてのアクションには、スクリプトとブラウザの間のラウンドトリップが必要です（ローカルで実行しているときは短いですが、クラウドで実行すると増加します）。また、Playwright MCPのトークン消費の激しさに不満を述べる投稿も複数見かけました。

    そのため、私たちはStagehandをゼロから作り直し、v4をリリースしました。v4では、ブラウザ起動時に自動的に読み込まれる拡張機能からStagehandがブラウザを制御します。

    Stagehand v4にはバッチコマンドのサポート、トークン効率に特化したメソッド`act()`と`extract()`、そしてPlaywrightより2倍高速でトークン効率が80%向上するまったく新しいアーキテクチャが搭載されています。

    十数種類のモデル（フロンティアとオープンウェイト）とツール（Codex、Claude Codeなど）にわたる性能を比較したベンチマークで、ぜひご自身で確かめてみてください: https://www.stagehand.dev/evals

    何でも聞いてください！

  3. ulrikrasmussen

    とても便利そうですし、キャッシュのアイデアは自己修復型のCIテストに面白いと思います。

    キャッシュされたact()がいつ失敗し、LLMによる再評価が必要になるかをどう判断するのですか？特に、キャッシュがクラウド（Browserbase？）に保存される場合、サイトの異なるバージョンが同じキャッシュに対して実行されるCIパイプラインで使うと、キャッシュの入れ替わりが大量に発生しませんか？

    また、キャッシュをBrowserbaseが提供するのではなく、スクリプトと一緒にチェックインされる単なるローカルファイルにできない技術的な理由はあるのですか？もしそうできれば、開発者はLLM呼び出しを使ってローカルで失敗したテストを修復しつつ、CIは完全に決定論的に実行できます。

  4. yread

    cypress向けにこのようなものはありますか？

  5. tengkahwee

    一般的なエージェントベースの検証作業には、agent-browserよりもこれを使うことを勧めますか？何かパフォーマンス上の利点はありますか？

この日のほかの記事

2026-09-19