AI UI自動修正が失敗する理由と究極の解決策

@Lonely__MH
中国語2026年9月13日
185K
241
36
58
483

TL;DR

著者は、AI駆動のUI自動修正がなぜしばしば品質低下を招くのかを検討し、視覚的差分(ビジュアルディフ)、構造化された診断、そして歴史的なベストバージョンの保持を組み合わせたワークフローを提案しています。これにより、結果の安定性を確保します。

この記事では、AI を使ってページを再現する際に直面したいくつかの落とし穴について記録しています。その後、これらの問題を解決するためのワークフローを構築し、プロセス全体を整理して共有します。

あなたも同じ経験をしたことがあるかもしれません。

スクリーンショットを AI に渡して、「これに基づいてページを作って」と頼むことがあります。最初のバージョンは一見それっぽく見えますが、よく観察すると違和感があります。カードが少し広かったり、フォントが小さかったり、影の表現が違ったり——些細な問題ばかりです。

そうなると、どこをどう調整すべきか言葉で説明しなければなりません。修正と確認を繰り返すのに、かなり時間がかかります。

そこで私は、レンダリング、スクリーンショット撮影、比較、修正を一連のワークフローとして繋ぎ、モデル自身にチェックと修正を行わせることを考えました。このアプローチは理にかなっているように思えました。

しかし実際には、計画通りには進みませんでした。2 回目の修正後に 3 回目で変更が元に戻ってしまったり、結果が安定せず、反復を重ねるたびにページが悪化してしまうことさえありました。

結論から言いましょう。

自己修正を可能にする方法

プロセス自体は複雑ではありません。

text
1ターゲットのスクリーンショット ──▶ モデルが HTML を作成 ──▶ ブラウザで 1:1 のスクリーンショットを撮影 ──▶ ピクセル単位の差分(Diff)生成
2
3ベスト履歴の保持 ◀── 再レンダリング ◀── モデルが診断しコードを編集 ◀── 原画 + レンダリング画像 + Diff

Diff はモデルのためにページを直接修正するわけではありません。「なんとなく違う」を具体的な偏差の視覚的マップに変換し、それをモデルにフィードバックして次のステップを判断させるだけです。

モデルが Diff だけで闇雲に推測しないよう、各修正の前に以下の 3 つの質問に答えることを必須としています。

  1. 最も大きな問題はどこか?
  2. その原因となった可能性が高い要素や CSS プロパティはどれか?
  3. どう修正する予定か?

これらに回答してから初めて、コードに触れます。

今回のテストでは Ling-3.0-flash-VL を使用し、シンプルなデモ用に 2 つのカードを選択しました。1 つは明るい背景、太い黒枠、ハードシャドウ付きの黄色いカード。もう 1 つはグラデーションボタン、タグ、機能リストを含む暗い SaaS 価格カードです。

カードは最適だと考えています。要素数は多すぎず、幅、余白、ボタンの向き、影など——一つでもズレがあればすぐに気づけるからです。

初回実行

まずは黄色いカードから始めます。

最初のバージョン後、全体的な結果は実際になかなか良いものでした。

構造、配色、コピー、ボタンの位置はほぼ再現できていました。原画と並べて比較しなければ、「十分近い」と思うレベルです。

しかし並べてみると、微妙な差異が見えてきます。カードがわずかに大きく、フォントの太さが異なり、余白やボタンのサイズも完璧には一致していません。

そこで、原画、第 1 ラウンドの結果、そして Diff を Ling に再び入力し、これらの詳細な問題を特定させました。

診断結果を見ると、単に「似ていない」と言うだけでなく、カードサイズ、フォント、ボタンなどの問題をピンポイントで指摘し、対応する CSS を修正しています。

Lonely - inline image

黄色いカードの 3 ラウンド比較:第 2 ラウンドで改善しましたが、第 3 ラウンドで退行したため、歴史的ベストとして第 2 ラウンドを採用しました。

ただし、初回が良くても継続的な改善を保証するものではありません。

この動画はその問題点を捉えています。第 2 ラウンドは原画により近づきましたが、第 3 ラウンドでやや後退しました。幸い、ワークフローは最終ラウンドを自動的に正解とするのではなく、第 2 ラウンドの歴史的ベストを保持していました。

つまり、Diff をフィードバックしても、モデルが突然賢くなるわけではないということです。多くの詳細な問題を発見し、判断を具体的な CSS にマッピングできますが、それでも混乱することはあります。

ワークフローの実行方法の詳細については、以下の画面録画をご覧ください。

Lonely - inline image

暗い価格カードのフルデモ:アセット選択、初期生成、スライダーによる比較、そして 2 回の自己修復ラウンドの実行。

ここでの変化は劇的ではありませんでした。なぜなら、第 1 ラウンドで既にかなり近かったからです。その後のラウンドでも改善は続き、カードサイズ、角丸、ボタン、グラデーションなどに焦点が当てられました。

両方の録画を比較すると、異なる傾向が見られます。

Lonely - inline image

黄色いカードは第 2 ラウンドまで改善しましたが、第 3 ラウンドで退行しました。一方、暗いカードは 3 ラウンドを通じて着実な小幅な改善を示しました。2 つの録画だけでは統計的な規則性を証明できませんが、同じワークフローでも毎回必ずしもより良い結果になるとは限らないことがわかります。

明白な問題は通常、最初の 1〜2 ラウンドで修正されます。その後の反復では、フォントサイズ、角丸、影のオフセットなどの微調整が行われますが、一つを直すと別のところが崩れることがよくあります。そのため、私は最後のラウンドを正解とするのではなく、歴史的ベストを保存しています。

実際に何ができるのか?

これらの結果から、最初のバージョンは標準的な「Screenshot-to-Code(スクリーンショットからコードへ)」です。興味深いのは、レンダリングされた出力を見た後、単に「もっと似せて」と言うのではなく、問題を特定の要素や CSS プロパティに絞り込める点です。

自動修正がなくとも、この診断ステップは有用なチェックリストとして機能します。

多くの視覚的な問題はエラーを引き起こしません。モデルがブラウザの実際のレンダリングページを見ることができれば、自ら修正を続けるチャンスがあります。

もう一つの重要な点は、このワークフローはモデル呼び出しを繰り返す必要があり、速度が重要になることです。私が記録した単一のフルページ HTML 生成は約 7 秒かかりました。公開データによると、Ling-3.0-flash-VL は総パラメータ数 124B で、推論ごとに 5.5B がアクティブになり、視覚理解と Visual Agent 機能が追加されています。

7 秒という数字は、私の特定のインターフェースと設定に基づくものです。横断的な比較は行っていませんし、アクティブパラメータのみから速度やコストを導き出すことはしません。

落とし穴はどこにあるのか?

本当の時間の無駄はモデルとの接続ではなく、フィードバックの精度を確保することでした。当初は変動の原因がモデルの不安定性にあると思っていましたが、Diff を一つずつ確認していくうちに、問題の一部が私のフィードバックループにあることに気づきました。

1. 第一の落とし穴:サイズ

ターゲット画像がスケーリングされ、ブラウザのスクリーンショットが異なるサイズで撮影されると、画像は最初から整合性が取れません。正しい答えがあったとしても、Diff では大きな差異が表示されてしまいます。

ピクセル差分の場合、グローバルに数ピクセルずれるだけで、巨大なエラーゾーンが発生します。

2. 第二の落とし穴:アニメーション

ある時、モデルは機能リストにフェードイン効果を追加しました。アニメーション途中のスクリーンショットでは、コンテンツが透明になってしまいました。

アニメーションを削除した後、ページは視覚的には正常に見えましたが、自動比較スコアは悪化しました。

理由:透明なコンテンツによって背景が見えるようになり、ピクセルアルゴリズムが「より似ている」と誤認してしまったためです。

3. 第三の落とし穴:バージョン管理

あるラウンドでデザインが壊れた場合、悪いコードの上にさらにパッチを当て続けると、エラーが積み重なります。歪んだ土台の上に建物を建てるようなもので、努力すればするほど状況は悪くなります。

要するに、Diff はツールであり、審判ではありません。

フィードバックが間違っていれば、モデルはそれに気づけません。欠陥のある入力に基づいて、間違った方向を熱心に修正しようとするだけです。

結論

ルールを 3 点に集約しました。

  1. 原画とブラウザのスクリーンショットは同一寸法を使用し、二次スケーリングは行わない。
  2. ビューポート、フォント、アニメーション状態、スクリーンショットのタイミングを固定する。
  3. 各ラウンドでは歴史的ベストバージョンから継続し、劣化したコードにパッチを当てない。

動作するコードはあくまで第一歩です。エラーにならないけれど見た目が変な問題は、確かに視覚モデルでチェック可能です。しかし、偏差が見えたからといって、毎回正しく修正できるとは限りません。

だから私は、ラウンド数を増やせば結果が良くなるとはもう想定していません。明白な問題を先に修正し、改善が頭打ちになったら止める——それで十分だと考えています。

モデルはオープンソースで、2 週間無料です。自分で試してみたい場合は、以下のリンクをご利用ください 👇🏻:

追伸:この記事は AI に口述し、推敲してもらったものなので、魂が宿っています ✌🏻

ワンクリック保存

YouMindでバイラル記事をAI深読み

ソースを保存し、的を絞った質問をし、主張を要約して、バイラル記事を再利用できるノートに変えます。すべてを1つのAIワークスペースで行えます。

YouMindを探索
クリエイターのために

あなたの Markdown をきれいな 𝕏 記事に

自分の長文を投稿するとき、画像・表・コードブロックを 𝕏 向けに整形するのは手間がかかります。YouMind は Markdown 全体を、そのまま投稿できるきれいな 𝕏 記事に変換します。

Markdown → 𝕏 を試す

解読すべきパターンをもっと

最近のバイラル記事

バイラル記事をもっと見る