Webサイトの品質チェックにLighthouseを使っている開発者は多いはずです。LCP（最大コンテンツ描画時間）やARIAラベルの欠落など、DOM構造やパフォーマンス指標は自動で測定できます。
ただし「CTA（行動喚起）ボタンが背景グラデーションに埋もれて見えない」といった視覚的な問題は、こうした指標には表れません。この種の課題は、実装が正しくても発生する見た目の問題だからです。
この視覚的なUX課題を、マルチモーダルビジョンモデル（画像とテキストを同時に扱えるAIモデル）で自動検出する試みが、オープンソースのVisual CROエンジンとして公開されています。CRO（Conversion Rate Optimization、コンバージョン率最適化）の文脈で、画面のどこに問題があるかを座標付きで指摘する仕組みです。フロントエンド開発者にとって、既存の自動テストパイプラインに何を追加すべきかを考える材料になります。
何を解決しようとしているのか
この仕組みが狙うのは「機能的には正しいが、視覚的に伝わらないUI」の検出です。
たとえば価格表に5種類のバッジ色が競合していて認知負荷が高い、サインアップフォームでパスワード要件が隠れていて離脱を誘発する、といった問題です。これらはHTML的には妥当でもユーザー体験を損ないます。
従来の自動テストツールがカバーする範囲と、視覚的なUX診断がカバーする範囲は明確に分かれています。両者は競合するものではなく、補完関係にあると捉えるのが妥当です。
| 観点 | Lighthouse等の従来型ツール | Visual CRO（画像診断型） |
|---|---|---|
| 測定対象 | DOM構造・パフォーマンス数値 | スクリーンショット上の視覚要素 |
| 検出例 | LCP遅延・ARIA欠落・画像サイズ未指定 | コントラスト不足・視覚的混乱・信頼性シグナル欠如 |
| 出力形式 | 数値スコア・ルール違反リスト | 座標付きバウンディングボックス+修正コード |
| 実行コスト | 低い（静的解析中心） | 高い（LLM推論+ヘッドレスブラウザ） |
技術的な仕組みを段階的に見る
処理の流れは大きく3段階に分かれています。URL入力からスクリーンショット取得、AIモデルによる座標推定、そして画面上へのオーバーレイ表示です。
1. 高DPIスクリーンショットの取得
まずPuppeteer（Node.jsからヘッドレスChromeを操作するライブラリ）でページを開きます。ここで重要なのはdeviceScaleFactor: 2という設定です。
これは画面解像度を2倍で描画する指定で、バッジの小さな文字やアイコンをAIモデルが正確に認識できるようにするためです。低解像度のスクリーンショットでは、細かいコントラスト差やフォントのかすれをモデルが見落とす可能性があります。
またwaitUntil: networkidle2というオプションで、ネットワーク通信が落ち着くまで待機します。SPA（シングルページアプリケーション）のようにJavaScriptで後からコンテンツが描画されるサイトでは、この待機処理がないと空白のスクリーンショットを撮ってしまいます。
2. マルチモーダルモデルへの構造化プロンプト
次にスクリーンショットをビジョンモデルに渡します。ここでの工夫は、モデルに自由な文章で説明させるのではなく、JSON形式で厳密なスキーマを守らせている点です。
具体的にはbox_2dというキーで[ymin, xmin, ymax, xmax]という4つの数値を0〜1000の正規化スケールで返させます。正規化とは、画面サイズに依存しない相対座標に変換することです。
たとえば1440x900の画面でも、モバイル表示の375x812の画面でも、同じ0〜1000の座標系で位置を表現できます。これにより、後段のオーバーレイ処理が画面サイズを気にせず座標を描画できます。
3. インタラクティブなオーバーレイ表示
最後にReactコンポーネントが、取得した座標を元にスクリーンショット画像の上に半透明のボックスを重ねて表示します。severity（重大度）をcritical/warning/infoの3段階で分類し、色分けする設計です。
このアプローチは、Google Chromeの開発者ツールにある要素インスペクタの「AI版」と考えると理解しやすいです。ただし対象はDOM構造ではなく、人間の目に映る視覚情報そのものです。
既存技術との位置づけ
この仕組みが依拠している正規化座標という概念は、目新しいものではありません。物体検出（オブジェクトディテクション）分野で長年使われてきた表現方法です。
GoogleのGemini系モデルやOpenAIのGPT-4系モデルなど、近年のマルチモーダルモデルは画像内の物体位置を座標で返す能力を持つようになっています。この特性をUXの視覚的問題検出に応用した点が、この取り組みの実用的な工夫といえます。
フロントエンド開発の文脈で言えば、これはVisual Regression Testing（見た目の差分を検出する既存のテスト手法、PercyやChromaticなどが有名）とは目的が異なります。差分検出は「前回と変わったか」を見るのに対し、このVisual CRO的アプローチは「今の状態が良いか悪いか」を単体で判定します。
この違いは重要です。差分検出だけでは、最初から視覚的に問題のあるデザインをそのまま検出できません。単体評価型のアプローチが補完的に必要になる理由がここにあります。
今日確認できること
実際に自分のプロジェクトへの適用可能性を判断する材料として、以下を確認してみるとよいです。
- 現在のCI/CDパイプラインにLighthouse CIなど数値ベースの検査があるか、視覚面のチェックが手作業のレビューに依存していないか
- PuppeteerやPlaywrightなど、既にヘッドレスブラウザ操作の仕組みが社内にあるか（あれば同種のスクリーンショット取得パイプラインへの統合が容易です）
- 利用しているマルチモーダルモデルのAPIが、座標付きJSON出力に対応しているか（プロンプトでスキーマを明示的に指定できるか公式ドキュメントを確認）
- ランディングページやフォームなど、コンバージョンに直結するページから優先的に対象にできるか
コストの面では、スクリーンショット取得はPuppeteerのローカル実行で無料ですが、ビジョンモデルへの推論リクエストは画像1枚ごとに課金される点に注意が必要です。全ページを毎回スキャンするより、リリース前のランディングページなど絞った範囲から試すのが現実的です。
またdeviceScaleFactorやviewportのサイズは、対象サイトのレスポンシブ設計に合わせて調整が必要です。モバイル向けのUXも診断したい場合は、375x812相当のビューポート設定も別途用意することになります。
まとめ
DOM解析中心の従来ツールと、画像診断中心のビジョンモデルは、検出できる問題の種類が根本的に異なります。両方を組み合わせることで、パフォーマンスと視覚的UXの両面をカバーできる可能性があります。
導入を検討する場合は、まず既存のヘッドレスブラウザ環境があるかを確認し、対象ページを1〜2ページに絞って試すのが手堅い進め方です。座標の正規化方式やプロンプトのスキーマ設計は、公開されているコードを参考にしながら自社のデザインシステムに合わせて調整していくことになります。
数値指標だけでは見えないUX課題に気づく手段として、この種のアプローチを手元の環境で一度試してみる価値はあります。