v0を本番前に使うなら：Project・Environment Variables・GitHubを分ける基準

3行まとめ

このテーマをもう少し広げて見るなら、OpenAI Agents SDKのtool guardrailsを実務に入れる前に：handoff・built-in tools・人間承認の分け方 と AIコーディングエージェントのprompt injection対策：Issue・Docs・MCPを読ませる前に決めること も合わせて確認してください。v0で生成、連携、公開まで進める前に、人間承認とtool実行の境界を補えるため

Chat

生成と試行錯誤の単位。

Project

Vercel資源の単位。

Env

API keyや接続情報。

Deploy

previewとproduction。

v0は生成とdeployが近いので、Vercel project単位で整理します。

• v0は自然言語からUIやfull-stack appを生成し、Vercel projectとしてdeployできるAI-powered development platformです。
• 本番前に使うなら、v0 chat、Vercel project、environment variables、GitHub、design system、deploymentsを分けて扱います。
• 生成UIがきれいでも、project scopeのenv vars、GitHub PR review、preview/production deployment、accessibility、data flowを人間が確認します。

本文の事実確認には、v0公式docsのWhat is v0、Projects、Vercel Integration、Deployments、GitHub、Environment Variables、Design Systems、およびVercel公式environment variables docsを使っています。Xで見かけるv0、shadcn/ui、Vercel deploy、design system連携への投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Project

chatとprojectの関係。

Vars

環境変数のscope。

GitHub

PR reviewへ戻す。

Design

shadcn registryを使う。

UI生成だけでなく、運用するprojectとして扱うのが出発点です。

• v0を本番前に使う時に最初に分ける運用境界
• v0 chatとVercel projectをどう見分けるか
• Environment Variablesをproject scopeで管理する理由
• GitHub連携をPR reviewへ戻す考え方
• Design Systemsをregistryやtokensで扱う方法
• Deploymentsをpreviewとproductionで分ける方法

v0は、自然言語で作りたいものを説明し、UIやapp codeを生成し、Vercelへdeployできる道具です。生成UIが速くきれいに見えるため、prototypeやlanding pageでは特に便利です。

一方で、本番前には「chatで生成できた」と「Vercel projectとして運用できる」を分ける必要があります。環境変数、GitHub、domain、deployment protection、analytics、design systemの整合性は、生成UIとは別のreview対象です。

前提知識

項目	内容	見方
v0		自然言語からUI/appを生成。
Vercel project		deploy、env、domainを持つ。
GitHub		version controlとPR review。
Design systems		registryとthemeを使う。

v0はAI生成UIとVercel運用の接点として理解します。

v0公式docsでは、v0をAI-powered development platformとして説明しています。自然言語でアイデアを説明すると、v0のagentがappを作り、web search、site inspection、error fixing、external toolsとの連携も行えると説明されています。

Vercel docsでは、v0でprojectを作ると対応するVercel projectが作られ、deployments、environment variables、integrations、その他resourcesを使えると説明されています。v0 projectは、複数のchatが貢献できる1つのappとして扱われます。

この記事の扱う範囲

項目	役割
v0 chat	prompt、生成、修正の会話単位
Vercel project	deployments、env、domainsを持つ運用単位
Environment Variables	API keys、database URLs、feature flags
GitHub	version control、branch、PR review
Design Systems	shadcn registry、Tailwind、CSS variables
Deployments	preview、production、domain、protection
Integrations	Supabase、Stripeなどの接続
Human review	accessibility、data flow、security

2026年6月1日時点で公開されているv0公式docsとVercel公式docsを確認しています。導入時には、利用中のv0 plan、Vercel team、project settings、GitHub repository、env vars、integration、domain設定を改めて確認してください。

注意点

この記事は、v0を否定するものではありません。むしろ、生成UIを本番コードへ戻すために、Vercel projectとして必要な設定を分けて確認する記事です。

まず6つの境界に分ける

項目	内容	見方
Prompt		依頼と完了条件。
Chat		生成履歴。
Project		Vercel資源。
Env		secretと環境。
GitHub		branchとreview。
Deploy		previewとproduction。

境界を分けると、生成UIを本番コードへ戻しやすくなります。

v0を本番前に使うなら、最初に6つの境界を分けます。

境界	確認すること
Prompt	依頼内容、制約、完了条件
Chat	生成履歴と試行錯誤
Project	Vercel project、resource、deployment
Env	API keys、database、feature flags
GitHub	branch、PR、CI/CD
Deploy	preview、production、domain、protection

この6つを分けると、v0で作ったものを「chatでよさそう」から「本番へ出せるproject」へ近づけやすくなります。

v0の強み

v0はUI生成だけでなく、full-stack app、dashboard、ecommerce、AI appなどを作れるとdocsで説明されています。Vercelにdeployしやすいことも大きな強みです。

v0の注意点

生成されたUIが整っていても、env vars、auth、database、payment、domain、CI、accessibilityは別です。UIがきれいなほど、裏側の確認が抜けやすくなります。

判断基準

迷ったら、「この変更はchat内の試行錯誤か、Vercel projectの運用設定か」を分けます。運用設定なら、GitHubやVercel dashboardで確認します。

v0 chatとVercel projectを分けて見る

Chat

promptとversionの会話。

Project

複数chatが貢献するapp。

Resources

env、domain、deploy。

Scope

1 project 1 appを意識。

chatは作業の履歴、projectは運用するappの単位です。

v0 Projects docsでは、Vercel Projects in v0は1つのcohesive appであり、複数のchatが貢献できると説明されています。1つのprojectはdeployment、hosting、domains、environment variablesを共有します。

つまり、chatとprojectは同じではありません。

chatで見るもの

項目	役割
prompt	何を依頼したか
generated UI	生成された画面やcomponent
iterations	修正履歴
context	参照した情報
version	どの生成物を使うか

projectで見るもの

項目	役割
deployments	previewとproduction
environment variables	project全体で使う設定
domains	URLとcustom domain
integrations	Supabase、Stripeなど
analytics	Web AnalyticsやSpeed Insights

1 project 1 appを意識する

同じprojectに関係ないchatが増えると、env varsやdeploymentsが混ざりやすくなります。実務では、1つのapp、1つの運用単位としてprojectを扱います。

project名を後から見ても分かるようにする

project名には、product名、環境、用途を入れます。demoやtestだけだと、env varsやproduction URLの意味が分からなくなります。

Environment Variablesはproject scopeで管理する

項目	内容	見方
Secrets		API keyやDB接続。
Project scoped		全chatで共有される。
Preview		確認用の値。
Production		本番用の値。

環境変数はchat単位ではなくproject単位で扱います。

v0 Environment Variables docsでは、environment variablesがproject-scopedであり、project内のすべてのchatで同じ値を使えると説明されています。API keys、database connections、feature flags、deployment settingsなどを管理できます。

本番前には、env varsをchatではなくprojectの設定として扱います。

env varsで見る項目

項目	確認すること
key	何の値か分かる名前か
value	secretが適切に管理されているか
environment	production、preview、development
owner	誰が更新できるか
integration	Connectで追加された値か

Vercel側との同期

v0 Vercel Integration docsでは、v0のVars sectionやConnect sectionで追加したenv varsがv0 editorとVercel deploymentの両方で使えると説明されています。また、Vercel project側に追加されたenv varsもconnected v0 chatで利用できると説明されています。

これは便利ですが、どこから入った値かが見えにくくなることがあります。公開前に、v0側とVercel側の値を確認します。

productionとpreviewを分ける

Vercel docsでは、environment variablesをproduction、preview、developmentなどのenvironmentへ適用できると説明されています。Stripe、Supabase、OpenAI keyのような値は、previewとproductionで分けます。

.env.localだけに頼らない

localで動くこととVercel deploymentで動くことは別です。Vercel CLIでenvをpullできる場合もありますが、本番前にはdashboard側のenv varsを確認します。

GitHub連携はPR reviewの入口にする

項目	内容	見方
Version		変更履歴を残す。
Branch		main以外へpushする。
PR		人間が差分を見る。
CI/CD		Git pushでdeployする。

v0の生成結果はGitHubへ戻し、人間のreview flowに載せます。

v0 GitHub docsでは、GitHub repositoriesをv0へ接続し、version control、collaboration、CI/CD、pull requestsに使えると説明されています。chatからrepositoryを作成し、branchを選んでpushできることも説明されています。defaultではmain branchへpushされると説明されています。

本番前には、GitHub連携をPR reviewの入口にします。

GitHubで見る項目

項目	役割
repository	codeをv0外に残す
branch	main以外へpushして確認する
pull request	人間が差分をreviewする
CI	lint、test、buildを通す
deployment	Git pushからpreviewへつなぐ

mainへ直接pushしない

v0 docsではdefaultでmain branchへpushされると説明されています。チーム運用では、mainへ直接ではなく、feature branchを選ぶか作る方が安全です。

PRに必要な情報

PRには、v0 chat URL、生成した目的、確認した画面、env vars、未確認flow、design systemの扱いを書きます。

v0差分のreview観点

生成されたUIは、見た目だけでなく、component構造、state管理、accessibility、data fetching、error handling、env var参照を見ます。

Design Systemsはshadcn registryとして扱う

Registry

componentを公開する。

Tokens

CSS variablesを守る。

Tailwind

utilityとthemeを共有。

Review

生成UIが逸脱しないか見る。

design systemはpromptではなく、registryとtokensで渡すと再利用しやすくなります。

v0 Design Systems docsでは、custom registryを使ってdesign systemをv0とshadcnで使えると説明されています。v0はTailwind configやglobals.css、custom utility classes、CSS variablesを使えると説明されています。

design systemをpromptだけで伝えようとすると、毎回ぶれます。registryやtokensとして渡す方が安定します。

design systemで見る項目

項目	確認すること
registry	componentを公開しているか
tokens	CSS variablesが守られているか
Tailwind	utilityとthemeの前提
components	既存componentを使っているか
accessibility	label、focus、contrast

shadcn系の強み

v0はshadcn/uiやTailwindとの相性がよい文脈で使われます。すでにcomponent registryを持っているチームは、v0をdesign systemに寄せやすくなります。

生成UIの逸脱を見つける

AIは見た目を合わせようとして、既存componentを使わずに似たUIを作ることがあります。design system導入時は、既存componentを使っているか、token名を守っているかをreviewします。

registryを更新する責任者

registryは誰かが保守します。v0向けに作ったregistryが古くなると、AI生成UIも古い前提を使います。

Deploymentsはproduction URLとpreviewを分ける

項目	内容	見方
Preview		PRや確認用。
Production		公開URL。
Domain		custom domain管理。
Protection		passwordなどの保護。

Publishは便利ですが、previewとproductionを分けて確認します。

v0 Deployments docsでは、Publish actionがVercel infrastructure上にproduction deploymentを作ると説明されています。production URLはprojectごとに扱われ、Deploy Changesでproductionを更新できます。

便利ですが、Publishは人間の公開判断です。

deploymentで見る項目

項目	確認すること
preview	PRや変更確認用
production	public URL
domain	custom domainとDNS
protection	password protectionなど
analytics	Web Analytics、Speed Insights
monitoring	errorやperformance

one production URLを意識する

v0 deployments docsでは、projectごとにone production URLとして管理する説明があります。複数のchatからproductionを更新するなら、どのchatの変更が本番に入るかを明確にします。

deploy前に見るもの

deploy前に、build、env vars、critical user flow、mobile layout、error state、SEO metadataを確認します。

productionへ出す前にpreviewで触る

見た目だけではなく、form、auth、data fetching、loading、error、empty stateをpreviewで触ります。

IntegrationsはConnectとVarsの違いを見る

Connect

SupabaseやStripe連携。

Vars

手動の環境変数。

Both ways

Vercel側の値も使われる。

Audit

どの値が入ったか見る。

integrationで自動設定された値も、公開前に人間が確認します。

v0 Vercel Integration docsでは、Vars sectionからenv varsを追加でき、Connect sectionからSupabaseやStripeなどのintegrationsを追加できると説明されています。これらはv0 editorとVercel deploymentの両方で利用可能になります。

本番前には、どの値がどこから入ったかを見ます。

Connectで見るもの

integration	確認すること
Supabase	URL、keys、RLS、auth redirect
Stripe	publishable key、secret key、webhook
AI provider	API key、rate limit、model
database	productionとpreviewの分離

Varsで見るもの

manualに入れたenv varsは、key名、value、environment scope、ownerを確認します。使っていない値は消します。

双方向同期の注意

v0とVercel projectの間でenv varsが共有されると、便利ですが変更元が分かりにくくなることがあります。公開前には、v0とVercel dashboardの両方を確認します。

secretの露出

Next.jsではclientへ出す値とserverだけで使う値を分けます。AI生成codeにsecretがclient側へ出ていないかを確認します。

生成UIはaccessibilityとdata flowでreviewする

項目	内容	見方
A11y		label、focus、contrast。
Responsive		主要幅で崩れない。
Data		保存、更新、削除。
Errors		失敗時の表示。

v0のUIはきれいでも、操作性とdata flowを別に確認します。

v0の生成UIは見た目が整いやすいです。だからこそ、公開前reviewではaccessibilityとdata flowを分けて見ます。

accessibilityを見る

観点	確認すること
label	form labelがあるか
focus	keyboardで操作できるか
contrast	textが読めるか
aria	必要な属性があるか
heading	見出し構造が自然か

data flowを見る

観点	確認すること
create	dataが保存されるか
read	権限外dataを読まないか
update	変更が反映されるか
delete	誤削除を防げるか
error	API失敗時の表示

design systemを見る

既存component、spacing、colors、tokens、interaction patternに合っているかを確認します。v0生成UIがブランドやproductの操作感から外れていないかを見ます。

AIらしい文言を直す

genericな見出し、説明過多なカード、空疎なCTAは直します。UI生成でありがちな「見た目は整っているが中身が薄い」状態を残しません。

導入初週の進め方

1. 1日目

   静的UIを1画面作る。

2. 2日目

   projectとenvを確認。

3. 3日目

   GitHubへ接続。

4. 5日目

   design systemを試す。

5. 7日目

   previewからproductionへreview。

初週は生成速度より、本番運用へ戻せるかを確認します。

v0は、最初の1週間で「生成できる」より「本番運用へ戻せる」を確認します。

日	やること	目的
1日目	静的UIを1画面作る	生成品質を見る
2日目	Vercel projectとenv varsを確認する	運用単位を理解する
3日目	GitHubへ接続する	PR review場所を作る
4日目	design system registryを試す	生成UIを揃える
5日目	preview deploymentを確認する	envとbuildを見る
6日目	production前checklistを作る	公開判断を分ける
7日目	actual projectへ小さく適用する	本番導入条件を決める

初週の評価軸

評価軸	見ること
UI品質	既存design systemに合うか
env管理	project scopeで説明できるか
GitHub	branchとPRでreviewできるか
deployment	previewとproductionを分けたか
data flow	APIやDBの失敗時を確認したか

広げる条件

次の条件を満たしたら、本番に近いtaskへ広げます。

• Vercel projectとchatの関係を説明できる
• env varsがproduction/preview/developmentで分かれている
• GitHub PRで差分をreviewできる
• design system registryやtokensの方針がある
• preview deploymentで主要flowを確認している
• production URL更新の責任者が決まっている

FAQ

Chat?

作業履歴として扱う。

Project?

運用単位として扱う。

Env?

project scopeで管理。

Deploy?

previewで確認してから。

迷ったら、Vercel projectの設定として説明できるかで判断します。

v0 chatだけで本番運用できますか？

本番運用ではVercel projectとして見る必要があります。chatは生成履歴、projectはdeployments、env vars、domains、integrationsを持つ運用単位です。

Environment Variablesはどこで管理しますか？

v0 docsではenv varsはproject-scopedです。v0のVars、Connect、Vercel dashboardのどこから入った値かを確認し、production、preview、developmentで分けます。

GitHub連携は必要ですか？

個人prototypeなら必須ではありません。チームでreview、CI/CD、PR、履歴管理をするならGitHub連携が必要です。mainへ直接pushせずbranchを使います。

v0のdesign system対応は何から始めますか？

既存componentをshadcn registryとして使える形にし、tokens、Tailwind、globals.cssを揃えます。promptで毎回説明するより、registryで再利用します。

Publishしたらproductionですか？

v0 Deployments docsではPublishがproduction deploymentを作ると説明されています。公開判断として扱い、previewで確認してからproductionへ進めます。

BoltやLovableとどう分けますか？

v0はVercel project、Vercel deployment、shadcn/Tailwind design systemとの接続が強いです。BoltやLovableはapp builderとしてのbackend/database運用に寄せ、v0は生成UIをVercel本番運用へ戻す観点で見ます。

---

次に読むなら

参照した主な情報源

• https://v0.dev/docs
• https://vercel.com/docs/v0
• https://v0.app/docs/projects
• https://v0.dev/docs/vercel-integration
• https://v0.dev/docs/deployments
• https://v0.dev/docs/github
• https://v0.dev/docs/api/platform/guides/environment-variables
• https://v0.dev/docs/design-systems
• https://vercel.com/docs/environment-variables

次に読むなら

更新履歴

1. 2026年6月1日

   v0公式docsとVercel公式docsを確認して初版を作成しました。

導入時には利用中のv0 project、Vercel team、GitHub設定を確認してください。

• 2026年6月1日: v0公式docsとVercel公式docsを確認し、初版を作成しました。