← MomijiUI ドキュメント

参照画像と一致する 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 はあくまでレンダー同士に使う。

推奨する次の一歩

  1. 実装済: tools/screen-regression.mjs — 画面を撮り直し、コミット済みベースライン PNG と SSIM 比較(ImageMagick compare -metric SSIM・CPU・GPU不要)。閾値 0.99 未満で exit 1。--update でベースライン更新。出力の RAW (NORMALIZED) の NORMALIZED(歪み, 0=一致)を取り 類似度 = 1 - 歪み で判定。検証: 無変更→全画面 1.0000、パネル色変更→0.9292 で検知。
  2. 実演済: ビジョン判定サブエージェントを立て、各画面のレンダーと参照を比較→element/issue/severity/suggested_fix の構造化 findings + layout_match(0-100) を返させた(キャラ4画面: 所持78/育成82/プロフィール68/レベリング85)。指摘を反映(育成=装備スロット4→6、プロフィール=2カラム化+ナビ削除、レベリング=リンク枠状態修正)→ プロフィール再判定 68→90(close)。=「判定→修正→再判定」のループを人が手で回した状態。
  3. 実演済: 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、AnimaLocofybuilder.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+算術をビルド時展開(レンダラ無改修)
検証目視/Storybookmomiji-validate--captureSSIM回帰(実装済)+(将来)ビジョン
制約自由度高い分ブレやすい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

Ad: inContent (336x280)
Ad: stickyBottom (728x90)
kaedevn - ノベルゲームを作れるプラットフォーム