参照画像と一致する UI 画面を作る — 現状の方法 / 改善方法 / 先行事例
Generated by Claude Opus 4.8 — 2026年6月2日
「既存ゲームのスクリーンショットを渡す → それと一致する宣言的UI画面(MomijiUI JSON)を作る」という作業(メメントモリ風キャラ画面6面で実証)について、いま回している方法・改善余地・他者の取り組みを整理する。
1. 問題設定
- 入力: 参照画像(実機スクショ。低解像度・スタイライズ前の実写)+ フォルダ階層=画面名。
- 出力: 参照とレイアウトが一致する画面JSON(
MomijiUI、1280×720)。native(kaedevn_game)/web(web-momiji)で同一描画。 - ゴールの粒度: ピクセル完全一致ではなく構造・配置・テキストの一致(立ち絵等の実素材は色プレースホルダで代替)。
2. 現状の方法(今回確立したワークフロー)
参照画像を見る(構造読取)
→ 宣言的JSON を生成 部品(use)/反復(repeat)/算術({{cx+4}}) を使う
→ 展開 expand-components で素のツリーへ
→ 描画 kaedevn_game --capture <png>
→ 目視比較 参照と並べて差を見る
→ 修正 ズレ(色・座標・被り)を直して再描画
→ 検証 momiji-validate / CI
効いている要素
- 既存モックが土台: 解像度・配色・nav/tab・パネル位置が確立済み。新画面はそこに乗せるだけで精度が出る(ゼロから座標を当てない)。
- 部品化機構:
bottom-nav/top-tabs/char-card/card-gridの再利用+repeat+算術で、盤面・カードを少ない記述で正確に量産(01)。 - 即時レンダー&比較:
--captureで1枚撮り、AI(私)が目で照合。cmp/将来の SSIM で回帰も取れる。
限界(正直な評価)
- 精度の最後は AI の目視判断で、自動の閉ループではない。座標はキリのいい値への推定(1px一致ではない)。
- 実写参照とスタイライズ再現の差が大きく、生の画像差分では「寄り具合」を測りにくい。
- 失敗モード(テーマ明色で文字が背景に同化、ボタンが nav に被る)は、今回いずれも描画して見て初めて気づいた。
3. 改善方法(自動化の段階)
| 改善 | 手段 | 効果 | コスト |
|---|---|---|---|
| 回帰の自動化 ✅ | 前回レンダー vs 今回を SSIM(CPU・GPU不要) で比較、閾値割れで fail(tools/screen-regression.mjs 実装済) | 「見た目を壊した」を機械検知 | 小(compare -metric SSIM) |
| 媒体一致の自動化 | 同一JSON の native と web レンダーを SSIM/幾何照合 | マルチプラットフォームのズレ検知([01] F2) | 小〜中 |
| 参照一致のフィードバック ✅実演 | レンダーと参照を ビジョン判定サブエージェント に渡し「どこが違う(element/issue/severity/fix)」を構造化で返す | 目視の自動化。失敗モードを機械が指摘 | 中(モデル呼び出し) |
| 自動詰めループ | 上記フィードバックを ワークフロー化し、合格まで生成→描画→判定→修正を反復 | 人を外せる方向 | 中〜大 |
| 前処理で当てやすく | 参照を OCR でテキスト抽出、グリッド/矩形検出で座標推定、配色を抽出 | 初回生成の精度↑ | 中 |
| アライメント | 実写参照を 1280×720 にリサイズ/クロップ・色正規化してから比較 | SSIM/差分が意味を持つように | 小 |
役割分担の指針
- 回帰(壊れ検知)= SSIM(安い・CPU・決定的)→ CI に常設。
- 参照への寄り具合 = ビジョン/LLM判定(実写とスタイライズ差を吸収できる)。
- 生の SSIM を「実写参照」に当てるのは不向き(絵が違うため低スコア)。SSIM はあくまでレンダー同士に使う。
推奨する次の一歩
- ✅ 実装済:
tools/screen-regression.mjs— 画面を撮り直し、コミット済みベースライン PNG と SSIM 比較(ImageMagickcompare -metric SSIM・CPU・GPU不要)。閾値 0.99 未満で exit 1。--updateでベースライン更新。出力のRAW (NORMALIZED)の NORMALIZED(歪み, 0=一致)を取り類似度 = 1 - 歪みで判定。検証: 無変更→全画面 1.0000、パネル色変更→0.9292 で検知。 - ✅ 実演済: ビジョン判定サブエージェントを立て、各画面のレンダーと参照を比較→
element/issue/severity/suggested_fixの構造化 findings +layout_match(0-100) を返させた(キャラ4画面: 所持78/育成82/プロフィール68/レベリング85)。指摘を反映(育成=装備スロット4→6、プロフィール=2カラム化+ナビ削除、レベリング=リンク枠状態修正)→ プロフィール再判定 68→90(close)。=「判定→修正→再判定」のループを人が手で回した状態。 - ✅ 実演済: Workflow(多エージェント自動オーケストレーション) で自動詰めループを回した。Phase 1=並列ビジョン判定、Phase 2=スコア<目標(88)の画面を逐次リファイン(生成器の該当関数だけ編集→再生成→
momiji-validate→再描画→再判定、最大2ラウンド/生成器が共有ファイルのため逐次)。結果(1回目): 育成 88(到達済→0R)、レベリング 82→88(1R)。各リファインに「その画面の関数だけ・共有部品は触らない・明パネルは暗色明示」を厳命し、生成器破壊や他画面巻き込みを防止。 2回目(参照を高解像度に取り直して): 進化 62→88(1R)、詳細ステータス 58→88(1R)。高解像度参照で初期スコアが下がる(細部の差が見える)=判定が厳しく正確に。詳細ステータスは戦力数値の修正(7,290,110→7,205,110)・左アイコン列追加・装備6→4枠化など実改善。 人の最終確認の価値(重要): ループは layout を 88 に上げたが、リファインがフォント未収録のアイコン字形(⬇⚔♪↻⇅)を挿入してトーフ化した。これは layout_match の自己判定では拾えず、人が描画を見て検知→安全字形/箱に修正した。=「機械が詰める・人がトーフ等の最終品質を見る」の役割分担が実地で確認できた。
4. これは他でもやられているか(先行事例)
やられている。「画像→UIコード」は活発な領域。ただし多くは HTML/CSS 生成が主で、本件のような宣言的UIランタイム+マルチプラットフォーム(native/web)+部品展開は珍しい構成。
注: ツールの機能は変化が速く、以下は一般的傾向。最新の正確な仕様は各公式で要確認。
産業ツール(design/screenshot → code)
- v0 (Vercel): プロンプト/画像から React/Tailwind UI を生成、反復改善。
- Figma → code 系: Figma Dev Mode、Anima、Locofy、builder.io Visual Copilot など、デザイン/画像から HTML/React/Flutter を出力。
- screenshot-to-code 系 OSS: スクショを vision LLM に渡して HTML/CSS/Tailwind を生成する公開実装が複数。
研究・ベンチマーク
- pix2code(2017)・Sketch2Code(Microsoft): GUI スクショ/手描き → DSL/HTML の草分け。
- Design2Code(スクショ→コードのベンチ)など、マルチモーダルLLMでの screenshot-to-code 評価が進む。
- 自己改善ループ: レンダーを撮り直して視覚的に self-refine する手法(render→比較→修正を反復)が論文化されており、本件の「描画して直す」ループと同系統。
本件との違い(差別化)
| 観点 | 一般的な image→code | 本件(kaedevn) |
|---|---|---|
| 出力 | HTML/CSS/React 等 | 宣言的UI(MomijiUI JSON) |
| 実行先 | Web ブラウザ | native(C++/SDL) と web を同一JSONで(マルチプラットフォーム) |
| 再利用 | コンポーネント(コード) | 部品(use)+repeat+算術をビルド時展開(レンダラ無改修) |
| 検証 | 目視/Storybook | momiji-validate+--capture+SSIM回帰(実装済)+(将来)ビジョン |
| 制約 | 自由度高い分ブレやすい | 12ウィジェット+スキーマで生成がブレにくい・検証可能 |
→ 「スキーマで縛られた宣言的UIに落とす」ぶん、Web 自由生成よりブレが小さく・検証しやすく・媒体を跨げる。ゲームUIの量産という用途に噛み合っている。
5. これは「発明」か(独自性の正直な評価)
過大評価しないために線を引く。
個々の要素は新しくない: 画像→UI(v0 等・研究多数)、宣言的UI(Flutter/SwiftUI/React・ゲームUIフレームワーク)、マルチプラットフォーム、コンポーネント。どれも単体では枯れた技術で、特許的なブレイクスルーではない。
うまいのは合成とパッケージング:
- 1枚のスキーマ準拠JSON → native(C++/SDL) と web(Canvas2D) を同一描画(媒体跨ぎ)
- 部品 +
repeat+ 算術をビルド時展開(レンダラ無改修=二重実装・drift なし) - スクショ→生成→展開→描画→検証(SSIM) が一本のパイプライン
- 12ウィジェット+スキーマで生成がブレない・機械検証できる
→ "発明" というより 「狙った仕事(ゲームUIの量産モック)に異常に噛み合った設計統合」。この用途にこの綺麗さで束ねた例は珍しい、は言える。
正直な線引き(ここ重要): 再現できるのは レイアウト(位置と形) で、ゲームロジック・実アート・アニメ・操作の深さは別物。だから「どんなゲームもすぐ実装」は厳密には「どんなゲームの“静的UIモック”も高速に・多媒体で出せる」が正確。ゲームが作れるのではなく、UIモックが爆速で多媒体に出る。それでも企画/デザイン検証・マルチプラットフォームの当たり付け・量産の土台としては十分に価値が高い。
| 問い | 答え |
|---|---|
| 新しい原理の発明か | No(要素は既出) |
| 統合・運用として独自で有用か | Yes(宣言的UI×マルチプラットフォーム×部品展開×検証の束ね方が珍しい) |
| 「どんなゲームもすぐ作れる」か | No。「どんなゲームのUIモックもすぐ多媒体で出せる」が正確 |
| 価値はあるか | 高い(量産・媒体跨ぎ・検証可能という実用面) |
6. まとめ
- 現状は「構造読取→生成→描画→目視比較→修正」の AI 主導ループ。生成は自動、最終判定は目視。
- 改善は「SSIM(回帰・CPU) + ビジョン判定(参照一致) + ワークフロー化(自動詰め)」の三段で、人の目を段階的に外せる。
- 領域としては image→UI は一般的だが、本件の宣言的UI×マルチプラットフォーム×部品展開という形は独自性があり、ゲームUI量産に向く。
この文書は Claude Opus 4.8 が生成しました。ツールの最新仕様や研究状況は人間のレビューで確認してください。
Claude Opus 4.8 — Anthropic