Sentry ハックウィークの舞台裏　壊すための口実

 

大まかには、Gremlins はシンプルな手順に従います。

1. ユーザーが対象サイトを設定し、必要に応じてエージェント設定を追加する
2. エージェント（群）をサイトに放つ
3. Gremlins があぶり出したエラーを Sentry が捕捉する

 

設定は軽量で、ユーザーは次の項目を指定できます。

• 対象サイト
• 任意のテスト指示（例：「設定ページを壊してみて」）
• 認証情報
• Gremlins の数 など

 

 

エージェントの構築

私たちは、次の2種類のエージェントで実験しました。

1. Claude、Playwright、ARIA summaries を用いた自前実装
2. browser-use と ChatGPT を用いた実装

 

自作エージェント

Web エージェントのコアループは、驚くほどシンプルでした。

要点としては、次のとおりです。

1. ページの状態をテキスト表現に変換する
2. それをユーザーの発話として会話履歴に追加する
3. 会話履歴をプロンプトとして LLM に与える
4. LLM の応答を会話履歴に追加する
5. 各ツール使用要求について
   1. そのツールを実行する
   2. 結果を会話履歴に追加する
6. 繰り返す

このシンプルさは、LLMの中核的なイノベーションの一つを物語っています。単一のAPIで多くの課題に容易に対応できるのです。LLMという強力な「ハンマー」を手にしたことで、多くの問題が「釘」のように見えてくるのです。

テキスト表現

私たちは、ページのテキスト表現を作るために ARIA を活用しました。Playwright の ariaSnapshot() と ARIA によって、たとえば Sentry のロゴのような要素を次のように変換します。

使える YAML データへの変換します。

この方法により、私たちの Gremlins は HTML のノイズを切り抜け、ページ上のインタラクティブ要素を最小限の表現で LLM に渡せるようになりました。LLM はその情報を使って「次に何をするか」を判断しますが、実際に相互作用するためには…

ツール

LLM がプレーンテキストを入出力する巨大な「ハンマー」だとすれば、「ツール」は、LLM にとっての選択肢付きのアドベンチャーゲーム、いわばゲームブックのような存在です。

LLM プロバイダーがツールを直接実行する場合もあれば、API リクエストでツールのリストを定義して、ローカルでリクエストを処理することもできます。

LLM はツール呼び出しのリクエストで応答し、あなたのコードがそれを実行して結果を記録し、ループを続行します。

Gremlins では、新しいツールを簡単に定義・検証・実行できるようにする小さなフレームワークを作りました。例えば、次のとおりです。

ARIA スナップショットとカスタムツールにより、雑然としたウェブページをモデルが推論できる構造化テキストへ変換し、その推論に基づいてクリック・入力・遷移を実行することで、実際のユーザー（Gremlins）のように動作させることができました。

Thinking（思考型） vs. Prefilled Responses（事前入力型）

この過程で、LLM のレスポンスに対して一部をあらかじめ入力しておく方法を学びました。ユーザーのプロンプトに加えて、期待されるレスポンスの冒頭（プレフィックス）も与えるのです。たとえば、次のような質問をLLMに提示する場合です。

次のようなレスポンスを返す傾向があります。

これはパースが難しいです。レスポンスを「(」で事前入力しておくことで、エージェントが最初に数値から返す可能性を高められます。

当初は大いに役立ちましたが、最終的には次の方針に切り替えました。

• 「Thinking」モデルの採用（Prefilled Responses との併用が難しい）
• 会話そのものを直接パースしようとするのではなく、ツールの活用

browser-use はどのように比較できるか

browser-use は、Web エージェント向けのオープンソース解として最も人気があるように見えます。立ち上げ自体はかなり簡単でしたが、o4-mini を使用した際に初期の時点でいくつかの痛点に直面しました。まずは良かった点からご紹介します。

良かった点

browser-use エージェントによるナビゲーションは、ほとんど素の状態でも驚くほど安定して動作しました。いくつかのガードレールと根気、そして丁寧なプロンプトを与えることで、認証ページを突破し、サイト内のさまざまな領域を探索できました。

キャプチャ（hehe）を除けば、私たちが設定した認証済みページのほとんどを問題なく探索できています。エラーを引き起こすために、サポートメールの送信、ビルド実行のトリガー、各種ウェイトリストへの登録なども試みました。

課題

課題1：正しいウェブページでブラウザを起動すること

サンプルやドキュメントでは、エージェントに最初に「{url} にアクセスして…」と平易な英語で指示すればよいと示されていますが、私たちの環境では成功率は約60％で、それ以外は壊れた Chromium ウィンドウが開いてしまいました。

これについては、開始時に手動で playwright.chromium のインスタンスを作成し、正しいURLを設定してから、そのブラウザを使って BrowserSession を生成することで修正しました。

なお、browser-use の fast-agent サンプルで試したところ、OpenAI と比べて GroqLLM を使うほうが、ブラウザのセットアップを正しく行える信頼性が高まるように感じました。

課題2：高いリソース使用量とメモリリーク

私たちが構築した browser-use のエージェントは、かなりのメモリと多くのCPUを消費します。このプロジェクトは複数エージェントの同時実行を想定していますが、Apple M1 Max でも同時に4体以上を起動すると、コンピュータが実質的に動作不能になってしまいました。

また、エージェントの終了（de-spawn）時にメモリリークが発生しており、いくつか対処を試みたものの、ほぼ確実に再現されました。各プロセスのメモリ使用量が大きいため、リークが急速に蓄積してしまいます。

課題3：依然として十分に洗練されていない

ハックウィーク期間中、「browser-use」は自作のソリューションと比較して、明確に優れているとは言い難い結果となりました。

両者とも、以下のような問題に頻繁に直面しました。

• きわめて明確な指示にもかかわらず、ユーザー名フィールドにパスワードを入力しようとし、その後の試行でようやく成功することが多い
• ランダムなモーダルで、かなりの時間スタックする
• さまざまなサイトへのサインアップを促した際、利用規約を開いて全文を読もうとしてスタックし、無視するように異なるプロンプトを与えても抜け出せない

 

UI の構築 — ウェブ同期の「みにくいアヒルの子」（SSE）

最後に、これらすべてのデータ（スクリーンショット、報告された問題、トークン数、興味深いやり取りのログ）を UI に取り込む方法が必要になりました。これにはポーリングと Server-Sent Events（SSE）を組み合わせて使いました。

SSE は、ウェブエコシステムでもっとも軽視されがちな領域のひとつです。誰に聞くかによりますが、SSE は「時代を先取りしすぎたアイデア」（<canvas> と同時期の 2005 年頃に策定）とも、「とてつもなく厄介な仕組み」とも言われます。

概念的には、SSE は WebSockets のようなものだと考えてください（サーバーとクライアントの間で任意の順序付きデータを送る長寿命の接続）が、重要な制約がひとつあります。一方向、つまりサーバー → クライアントのみなのです。実際のところ、SSE は HTTP 上に構築された、巧妙な段階的フォールバック（graceful degradation）的なハックです。サーバーは通常の HTTP 応答と同様の挙動を保ちつつも、接続を切断せずに数秒、数分、あるいは数時間にわたってテキストベースのイベントを継続的に送り続けることができます。ただし、この特性が原因で、「ワーカースレッドやプロセスが同時に 1 リクエストしか処理できない」タイプのウェブサーバーでは、多くの問題が発生する可能性があります。

ここまで読んで「SSE は WebSockets の下位互換では？」と感じた方もいるかもしれません。

その通りです。実際、多くの場面で、かつてはポーリングや SSE を用いていた用途でも、現在であれば WebSockets を選ぶのが一般的でしょう。しかし最近では、Model Context Protocol（MCP）の登場により、SSE が一時的に再評価されました。短期間ではありますが、MCP によって SSE がトランスポート機構（通信方式）として標準的に採用されていたためです。

SSE にも問題がなかったわけではありません（例：6 タブ制限）が、多数のイベントをフロントエンドに大量のイベントをストリーミングするという手法は、データ量の多いライブ UI を迅速に構築する上で非常に有効でした。

考察

わずか数日間の作業でしたが、私たちの自家製の「ARIA × Claude」エージェントは、browser-use エージェントと比べても良好に動作しました。具体的にはパフォーマンスが高く、より多くのエージェントを並行起動できたため、テストカバレッジを拡大することができました。

以下が私たちが学んだ点です。

• トラフィックの多いサイトは非常に強力なボット検知を備えています。私たちのどちらのボットも CAPTCHA を処理できず、中には即座にブロックしてくるサイトもありました。のちに、browser-use 側の回避策を見つけ、Reddit のような最も制限の厳しいサイトであってもクロールできるようになりました。
  
  
• 大きな自律性には、大きな（セキュリティ上の）責任が伴います。信頼できるサイトに対してボットのアクセス制限を緩めるにつれ、Anthropic の Claude for Chrome のリリースで論じられている注意事項の重要性を実感しました。プロンプトインジェクションのリスクは現実的です。開発者はブラウザ内で AI エージェントが何を見て何ができるのかを把握し、本番サイトと自律エージェントを相互作用させる際の安全策を講じることが不可欠です。
  
  

• エージェントにランダムな挙動を取らせるのは、想定以上に困難でした。「アクションをランダムに選択してください」と明示的に指示していても、複数のエージェントを並列に実行すると、同じアクションを選び、似たようなページを優先する傾向が見られたのです。そこで、モデルの温度（temperature）を調整したり、別の Web エージェントによって生成されたサイトマップから、インスタンスごとに異なる開始ページ（例：/settings や /issues）を与えたりといった工夫を行いました。その結果、一定の改善は得られたものの、さらなる改善の余地があるのは明らかです。
  
  

• 最後に、LLM は“キャラを演じ切る”のがかなり得意です。私たち自身が楽しめるように、Gremlins には少し個性を持たせました。

 

その結果、愉快な会話や興味深いテキスト入力がいくつか生成されました。他にもいろいろありますが、その一部を以下に紹介します。

 

Gremlins の実演動画は、以下 ハックウィークの提出物からご覧いただけます。