AIにスクリーンショットやデザインを渡し、Webページを生成してもらうことは珍しくなくなりました。見た目だけなら、短時間でかなりそれらしいページが出てきます。
しかし、デスクトップのChromeで一度表示できたからといって、そのページが実用上問題なく完成しているとは限りません。スマートフォンへ切り替えた瞬間に横にはみ出す、文字ごと縮小される、要素が重なる、といった問題は別です。
2026年8月に公開された論文「Does It Render Everywhere? A Study of Cross-Environment Compatibility in MLLM-Generated Webpages」は、この部分を正面から調べています。AI生成Webページを複数のブラウザ・端末環境で比較し、どのような互換性問題が起きるのか、その原因は何か、さらに自動検出できるかまで評価した研究です。
Does It Render Everywhere? A Study of Cross-Environment Compatibility in MLLM-Generated Webpages
Multimodal Large Language Models (MLLMs) have been increasingly adopted to automate webpage generation from visual designs (e.g., screenshots). However, existing evaluations are limited to visual fidelity assessment under a fixed browser-device configuration. Such a setting overlooks the cross-environment rendering compatibility for real-world deployments. To address this gap, we present the first systematic empirical study of cross-environment compatibility in AI-generated webpages. Specifically, we construct WebCompat, a dataset of 2,032 annotated instances, comprising webpages generated by 8 representative AI tools, each rendered across 9 browser-and-device combinations. We analyze the prevalence of compatibility issues, their user-perceptible symptoms, and underlying code-level root causes. Our findings reveal that 68% of generated webpages exhibit at least one compatibility issue, underscoring the pervasive reliability concerns surrounding MLLM-generated front-end artifacts. The most prevalent symptoms are failures that disrupt the entire page layout (88.3%): pages shrink directly to fit the target screen with too small fonts, or exhibit scale mismatches that produce cut-off content. Failures localized to individual elements, such as image distortion or missing components, are comparatively less common (13.4%). Furthermore, although most MLLMs incorporate responsive design patterns into the generation, they fail to properly implement these codes. Guided by the findings, we develop XCompat, a lightweight offline compatibility issue detector that combines visual screenshots and the structural DOM tree for analysis. It achieves an F1 score of 0.903 on the WebCompat-test, outperforming the existing compatibility checking tools and LLM baselines. All datasets and tools are released to support future research on rendering reliability in MLLM-based front-end code generation.
https://arxiv.org/abs/2608.12518
この研究で興味深いのは、「AIはCSSを知らないから失敗する」という単純な話ではないことです。生成されたコードの多くはflexやgridを使い、レスポンシブを意識した構造も持っています。それでも、画面幅が変わったときの制約を最後まで成立させられず、実際の表示では壊れるページが多く見つかりました。
フロントエンドエンジニアやAIコーディングを使うエンジニアにとって重要なのは、ここです。AIへ「レスポンシブ対応して」と指示するだけではなく、生成後に実ブラウザで表示し、複数のviewportで壊れていないことまで検証する必要があります。
論文が調べたのは「コードを書けるか」ではなく「どこでも表示できるか」
この論文が扱っているのは、スクリーンショットなどからWebページを再現するUI-to-Code系のタスクです。
研究では複数のモデル・生成ツールを使ってページを生成し、BrowserStack上の9環境で表示しています。評価対象にはAndroid、iPhone、Windows、macOSが含まれ、ChromeだけでなくSafari、Firefox、Edgeも使われています。
主な環境は次の通りです。
| OS・端末 | ブラウザ |
|---|---|
| Pixel 7 / Android | Chrome |
| iPhone 13 | Safari、Chrome |
| Windows 11 | Chrome、Firefox、Edge |
| macOS | Chrome、Firefox、Safari |
Windows 11 + Chromeを基準環境として、ほかの環境との差を調べています。論文全体では2,032件のクロス環境比較が人手でアノテーションされました。
判定も単純な画像差分だけではありません。フロントエンドやGUIテストの経験を持つ2名が独立して確認し、判定一致度を示すCohen’s κは0.9506でした。つまり、「何となく崩れて見える」という主観的な観察だけではなく、互換性問題を一定の基準で分類する設計になっています。
AI生成ページの68%に少なくとも1つの互換性問題が見つかった
研究対象となったAI生成ページでは、203ページ中139ページ、68%に少なくとも1つの互換性問題が確認されました。
比較用の人間実装では60ページ中24ページ、40%でした。今回の実験条件ではAI生成ページの方が問題を起こす割合が高く、論文ではFisherの正確確率検定でも有意差があると報告しています。
ただし、この「68%」だけを切り取って、
AIが作ったWebサイトの68%は壊れている
と一般化するのは適切ではありません。
今回の対象は自己完結した静的なsingle-page Webページが中心です。複雑なReactやVueのアプリケーションを本番運用したときの障害率を測った研究ではありません。この制約については後半でも触れます。
重要なのは数字の大きさそのものより、AI生成ページではクロス環境の表示確認を省略できないことが、実測データとして示された点です。
問題の中心はChrome対Safariではなく、Desktop対Mobileだった
クロスブラウザ互換性と聞くと、SafariだけCSSの表示が違う、Firefoxで特定機能が動かない、といったブラウザ固有問題を想像しがちです。
しかし、この論文では別の傾向が強く出ています。
AI生成ページで見つかった問題のうち、**デバイス差だけで発生したものが67.5%**だったのに対し、**ブラウザ差だけで発生したものは1.0%**でした。
少なくとも今回の実験では、ChromeとSafariの違いよりも、デスクトップとモバイルの表示領域の違いの方が大きな問題になっています。
これは実務でも重要な視点です。AI生成フロントエンドを確認するとき、最初から大量のブラウザ組み合わせを増やすより、まずviewportを大きく変えたときにレイアウトが成立するかを確認する方が、主要な問題を見つけやすい可能性があります。
もちろんSafariやFirefoxの確認が不要になるわけではありません。論文から言えるのは、今回観測された失敗の中心がブラウザエンジン差ではなく、画面サイズが変化したときのレイアウト設計だったということです。
壊れ方の多くはページ全体のレイアウトだった
互換性問題が確認されたケースの88.3%では、ページレベルのレイアウト問題が含まれていました。
代表的な症状として、論文では次のようなものが報告されています。
| 症状 | 問題が確認されたケースでの割合 |
|---|---|
| ページ全体が縮小され、文字まで小さくなる | 42.1% |
| viewportと初期スケールが合わず表示が切れる | 23.1% |
| 要素がoverflowして画面外へ出る | 23.1% |
| 不自然に大きな空白が生まれる | 13.8% |
| 要素同士が重なる | 5.5% |
一つの画像だけが少し歪む、といった局所的な問題よりも、ページ全体のレイアウトが狭い画面へ適応できないケースが目立ちます。
フロントエンドでは、コンポーネント単体のCSSが正しそうに見えても、親要素のmin-width、固定幅、折り返し、viewport設定などが組み合わさることでページ全体が崩れます。AI生成コードでも同じことが起きています。
AIはflexやgridを知らないわけではない
この研究で特に面白いのが、生成されたHTML/CSSの分析です。
互換性問題の原因として多かったものは次の通りでした。
| 原因 | 該当ページの割合 |
|---|---|
| viewport metaの欠落・誤り | 46.0% |
| flex/gridなどで折り返しが不足 | 29.5% |
widthやmin-widthなどの固定値 | 19.4% |
| 画像サイズの固定 | 10.1% |
| responsive指定によって要素が消える | 2.2% |
| ブラウザ固有のレンダリング | 1.4% |
一つのページに複数原因が含まれるため、割合の合計は100%にはなりません。
ここだけを見ると、「AIがレスポンシブCSSを理解していない」と考えたくなります。しかし、生成コードの97.5%には何らかのレスポンシブ関連構造があり、flexは95.1%、gridは43.3%で使われていました。
つまりAIは、レスポンシブなUIで使われる構文自体はかなり知っています。
たとえば、次のようなコードを書くことはできます。
.container {
display: flex;
}問題は、狭い画面で折り返す必要があるのに、
.container {
display: flex;
flex-wrap: wrap;
}のような条件まで成立させられていなかったり、別の場所で固定幅を設定してしまったりすることです。
.content {
width: 1200px;
min-width: 900px;
}このような指定が混ざれば、flexやgridを使っていてもモバイルで横にはみ出します。
レスポンシブ用の構文が存在することと、レスポンシブなレイアウトとして成立することは別です。
AI生成コードをレビューするとき、この違いはかなり重要です。
「md:があるから大丈夫」というコードレビューでは足りない
Tailwind CSSを使った生成コードでも考え方は同じです。
<div className="flex gap-4 md:grid md:grid-cols-3">この1行だけを見ると、画面幅による切り替えを意識しているように見えます。しかし、子要素に固定幅がある、親にmin-widthがある、画像が縮まない、長い文字列が折り返せない、といった別の条件で簡単に崩れます。
人間がコードレビューするときも、
flexを使っているgridを使っている- Media Queryがある
- Tailwindのresponsive prefixがある
という「レスポンシブらしい記述の有無」だけでは、最終結果を保証できません。
AI生成コードでは特に、実際にviewportを変えてレンダリングした結果を確認することが重要になります。
たとえば最低限でも、次のように代表的な幅で画面を確認できます。
320px → 表示確認
375px → 表示確認
768px → 表示確認
1280px → 表示確認すべての端末サイズを網羅する必要はありません。まず大きく条件が変わる幅で確認し、その間でもレイアウトが自然につながるかを見る方が実用的です。
AIコーディングでは「生成」ではなく「検証」までを一つの仕事にする
この論文から、AIを使ったフロントエンド開発で特に持ち帰りたいのは、ワークフローの考え方です。
AIへ実装だけを依頼すると、流れは次のようになります。
Generate
↓
完成しかし、実際の表示品質まで扱うなら、次のようなループにした方が合理的です。
Generate
↓
Render
↓
Inspect
↓
Fix
↓
Render againつまり、生成後のレンダリングをacceptance criteriaへ入れるということです。
Cursor、Codex、Claude CodeなどのAIコーディング環境を利用するときも、単に「このデザインを実装してください」で終わらせず、ブラウザを操作できる環境やE2Eテストと組み合わせて、結果を確認させる方向が考えられます。
たとえば、実務向けの指示なら次のように書けます。
このページを実装してください。
実装後、320px、375px、768px、1280pxでページをレンダリングし、
次の条件を確認してください。
- horizontal overflowがない
- テキストやボタンが重ならない
- 重要なUIが非表示にならない
- 画像のaspect ratioが崩れない
- モバイルでdesktopレイアウトを単純縮小しない
問題があれば修正し、同じ条件で再テストしてください。これは論文がこのプロンプト自体を評価した結果ではありません。論文で見つかった主要な失敗原因を、実務の検証条件へ置き換えた例です。
重要なのは「もっと上手にプロンプトを書く」だけに頼らないことです。最終的な画面をテストできるなら、AIが正しいCSSを書いたかを推測するより、正しい表示結果になったかを機械的に確認する方が強いからです。
見た目の再現度が高くても、互換性が高いとは限らない
UI-to-Codeの評価では、元のスクリーンショットへどれだけ似ているかが重要になります。この論文でもCLIP、SSIMなど複数の指標を使って視覚的な再現度を評価しています。
ところが、元デザインへの再現スコアが高い生成方法ほどクロス環境互換性も高い、という単純な関係にはなりませんでした。
これは実務でも注意したい点です。
AIへデザインを渡して生成し、デスクトップ画面を見て、
かなり元デザインに近い。これで完成だ
と判断しても、モバイルでの成立性はまだ確認できていません。
一つのスクリーンショットへの忠実度と、複数環境で壊れないことは別の品質軸です。
UI生成ツールを評価するときも、「一発でどれだけ似た画面が出るか」だけではなく、viewport変更、ブラウザ変更、操作時の状態変化まで含めた品質を見る必要があります。
生成ツールのランキングとしては読まない方がよい
論文では生成方法ごとの互換性問題率にも大きな差がありました。たとえばv0は26%と低く、Direct Geminiは42%、Direct GPT-4は43%だった一方、Cursorや一部のGPT系構成ではより高い問題率が報告されています。
ここだけを切り取って、
v0はGPT-5よりフロントエンド生成能力が高い
と結論付けるのは適切ではありません。
各構成で最終的に評価へ残ったページ数は同じではなく、今回の課題も一般的なReactプロジェクトの保守ではなくScreenshot-to-Code中心の静的ページ生成です。また、製品としての生成結果にはモデル単体だけでなく、scaffold、design system、prompt、agent loop、生成後の補正なども影響します。
この結果から読み取りやすいのは、基盤モデルの性能が上がれば、自動的にクロスデバイス品質も上がるとは限らないということです。
フロントエンド生成では、モデル選択と同じくらい、その外側にある制約や検証ループが重要になります。
AI時代でもフロントエンドエンジニアの「制約を考える力」は残る
AIはCSSプロパティをかなり知っています。flexもgridもMedia QueryもTailwind CSSのresponsive prefixも生成できます。
そのため、単に「このCSSプロパティを知っている」という知識だけなら、AIへ任せられる範囲は広がっています。
一方で、実際のUIでは別の判断が必要です。
このナビゲーションは狭くなったら折り返すのか、別UIへ切り替えるのか。カードの最小幅はどこまで許容するのか。画像は縮小するのか、cropするのか。320pxで表示できない情報が出たとき、何を優先して残すのか。
これらは単独のCSS構文ではなく、画面全体の制約とプロダクト上の優先順位を決める仕事です。
今回の結果は、AIがフロントエンドの「書き方」をかなり知っていても、そのページが成立する条件を常に保証できるわけではないことを示しています。
AIを使うエンジニア側には、実装量を減らすだけでなく、どの条件を満たせば完成なのかを明確にし、それを自動検証できる形へ落とす力がより重要になっていきます。
論文自体も「生成後に検査する」方向へ進んでいる
研究チームは問題を分析するだけでなく、クロス環境互換性問題を自動検出するXCompatも提案しています。
XCompatはDOM、スクリーンショット、viewport情報を組み合わせて問題を検出します。held-outの408比較に対する評価では、Precision 0.917、Recall 0.889、F1 0.903を報告しています。
ここも研究の方向性として興味深いところです。
解決策を、
AIにもっと上手なCSSを書かせればよい
だけにしていません。
生成物を実際にレンダリングし、生成後の結果を自動検査する仕組みまで研究対象にしています。
AIコーディングの信頼性を上げるとき、モデルの出力精度だけを追うより、テストや静的解析、ブラウザ実行など外側の検証器を強くする方が有効な場面は多くあります。フロントエンドでは画面そのものが検証対象になるため、この考え方と特に相性がよいはずです。
この論文から「言えないこと」も整理しておく
実務への示唆が強い研究ですが、適用範囲には注意が必要です。
まず、今回の中心は自己完結した静的single-page Webページです。インタラクションやバックエンド状態へ強く依存するページなどは評価対象から外されています。
そのため、この研究から、
AIが生成したReactアプリの68%は壊れている
とは言えません。
複雑なSPAでは、レスポンシブレイアウト以外にも次のような問題があります。
- hydration
- routing
- async data
- state management
- form
- keyboard / touch interaction
- accessibility
これらを含めた総合的なアプリケーション品質を評価した論文ではありません。
もう一つ重要なのがプロンプトです。研究ではAIへ、クロスブラウザ・クロスデバイス互換性を明示的に保証するよう強く指示していません。著者もこの点をThreats to Validityとして扱っています。
つまり今回の結果は、
特に言われなくても、AIは実用的なクロスデバイス対応まで自然に仕上げてくれるのか
という問いに近いものです。
互換性を明示的な要件として渡し、さらに生成後テストまで実行させれば、結果が改善する可能性はあります。むしろ実務では、その改善余地をワークフロー側で利用するべきでしょう。
まとめ：AI生成フロントエンドでは「実行結果」をレビューする
この論文から得られる一番実用的な教訓は、AI生成コードではコードの見た目より、実行結果を検証する重要性が高いということです。
AIはflexやgridを使えます。Media Queryも書けます。それでも、固定幅や折り返し不足、viewport設定など別の制約が組み合わさると、モバイルでは簡単に崩れます。
したがって、AI時代のフロントエンド開発では、
Generate → Render → Inspect → Fixまでを一つの作業単位として考える方がよさそうです。
モデルへ「レスポンシブ対応して」と頼むことは出発点にすぎません。320px、375px、768px、1280pxなどで実際に表示し、overflowや重なり、消失がないことを確認する。必要ならブラウザ差も確認する。そして問題があればAI自身に修正させて再テストする。
AIがコードを書く速度が上がるほど、エンジニア側では何をもって完成とするかを定義し、それを検証可能にする仕事の価値が上がります。
「AIが正しいコードを書いたか」だけを見るのではなく、「ユーザーが使う環境で正しい結果になったか」まで確認する。この論文は、その当たり前に見える工程がAI生成フロントエンドでも省略できないことを、かなり具体的なデータで示しています。
