アーカイブ / VLM / LLM
画面画像から再利用できるUI部品を設計するMLS：合成値の評価に注意
Modular Layout Synthesis (MLS)
概要
- MLSは画面画像から階層を推定し、繰り返す領域を部品候補にまとめてからコードを生成する。
- 中間の設計図に表示ごとの値と型を残し、React、Vue、Angularなどの構文に合わせて生成する。
- 論文の実験節にある性能値は著者が合成値と明記しており、実測による改善幅は示されていない。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Modular Layout Synthesis (MLS)の仕組み
- 01画面画像
- 02階層と位置を推定
- 03繰り返しを部品化
- 04方式別コード
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
画面画像からコードを作れても、似たカードや行を毎回書き写した長いファイルになると、表示の変更や再利用が難しくなる。論文は、部品の境界が明示されず、部品に値を渡す仕組みも弱いことを課題に挙げる。
実務ではReact、Vue、Angularなど、開発方式ごとの書き方にも合わせる必要がある。MLSは、画面の見た目に加えて、繰り返す領域を部品として表せるコードを目指す。
手法
MLSは画面画像から、行・列・文字・画像などの種類と位置を持つ階層の木を推定する。木は「どの領域の中に何があるか」を表す形式で、この段階の学習には画像と正解の木・位置の組を使う。次に表示内容を構造から分け、要素を画面上の順に整え、形が同じか近い領域を探す。
例えば商品カードが複数あれば、共通の形を部品候補にし、商品名や画像の参照先など異なる値を表にまとめる。この中間の設計図を大規模言語モデル（LLM）に渡し、指定された開発方式のコードを生成する。型とは文字列やURLなど値の種類の指定で、生成時には値の結び付きと型に合う出力へ候補を絞る。
新規性
MLSの提案は、画面の階層を推定し、繰り返す構造を部品候補にまとめ、開発方式に応じたコードを生成する処理を分けた点にある。中間の設計図には、部品の形、表示ごとの値、値の型を残す。
部品候補が重なる場合は、重複を減らす効果を基に採用する候補を選ぶ。コード生成時には、ファイルやタグの形式、値と部品の結び付き、値の型に合う出力を制約する。
従来手法との違い
論文が比較対象に挙げるのは、画像から一度にコードを出す方法、画面を分けて処理するDCGen、配置情報を使うLayoutCoderなどである。MLSはコード生成の前に繰り返しを探し、部品と表示内容を中間の設計図へ整理する。
React、Vue、Angularでは、その設計図から各方式の繰り返し構文を選ぶ。ただし、比較表と部品抽出などを外した試験の数値は著者が乱数生成の合成値と明記しており、実測による優劣は示していない。
実験結果
著者は実験節の数値をすべて乱数生成の合成値と明記している。Design2Codeの484件を対象と記した表では、描画結果と入力画像を比べるCLIP類似度がMLSで0.844、WebVIA-UI2Codeで0.821、繰り返し領域の部品化を測るReuse@Kがそれぞれ0.412、0.275と示される。
同表のTypeCheck、すなわち型検査の通過率は86.9％と72.3％だが、これも合成値である。React、Vue、Angular向けの300件の比較と、部品抽出などを外した試験も合成値に基づく。確認できた本文の範囲では、実測の成績は示されていない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の商品一覧画面の画像から、React用の商品カード部品を試作する。入力は画面画像と、商品名、画像の参照先、リンク先の原データ。出力は共通のカード部品、商品ごとの値を渡す定義、一覧を描くコードとする。
画像から階層を推定する部分をこの画面向けに学習・調整するなら、画面画像と正解の階層・位置ラベルの組が必要になる。追加センサーは使わず、担当者が部品の境界と表示内容を照合し、社内の部品規約に合わせて修正する。保守負担が減るかは検証事項である。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：商品カードが並ぶ一画面を選び、画面画像、商品名・画像の参照先・リンク先の原データ、正解の階層・位置ラベルを用意する。画像から木を推定する部分を学習・調整する場合は画像とラベルの組を使い、追加センサーは使わない。
部品規約に合わせて出力を修正し、同じ画像から一度にコードを生成する方法を比較基準とする。両方を描画して元画像との一致、重複したコードの割合、型検査の通過、部品境界と表示内容の修正件数を記録する。採用基準は実測結果を見て定める。
限界と課題
著者は、画面からコードを作る技術が欺瞞的なウェブコンテンツの制作を容易にし得ると述べ、出所追跡や安全対策を今後の課題に挙げる。また、実験節の数値はすべて合成値と明記しており、実運用での性能を裏付ける結果ではない。
編集上の検証事項は、画像から階層と表示内容を正しく得られるか、用途の違う領域を誤って同じ部品にしないか、生成コードが各方式で動くかである。表示内容を画像から取り出す具体的な手順や、必要な学習データ量も、確認できた本文の範囲では判断できない。
出典
元のタイトル・要旨を確認する（英語）
Modular Layout Synthesis (MLS): Front-end Code via Structure Normalization and Constrained Generation
Automated front-end engineering drastically reduces development cycles and minimizes manual coding overhead. While Generative AI has shown promise in translating designs to code, current solutions often produce monolithic scripts, failing to natively support modern ecosystems like React, Vue, or Angular. Furthermore, the generated code frequently suffers from poor modularity, making it difficult to maintain. To bridge this gap, we introduce Modular Layout Synthesis (MLS), a hierarchical framework that merges visual understanding with structural normalization. Initially, a visual-semantic encoder maps the screen capture into a serialized tree topology, capturing the essential layout hierarchy. Instead of simple parsing, we apply heuristic deduplication and pattern recognition to isolate reusable blocks, creating a framework-agnostic schema. Finally, a constraint-based generation protocol guides the LLM to synthesize production-ready code with strict typing and component props. Evaluations show that MLS significantly outperforms existing baselines, ensuring superior code reusability and structural integrity across multiple frameworks
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01