🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure は、決定論的な相互作用軌跡を通じてインタラクティブな HTML を評価・修復する状態誘導型ブラウザ体験フレームワークを導入し、シードコーパスを高品質なデータセットへと大幅に拡張することで、27B モデルが Kimi-K2.6 や GPT-5.4 などの最先端システムと同等の性能をインタラクティブな Web ベンチマークで達成することを可能にします。

原著者： Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

公開日 2026-05-27

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

以下は、HTMLCURE 論文の説明を、日常的な比喩を用いたシンプルな概念に分解したものです。

大きな問題：「見た目だけ良く、実際は壊れている」

あなたが非常に才能のある芸術家（AI）に、おもちゃの車を組み立てるよう頼んだと想像してください。芸術家は美しいモデルをあなたに手渡します。写真で見れば完璧に見えます。しかし、あなたがそれを押そうとすると車輪が外れ、ハンドルを操作しようとするとハンドルが無意味に空回りします。

これが現在の AI 生成 Web ページ（HTML）が抱える問題です。単一のスナップショット（スクリーンショット）では美しく見えても、実際の人がボタンをクリックしたり、スクロールしたり、ウィンドウサイズを変更したり、ゲームを遊んだりしようとすると、ページが壊れてしまいます。

従来の方法： 研究者たちは以前、ページの写真を見て、それが美しく見えるか確認し、「良い」かどうかを判断していました。これでは、外れた車輪などの欠陥を見逃していました。
結果： 実際には修正可能な数千のページを捨ててしまったり、見た目だけ良く機能しないページをそのまま残したりしていました。

解決策：HTMLCURE（「試乗」メカニック）

著者たちは HTMLCURE というシステムを構築しました。単に写真を見るのではなく、HTMLCURE は車を試乗するメカニックのように機能します。

以下がその仕組みをステップごとに説明したものです。

1. 試乗（ブラウザ体験）

単に写真を撮るのではなく、HTMLCURE は Web ページを実際のブラウザに読み込みます。ただ待っているのではなく、積極的に相互作用します：

上下にスクロールします。
ウィンドウサイズを変更します（まるで、小さなガレージに車が入るか確認するかのように）。
ボタンをクリックし、リンクにカーソルを合わせ、ゲームをプレイしようとします。
何が起こったかを正確に記録します。「ボタンが機能しなかった」「ゲームがフリーズした」「モバイル版でレイアウトが崩れた」など。

比喩： これは車の運転テストのようなものです。塗装の美しさを見るだけでなく、エンジンがかかるか、ブレーキが効くか、変速が滑らかかを確認するために実際に運転します。

2. 診断（状態信号）

試乗後、システムはページに「健康スコア」と診断を与えます。医師が患者をトリアージ（優先度付け）するように、ページを 3 つのグループに分類します：

低スコア（廃車）： ページはぐちゃぐちゃです。構造の大きな部分が欠けています。
- 対策： 完全書き換え。 パッチを当てようとするのではなく、ゼロから新しい車を組み立てます。
中スコア（ボロ車）： ページは概ね機能していますが、特定の破損部分があります（例：ラジオが動かない、ドアノブが固着しているなど）。
- 対策： 標的修理。 特定の破損部分を診断し、その部分だけを修理します。
高スコア（スポーツカー）： ページはすでに素晴らしい状態です。
- 対策： 磨き上げのみ。 エンジンには触れないでください。おそらく塗装をワックスかける程度に留めます。「壊れていない」ものを「修理」しようとすると、逆に壊してしまう可能性があります。

重要な洞察： 論文は、すべてのページに同じ修理方法を使用することは誤りであると主張しています。ページが実際にどの程度壊れているかによって、異なる戦略が必要です。

3. 修理ループ（フィードバックサイクル）

システムが戦略（書き換え、パッチ、磨き上げ）を決定すると、AI にページを修正するよう依頼します。

重要なステップ： システムは AI の言葉をただ信じるわけではありません。新しいバージョンのページを取得し、試乗を再度実行します。
ゲートキーパー： 新しいバージョンが改善されていれば、それを採用します。もし新しいバージョンが悪化した場合（「回帰」）、それを捨てて再度試みます。
目標： ページが高品質の基準（100 点満点中 97 点）をクリアするまで、これを繰り返します。

比喩： 料理人がスープを味見していると想像してください。塩辛すぎれば、水を追加します。そして再度味見します。水で直ったと単に想定するのではなく、確認します。もし水を入れすぎて味が薄くなりすぎたら、止めて別のレシピを試します。

結果：より良いライブラリの構築

著者たちは、97,000 件の AI 生成ページという膨大なコレクションに対してこのシステムを使用しました。

彼らは「完璧」なページの小さな山から始めました。
HTMLCURE を使用して「壊れた」ものを修正しました。
その結果、63,000 件の高品質で検証済みのページ（元の小さなセットから増加）を手にしました。

彼らはその後、この新しくクリーニングされたライブラリを使用して、新しい AI モデル（HTMLCure-27B と呼ばれる）をトレーニングしました。

結果：

新しいモデルは、機能する Web ページを作成する能力が大幅に向上しました。
HTMLBENCH という厳格なテストで 50.6 というスコアを記録し、Kimi-K2.6 や GPT-5.4 などのトップクラスの商用モデルと同等の性能を示しました。
別のテスト（MiniAppBench）では、未トレーニングのバージョンと比較して 15 ポイント 向上しました。

一文で要約

HTMLCURE は、AI が Web ページが機能するかどうかを単に「推測」するのをやめさせるシステムです。代わりに、AI にすべてのページを試乗させ、何が壊れているかを正確に診断し、適切な戦略で修理し、修正が実際に機能したかを確認するために再テストさせ、高品質で機能するコードの膨大なライブラリを作成します。

技術的サマリー：HTMLCure

問題定義

大規模言語モデル（LLM）は完全な HTML ページを生成する能力を示してきましたが、これらの出力はしばしば「表面的な正しさ」という問題に悩まされます。生成されたページが単一の静的スクリーンショットでは正しくレンダリングされても、スクロール、ホバー、クリック、リサイズ、またはゲームプレイなどの動的な条件下では頻繁に失敗します。静的スクリーンショットや希薄な視覚的トレースに依存する従来の評価手法は、これらのインタラクション固有の失敗を見逃します。さらに、標準的なデータフィルタリング手法は、これらのページを多くが使用不能として破棄し、それらがしばしば修復可能であることを認識できていません。特定された核心的な課題は、インタラクティブな HTML のためのデータ構築が、単なるスコアリング問題ではなく状態推定問題であるという点です。静的な観測だけでは、特定のユーザーインタラクション後にのみ顕在化する失敗を明らかにすることはできません。

手法

本論文は、ブラウザ実行トレースによって駆動される閉ループプロセスを通じて、インタラクティブな HTML を評価、診断、修復するために設計されたブラウザ体験フレームワークHTMLCUREを導入します。

1. 多次元体験評価パイプライン

静的スクリーンショットに依存する代わりに、HTMLCURE は一連の閲覧およびインタラクション動作（ $\pi$ ）を実行することによって、HTML 人工物（ $h$ ）を評価します。

4 層体験プロトコル:
- L1（視覚的観測）: ロード動作と初期レンダリングを確認します。
- L2（能動的インタラクション）: コントロール、ホバー状態、キーボードバインディング、スクロール動作をテストします。
- L3（深層ゲームプレイ）: ゲームや複雑な UI に対するタスク駆動型のロールアウトを実行し、状態遷移、カウンター、キャンバスの変化を検証します。
- L4（レスポンシブ）: イベントコンテキストを伴う実行軌道から代表的なキーフレームを選択します。
構造化証拠: 評価器は、視覚的証拠（ $v_t$ 、例：レンダリングされたフレーム）と行動的証拠（ $b_t$ 、例：DOM 状態、コンソールエラー、プローブ結果）を含む順序付けられたトレース $E(h, \pi)$ を生成します。
5 要素スコアリング: スコア $S(h)$ は、レンダリング、視覚的デザイン、機能性、インタラクティビティ、コード品質の 5 つの次元から導き出されます。重要なのは、視覚的デザインがキュレーションされたキーフレームに基づいてビジョン・ランゲージモデル（VLM）によって評価される唯一のコンポーネントであり、他のすべての次元は決定論的なブラウザ実行と静的解析に依存している点です。

2. 状態認識型インタラクティブ修復エンジン

修復プロセスは、一般的な再生成ではなく、ページの現在の状態に基づいた制御された介入です。

状態ルーティング: システムはスコア $s$ $s$ に基づいてページを 3 つの状態に分類します。
- Low（< 40）: 安定した局所目標を持たないページ。戦略：包括的書き換え。
- Mid（40–79）: 使用可能な構造を持つが動作が破損しているページ。戦略：診断ガイド型局所修復（例：特定のインタラクションバグの修正）。
- High（≥ 80）: 強力なページ。戦略：維持または回帰を避けるための標的型微調整。
閉ループ実行: コントローラーは修復ファミリーを選択し、候補を LLM にプロンプトし、すべての候補をブラウザで再実行します。
回帰認識型受入: 候補は、機能性とインタラクティビティにおける回帰を罰する複合スコア $S_{comp}$ を使用して選択され、視覚的デザインにおける改善が壊れたロジックの代償として行われないことを保証します。
終了: ページが高目標スコア（≥ 97）に達するか、改善が頭打ちになるか、ラウンド予算が尽きるまでループは停止します。

3. データ構築

HTMLCURE は、修復をデータ構築メカニズムとして扱います。初期の 97K プロンプトコーパスから受け入れられた修復は、洗練された教師あり微調整（SFT）プールにエクスポートされます。このプロセスは、「High」ページという小さな部分集合から、63,703 件の品質クリアされたページというより大きなプールへと使用可能なデータセットを拡大し、そこから最終的な 40K のトレーニングセットが構築されます。

主要な貢献

修復状態シグナルとしてのブラウザ体験: 本論文は、ブラウザ実行トレースを構造化されたページ状態に変換することで、VLM の視覚的判断の正確な境界を定め、特定の修復決定を駆動できることを実証しています。
状態認識型インタラクティブ修復: このフレームワークは、修復戦略（書き換え対診断対維持）がページの観測された状態に基づいて動的に選択されるポリシーを導入します。これにより、高品質なページでは動作するコンポーネントの破壊を防ぎ、低品質なページでは構造的な再構築を確実にします。
データ構築としての修復: 再実行を通じて修復を検証することで、システムは高品質で検証済みの SFT コーパスを生成します。このアプローチは、「フィルタリング」（不良ページを破棄する）というパラダイムを、「回復」（ページを修復し検証する）というパラダイムへと変換します。

結果

著者は、決定論的なブラウザ実行ベンチマークであるHTMLBENCH-400と、MiniAppBench検証分割を使用して、この手法を評価しました。

パフォーマンス: 同じバックボーン（Qwen3.5）とトレーニングレシピの下で、HTMLCure-27B-Refinedモデルは以下の結果を達成しました。
- HTMLBENCH-400 で50.6（総合スコア）。
- 決定論的テストケースのパス率45.2%。
- MiniAppBench 検証分割で平均81.2。
比較: これらの結果は、Kimi-K2.6 や GPT-5.4 などの強力な参照システムと同じパフォーマンス帯にモデルを位置付けます。
アブレーション: 同等のデータサイズ（12,392 例）を用いた制御実験により、「Refined」ルート（修復済み、検証済みデータを使用）が、「Raw」（元の生成物）および「Filtered」（元の高品質ページのみ）の両方のルートを上回ることが確認されました。これは、データ量だけでなく、ブラウザ体験から導き出される監督の質が改善の主要な駆動力であることを証明しています。

意義と主張

本論文は、HTMLCURE がインタラクティブな HTML 生成のパラダイムを「生成してフィルタリング」から「体験、修復、検証」へとシフトさせると主張しています。

制御としての実行: 中心的な主張は、ブラウザ実行を単なる最終的な通過/不合格の判定としてではなく、欠落した構造と破損したインタラクションを分離する連続的な制御信号として使用すべきであるという点です。
データ品質: この研究は、状態固有の制御の下で弱く部分的なページを修復することが、単に既存の高品質なページを選択するよりも SFT に対して強力な監督をもたらすことを実証しています。
再現性: 著者は、決定論的テストケースを備えた凍結されたベンチマーク（HTMLBENCH）と、再現可能な比較のための完全なパイプラインを提供しており、標準化された失敗記録が欠如したエージェントベースの評価を超えています。

本論文は、その限界に関して控えめであり、視覚的デザインスコアリングには依然として VLM が必要であること、ブラウザプローブはあらゆる可能なインタラクションを網羅できないこと、複雑なゲームは結合されたタイミングの失敗を露呈させる可能性があることを認めています。将来の作業としては、ルーティングと停止ポリシーを修復トレースから直接学習することが提案されています。