v0で既存デザインをもとにUIを作るときの進め方

v0で既存デザインをもとにUIを作るときの進め方。v0などを対象に、向き不向きが分かるように整理します。

AIものさし編集部

既存デザインをもとにv0でUIを作るときは、画像をそっくり写すことより、画面の構造と必要な振る舞いを分けて伝えることが大切です。Figma linkが使えるなら、視覚情報に加えて色やspacingなどのdesign contextを読み取る助けになります。画像しかない場合は高解像度のscreenshotを添え、画像では分からない操作条件を文章で補います。

最初から画面全体を完成させようとせず、ナビゲーション、一覧、フォームなど意味のある部品から作り、個別に確認してから組み合わせます。元デザインの意図、実装で守る制約、未確定の挙動を分けておけば、生成結果を直す際も「見た目が違う」だけでなく、どの情報が足りないか判断できます。以下は既存デザインをWeb UIへ移すための作業手順です。生成精度を実測した内容ではありません。

参照画像の前に目的と完了条件を決める

作業に入る前に、画面を使う人とその画面で完了する仕事を一文にします。たとえば申込フォームなら「初めての利用者が必要情報を入力し、送信前に内容を確認できる」です。目的が決まると、元デザインにある要素のうち、維持するものと変更してよいものを分けられます。

元デザインの所在も確認します。Figmaの特定frameを共有できるか、画像として書き出す必要があるか、複数状態の画面があるかを整理します。v0公式DocsはFigma連携でvisual layoutやdesign tokenなどを読み取り、screenshot入力では画像のlayout、色、componentを解析する方法を案内しています。ただし、画像からボタン操作後の結果や入力規則まで確定できるとは限りません。behaviorは別の文章で示します。

Figmaとscreenshotの選び方

Figma fileを使えるなら、目的のframeやnodeを指定し、複雑な画面は主要componentに分けて扱います。画面全体が一枚の大きなframeに詰まっている場合は、navigation、form、一覧などを個別に確認してから組み立てる方法があります。公式ガイドも、管理できるcomponentへ分けて反復する手順を推奨しています。既存のdesign systemがある場合は、それを正本として色や文字階層を指定します。

screenshotしかない場合は、画面全体の関係が必要なら全体を、細部の修正なら対象箇所を切り出します。文字が読めないほど小さい画像、余白が切れた画像、複数の状態が混ざった画像は、生成側が誤った構造を捉える原因になります。スマートフォンとPCで構造が違うなら、両方の画像か、どの項目を移動・省略するかの説明を用意します。PCの画像を渡して「レスポンシブに」とだけ頼んでも、画面幅ごとの優先順位は決まりません。

表は横にスクロールできます

作業前に見るもの具体的な確認不明な場合
画面の目的利用者が何を終えるか先に業務担当へ確認
参照元frame、node、画像の範囲元データの所在を確認
固定条件色、ロゴ、文字階層、幅固定か参考かを区別
操作入力後の画面、エラー、取消仮の挙動と明示する
対象幅PC・mobileで残す情報未確定として別に扱う

この表は準備用です。小さな見た目修正にすべての項目が必要という意味ではありません。機能を含む画面なら、画像だけで不足する挙動や例外を補うために使います。

部品へ分けるときは変更理由で考える

component分けはファイル数を増やすためではありません。独立して確認する、複数画面で再利用する、異なる状態を持つといった理由で境界を決めます。申込画面なら共通header、入力form、住所検索、確認表示、送信状態のように、役割が異なる部分を分けられます。小さな文字やiconまで別々に生成すると、全体の調整が増えるため、主要領域から始めます。

最初にcontainer幅と大きなlayoutを作り、次に主要component、続いて入力・選択などの状態、最後に装飾を調整します。画面全体を一気に再生成すると、良かった部分まで変わり、修正の影響を比較しにくくなります。component単位でPreviewし、最後に結合した状態を確認します。共通componentが変更されたときは、そのcomponentを使う他の画面も回帰確認します。

見た目とbehaviorを別々に指示する

Figmaやscreenshotは色・形・配置の参考になりますが、操作による変化までは十分に示しません。ボタンを押した後にページ遷移するのか、dialogが開くのか、同じ画面でエラーが出るのかを説明します。「送信ボタンを置く」だけでなく、「必須項目を満たすまでdisabledにし、送信後は完了表示へ切り替える」のように状態と結果を結び付けます。

デザインの条件は必須と参考に分けます。「ロゴとブランド色は変えない」「余白は参照frameに近づける」「本文幅は既存サイト規則に合わせる」と書けば、どこに裁量があるか伝わります。色tokenや文字サイズの値が分かるなら明示します。不明な値を画像だけから正確に読み取れると仮定せず、見た目を見ながら調整する条件として扱います。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

依頼文の例は次の通りです。

> 目的:利用者が申込内容を入力し、送信前に確認する画面。

> 参照:添付した申込フォームのFigma frame。

> 固定:ロゴ、主要色、見出し階層。

> 変更可:入力欄の余白。

> 挙動:必須項目が未入力なら送信不可、エラーを該当欄の近くに表示。

> mobile:項目順を維持し、補足説明は入力欄の下へ置く。

> 確認:未入力、入力エラー、確認、送信完了の各状態。

この例は整理の出発点です。既存アプリのroute、component、API仕様、アクセシビリティ条件は必要に応じて追加し、未確定事項を事実のように埋めないでください。

Previewで元デザインと実装を比較する

Previewでは雰囲気だけでなく、比較する箇所を決めます。header高さ、container幅、見出しの折返し、buttonの配置、画像crop、入力欄同士の間隔などを同じ画面幅で見ます。FigmaのframeとPreviewの表示幅が違うと、余白の差を実装ミスと取り違えることがあります。

次に操作を確認します。入力の必須条件、初期選択、エラーの場所、取消後の状態、送信中の二重操作を見ます。元画像にない挙動を仮置きした場合は、デザイン確定事項と実装上の仮定を区別します。業務上、誤送信や二重登録が問題になるなら、確認画面や送信中の制御も設計に含めます。

修正は確認可能な単位で一つずつ行います。「幅を参照frameに合わせる」「補足文を入力欄の直下に移す」「エラーを入力欄と関連付ける」など、何を見て成功とするかを伝えます。余白、色、操作を同時に変更するより、原因と結果を追いやすくなります。

Responsiveは情報の並べ替えから設計する

PCとスマートフォンで同じ要素を縮小するだけでは、読みづらくなることがあります。PCでは一覧と補足欄を並べられても、mobileでは主要操作を上に置き、説明を折りたたむ必要があるかもしれません。情報を「必ず残す」「順番を変える」「詳細へ移してよい」に分類します。

表をcardへ変えるなら、値と項目名の対応関係を維持し、状態や期限など重要情報が最初に読めるようにします。固定headerや画面下のbuttonは、入力欄や説明を覆わないか確認します。日本語の長いラベル、エラー文、複数行のbuttonも試し、横overflowだけでなく、操作対象が押しにくくなっていないかを見ます。

公開前の確認と失敗の切り分け

生成後は、初期状態だけで完成扱いにしません。少なくとも通常表示、入力エラー、送信中または保存中、完了後、小さい画面を確認します。キーボードで移動できるか、focusが見えるか、入力欄にlabelが付いているかも確認対象です。見た目が参照に近いことと、操作が利用できることは別の条件です。

画面が崩れた場合は、どの部品で差が生じたか記録します。画面全体の余白ならcontainer、buttonの折り返しなら文言や幅、エラー位置ならformの構造というように原因候補を絞ります。behaviorの問題なら画像入力を増やすのではなく、操作条件を文章で補います。未確認の状態は「未確認」とし、生成結果を実測したように書きません。

AIものさしの判断

v0へ渡すデザインは完成コードの正解ではなく、視覚と構造の根拠です。Figmaがあればframeやdesign tokenを活用し、screenshotだけなら画像にない操作条件を文章で補います。主要componentから作り、状態とresponsiveを別々に確認することで、見た目の再現と利用者の仕事を両立しやすくなります。

最終判断では、元画像との近さだけでなく、入力・エラー・成功後の流れが成立するか、既存design systemへ統合できるかを見ます。画像から分からない挙動を想像で確定せず、未確定事項を切り分けて扱うことが手戻りを減らします。 Reference frameに複数の状態がある場合は、どの画面が初期状態でどれが操作後かも明記し、違う状態を一つの完成画面として混ぜないようにします。

差異の記録には参照frame、実装側の表示幅、異なる部位、次の修正条件を残します。これなら別の人も同じ観点で比較できます。

引用・データ出典

次の一手

記事の内容を踏まえて、公式とTool詳細から続けられます。

次に読む・使う

この記事の次に必要な情報へ進めます。