v0でできること・向かないこと

v0はUIやfull-stack applicationのcodeを生成し、Previewで確認・修正しながらGitHubやdeploymentへつなげるAI agentです。生成物が要件どおり動く保証ではないため、code reviewとtestは別に行います。

UIを自然言語から生成できる

landing page、dashboard、form、pricing page、admin UIなどをpromptから生成できます。

wireframeやmockupをinputにして、高精度なUIへ展開する使い方もできます。

実際のcodeを編集できる

生成結果はPreviewだけでなくCode viewから確認できます。

自分でcodeを修正することも、v0へ追加修正を依頼することもできます。

full-stack appを作れる

v0はfrontendだけでなく、backend endpoint、server action、database connectionなどを含むfull-stack applicationへ展開できます。

公式DocsではNext.jsをdefaultとして、Supabase、Neon、Upstashなどのdatabase integrationを案内しています。

Design Modeでvisual editできる

Preview上のelementを選び、styleをvisualに編集できます。ただし公式Docsでは最新preview runtimeの最新chatに限られ、read-only chatやmobile viewportでは利用できません。

design調整をcodeだけで行わず、見た目からsourceへ反映できます。

GitHubと連携できる

existing repositoryをimportできます。

選んだbase branchからworking branchが作られ、コード変更は自動commit・pushされます。PublishではPull Requestを作成または再利用してbase branchへmergeします。review、CI、branch protectionでPublishが止まる場合があります。

Vercelへ直接deployできる

Publish操作からproduction deploymentを作成できます。

Vercel Project、custom domain、environment variables、monitoringなどへつなげられます。

databaseや外部APIを使える

Marketplace integrationやenvironment variablesを通してdatabase、payment、AI model、external APIなどへ接続できます。

MCPを使える

v0はMCP Serverへ接続できます。

Linear、Notion、Sentryなどのproject contextや外部toolをAIへ追加できます。

terminal commandを実行できる

agentic featureではsandbox内でshell commandを実行し、test、repository調査、CLI操作などを行えます。

permission modeでどこまで自動実行を許可するかをcontrolできます。

向かないこと：生成したcodeを無reviewでproductionへ出す

securityやbusiness logicまで自動的に保証されるわけではありません。

authentication、payment、database migration、secret handlingは人間がreviewすべきです。

向かないこと：完全にcode-firstだけで運用したい

v0はchat、preview、visual edit、agentを中心としたworkflowです。

すべてをlocal editor、CLI、Git commandだけで管理したいteamでは、既存IDE + coding agentの方がworkflowへ合う場合があります。

向かないこと：Vercel以外のinfraを中心にしたい

生成codeを別環境へ持ち出すことはできますが、v0のdeployment、project、environment variables、MarketplaceはVercelとの統合が深いです。

向かないこと：完全にdeterministicな生成を求める

厳密なcomponent仕様、design system、security policyがある場合は、promptだけでなくrepository rule、review、test、design referenceを組み合わせる必要があります。

まずは使ってみる

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

• 

  v0

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

機能名ではなく、完成させたい作業で向き不向きを見る

v0でできることを機能名だけで判断すると、Previewに画面が出た段階を「アプリが完成した」と誤解しがちです。先にReader Jobを具体化し、必要な出力と失敗時の責任を並べます。

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

やりたいこと	v0を試す価値がある条件	別の工程・担当が必要な条件
画面案を作る	文言・入力項目・画面幅を指定できる	既存Design Systemとの完全一致が必須
既存repoの改修	対象file、base branch、変更範囲を説明できる	大規模migrationや全体architecture変更
dataを保存する	database、権限、validationを定義できる	法規制・監査要件が未整理
外部service接続	必要scopeとsecret管理者が決まっている	接続先のcontract・責任者が不明
production公開	test、security review、運用ownerがある	性能保証・無停止運用をAIだけへ委ねたい
厳密な再現	受け入れ条件やtestを用意できる	決定論的な同一outputを無reviewで要求

小さく試すときは、ツールの機能を列挙する代わりに一つの作業を完了条件へ分解します。例として「社内の架空問い合わせを一覧表示し、状態で絞り込み、担当者が詳細を確認できるUIを作る」なら、入力項目、表示状態、操作、画面幅、今回実装しない機能を先に書きます。合格条件は「画面が表示される」ではなく、絞り込みが一覧を変える、0件時に案内が出る、詳細へ移動して戻れる、狭い幅でも必要情報が読める、のように観察できる形にします。これは評価用の例であり、特定versionで実際に操作した結果ではありません。

作業を始めた後は、失敗の種類ごとに次の一手を変えます。

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

症状	最初に切り分けること	次に行うこと
画面の意図が伝わらない	役割、表示項目、操作が混ざっていないか	一画面分の目的と入力・出力へ縮小
buttonが見た目だけ	状態変更や保存の要件を明示したか	操作後の期待状態を指定して再依頼
dataが保持されない	仮dataかdatabase連携済みか	永続化の範囲と失敗時表示を定義
layoutが崩れる	対象幅、長い文字、empty state	再現幅・崩れる要素・期待表示を伝える
build / deployで失敗	差分、log、環境変数、依存関係	変更を分けて原因を一つずつ確認
securityが不安	認証、権限、入力検証、secretの場所	公開せずreview担当へ渡す

v0を試す前後の判断票

試す前に「今回必要な機能」「既存repoを変更してよい範囲」「データをどこへ保存するか」「誰がreviewするか」を記録します。試した後は、要件ごとにPass / Fail / 未検証を付け、Failと未検証を次の作業として残します。見た目の満足度だけでまとめず、Reader Jobの完了条件に対して何ができたかを示します。

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

受け入れ項目	結果	証跡
目的の画面と表示項目	Pass / Fail / 未検証	画面名、要件
主要操作と状態変化	Pass / Fail / 未検証	入力と期待結果
空・失敗・読み込み状態	Pass / Fail / 未検証	再現条件
既存codeへの影響	Pass / Fail / 未検証	fileとdiff
認証・権限・secret	Pass / Fail / 未検証	確認者
公開・運用責任	Pass / Fail / 未検証	担当と残課題

向いている人は、UI案から動くcodeへ進み、生成物の確認と修正を自分またはteamで引き受けられる人です。画面の試作だけなら、生成・Preview・code確認までを範囲にして終了できます。databaseやintegrationが必要なら、data flowと権限を決めてから追加します。security、権利、payment、顧客dataを扱うproductionなら、v0を採用するかとは別に、専門担当のreviewと受け入れtestが必要です。v0のOutputは完全性や用途適合が保証されていないため、重大な障害をAIが自動で防いでくれると期待せず、運用を支える人と手順がない場合は、まず小さな試作に限定してください。

15分で試作の向き不向きを判断する

導入前に大きなapplicationを作らず、失敗しても捨てられる一つの画面で確認します。架空dataを使い、合格条件と対象外の機能を先に決めます。

1. 5分：目的、利用者、表示項目、操作、対象幅を短く書く

2. 5分：画面を生成し、主要操作を一つだけ確認する

3. 3分：code差分と変更file、dependency、secretの有無を確認する

4. 2分：要件ごとにPass / Fail / 未検証を記録し、次の担当を決める

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

評価軸	合格の目安	保留にするサイン
目的達成	指定した主要操作が期待状態へ変わる	見た目だけで操作が動かない
修正の追跡	依頼とdiffの対応が分かる	無関係なfileまで大きく変わる
運用へ渡せるか	review ownerと公開先が決まっている	公開・data責任が未定

15分試験は性能比較やsecurity監査ではありません。候補の適合性を見る入口です。合格しても、production採用前には通常のcode review、test、accessibility・security確認が必要です。失敗した場合は、prompt改善で解決する問題か、既存IDEや専門担当が必要な問題かを分けてから次へ進みます。

AIものさしの判断

v0が強いのは、Prompt → Preview → Code → database / integration → GitHub → Deployを一つの環境へまとめられることです。

Web productを高速に試作し、そのまま実装へ育てたい場合に使いやすい一方、production品質の最終判断まで丸投げするtoolではありません。