DesignBench: A Comprehensive Benchmark for MLLM-based Front-end Code Generation

既存のベンチマークが抱えるフレームワーク対応の欠如や多段階タスク評価の不足といった課題を解決するため、React、Vue、Angular などの主要フレームワークと生成・編集・修復の多様なタスクを網羅し、MLLM のフロントエンドエンジニアリング能力を多角的に評価する包括的なベンチマーク「DesignBench」が提案されています。

要約

この論文「DesignBench」は、**「AI にウェブサイトの画面（デザイン）を見せると、その通りに動くプログラムを作れるか？」**という問いに、これまでになく詳しく、そして現実的に答えるための「試験問題集（ベンチマーク）」を作ったという研究です。

まるで、「料理のレシピ（デザイン）」を渡して、AI 料理人が「実際に美味しい料理（コード）」を作れるか、そして「味付けを直せ」と言われたら直せるかを試すコンテストのようなものだと考えてください。

以下に、専門用語を排し、身近な例え話を使って解説します。

---

1. なぜこの研究が必要だったの？（これまでの問題点）

これまでに「AI がデザインからコードを作る」ことを測るテストはありましたが、いくつかの「現実離れした」問題がありました。

• 問題点①：「昔ながらの料理」しか作れない
  • 今のウェブ開発では、React や Vue、Angular という「便利な調理器具（フレームワーク）」を使うのが主流です。でも、これまでのテストは、それらを使わずに素の HTML/CSS（手作業の包丁とまな板）だけで作るものばかりでした。
  • 例え： 「プロの料理人」を評価するのに、家庭用のフライパンしか使わせないのはおかしいですよね。
• 問題点②：「作り始め」しか見ていない
  • 実際の仕事では、一度作って終わりではありません。「ここを青くして」「ボタンを足して」という**修正（Edit）や、「画面が崩れているから直して」という修理（Repair）**が何度も行われます。でも、これまでのテストは「最初の一発勝負」しか見ていませんでした。
• 問題点③：「見た目」だけを見ていた
  • 「なんとなく似ているか？」だけで評価していました。でも、コードが本当に正しいか、再利用しやすいか、どこが間違っているかという**「中身（コードレベル）」の分析**が不足していました。

2. DesignBench とは何か？（新しい試験問題集）

そこで研究者たちは、**「DesignBench（デザインベンチ）」**という新しい試験問題集を作りました。

• 3 つの主要な「調理器具」に対応： React、Vue、Angular、そして素の HTML/CSS。
• 3 つの「仕事」を評価：
  1. 生成（Generation）： デザイン画像を見て、ゼロからコードを作る。
  2. 編集（Edit）： 「背景を青くして」という指示で、既存のコードを修正する。
  3. 修理（Repair）： 「このボタンが重なっているから直して」という不具合を直す。
• 900 問のサンプル： 11 種類のテーマ（ニュース、EC サイトなど）から、実際のウェブサイトを元に作られた 900 問の問題。

3. 実験結果：AI はどこが苦手？

9 つの最新の AI モデル（GPT-4o, Claude, Gemini など）にこのテストを解かせたところ、いくつかの面白い（そして厳しい）結果が出ました。

① 「道具」によって得手不得手がある

• 素の HTML/CSSなら、AI はかなり上手に作れます。
• しかし、React や Vue、Angularを使うと、性能がガクッと落ちます。
  • 例え： 「包丁とまな板」なら上手に野菜を切れるのに、「電気ケトル」や「ミキサー」を使うと、ボタンを押す場所を間違えたり、説明書を読めなかったりします。特に Angular という「堅いルール」の道具では、AI は混乱しやすいようです。

② 「修正」や「修理」はもっと苦手

• 「ゼロから作る」よりも、「既存のものを直す」方が AI は苦戦します。
• 特に「どこを直せばいいか」を見つけることが苦手です。
  • 例え： 「この料理が塩辛すぎるから直して」と言われても、AI は「塩を減らす」のではなく、「別の野菜を足す」などの間違った対応をしたり、何もしなかったりします。

③ 「画像」より「コード」を見せた方が上手

• 修正や修理のタスクでは、「元の画像」を見せるよりも、「元のコード（テキスト）」を見せた方が、AI の性能が良くなりました。
  • 例え： 「この絵を直して」と言われるより、「このレシピの 3 行目を削除して」と言われる方が、AI は正確に理解できるようです。AI は「視覚的な情報」よりも「言語的な情報」の方が得意なようです。

④ 難しい課題になると、性能が急落

• 画面が複雑すぎたり、指示が難しすぎたりすると、AI はパニックを起こして失敗します。
  • 例え： 「シンプルなサラダを作れ」なら成功しますが、「100 種類の具材を使った複雑なフレンチ料理を作れ」と言われると、AI は混乱して失敗します。

4. AI がよくやる「失敗」の種類

テスト結果から、AI がよく犯すミスが 22 種類見つかりました。

• 生成ミス： 要素が足りない、位置がズレている、色が違う。
• 編集ミス： 「青くして」と言われたのに、余計なところまで変えてしまう。
• 修理ミス： 「崩れている」と言われても、どこが崩れているか見つけられず、何も直さない。

5. 私たちへのアドバイス（結論）

この研究から、AI を使う開発者や研究者へのアドバイスが得られました。

• AI への指示は具体的に： 「ここを直して」と言わず、「このボタンの色を青にして」と場所を特定して指示しましょう。
• 複雑な仕事は分解しよう： 一度に全部作ろうとせず、小さなタスクに分けて指示を出しましょう。
• AI の得意分野を知ろう： AI は「コードのテキスト」を見る方が得意なので、画像だけでなくコードも渡してあげると、より良い結果が得られます。

まとめ

DesignBenchは、AI が「ウェブ制作」の現場で本当に使えるかどうかを、「実際の道具（フレームワーク）」を使い、「実際の工程（修正・修理）」を通じて、徹底的にテストした画期的な研究です。

今の AI は「絵を描く」のは上手ですが、「プロの現場で道具を使って、複雑な料理を完成させる」にはまだ修行が必要です。この研究は、その「修行の道筋」を明確に示してくれたと言えます。

技術概要

DesignBench: MLLM ベースのフロントエンドコード生成のための包括的ベンチマーク

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

本論文は、マルチモーダル大規模言語モデル（MLLM）の自動フロントエンドエンジニアリング能力を評価するための、画期的なベンチマーク「DesignBench」を提案したものです。既存のベンチマークが抱える限界を克服し、現代のフロントエンド開発の実情（フレームワークの使用、反復的な編集・修正プロセス）を反映した多角的な評価体系を構築しています。

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

---

1. 背景と問題定義

Web 開発において、UI デザインから機能的なコードへの変換は重要ですが、依然として人手と時間がかかるプロセスです。MLLM は視覚的なコード生成において有望な成果を示していますが、既存の評価ベンチマークには以下の重大な限界がありました。

1. フレームワークの欠如: 現代のフロントエンド開発では React, Vue, Angular などのフレームワークが主流ですが、既存のベンチマークは主に素の HTML/CSS（Vanilla）に限定されており、フレームワーク特有の構文やコンポーネント指向のパラダイムを評価できていません。
2. タスクの範囲が狭い: 既存の評価は「デザインからのコード生成」のみを対象としており、実際の開発フローで不可欠な「デザイン編集（リファイン）」や「バグ・表示問題の修正（リペア）」といった反復的なタスクを無視しています。
3. 評価次元の不足: 生成された UI の全体的な品質のみを評価する傾向があり、タスクの難易度、入力コンテキスト（画像のみかコード含むか）、コードレベルの正確性や再利用性など、多面的な分析が不足しています。

2. 提案手法：DesignBench

DesignBench は、これらのギャップを埋めるために設計された、マルチフレームワーク・マルチタスクの評価ベンチマークです。

2.1 データセットの構成

• 規模: 900 件のウェブページサンプル。
• カバレッジ: 11 以上のトピック、9 種類の編集タイプ、6 種類の表示問題カテゴリを網羅。
• フレームワーク: React, Vue, Angular の 3 つの主要フレームワークと、素の HTML/CSS（Vanilla）の 4 種類に対応。
• タスク定義:
  1. デザイン生成 (Design Generation): UI モックアップ画像からコードを生成するタスク。
  2. デザイン編集 (Design Edit): 元の画像、元のコード、ユーザーの自然言語指示に基づき、コードを修正するタスク。
  3. デザインリペア (Design Repair): 表示上の問題（レイアウト崩れ、重なりなど）がある画像とコードを受け取り、修正したコードを生成するタスク。

2.2 データ収集とアノテーション

• 生成タスク: GitHub の人気プロジェクトや Top 500 ウェブサイトから収集し、Selenium でスクリーンショットを生成。
• 編集タスク: Vercel の V0 や Vue0 などのプラットフォームから、実際のユーザー指示とコード変更履歴を収集。PhD 学生による厳格なフィルタリング（指示の明確さ、修正の質）を実施。
• リペアタスク: 収集したページからレイアウト崩れや視覚的不整合（Occlusion, Crowding, Alignment など 6 種類）を特定し、専門家が手動で修正コード（Ground Truth）を作成。

2.3 評価指標

• 視覚的指標: CLIP（意味的類似性）、SSIM（構造的類似性）。
• コード指標:
  • CSR (Compilation Success Rate): コンパイル成功率。
  • CMLS (Code Modification Location Similarity): 修正位置の正確性（Jaccard 類似度）。
  • CMCS (Code Modification Content Similarity): 修正内容のセマンティックな正確性（CodeBLEU）。
• MLLM-as-Judge: GPT-4o を用いて、指示の遵守度や問題解決度を 0-10 点で評価（人間による検証済み）。

3. 主要な実験結果と知見

9 つの主要な MLLM（Claude-3.7, GPT-4o, Gemini-2.0, Llama, Pixtral, Qwen など）を対象に評価を行いました。

3.1 パフォーマンスの全体像

• トップモデル: Claude-3.7, GPT-4o, Gemini-2.0, Pixtral-124B が全体的に優れた性能を示しました。
• モデルサイズの影響: 大規模モデル（例：Llama-90B vs 11B）は小規模モデルより一貫して高性能でした。

3.2 タスクごとのボトルネック

• 生成タスク: 主な課題は「コンパイルエラー」と「視覚的な不正確さ」です。特に Angular では構文の複雑さによりコンパイル成功率が低下しました。
• 編集・リペアタスク: コードがコンパイル成功しても、**「どの部分を修正すべきか（コード局所化）」と「何を修正すべきか（セマンティックな修正）」**を特定する能力に大きな限界がありました。CMLS/CMCS スコアは CSR に比べて著しく低く、指示の範囲を正確に理解し、最小限の修正を行うことが困難であることが示されました。

3.3 フレームワークごとの差異

• Vanilla (HTML/CSS): 最も高いパフォーマンスを発揮。
• React/Vue: 中程度の性能。
• Angular: 最も性能が低下。TypeScript やコンポーネント構造の理解が不十分でした。
• コンポーネント指向の実装: MLLM は再利用可能なコンポーネント設計（例：Vue の v-for など）をほとんど使用せず、ハードコードされた繰り返し構造を生成する傾向がありました。

3.4 入力コンテキストの影響

• コード入力のみ vs 画像のみ: 編集・リペアタスクにおいて、「コード入力のみ」が「画像のみ」よりも一貫して高い性能を示しました。
• マルチモーダル（画像＋コード）: 両方を入力しても、コード単独入力ほどの改善は見られず、場合によっては性能が低下しました。これは、これらのタスクにおいてテキストコードの方が視覚情報よりも精密な意味情報を提供することを示唆しています。

3.5 難易度と失敗パターン

• 難易度: UI 画像が大きい、指示が複雑、問題が深刻な場合、性能は顕著に低下しました。
• 失敗タイプ:
  • 生成：要素の欠落、位置/サイズの誤り。
  • 編集：不要な修正、部分的な修正、対象要素の誤り。
  • リペア：問題の特定失敗（修正を行わない）、誤った修正。

4. 主要な貢献

1. 初の包括的ベンチマーク: HTML/CSS, React, Vue, Angular の 4 つのフレームワークと、生成・編集・リペアの 3 つのタスクを網羅する初のベンチマークの導入。
2. 多角的な評価体系: 難易度、入力コンテキスト、コードの正確性・再利用性など、多次元での評価を実施。
3. 重要な知見の提示:
   • フレームワーク固有の構文理解（JSX, テンプレート構文、TypeScript）の限界。
   • 編集・リペアタスクにおける「コード局所化」能力の欠如。
   • 画像入力よりもコード入力の方が修正タスクには有効であるという逆説的な発見。
   • 22 種類の失敗パターンの特定。

5. 意義と今後の展望

DesignBench は、MLLM のフロントエンド開発における実用性を評価するための標準的な基盤を提供します。

• 研究者向け: フレームワーク固有のトレーニングデータの充実、マルチモーダル情報のより効果的な融合（特にコードと視覚情報のアライメント）の必要性が示されました。
• 開発者向け: MLLM を実務に活用する際は、複雑な指示を分解し、編集箇所を明示的に指定するなどの工夫が必要であることが示唆されました。

本論文は、単なる「画像からコードへ」の変換を超え、実際の開発ライフサイクル全体をカバーする MLLM の能力評価と改善の道筋を示す重要な研究です。