JUSTWIT WORKS

はじめに

デザイナーがいない個人開発・小規模開発では、UIの「なんかダサい」を自力で言語化して直す必要があります。ここ数ヶ月のアプリ・Webサイト開発で定着したのが、スクリーンショット駆動のデザイン反復です。

実装 → スクリーンショット撮影 → 生成AIに批評させる → 修正、のループを回すだけですが、いくつかのコツで効果が大きく変わります。

なぜスクリーンショットを見せるのか

生成AIにコードだけ見せて「このUIを良くして」と頼むと、コードから想像した一般論が返ってきます。実際の描画結果を見せると、指摘が具体化します。

コードだけの場合:

「余白を調整し、視覚的階層を明確にすると良いでしょう」

スクリーンショットを渡した場合:

「統計カードの数字とラベルの距離が近く、4つのカードが1つの塊に見える。数字を700ウェイトにし、カード間の罫線を消して余白で区切ると階層が出る」

後者はそのまま実装に落とせます。批評の解像度は入力の解像度で決まります。

ループの基本形

1. 実装する
2. 実機相当のスクリーンショットを撮る（複数画面サイズ）
3. 生成AIに「診断」させる（修正はまだ）
4. 指摘に優先度を付けさせ、人間が採否を決める
5. 採用分だけ修正指示 → 1に戻る

重要なのは 3と4を分けることです。診断と同時に修正させると、指摘の妥当性を検討する前にコードが変わってしまい、良し悪しの判断が「差分を見てから後付け」になります。

診断させるときのプロンプト

漠然と「どう思う?」と聞くより、観点を固定すると安定します。

このアプリ画面のスクリーンショットを、次の観点で診断してください。
1. 視覚的階層: 最初に目が行くべき要素に行くか
2. 余白のリズム: 詰まりすぎ/空きすぎの箇所
3. 一貫性: 角丸・影・色使いの不統一
4. タイポグラフィ: サイズ・ウェイトの段階が機能しているか
各指摘に重要度(高/中/低)と、修正案を1行で添えること。
「悪くない」で済ませず、必ず改善候補を5つ以上挙げること。

最後の一文が意外と重要で、これがないと当たり障りのない褒め言葉で終わることがあります。

デザイントークン化とセットで回す

このループの効果を最大化するのが、先にデザイントークンを整備しておくことです。色・角丸・影・字間を CSS 変数や Flutter の ThemeExtension に集約しておくと、生成AIの修正指示が「トークンの調整」に収束し、画面ごとのバラつきが生まれません。

実際、サイトのカラーパレット刷新（ブラウン基調→チャコール×ブラス）は、トークンが集約されていたおかげで置換対象が実質1ファイルで済みました。トークン化されていなければ、全ファイル横断の書き換えになっていたはずです。

さらに、決めた原則を DESIGN.md のような規約ファイルに書いておくと、以後の生成AIの提案がその世界観に沿ったものになります。「環境光は1画面に1つ」「ウェイトは400/700のみ」のような制約は、書いた瞬間から効き始めます。

複数案を「実物」で比較する

配色やレイアウトの方向性で迷ったときは、モック画像ではなく実装済みの画面にスタイルを注入して実物のスクリーンショットで比較します。Web なら Playwright で CSS 変数を上書きして撮影、Flutter なら ThemeExtension を差し替えたビルドバリアントで撮影できます。

// Playwright: パレット候補をCSS変数の上書きで実サイトに適用して撮影
await page.addStyleTag({ content: `
  :root { --ink: #0E1B2C; --accent: #4A7BB5; }
` })
await page.screenshot({ path: 'palette-navy.png' })

Figma モックとの決定的な違いは、実データ・実フォント・実レイアウトの上で比較できることです。「モックでは良かったが実装したら違った」が起きません。

崩れの機械検出も同じループに乗せる

デザイン批評と同じ仕組みで、レイアウト崩れの検出もできます。

document.documentElement.scrollWidth - clientWidth で横スクロール検出
全ページ × 複数幅（390 / 768 / 1440px）で自動スクリーンショット
生成AIに「テキスト見切れ・ボタンはみ出し・重なり」を列挙させる

リリース前チェックとして数分で全画面を走査できるので、目視レビューの負荷が大きく下がりました。

限界と使いどころ

このワークフローで上がるのは「破綻のなさ」と「一貫性」であって、独創的なアートディレクションは出てきません。ゼロからの世界観づくりは依然として人間（またはデザイナー）の仕事です。

一方、「プロがレビューしたら10分で指摘されるレベルの粗」を開発サイクル内で潰し続けられるのは大きく、デザイナー不在プロジェクトの品質底上げ手段としては現状もっとも実用的だと感じています。

まとめ

コードではなくスクリーンショットを見せると批評の解像度が上がる
診断と修正を分離し、採否の判断は人間が握る
デザイントークン + 規約ファイルの整備がループの効果を最大化する
方向性の比較は「実物にスタイル注入」で行うとモックとのギャップが出ない
崩れ検出も同じループに乗せてリリース前チェックを自動化できる

スクリーンショット駆動でUIを磨く — 生成AIとのデザイン反復ワークフロー