Vision2Web: A Hierarchical Benchmark for Visual Website Development with Agent Verification

本論文は、静的 UI からフルスタック開発までを網羅する階層的ベンチマーク「Vision2Web」と、GUI エージェント検証器および VLM ベースのジャッジによるワークフロー検証手法を提案し、現状の最先端モデルでもフルスタック開発において大きな性能課題が残っていることを明らかにしたものである。

要約

Vision2Web：AI 建築家のための「超・実践テスト」の紹介

この論文は、**「AI に『ウェブサイト』を作らせるテスト」**について書かれています。

最近の AI（大規模言語モデル）は、コードを書くのが上手になりました。しかし、「本当に複雑なウェブサイトを一から作れるのか？」を測る、しっかりとしたテストがまだありませんでした。そこで、研究者たちは**「Vision2Web（ビジョン・トゥ・ウェブ）」**という新しいテスト基準を作りました。

これをわかりやすく説明するために、**「AI を建築家（大工さん）に例えて」**考えてみましょう。

---

1. 従来のテストは「お絵かき」だけだった

これまでの AI のテストは、主に「この部屋の間取り図（コード）を書いて」というレベルでした。

• SWE-Bench などの既存テスト： 「壁のひび割れを直す（バグ修正）」や「窓を一つ増やす（機能追加）」のような、部分的な作業しか見ていませんでした。
• デザインからコードへのテスト： 「この絵をそのまま写し取る」だけでした。

しかし、現実のウェブサイト開発は、「設計図（デザイン）」を見て、「壁（フロントエンド）」を建て、**「配管や電気（バックエンド）」を張り巡らせ、「住人が快適に住める家（フルスタック）」**を完成させるまでが必要です。これまでのテストでは、この「家全体を建てる力」は測れていませんでした。

2. Vision2Web：3 つのレベルで試す「建築試験」

Vision2Web は、難易度が上がる3 つのレベルで AI を試します。

• レベル 1：静かな写真（静的 Web ページ）
  • 例え： 「この写真（デザイン図）を、そのまま壁紙として貼ってください」。
  • 内容： デスクトップ、タブレット、スマホなど、画面サイズに合わせてデザインを忠実に再現できるか？
• レベル 2：動くおもちゃ（インタラクティブなフロントエンド）
  • 例え： 「部屋と部屋をつなぐドアを開けたり、階段を登ったりできる家を作ってください」。
  • 内容： 複数のページを行き来したり、ボタンを押すと画面が変わったりする「動き」があるサイトを作れるか？
• レベル 3：完全なマンション（フルスタック・ウェブサイト）
  • 例え： 「電気、水道、セキュリティ、住人の管理システムまで含めた、完璧なマンションを建ててください」。
  • 内容： データの保存、ログイン機能、複雑な処理など、裏側（サーバー）も含めた完全なシステムを作れるか？

3. 採点方法：「AI 検査員」と「AI 審査員」のダブルチェック

ここがこのテストのすごいところです。AI が作ったサイトが「本当に良いか」を、人間が一つ一つチェックするのは大変です。そこで、2 人の AI 助手に採点させます。

• 検査員（GUI エージェント）：
  • 役割： 「実際に住んでみる」人。
  • 行動： 「ログインボタンを押す」「カートに入れる」「ページを移動する」といった実際の操作を自動で行い、「ちゃんと動くか？」をチェックします。
• 審査員（VLM ジャッジ）：
  • 役割： 「設計図と見比べる」人。
  • 行動： 完成したサイトの画面と、元のデザイン図（写真）を AI が比較し、「色は合ってる？」「ボタンは正しい位置にある？」という見た目の美しさを採点します。

この「動くか（機能）」と「綺麗か（見た目）」の両方を、AI 同士で厳しくチェックする仕組みが「ワークフローベースの検証」です。

4. 実験結果：AI は「部分」は得意だが「全体」は苦手

このテストで、最新の AI 8 種類をテストしたところ、以下のような結果が出ました。

• レベル 1（写真）： 多くの AI が上手に作れました。
• レベル 2（動き）： 難易度が上がると、AI は迷子になったり、ボタンが動かなかったりし始めます。
• レベル 3（完全な家）： ここが最大の壁でした。
  • 最も優秀な AI でも、複雑なシステムを完成させるのは非常に苦戦しました。
  • 「ログインはできたけど、データ保存ができなかった」「ページは動いたけど、デザインが崩れていた」といった、「全体を統括する力」の不足が浮き彫りになりました。

特に、**「SaaS（業務システム）」**のような複雑なサイトを作るのは、現在の AI にとってまだ「無理ゲー」に近い状態です。

5. この研究の意義

この論文は、**「AI が本当に使えるようになるには、単にコードを書くだけでなく、複雑なプロジェクトを『全体』として管理する力が不可欠だ」**と教えてくれました。

• 現状： AI は「良い職人」にはなれたが、「大工長（プロジェクトマネージャー）」にはまだなれていない。
• 未来： このテスト（Vision2Web）を使って、AI が「全体をどう管理するか」を鍛えれば、将来的には人間が指示するだけで、完璧なウェブサイトが自動で完成する日が来るかもしれません。

まとめ

Vision2Web は、AI 建築家たちに**「写真写し取り」から「マンション建設」までを課し、「動くか」「綺麗か」を AI 同士で厳しく審査する**新しいテスト場です。
今の AI は「部分」は得意ですが、「全体」を任せるにはまだ修行が必要だ、という重要な発見をもたらしました。

技術概要

Vision2Web: エージェント検証を備えた視覚的 Web 開発のための階層型ベンチマーク

技術的サマリー（日本語）

本論文は、大規模言語モデル（LLM）の進歩に伴い強化されたコーディングエージェントの能力を評価する新たなベンチマーク**「Vision2Web」**を提案するものです。既存のベンチマークが局所的なコード修正や静的な UI 生成に限定されていたのに対し、Vision2Web は「静的 UI からコード生成」から「インタラクティブな多ページフロントエンドの再現」、さらに「フルスタック Web サイトの構築」に至るまで、視覚的 Web 開発の全ライフサイクルを網羅する階層型評価枠組みを提供します。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳述します。

---

1. 問題定義と背景

現在のコーディングエージェント評価には、以下の 3 つの主要な限界が存在します。

• タスク定義の限界: 既存の SWE-Bench などは「問題解決（Issue fixing）」に焦点を当てており、システム設計からデバッグまでのエンドツーエンドのソフトウェア工学能力を評価できていません。
• マルチモーダルカバレッジの不一致: 最近の Web 生成ベンチマークはテキストベースであり、視覚的プロトタイプ（デザイン図）からのコード生成を評価するもの（Design2Code など）は、単一ページや静的な UI に限定されています。
• 検証メカニズムの不備: 複雑な相互作用や長期的なシステム成果を、再現性高く、客観的に評価する手法が不足しています。

これらを解決するため、Vision2Web は**「視覚的プロトタイプとテキスト要件を統合し、エージェントによる Web サイト開発を評価する」**ことを目的としています。

2. 手法とアーキテクチャ

2.1 階層的タスク設計

Vision2Web は、タスクの難易度と必要な能力に応じて 3 つのレベルに階層化されています。

1. レベル 1: 静的 Web ページ (Static Webpage)
   • デスクトップ、タブレット、モバイルの 3 種類のデバイス向けプロトタイプ画像を入力とし、レスポンシブな静的 HTML/CSS を生成します。
   • 評価基準：レイアウト、視覚コンテンツ、スタイリングの忠実度。
2. レベル 2: インタラクティブなフロントエンド (Interactive Frontend)
   • 複数のページ間の論理的関係を示すテキストと、複数のプロトタイプ画像を入力とします。
   • 評価基準：多ページ間の構造的一貫性、ナビゲーションフロー、コンポーネントの整理。
3. レベル 3: フルスタック Web サイト (Full-Stack Website)
   • 要件定義書とプロトタイプ画像を入力とし、バックエンド、データベース、複雑なアプリケーション状態管理を含む完全なシステムを構築します。
   • 評価基準：要件解釈、状態管理、統合デバッグ、エンドツーエンドのシステム完成度。

データセット:

• 実在の Web サイト（C4 データセットから抽出）に基づき構築。
• 193 タスク、16 のサブカテゴリ、4 つの主要カテゴリ（コンテンツ、トランザクション、SaaS、公共サービス）。
• 918 枚のプロトタイプ画像、1,255 のテストケースを含む。

2.2 ワークフローベースのエージェント検証 (Workflow-Based Agent Verification)

従来の単一テストやピクセル比較では不十分であるため、構造化されたテストワークフローと2 つの検証コンポーネントを組み合わせた新しい評価パラダイムを導入しました。

• ワークフロー設計:
  • 認証、多ページ移動、機能検証などを、依存関係グラフとして定義。
  • 相互依存するテストノードを「デカップリング（分離）」し、エラーの蓄積を防ぎつつ、関連するノードを「統合」して効率的に検証します。
• 検証コンポーネント:
  1. GUI エージェント検証者 (Functional Verifier):
     • 機能の正しさと相互作用の忠実度を評価（Functional Score: FS）。
     • 専門家が設計したワークフローに基づき、GUI エージェントが実際の操作（クリック、入力など）を実行し、論理的アサーションや状態チェックを行います。
  2. VLM ベースのジャッジ (Visual Judge):
     • 視覚的な忠実度を評価（Visual Score: VS）。
     • 生成されたレンダリングページとプロトタイプ画像を VLM（Vision Language Model）で比較し、コンポーネントレベルの一致度をスコアリングします。

このアプローチにより、実装に依存しない（implementation-agnostic）、再現性が高く、客観的な評価が可能になります。

3. 主要な貢献

1. 階層的タスク設計: 視覚的 Web 開発の各段階（静的→インタラクティブ→フルスタック）におけるエージェントの能力を体系的に解離・評価できる枠組みの提案。
2. 現実的なマルチモーダルデータ: 実世界の Web サイトに基づき、明確な仕様と多様なプロトタイプを含む大規模ベンチマークの構築。
3. ワークフローベースのエージェント検証: 構造化ワークフローとエージェント実行を組み合わせ、機能正しさと視覚的忠実度を同時に評価する、再現性の高い評価パラダイムの提案。

4. 実験結果と知見

8 つの最先端マルチモーダルモデル（Claude-Opus-4.5, GPT-5, Gemini-3-Pro など）を、OpenHands と Claude Code の 2 つのフレームワークで評価しました。

• 結果の傾向:

  • タスク複雑度による性能低下: 静的 Web ページでは比較的高いスコアを達成するモデルも、フルスタックタスクでは劇的に性能が低下しました（例：Gemini-3-Pro-Preview は静的で 52.3 点だが、フルスタックでは VS 9.3 点、FS 17.2 点）。
  • デバイス依存性: デスクトップに比べ、タブレットやモバイル、複雑なプロトタイプ画像では性能が 10〜20% 低下しました。
  • モデル間の差: Claude-Opus-4.5 が全レベルで最も高い性能を示しましたが、それでもフルスタックタスクでは課題が残っています。Qwen や Seed などのモデルは、フルスタックタスクでほぼ機能しませんでした。
  • カテゴリ別性能: 「公共サービス」サイトは比較的容易でしたが、「SaaS プラットフォーム」や「トランザクション」サイト（複雑な状態管理や多ページ連携が必要）では性能が著しく低下しました。
  • 失敗モード: 微細な視覚アライメントの誤り、ページ間での視覚的整合性の欠如、長期的な計画と状態管理の失敗が主要なボトルネックでした。

• 検証者の信頼性:

  • GUI エージェント検証者は人間のアノテーションと 87.2% の一致率を示しました。
  • VLM ジャッジは人間の評価とのスピアマン順位相関係数で 0.66（中央値 0.80）を達成し、実用的な一致度を示しました。

5. 意義と結論

Vision2Web は、単なるコード生成能力ではなく、**「視覚的理解」「長期的な計画」「状態管理」「マルチモーダル推論」**を統合した、真のエンドツーエンドのソフトウェア開発能力を評価する重要な基盤を提供します。

本研究は、現在の最先端モデルであっても、複雑なフルスタック開発や長期的なタスク遂行には根本的な限界があることを示しました。今後の研究においては、階層的で段階的に難易度が上がるタスク設計と、再現性のある自律評価パラダイムを重視し、エージェントの推論能力とソフトウェア開発パフォーマンスの向上を目指す必要があります。

このベンチマークは、オープンソースの Web サイトから構築されており、学術研究目的でのみ使用され、倫理的・法的な問題はないとされています。