v0 APIの使い方：アプリ生成からデプロイまでの実践ガイド

v0 APIで実際にできること

v0 APIが自然言語の指示から作るのは、単なるコード案ではなく、実際に動くフルスタックアプリです。コードの生成からVercel Sandboxでの実行、安全なライブプレビューの提供、Vercelへのデプロイまでを一続きで扱えます。

v0の各チャットは、1つのアプリ専用の作業場だと考えると分かりやすいでしょう。その作業場の鍵になるのがチャットIDです。v0は内部のファイルを読み、編集し、実行できます。追加のメッセージを送るたびに、現在の状態を引き継いで作業が続きます。たとえば、最初に課題のトリアージ用ダッシュボードを依頼し、次に担当者列の追加を頼むと、2つ目の指示では作業中のアプリそのものが更新されます。

重要なのは、この状態を保ったまま反復できる点です。通常のコードモデルはテキストを返し、実行は利用者に委ねます。一方、v0は開発サーバーを起動してコードの動作を確認し、作業中にエラーを見つけて修正することもできます。

新しいv2 APIは、内部の仕組みを詳しく知らなくても理解できる4つの要素で構成されています。

• Chatsには、アプリの現在のファイル、メタデータ、公開範囲、Vercelプロジェクトとのリンクが保持されます。
• Messagesは指示と履歴です。順序付きのpartsには、テキスト、思考過程、ファイルの読み取りや編集、検索、シェルコマンド、ツール呼び出し、エージェントのアクションが表示される場合があります。
• Previewsは、短期間有効なトークンで保護された実行中のビルドです。
• Deploymentsは、チャットの現在の状態をVercelへ公開します。

古いサンプルをそのまま使うと混乱しやすいのも、この違いがあるためです。現在のv2クイックスタートはv0パッケージからインポートします。以前のv1サンプルはv0-sdkからインポートしており、v1のチャットIDはv2では使えません。

v0 APIの使い方

安全かつ最短で始めるなら、自社インターフェースとv0の間に小さなサーバールートを置きます。ブラウザからユーザーのプロンプトを自社サーバーへ送り、サーバー側でAPIキーを保持してv0を呼び出します。返されたチャットIDを保存し、インターフェースには必要な結果だけを返す構成です。

1. 用途に合う導入方法を選ぶ

選択肢は次の3つです。

1. npx create-v0-sdk-appで、アプリ生成に必要なインターフェース一式を立ち上げる。
2. npm install v0で、既存プロダクトにサーバーSDKを追加する。
3. 既存のエージェントからリモートv0 MCPサーバーを利用する。MCPの設定にAPIキーを記載せず、OAuthで接続できます。

全体像を最速で確かめたいなら、スターターが適しています。React製のチャットインターフェース、サーバープロキシルート、生成ファイルの表示、隔離されたプレビューアプリ、v0エージェントスキルが含まれています。

2. キーを発行し、サーバー側だけで管理する

v0の設定画面でAPIキーを作成し、サーバー環境のV0_API_KEYとして保存します。ブラウザ側のコードには公開せず、NEXT_PUBLIC_も付けないでください。

ローカルのラッパーはnpm run devで起動できますが、そのサーバールートが呼び出す先はホストされたv0 APIです。ローカル統合であり、v0のアプリ構築システムをローカルに複製するわけではありません。

3. 1つのアプリにつき1つのチャットを作る

最初の呼び出しで、会話とアプリワークスペースの両方が作成されます。

import { v0 } from 'v0'

const created = await v0.chats.create({
  message: 'Build an issue triage app for a support team.',
})

if (created.error) throw new Error(created.error.message)
const chatId = created.data.chat.id

const changed = await v0.messages.send({
  chatId,
  message: 'Add a priority filter and an assignee column.',
})

if (changed.error) throw new Error(changed.error.message)

chatIdは、自社側の顧客、ワークスペース、またはジョブのレコードとひも付けて保存します。メタデータでも同じ識別子を使ってチャットをまとめられますが、メタデータは整理のためのものであり、アクセス制御にはなりません。

空の状態からプロンプトを送る必要はありません。GitHubリポジトリ、ZIPアーカイブ、またはファイル一式を起点にチャットを始めることもできます。

4. 処理結果の受け取り方を決める

呼び出し元が完了まで待てるなら同期呼び出しを使います。処理をキューに入れ、後から状態を確認するスクリプト、Webhook、CIジョブには非同期呼び出しが向いています。ユーザーが画面を見ている場面ではストリーミングを使うと、エージェントがファイルを読み、コードを編集し、コマンドを実行して進捗を伝える様子をインターフェースに表示できます。

チャットとメッセージのレスポンスには使用量も含まれるため、各ジョブの完了時にトークン数とクレジット消費を記録できます。

5. プレビューは直接公開せず、プロキシを通す

APIからはプレビューURLと短期間有効なトークンが返されます。ブラウザのiframeからそのトークンを安全に付与することはできないため、公式の構成では、自社管理のバックエンドプロキシを経由してiframeのリクエストを送ります。

このプロキシは、メインアプリとは別の登録可能ドメインを持つ、プレビュー専用サイトに配置してください。生成されたプレビューでは、信頼できないコードが実行され得ます。また、プロキシ側で現在のユーザーを認証し、要求されたチャットへのアクセス権があるか確認する必要があります。v0のプレビューヘルパーは、この認可処理までは行いません。

6. 自社の確認を通してからデプロイする

アプリの準備が整ったら、v0.chats.deploy({ chatId })でチャットの現在の状態をVercelへデプロイします。環境変数は接続先のVercelプロジェクトに属し、Vercel APIを通じて管理されます。したがって、データベース認証情報やサードパーティーのキーは、別途、明示的に設定する必要があります。

v0 APIの料金体系

v0は、生成するアプリごとの定額料金ではなく、クレジット制です。入力トークンには、プロンプト、アップロードした内容、チャット履歴、ソースファイルなど、v0が読み取るコンテキストが含まれます。出力トークンはエージェントが生成した内容です。そのため、履歴やコードベースが大きくなる長期のチャットほど、料金が高くなる可能性があります。

Freeプランは月額$0で、毎月$5分のクレジットと1日7メッセージの上限があります。Plusは1ユーザー当たり月額$30、Businessは1ユーザー当たり月額$100で、どちらも1ユーザーにつき毎月$30分のクレジットが含まれます。利用可能なクレジットを使い切ると、生成は停止します。

顧客向けプロダクトでは、チャットとメッセージを呼び出すたびに、返された使用量を記録しましょう。テナントごとに予算、ジョブ数の上限、またはその両方を設定します。そうしなければ、極端に大きなリポジトリや終わりのない修正ループが、共有残高を使い切るおそれがあります。

効果を得やすい順に見る7つの活用例

v0が最も力を発揮するのは、既存のワークフローに組み込み、そのプロダクトがユーザー、データ、作るべきアプリの種類をすでに把握している場合です。

v0を裏側のエンジンとして使うべきか、それともv0自体が必要なプロダクトなのかを判断したい場合は、2026年版のおすすめAIアプリビルダーと比べてみてください。APIが有効なのは、顧客体験、ルール、課金、レビュー工程を自社で持ちたい場合です。この違いは重要です。

v0 APIで作る価値がある3つのプロダクト

この領域には確かな需要がありますが、汎用アプリビルダー市場はすでに混み合っています。狙うべきは、また1つ空のプロンプト欄を作ることではありません。価値ある特定の仕事を、誰よりも深く理解したビルダーです。

1. 最有力：既存SaaSに組み込む業界特化型アプリビルダー

特定の職種向けに用途を絞ったジェネレーターを作り、その顧客がすでに使っているソフトウェアの追加機能として販売します。不動産管理プラットフォームならオーナー向けポータル、物流プラットフォームなら配送例外ダッシュボード、フランチャイズ向けプラットフォームなら新拠点のローンチ管理を生成できます。

このカテゴリーを支えるだけの幅広い需要はあります。ai app builderの米国Google検索数は月間約12,100件で、データセットでは年間50%の伸びが示されています。AIアシスタントにbuild an app with aiと依頼する回数は月間約392件で、231件だった2025年8月から約70%増えています。既存のアプリビルダーには月額$16〜$160の料金設定があり、この用途に対して継続的なソフトウェア料金を支払う買い手がいることも分かります。

販売できる最小構成には、承認済みのアプリ種別を2〜3種類、構造化されたヒアリングフォーム、顧客アプリごとに1つのv0チャット、ストリーミング対応のレビュー画面、安全なプレビュープロキシ、人が操作するデプロイボタンが必要です。参入障壁になるのは、ホストプロダクトのデータモデル、権限、テンプレート、流通経路です。

厳しいものの役立つ判断基準があります。汎用ラッパーには、ほとんど防御力がありません。v0単体では知らない顧客業務の何を理解しているのか、明確に説明できないプロダクトなら作るべきではありません。

2. エージェンシー向けホワイトラベルWebサイト／キャンペーンビルダー

ブランドを反映した顧客ヒアリング、固定されたページ種別、自社のデザインシステムスキル、修正キュー、デプロイへの引き渡しをエージェンシーへ提供します。クライアントにはエージェンシー独自の体験を見せつつ、その裏側ではv0がアプリワークスペースとライブプレビューを担います。

ai website builderの米国Google検索数は月間約40,500件で、キーワードデータセットでは年間49%の伸びが示されています。今回の調査で確認できる最大の需要ですが、同時に、有力な既存サービスがひしめく市場でもあります。有効な切り口は「どんなWebサイトでも作れる」ではありません。「このエージェンシーが得意とするサイトを、この技術スタック、このコンポーネント、この承認工程で作る」という提案です。

MVPには、1つのブランド設定、3種類のページパターン、アセットのアップロード、プレビューへのコメント、デプロイ承認が必要です。課題はサポートです。生成されたコピー、レイアウト、アクセシビリティ、統合部分に修正が必要なとき、クライアントが評価するのはv0ではなくエージェンシーです。

3. プロダクトチーム向け「機能要望からプレビュー」ボット

承認済みのissueから、動作する変更案を作ります。GitHub Appまたは社内Webhookでリポジトリを取り込み、非同期のv0チャットを開始してチャットIDを記録し、プレビューをチケットへ投稿します。マージやデプロイの前には、必ず人がレビューします。

Googleではhow to build an app with aiが米国で月間約390回検索され、データセットでは年間86%の伸びが示されています。AIアシスタントにbuild an app with aiと依頼する需要は月間392件に達しました（2026年7月）。これはアプリ全体が動くことへの関心を裏付けますが、独立したCI市場が成立する証明にはなりません。広い層へ単独で販売するのではなく、チーム機能または開発者プラットフォームの追加機能として扱うのが妥当です。

MVPは、Webhook、リポジトリの許可リスト、非同期ジョブランナー、v0チャットの保存先、隔離されたプレビュー、承認ステータスで構成されます。課題はリスクです。生成されたプレビューコードは信頼できず、リポジトリへのアクセスは機密性が高く、もっともらしいデモが動いても、テスト、セキュリティ、マイグレーション、エッジケースが正しい証拠にはなりません。本番へのデプロイをデフォルトの動作にしてはいけません。

コーディングエージェントやプロンプトからアプリを作るツール全体の中での位置付けは、2026年版のおすすめvibe codingツールで詳しく比較できます。

v0 APIだけでは解決できないこと

APIが提供するのは、アプリを構築する作業者とその作業場です。周辺のプロダクトは、自社で担う必要があります。

• 何を作るべきかまでは決めません。 曖昧な依頼から、意図とは違うものを精巧に作ってしまう可能性は残ります。ヒアリング、テンプレート、制約、レビューゲートが重要です。
• 顧客の認可は行いません。 プレビューヘルパーはプレビュー通信を中継しますが、各チャットへ誰がアクセスできるかは自社アプリケーションで判断する必要があります。
• 生成コードを信頼できる状態にはしません。 プレビューは、登録可能ドメインが異なるプレビュー専用サイトから配信し、本番へ到達する前にコードをレビューしてください。
• v1のチャットをv2へ引き継ぎません。 v1のバージョンを1つ選び、ZIPとしてダウンロードして、その状態から新しいv2チャットを作成します。
• Vercel APIの代わりにはなりません。 環境変数や一部のプロジェクト操作は、接続されたVercelプロジェクト側にあります。
• 料金は固定されません。 ソースファイル、会話履歴、プロンプト、出力のすべてがトークン使用量に影響します。
• ローカルのアプリ構築エンジンではありません。 統合部分はローカルで動かせますが、公式のワークフローはホストされたv0 APIを呼び出し、Vercelのインフラ上でプレビューを実行します。

私の見解では、動作するプレビューと、状態を維持した反復にプロダクト上の価値がある場合にv0を使うべきです。必要なのがコードスニペット、単発のコンポーネント、厳密に決まったファイル変換だけなら、追加のワークスペース、プロキシ、クレジット管理、デプロイの仕組みは不要です。

自社ビジネス向けのv0搭載ビルダーを設計し、本番運用に耐える形へ仕上げたい場合は、本番環境向けAIシステムの構築を依頼できます。