Jev Ultrafast - DOM要素表と操作別の対象選択で動くブラウザーエージェント

自然言語の目標からブラウザーを動かす処理を考えるとき、JevのREADMEが改善点として挙げるのは、判断の通信回数、ページ観測のブラウザープロトコル呼び出し、実行前の対象検証である。この説明から、主要な課題は推論の待ち時間だけでなく、観測処理の負担と、観測後にページが変わることによる対象ずれにもあると読める。

操作を決めてから別の通信で対象を決めるなら、判断サイクルに通信待ちが重なる。観測でもコントロールの情報を繰り返し取得すれば、モデル以外の処理が増える。さらに、観測時に見えていた対象が実行時には変化したり、別の要素に覆われたりする。Jevはこの三つを、判断のまとめ方、DOMの読み方、実行直前の検証という異なる箇所で扱おうとしている。

READMEが対比するのは、サイト専用の操作スクリプト、準備済みの入力文字列、スクリーンショットによる観測である。Jevのポリシーにはサイト専用スクリプトや準備済み文字列がなく、通常の判断ループもスクリーンショットを使わないと説明されている。代わりに、その時点のページから操作対象を構造化し、必要な入力値だけを生成する。

この対比は設計を理解するための軸であり、特定の既存製品について検証した比較ではない。固定スクリプトによる自動化を置き換えられる範囲や、画像観測より優れるページの条件まで確定しているわけではない。まず押さえるべき前提は、Jevの判断材料と操作範囲が、読み取れるDOMコントロールに依存することだ。

リポジトリは2026年9月16日に作成され、取得データでは10月6日時点で22,107スター、1,595フォークを記録している。新しいブラウザーエージェントとして注目を集めていることは読み取れるが、この数値は公開日の10月9日時点のものではない。

発見データの実際の取得元はgithub_search_recentで、当日のスター増加数やTrending掲載順位は確定できない。短期間の増加速度を断定する材料にもならない。技術的に掘り下げる理由は、注目数に加えて、要素表、対象選択、文字列生成、実行前検証という処理構造がREADMEに具体的に示されている点にある。

実行の入口は、開始URLと自然言語の目標を受け取るAgentだ。ChromeにはBrowser Harness経由で接続する。READMEによれば、観測では一度のブラウザー呼び出しで可視コントロールの名前、値、テキストをまとめて読み、番号付きの要素表と実DOMノードへの参照を保持する。表は観測ごとに更新されるため、番号はその観測状態の対象を表すものとして理解する必要がある。

通常のループはこの構造化状態を使い、画面外の本文やフッターをモデル文脈へ入れない。ページ全体の画像から操作位置を判断する構成とは、観測の表現が異なる。モデルへ渡す情報を可視の操作対象へ絞ることと、ブラウザー側で実ノードへの対応を保持することが、後続の選択と実行をつなぐ。

READMEのファイル案内では、snapshot.jsがDOMの一括観測、番号付きコントロール、鮮度ガードを担う。これは責務の説明であり、その実装本文は今回の取得資料に含まれていない。

次に、観測状態から利用可能な操作と、その操作に対応する対象候補を構成する。操作集合はCLICK、TYPE_TEXT、SELECT、SCROLL_UP、SCROLL_DOWN、WAIT、DONE、BLOCKEDだ。対象側にはclick_target、type_text_target、必要に応じてselect_targetがあり、それぞれ互換性のある要素だけを候補に含めると説明されている。

TypeSafeへの一度のリクエストでは、operationと操作別のtargetを同じ観測状態から判断する。返された対象をすべて実行するわけではない。選ばれた操作がCLICKならclick_targetを採用し、他の操作に対応する対象は実行に使わない。ネイティブの選択肢には、観測した要素と選択肢の番号を使う。

この構成の要点は、操作と対象を別々の通信で決める待ちを避けつつ、対象候補を操作の種類に合わせて制限することだ。model.pyは動的な操作・対象ヘッドと文字列生成、questions.pyはモデル指示を担うとREADMEに示されている。ただし、互換性の制約を実装上どう保証するかまでは確認できていない。

操作がTYPE_TEXTなら、別の小型LLMへ入力値を生成させる。操作と対象の判断に使うTypeSafeと、入力文字列を作るテキストヘルパーは別の役割だ。したがって「一度の通信」は操作・対象選択についての説明であり、文字入力の実行までに必要な全API通信が常に一回という意味ではない。

READMEによれば、ヘルパーの出力は小さなJSONオブジェクトとして解析してから入力に使う。モデル出力をセレクター、座標、シェルコマンド、実行可能なJavaScriptへ変換しないとも説明されている。操作先は観測済みの候補から選び、生成した文章は入力値として扱うという境界がある。

ページが古くなって再試行する場合でも、生成値を無条件には使い回さない。テキストヘルパーへの入力全体が変わらない場合だけ再利用する。agent.pyは判断ループ全体とヘルパーへの受け渡しを担うとされ、この分離が再試行時の文字生成にも関わっている。

対象を選んだ後には、ページの鮮度と対象の状態を再確認する段階がある。READMEのクリック処理の説明では、文書、フォーム値、対象、周辺文脈を検証し、観測済みノードから対象を解決して現在の位置を求める。覆われたコントロールへの入力は拒否する。観測した表から選べたという理由だけでは、そのまま操作しない構成だ。

ここで扱うのは、観測時の情報と実行時のページの間にあるずれである。対象候補の互換性を制限する処理とは役割が違う。前者は判断に渡す候補を絞り、実行前検証は、その候補が現在も意図した操作先として使えるかを確かめる。browser.pyはブラウザー接続、現在の対象位置、操作実行を担うと案内されている。

ただし、鮮度判定や再試行条件の具体的な実装は未確認だ。モデル出力を実行コードにしないという境界も、包括的な安全性やプロンプトインジェクション耐性を証明するものではない。

操作を記録した後、コンボボックスへの入力では可視候補を最大200 ms待つ。その他の操作では最大2アニメーションフレームまたは50 ms待ち、次の観測へ進むとREADMEは説明している。操作、必要な状態の待機、要素表の更新を繰り返す流れであり、この待機時間だけであらゆるページの読み込み完了を保証するという説明ではない。

ループがDONEを選んでも、結果は独立して検証する必要がある。Flightsの例では、実際の片道設定、出発地、到着地、日付、フライト候補の表示を確認し、トレースを保存するとされる。フライトの選択や予約は行わない。終了判断と目標条件の確認を分けることが、この例を理解するうえで重要だ。

Pythonの使用例では、コンテキストマネージャー内でAgent.run()を反復し、elapsed_msとstatusを読む。実行状態を取得する入口は示されているが、それを読むこと自体が目標達成の検証になるわけではない。

適していると考えられるのは、一般的なHTML・ARIAコントロールで構成されたページで、検索、入力、選択を自然言語の目標から試す自動化の試作だ。ローカルインスペクターには番号付き要素、操作確率、対象確率、実行済み操作が表示され、Choose nextで実行前に停止できると説明されている。demo.pyがこの表示を担う。

対象選択を見ながら止める機能と、Pythonから状態を取得する入口は、判断を調べる開発に向く。CLIのuv run jevからインスペクターを使い、Agentをスクリプトへ組み込むという二つの利用形態が示されている。

固定したサイト別スクリプトとの比較では、Jevは観測ごとの候補選択と入力値生成を試す選択肢になる。ただし、既存の自動化を全面的に置き換える根拠はない。結果検証を用意し、対応範囲内で判断を調べる実験として補完的に使う位置づけが妥当だ。

DOM readerは一般的なHTML・ARIAコントロールを扱うが、アクセシブルネーム仕様全体には対応していない。Shadow roots、frames、canvas、ファイルアップロード、ポップアップタブ、入れ子のスクロール、任意のキーボード操作ウィジェットはMVPの対象外だ。これらが必要なページでは、通常のコントロールを扱えるという説明を広げて適用できない。

画像観測との対比も、この範囲を含めて読む必要がある。スクリーンショットを使わないことはJevの観測方式の特徴だが、視覚的なUIを含むあらゆるページで同じ操作能力が得られるという証拠ではない。DONEをそのまま成功扱いする自動処理も不適切だ。必要な結果条件を別に確認できるかが、導入判断の前提になる。

作者はGoogle Flights動画のタスク実行時間を7,073 msと報告している。計時は初回ページ観測後からで、モデル呼び出し、文字列生成、ブラウザー処理、古くなった判断、読み込み待ちを含む。初回観測前の時間は含まれず、指定条件と候補表示の確認も作者側の報告である。

別の比較では、同一モデル・設定、同一タスク、同一ブラウザープロファイルで二つのバージョンを交互に計6回実行し、各3回とも成功したとしている。作者によれば、タスク時間中央値は9.450秒から7.092秒へ約25%減り、ブラウザープロトコル呼び出し数の中央値は1,092から101へ減った。

観測処理の負担を検討する材料にはなるが、比較バージョンの識別情報と詳細条件は取得READMEにない。1タスク、各3回の結果から一般的な成功率や信頼性は判断できない。製品間の最速という主張や、再現可能な費用優位性を裏付ける比較でもない。

公開手順ではTYPESAFE_API_KEYとTEXT_MODEL_API_KEYを設定する。テキスト用の設定例はOpenRouterを使い、現行デモはinception/mercury-2.5をreasoning無効で利用する。READMEはGemini、GLM、DeepSeekもOpenAI互換ヘルパーで利用可能と説明しているが、操作判断には別途TypeSafeが関わる。ローカルChromeを使う構成でも、外部APIなしで完結する手順ではない。

ライブ例と録画スクリプトは有料APIを呼ぶ。料金や費用比較の測定値は取得資料になく、外部APIへの送信内容や認証条件も追加確認が必要だ。Chromeにはリモートデバッグ許可が必要で、管理するタブは既存のChromeプロファイルを共有する。専用プロファイルへの隔離やログイン状態の扱いは確認できていない。

OS別の対応、APIの成熟度、幅広いサイトでの本番信頼性についても判断材料が不足する。試作から継続運用へ進めるには、速度だけでなく、必要なコントロールへの対応、結果検証、プロファイルの扱い、API費用を確認する必要がある。