v0の基本的な使い方｜画面生成からコード確認まで

v0は、自然言語からUIやWebアプリを生成し、そのままコード確認・修正・GitHub連携・Vercel公開まで進められるAI開発環境です。

最初は「全部自動で完成させる」より、1画面を作る → Previewを見る → Codeを見る → 修正する、という流れを一度通すと理解しやすくなります。

1. 新しいChatかProjectを作る

v0へsign inし、新しいChatまたはProjectを作成します。

Projectは複数Chatで同じfile system、Vercel Project、environment variables、integrationを共有できます。

小さな試作ならChatだけでも十分ですが、継続開発するならProjectとして管理した方が整理しやすくなります。

2. 作りたい画面を自然言語で伝える

最初のpromptでは、画面名だけでなく、目的、主要section、必要な操作、雰囲気、使いたいframeworkやcomponentまで書くと結果を確認しやすくなります。

3. Previewで画面を確認する

v0は生成後に実行可能なPreviewを表示します。

layout、responsive、buttonやform、text、spacing、errorを確認します。

見た目だけでなく、interactive部分が期待通り動くかも見ることが重要です。

4. Code viewで実装を見る

Code tabへ切り替えると、生成されたfileとcodeを確認できます。

v0は単なる画像生成ではなく、実際のReact / Next.jsなどのcodeを生成します。

5. Design Modeで見た目を調整する

Design ModeではPreview上のelementを選び、styleをvisualに調整できます。公式Docsでは、最新preview runtimeを使う最新chatに限られ、read-only chatsやmobile viewportsでは利用できないとされています。

color、spacing、sizeなどを直接触りながら、変更をsource codeへ反映できます。

6. 小さく修正指示を出す

一度に全面改修を依頼するより、headerだけ修正、buttonだけ変更、mobile spacingを調整、form validationを追加、のようにscopeを限定するとdiffを追いやすくなります。

7. GitHubへ接続する

v0はGitHub repositoryと接続できます。

既存repositoryでは、chatは選択したbase branchから始まり、コード変更時にworking branchが作られて自動commit・pushされます。v0のPublishはPull Requestを作成または再利用し、review、CI、branch protectionの条件を満たすとbase branchへmergeします。repository import時はdefault branchが最初に選ばれますが、別のbase branchも選択できます。mainへ直接pushする仕組みではありません。

既存repositoryをimportして、実際のcodebaseへAI修正を加える使い方も可能です。

8. databaseや外部serviceを接続する

full-stack appではSupabase、Neon、Upstash、Vercel Blobなどのdatabase integrationを追加できます。

AI model、Stripeなどの外部serviceも接続可能です。

9. 必要ならMCPを接続する

v0はMCP integrationに対応しています。

Linear、Notion、Sentryなどの外部toolをつなぎ、project contextや操作をAIへ渡せます。

まずは使ってみる

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

• 

  v0

  公式サイトを見るTool詳細を見る

10. Publish前に確認する

v0からVercelへ直接Publishできます。

公開前にはbuild、responsive、formやAPI、environment variables、秘密情報、authentication、database write、error handlingを確認します。

まず一画面だけを完成させる

v0の使い方を覚える最初の目標は、画面を生成することではなく、要件を伝え、Previewで合否を決め、code差分を確認して修正する一周を終えることです。複数画面、database、認証、決済を最初から同時に頼むと、どこで要件がずれたか分かりにくくなります。問い合わせ管理画面なら、まず一覧画面だけを対象にします。

最初の依頼文は、次の枠を埋めると曖昧さを減らせます。

• 利用者と目的：誰が何を確認する画面か

• 表示項目：一覧に出す列、検索条件、並び順

• 操作：詳細を開く、状態を変える、戻る

• 状態：初期表示、読み込み中、0件、失敗時

• 制約：スマートフォン幅、既存component、使わない外部service

• 合格条件：どこまで動けば今回の作業を完了するか

例：「社内担当者が問い合わせを確認する一覧画面。件名、受信日、対応状態を表示し、状態で絞り込める。データはまだ仮の配列を使い、0件と読み込み失敗の表示も用意。今回はUIだけで、databaseや送信処理は追加しない。390pxと1440pxで列が読め、状態変更ボタンは押した後に表示が変わることを合格条件にする。」これは実際に動作を確認した結果ではなく、読者が試すための依頼例です。

小さな試作ならChatから始め、複数の会話で同じfile systemやVercel project、environment variablesを扱う予定ならProjectを検討します。名称だけで選ばず、作業を継続するか、共有する設定があるかで決めてください。途中で判断できなくても、最初の画面を確認してからProjectへ整理する方法があります。

生成後はPreviewを次の順で見ます。まず一覧が表示されるか、次に絞り込みを変えると結果が変わるか、0件のときに空状態が分かるか、読み込みに失敗したときに操作不能のままにならないかを確認します。表示だけで操作が未実装なら、見た目を整える依頼より先に、どの入力でどの表示へ変わるべきかを一つずつ指定します。

画面幅は390pxと1440pxを目安にし、狭い幅で列が欠けるなら、列を隠すのかカードへ切り替えるのかを決めます。これはresponsive表示の確認であり、実機端末すべてでの品質保証とは別です。Design Modeを使う場合は、対象chatが最新preview runtimeの最新chatであることを確認します。read-only chatとmobile viewportでは利用できません。

修正依頼は一回につき一つの問題に絞り、「状態ラベルの色を変える」より「未対応は灰色、対応中は青色、完了は緑色とし、文字ラベルも残す」のように見た目と意味を同時に指定します。変更後はPreviewだけでなくcode tabも開き、変更したfile、追加package、不要な設定変更、秘密値の直書きがないかを確認してください。生成codeは完成保証ではないため、認証・個人情報・決済・database writeは画面が表示されることだけで合格にしません。

GitHubへ渡す前の確認

接続済みrepositoryでは、作業branch、Pull Requestのbase branch、差分を確認してから取り込みます。mainへ自動的にmergeされると決めつけないでください。main以外を基準にする場合は、そのbranchが選ばれていることを画面とPRで確かめます。Previewで変更の意図が分かること、差分が対象画面に限られること、必要なcheckが通ることを確認してからreviewを依頼します。

公開前の完了票

• 依頼時の合格条件を満たした

• 390px / 1440pxで主要表示を確認した

• 空・読み込み・失敗の状態を確認した

• code差分とdependencyを確認した

• secret、access control、form/API、database更新を確認した

• base branchと公開先を確認した

• 未検証の条件を残課題として書いた

画面の見栄えだけ整い、一覧の絞り込みや失敗時表示が未完成なら、次の画面へ広げず、いまの一画面を完了させるのが先です。逆にUIだけの試作で保存や送信が要件に含まれないなら、その機能を作らず「今回はUI確認まで」と完成範囲を明示すればReader Jobは完了できます。

生成から公開までのチェックを段階で分ける

一画面の試作が動いた後も、同じ合格条件で公開まで判断しないでください。まずUIの動作を通し、次にdataや権限を確認し、最後にdeploy先の設定を確認します。

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

段階	合格にする条件	不合格なら戻る場所
UI試作	表示項目、主要操作、empty/loading/errorが指定どおり	promptを一画面・一操作に縮小
code確認	差分が依頼範囲で、不要dependencyやsecretがない	追加fileとpackageの理由を確認
repository連携	branch、base branch、PR差分が想定どおり	mergeせずbranch設定を直す
data接続	読み書き権限、validation、失敗時の処理が決まっている	仮dataへ戻し、schemaと権限を設計
公開	build、environment、domain、認証、監視、rollback担当が決まっている	previewで止める

たとえば一覧画面の試作なら、画面表示と絞り込みだけを受け入れ、まだ実装していない永続化や通知を「動く」と数えません。database接続が目的に加わった場合は、どのdataを読むか、誰が書けるか、削除や重複送信をどう扱うかを別の要件として書きます。

v0の公式資料は、Promptから画面を生成する操作と、repository連携、full-stack構成、deployをそれぞれ説明しています。これらを一つの機能とみなさず、段階ごとに検証することで、Previewが表示されたことをproduction-readyの証拠にしない判断ができます。

画面が意図どおりにならないときの修正順

問題を一度に全部直そうとせず、「どの入力で、何が起きて、何を期待するか」を三点で伝えます。たとえば絞り込み後に一覧が変わらないなら、対象の状態値、操作、期待する表示件数を示し、まず絞り込みだけを直します。入力が空でも同じ問題が起きるか、読み込み中や0件で表示が崩れないかも分けて試します。

• 表示位置だけの問題：対象要素、幅、期待位置を指定

• 操作後の状態が変わらない：入力値、期待する状態、現在の表示を指定

• build error：エラー全文ではなく該当箇所と直前の変更を確認

• 依存の追加を求められた：必要性と既存機能で代替できない理由を確認

直ったように見えても、別操作を壊していないか同じ受入条件を再実行します。未実装の保存や認証を画面の動作だけで合格にせず、次の工程と担当者を記録してください。

AIものさしの判断

v0を覚える最短ルートは、Prompt → Preview → Code → 修正 → GitHub → Publishを一度通すことです。

最初からdatabaseやMCPまで全部使わず、まず1画面を生成してcodeを読む。その後、full-stack機能やagentic featureを追加する方が理解しやすくなります。