v0とCursorを比較｜生成から実装までの役割の違い

v0とCursorは、どちらもAIにコードを書かせられます。大きな違いは、仕事の入口と作業範囲です。v0はWebアプリの画面や機能を作り、Previewからコード・GitHub・Vercelへ進める流れが分かりやすいサービスです。Cursorは既存のRepositoryを開き、Agentに複数ファイルの変更、コマンド実行、テストなどを依頼するCoding Environmentです。ゼロからWebアプリを形にするのか、すでにあるコードを継続して直すのかで候補を絞れます。

同じ要件を同じ状態のRepositoryへ投入していないため、コード品質や修正速度の優劣は判定しません。比較するのは、作業がどこから始まり、誰が変更を検証するかです。

仕事の入口で分ける

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

今の状況	v0が自然な入口	Cursorが自然な入口
新しいWeb画面の方向がまだ決まっていない	プロンプトや参考画面からUI案を作り、Previewで見る	既存Repositoryや仕様があり、その構造の中で実装したい
すでに動くアプリがある	Web機能を足し、Vercelへ公開する経路を作りたい	Bug fix、Refactor、Test、既存設計の変更を進めたい
レビュー	GitHubへつなぎ、branchやPull Requestを使う	Editor上で差分とTerminal実行を見て、Repository全体を確認する
UI調整	Previewを見ながらDesign Modeで調整する	ソースコードを直接編集し、必要に応じてBrowserやツールで確かめる
Web以外のコード	Web中心の構成を前提に適合性を確認する	Repository内の言語・frameworkを確認してから対応範囲を決める

これは機能の上限を断定する表ではありません。v0もコードを編集し、CursorもWeb UIを作れます。最初にどこへ作業を置くと、後の検証や引き継ぎを省かずに済むかを見ています。

v0は「Webアプリを作って公開する」工程へ寄る

v0では、自然言語から画面やアプリを生成し、Previewを確認し、コードを調整できます。公式DocsはNext.jsを既定の構成とし、API、Database接続などを含むFull-stack開発の流れを説明しています。GitHub連携でbranch、commit、Pull Requestを扱い、VercelへのDeploymentへつなげられます。

たとえば、社内の申請画面を新規に作るとします。最初にフォーム・一覧・詳細の画面を用意し、次に保存や認証を追加する、という順で段階的に試せます。ただしPreviewで見た画面は、保存や権限が動いている証拠ではありません。画面から入力してもデータが保存されない場合や、管理者しか見られない情報がURL変更で表示される場合があります。Preview上の操作と、Backend / API側の検証を別々に行います。

公開はVercelが自然な経路ですが、Deploymentが成功しただけで本番要件が満たされるわけではありません。Environment Variables、Domain、認証、Database、Logging、Rollbackをチームの運用に沿って設定できる担当者が必要です。Vercelを既に使っているなら、既存Projectへ統合する前に、PreviewとProductionの環境が分かれているか、古いデータを上書きしないかを確認します。

Cursorは既存コードの変更をAgentと進める

Cursor Agentはコードベースを検索し、ファイルを読み書きし、Terminalコマンドを実行して複数ファイルにまたがる作業を進められます。既存Repositoryの機能追加、Bug調査、Refactor、テストなどを依頼し、変更差分を確認する使い方が中心です。Cursorの公式Docsでは、Agentはファイル編集やコマンド実行を含むCoding Environmentとして説明されています。Agentの一部はCloudでRepository上の作業を続ける選択肢もありますが、実行環境や権限は設定によって異なります。

たとえば、既存の顧客管理Webアプリで「CSV Exportの文字化けを直す」と依頼する場合、Cursorはまず関連コードや既存テストを調べ、その構造に合わせて修正・検証できます。最初から新しいアプリ全体を別プロジェクトで作るより、今の仕様やテストを理解した上で差分を作る用途に向いています。ただし、Agentがテストを実行したからといって、要件を満たしたとは限りません。テストが対象の不具合を検出できる内容か、追加した変更が予期しない画面へ影響しないかを人がレビューします。

Cursorを使う場合、作業場所がRepositoryなので、既存の開発ルール、Secretの扱い、Branch、Test、Reviewをそのまま適用しやすい構成です。一方、初めて触るコードベースや曖昧な指示では、Agentが前提を誤ることがあります。まず対象コード、変更範囲、合格条件を示し、差分を小さく保つと確認しやすくなります。

UI生成から保守へ渡すなら、工程を切る

v0で作ったWebアプリをGitHubへつなぎ、Cursorで継続開発する併用も可能です。その場合は「どちらを主担当にするか」を工程ごとに決めます。例えば次の区切りです。

1. v0：画面の土台を作る

   画面構成と主要な状態をPreviewで検討し、要件と違う部分を直す。

2. v0 / GitHub：コードをRepositoryへ渡す

   branchやPull Requestの変更として保存し、どの時点の生成物かを固定する。

3. Cursor：既存設計へ合わせる

   lint、test、API、既存componentのルールを読み、差分を小さくして修正する。

4. チーム：公開を判断する

   セキュリティ、データ、動作、SEO、Deploymentをレビューして公開する。

この流れを選ぶ場合、同じファイルをv0とCursorから同時に変更しないようにします。どのRepository / branchが正本かを決め、v0側の変更を同期してからCursorで続きを行います。生成物のコードがRepositoryへ入った時点で、通常のコードレビューとテストを通します。

候補を決めるためのミニ検証

比較には、同じ要件を同じ順で試します。Webアプリの小さな検索画面を題材にする場合、次の合格条件を先に決めます。

• 条件入力後に一覧が更新される。

• 0件の場合に空の状態と次の行動が分かる。

• データ取得が失敗したとき、読者にエラーが伝わる。

• キーボードのみでも主要操作ができる。

• 画面幅390pxでもフォームと結果が横にはみ出さない。

• 必要なテストを実行し、その結果と変更差分をレビューできる。

• 公開する場合、API Keyや顧客データがブラウザへ漏れない。

v0で新しい画面を作るなら、Previewの状態ごとに上記を確認し、コードの出力先を記録します。Cursorで既存Repositoryに機能を足すなら、同じ条件を今のコード規約へ合わせて実装し、関連テストや差分を確認します。片方にだけ既存コードやテストを与えた結果を「AIの性能差」と解釈しないでください。比較しているのは、用意したContextとワークフローを含む結果です。

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

観点	確認する証拠
UIの完成度	画面表示だけでなく、空・失敗・読み込み中を含む状態
コード	生成・変更されたファイルと差分を追えるか
動作	合格条件に対応するテストと実際の操作
引き継ぎ	Repository、branch、環境変数、公開担当を説明できるか
継続コスト	生成利用量、Vercel等のHosting、保守作業の担当範囲

確認できない項目は未確認と記録します。画面の見栄えがよくても、保存、エラー処理、保守の確認がない状態では本番採用を決めません。

変更を渡すときに残す記録

v0からCursorへ作業を渡すなら、最低限、対象Repository、branch、最後に正常だったcommit、追加したEnvironment Variables名、実行したTestを記録します。秘密の値をREADMEやPromptへ貼らず、設定先と必要な権限だけを共有してください。Cursor Agentへ渡す指示も「画面をもっとよくする」ではなく、変更したいroute、守る既存動作、合格条件を明記します。

たとえば検索画面なら「検索条件をURLへ保持し、再読み込み後も結果を復元する」「0件なら条件の解除方法を表示する」「API失敗は再試行できる」と書きます。これで、v0では初期の画面と状態、Cursorでは既存コード内への実装とRegression Testという役割を分けられます。

さらに、同じcommitからBuildできることを確かめ、公開用のEnvironmentへ移す担当者を決めます。コードの所有とHostingの運用責任を分けて記録すると、生成後の保守先が曖昧になりません。

AIものさしの判断

v0は、Web UIやアプリをゼロから形にし、Preview、コード、GitHub、Vercelへ進める入口として候補になります。Cursorは、すでにあるRepositoryに対する機能追加・Bug fix・テストなどをAgentに依頼する入口として候補です。新規画面の探索と長期保守で役割を分ければ、どちらか一方を万能役にする必要はありません。

ただし、同一Repositoryと同一条件で完成度や実装時間を比較したHands-onは行っていません。新規Webアプリか既存Repositoryか、誰が差分をレビューするかを先に決め、同じ受入条件で小さく検証してください。