ボリス・スクリキンは、現代のソフトウェア向けに構築されたAI駆動のウェブテストプラットフォームDocketの共同創業者である。
自動化されたソフトウェアテストにおける一般的な誤解は、ドキュメントオブジェクトモデル（DOM）がウェブアプリケーションと対話する最良の方法だという考えだ。しかし、ほとんどのフロントエンドが過度に複雑なDOMと数メガバイトのランタイムロジックから継ぎ合わされている現在、この方法はあまり役に立たない。
AI支援の開発者の群れによって書かれる機会が増えているソフトウェアの品質保証は、シリコンバレーで最も注目されているトピックの一つとなっている。これはLLMブームと2025年のバイブコード流行の核心的な影響だ。かつては熟練したエンジニアによって行われる神秘的な魔術と見なされていたものが、今ではWindsurf、Claude Code、Lovableなどのツールから日常的に生成されるようになった。
諸刃の剣
アンクル・ベンが最も適切に言ったように：「大いなる力には大いなる責任が伴う」。これは、意欲的な開発者がAI生成コードを、社会的、金融的、医療的ニーズのためにこれらのプラットフォームに依存しているユーザーに提供する場合ほど真実ではない。AIは役立つが、完璧なコードを生成するわけではない。実際、LLMは思慮深い人間の開発者よりも高い確率でミスを犯す。今日、AIでコードを書くことは諸刃の剣だ。
その刃はテストにおいて最も深く切り込む。バイブコーディングされたアプリはブラウザでは機能しているように見えるかもしれないが、その基盤となるコードは多くの場合、膨大で無秩序で保守が難しい。私はよく、何千もの深くネストされた非標準的な要素を含むDOMツリーを目にする。ドキュメントもなく、仕様もなく、明確な意図もない—ただ不透明なマークアップが大量のスクリプトで接着されているだけだ。（ホーマー・シンプソンが洗濯バサミで自分自身をつなぎ合わせているシーンを思い浮かべてほしい。）
ブラウザの表面下
多くの「AIネイティブ」ブラウザ自動化ツールは、DOMが信頼できる真実の源であるという時代遅れの考えにまだしがみついている。それは2010年の手書きのウェブアプリには機能したかもしれないが、今日のAI生成UI、縮小化されたJavaScriptランタイム、「<canvas>」レンダリング、Flutterのようなフレームワークではあまり信頼できなくなっている。
データがサーバーからブラウザへ、コンテキストウィンドウへ、そして最終的にLLMへと流れるにつれて、各ステップで詳細と忠実性が失われていく：私はこれを損失連鎖と呼んでいる。エージェントが行動する頃には、それは実際に画面上にあるものともはや一致しない抽象化に基づいて作業している。
DOM要素は完全にレンダリングされたUIのようには動作しない。クリックハンドラが縮小化されたコードに埋もれているログインボタンであるはずの正しい「<div>」を見つけようとしてみてほしい。それにより自動化ツールが何をクリックすべきかを知ることが難しくなり、アプリがグラフィックやキャンバスベースのインターフェースに依存している場合、テストツールは推測作業に陥ってしまう。
真実の源としてのビジョン
私は今年の初めからブラウザエージェント、テストフレームワーク、ビジョンモデルを専念して研究してきた。この集中的な焦点は偶然ではない—それは私のスタートアップの主要な構成要素だ。以前、リグレッションを検出するプロジェクトでソフトウェアエンジニアとして働いていた経験から、従来のアプローチの限界を直接見てきた。また、ブラウザ自動化分野で働く他の創業者たちと会い、まさにこれらの課題について議論する機会も得た。
これに基づいて、私は解決策はコンピュータビジョンだと考えている：自動化ツールに目と手（スクリーンショットと仮想周辺機器）を装備することだ。これにより、AIが抽象化ではなく、実際にブラウザにレンダリングされているものに基づいて行動できるため、損失連鎖を完全に回避できる。
AIエージェントは、DOMツリーに埋もれたボタンを推測するよりも、実際に見えるログインボタンをクリックする方がより効果的だ。現代のバイブコーディングされたアプリでは、マークアップではなく、レンダリングされた画面こそが真実の源泉である。
ビジョンベーステストのトレードオフ
確かに、ビジョンベースのテストはまだDOMベースのフレームワークよりも遅く、高価で、成熟度が低い。しかし、それは急速に変化している。ビジョンモデルはより高速になり、推論コストは下がり、ByteDanceのUI-TARSのようなオープンウェイトの競合者はAnthropicのCUAにすでに挑戦している。
では、これらのトレードオフが最も重要になるのはいつだろうか？
読み取りが多いワークフロー（テキスト取り込み、スクレイピング、研究など）のプロジェクトでは、DOMベースのフレームワークがまだ良い選択であることが多い。ビジョンモデルはテキスト理解のために光学文字認識（OCR）とLLMの推論に依存しているため、小さなフォントで苦戦したり、プレースホルダーやURLやハッシュのような長い無意味な文字列を誤認識したりすることがある。また、ビューポートのスクリーンショット以外のコンテキストがないと、テキストを伴わないアイコンやボタンを誤解釈することもある。
一方、ビジョンモデルはウェブページとの多くの対話を必要とする書き込みが多いタスクに優れている。私の経験では、キャンバス、iframe、スクロール可能なコンテナ、ドラッグアンドドロップアクション、非標準の入力コンポーネントなどの処理に優れている。デザインツールやゲームなどのアプリケーションをテストしている場合、ビジュアルアプローチは追加のコストと時間の価値があるかもしれない。
「見る」ツールの構築
コンピュータの使用は本質的に視覚的だ。私たちは人間が見て、マウスとキーボードを使って対話するためのインターフェースを設計している。AIが脳であることを目指すなら、目と手が必要だ。バイブコードの時代には、DOM形式の世界観に自分自身を閉じ込めないでほしい。見ることができるツールを構築しよう。
