「AIファースト」ブラウザ自動化の舞台裏：TypeScriptフレームワーク「Stage Hand」開発で得た教訓

本記事では、AIファーストのブラウザ自動化フレームワーク「Stage Hand」をTypeScriptで構築する過程で得られた貴重な教訓について深掘りしていきます。Browserbaseが提供するStage Handは、AIによるWeb自動化を支援するために開発されました。私たちは、このフレームワーク開発を通じて、大きく3つの領域における教訓を得ました。

1. ブラウザ自動化フレームワークの構築に関する教訓
2. AIの状態変化を考慮したAIフレームワークの構築に関する教訓
3. 優れたTypeScriptフレームワークの構築に関する教訓

Browserbaseでは、AIがWebを自動化するのを支援しており、現在、数千もの顧客が実際にWebサイトとインタラクトできるAIエージェントを本番環境で運用しています。これらのAIエージェントは、フライトのチケット購入やレストラン予約のような派手な作業ではなく、例えばRFP（提案依頼書）が出ている政府契約の検索と提案書送付、奨学金やフードスタンプの申請支援、航空機用ネジの調査と調達といった、地味ながらもエンタープライズ領域で非常に実用的なユースケースに取り組んでいます。これらは、現在のAIが最も得意とする種類のソフトウェアです。

Browserbaseが提供するのは、主に以下の3点です。

• ブラウザインフラストラクチャ: クラウド上で動作するブラウザ、すなわち「Browser as a Service（サービスとしてのブラウザ）」を提供し、コードから接続できるようにしています。
• フレームワーク: Playwright、Puppeteer、Seleniumといったオープンソースのブラウザ自動化ライブラリが広く利用されていますが、私たちは独自のフレームワークである「Stage Hand」を開発しました。
• モデル連携機能: 様々なAIモデルをプラグインして、ブラウザを制御するためのコードを動的に生成する機能を提供しています。BrowserbaseはAIエージェントのためのブラウザツールであり、Stage Handはブラウザのためのコードインターフェースと言えるでしょう。

既存のブラウザ自動化フレームワークの課題と「Stage Hand」の登場

Puppeteer、Playwright、Seleniumといった既存のフレームワークは、主にフロントエンドアプリケーションのテスト目的で開発されてきました。一部ではWebスクレイピングや簡単な自動化にも応用されていますが、これらは本質的にはテストフレームワークです。

Stage Handは、こうした既存フレームワークとは一線を画し、「自動化ファースト」かつ「AIファースト」のアプローチを採用しています。ウェブサイトにアクセスし、自然言語でプロンプトを与えると、Stage Handがそれを実際のブラウザアクションに変換します。私たちはこれらの既存フレームワークを置き換えようとしているのではなく、自然言語を使ってウェブサイトを自動化するための補完ツールとしてStage Handを位置づけています。

自然言語を使用する最大の利点は、自己修復性です。ページのレイアウトや要素がわずかに変更された場合でも、Stage Handは大規模言語モデル（LLM）を使ってセレクターをその場で再生成できます。これにより、スクリプトが突然動作しなくなるという、これまでのブラウザ自動化で頻繁に発生していた問題に効果的に対処できます。

Stage Handの主な利点は以下の通りです。

• モデルに依存しない: LLM（大規模言語モデル）やVLM（視覚言語モデル）など、あらゆる種類のAIモデルと連携してウェブサイトを自動化できます。
• 自己修復性: ページの変更があっても自動的に適応し、スクリプトのメンテナンスコストを削減します。
• 開発者からの高い評価: その堅牢性と使いやすさから、多くの開発者や顧客から支持を得ています。

Stage Handの仕組み：自然言語からブラウザアクションへ

Stage Handは、自然言語の指示と、対象となるWebページの要素を組み合わせてブラウザアクションを実行します。そのプロセスは以下のようになります。

1. HTML解析とコンテキスト生成: フレームワークはWebページのHTMLを解析し、よりコンテキスト効率の良いバージョンに変換します。この際、「アクセシビリティツリー」のような構造を利用することが多いです。HTMLには余分なクラス名やFlexboxの指定などノイズが多いため、これらを取り除き、LLMに処理しやすい形で提供します。
2. LLMによる要素特定: LLMに「探しているボタンを見つけてほしい」といった指示を与えると、LLMはページ内の候補要素の中から、操作すべき適切な要素（例: 日付入力フィールド）を特定します。
3. アクションの決定: 特定された要素に対して、LLMは実行すべきコマンド（例: クリック、テキスト入力）を決定します。
4. セレクターの生成とキャッシュ: LLMの出力はCSSセレクターとなります。このセレクターはキャッシュ可能であり、初回のアクションで推論を行った後、ページのDOM（Document Object Model）の内容が変更されていない場合は、同じセレクターを再利用できます。この「LLMを用いてWebページとインタラクトするコードを生成し、その結果をキャッシュする」というアプローチは、再現性を高め、推論コストを削減するために非常に重要です。
5. ブラウザアクションの実行: 最後に、Stage Handは生成されたセレクターとアクションを用いてブラウザを制御します。この部分が最も技術的に困難であり、Chrome DevTools Protocol（CDP）の直接活用が鍵となります。

Stage Handは自然言語に対応しているため、日本語を含む多様な言語でプロンプトを与えることが可能です。これにより、これまでのフレームワークよりも大幅な国際化が進み、日本を含む多くの国で採用が広まっています。

Stage Hand開発から得た技術的な教訓：PlaywrightとCDPの選択

Stage Handの開発において、私たちは技術選定に関する重要な教訓を得ました。まず、Chrome DevTools Protocol（CDP）の利用は非常に高度な専門知識を要し、困難を伴うという認識がありました。実際、CDPのREADMEには「ブラウザ自動化のためにCDPを使う前に二度考えろ。Playwrightを使うべきだ」と明記されているほどです。

私たちはこの忠告に従い、Stage Handの初期バージョンはPlaywright上に構築しました。しかし、Playwrightにはいくつかの痛みを伴う制限がありました。特に「iframe（インラインフレーム）」や「Shadow DOM（シャドウDOM）」の扱いが容易ではなく、これらの要素が多く使われるWebサイトの自動化において課題に直面しました。これにより、Playwrightベースでは目標を達成できないと判断せざるを得ませんでした。

そこで、約1週間前にリリースされたStage Hand v3では、以前Playwright上に構築されていたStage Handを、Chrome DevTools Protocolに直接統合するという大きな方針転換を行いました。Playwrightを使った経験がある方ならご存知の通り、ブラウザ上での全てのアクションと1対1で互換性を持たせながらCDPに直接統合することは、非常に複雑で時間のかかる作業でした。しかし、この「ファーストプリンシプルズ（第一原理）」に基づくアプローチ、すなわちラッパーライブラリを介さずに基盤となるプロトコルを直接使用することで、より高いパフォーマンスと柔軟性を実現できることが証明されました。

まとめ

本記事では、AIファーストのブラウザ自動化フレームワーク「Stage Hand」をTypeScriptで構築する過程で得られた貴重な教訓について掘り下げてきました。既存のテストフレームワークとは一線を画し、自然言語による指示と大規模言語モデル（LLM）の力を借りて、より柔軟で自己修復性の高い自動化を実現するStage Handの革新的な仕組みをご覧いただきました。

特に、自然言語からCSSセレクターを生成し、これをキャッシュすることで推論コストを削減し、再現性を高めるアプローチは、今後のAIエージェント開発において重要な示唆を与えます。また、初期にはPlaywrightを利用しつつも、iframeやShadow DOMといった特定の課題に直面し、最終的にはChrome DevTools Protocolへの直接統合へと方針を転換した経験は、複雑な技術選定と挑戦がいかに重要であるかを物語っています。

Stage Handの進化は、単なるブラウザ自動化を超え、AIがウェブとより深く、より賢くインタラクトするための新たな道を切り開いています。これにより、国際的な開発者がより容易に、多様な言語でWeb自動化ソリューションを構築できるようになるでしょう。

---

参考動画

https://www.youtube.com/watch?v=PCNMoJhq_Go