v0で社内のデザインシステムを繰り返し使いたいなら、参考画像を渡すだけでなく、実際のUI部品、使い方、初期設定を再利用できる形へそろえます。見た目が似た新しいボタンを毎回作ることと、承認済みの社内部品を使うことは別です。
この記事は、v0のDesign Systems 2.0へ取り込む資料を選び、最小のstarterを確認してから別の画面で使うための手順です。実際のインポート、アカウント接続、生成、パッケージ導入は行っていません。後半の部品名とコードは、確認の考え方を示す独自の架空例です。
目次
一画面の再現か、複数画面での部品再利用かを選ぶ
参照画面を一つ作りたいなら、Figmaや画像と操作条件を渡す方法から始められます。Figma連携の公式資料は、画面構造、テキスト、トークン、部品名などを読み取る方法と、有料v0プランの条件を説明しています。画像やFigmaの見た目から、社内パッケージの正しいimportや利用可能なpropsまで推測して確定しません。v0:Figma(新しいタブで開く)
一方、社内の複数案件で同じ部品と設定を再利用したい場合は、Design Systems 2.0を検討します。公式説明では、実装元と利用例からstarterを作り、確認後にv0内のskillとして保存します。旧registry方式のガイドにはlegacyと明記されているため、現在の取り込み画面と旧手順を混ぜません。v0:Design Systems 2.0(新しいタブで開く)、旧registryガイド(新しいタブで開く)
ここでいうstarterは、新しい画面を作り始める土台です。今回の目的は、画面のスクリーンショット集ではなく、自社の実装部品を使い始められる土台と、確認した根拠を残すことです。
先に用意する資料を、役割で分ける
部品の提供元と、それを正しく使っているアプリを対応づけます。名前が同じでも、古い文書のButtonと現在のButtonで引数が違う場合があります。資料を大量に渡すより、対象バージョンに合う実例へ絞ります。
表は横にスクロールできます
| 渡すもの | 確認すること | 足りないとき |
|---|---|---|
| インストールできるパッケージやソース | 部品の実装元、対象版、依存関係 | 管理者に配布方法を確認 |
| その部品を使う既存アプリ | import、必要なラッパー、CSS、フォント | 動く利用例を探す |
| Storybookや利用文書 | props、状態、禁止・非推奨の使い方 | 実装元と文書の差を質問へ残す |
| 参照画面 | 配置、密度、表示したい状態 | 対象画面と状態を指定 |
| 追加メモ | 必ず使う部品、作り直さない部品 | 裁量と固定条件を分ける |
この表は取り込み前の編集用チェックです。すべての資料がそろうまで着手できないという製品条件ではありません。ただし、実装元が分からない部品を「社内標準として使える」と確定することは避けます。
private packageへアクセスできないときは、担当管理者へ対象パッケージと必要な用途を渡します。認証情報の値を依頼文や部品資料へ貼りません。アクセスの問題を解決するために、無断でソースを公開したり、似た別ライブラリへ置き換えたりしないでください。
取り込みでは、starterの中身を先に確認する
公式の取り込みフローは、Design Systemsページから資料を指定し、生成された小さなstarterをレビューしてから保存する流れです。保存先のscopeも確認します。チーム用を意図していたものが個人だけの保存になっていないかを、名称だけで判断しません。
レビューでは、ボタンの色だけでなく「どこから部品を読み込んだか」「部品を動かす初期設定があるか」を見ます。確認例として、次を別々に記録します。
- 既存UIパッケージと、確認したバージョンが対応する。
- 指定した部品をimportし、似た名前の自作部品へ置き換えていない。
- provider、テーマ、CSS、フォントなど、必要な初期設定がある。
- 通常、無効、エラーなど、今回使う状態の扱いが部品仕様と合う。
- 新しい画面でも同じ土台を使うための参照先と保存範囲を確認できる。
この受入条件を使い、Previewに表示されたことと、既存部品を使ったことを分けて判定します。見た目が合っていても、部品を複製して別実装を作っていれば、再利用の目的は満たしません。
Vercelの実務ガイドも、生成した画面を既存の実装へ渡す際は、部品やトークンとの対応とコードの確認を行う流れを示しています。画面案の生成と、既存アプリへの統合を同じ完了条件にしないでください。Vercel:v0の画面案を既存Next.jsへ渡す(新しいタブで開く)
架空のButtonで、色の一致とAPIの一致を分ける
説明用に、社内の架空パッケージ@sample/uiを考えます。実在の配布物やv0の組込みAPIではありません。今回、確認済みとする契約は、Buttonがvariantにprimaryまたはsecondaryを取り、disabledも使える、という範囲です。colorというpropは確認していません。
依頼は「このButtonで、一覧上の確認ボタンを置く」です。次の案Aは、例の契約と合う書き方です。ただし、実パッケージで型検査や描画を確認したコードではありません。
import { Button } from "@sample/ui";
export function ReviewAction() {
return <Button variant="primary">内容を確認</Button>;
}
案Bは、青く見せたいという意図から、未確認のcolorを作った例です。
import { Button } from "@sample/ui";
export function ReviewAction() {
return <Button color="blue">内容を確認</Button>;
}
表は横にスクロールできます
| 案 | この例の確認 | 次にすること |
|---|---|---|
| A | import元とvariantが指定契約に合う | 実環境で初期設定・型・表示・操作を確認 |
| B | colorは未確認で、指定したvariantもない | 契約へ戻して修正。画面の色だけで採用しない |
Bの問題は、青という色が悪いことではありません。指定部品のAPIを根拠なしに増やしていることです。足りない機能があるなら、部品管理者へ仕様追加を相談するのか、その機能を使わないのかを分けます。AIが独自のpropやCSSを足して、既存部品を使えたように見せることを避けてください。
掲載2案は、ローカルでTSX構文とimport・属性の対応を検査しました。確認したのは手製コードと架空契約の差であり、v0が実際に生成した結果でも、@sample/uiをインストールした結果でもありません。
保存したものを、新しい画面で使う
取り込みが終わったら、新しいチャットのプロンプトツールバーから保存したDesign Systemを添付するか、プロンプトで直接参照して、小さな画面を依頼します。例として「申請一覧の行と確認ボタンだけを作る」と範囲を限定し、画面の再現より先に、使う部品と状態の対応を確認します。
選択した社内Design Systemを使い、申請一覧の行と確認ボタンの画面案を作ってください。
部品、props、トークンは、指定した実装元と利用例で確認できるものだけを使ってください。
既存部品と似た自作部品への置換、未確認のpropsの追加はしないでください。
最初に、使う部品・import元・必要な初期設定・未確認事項を返してください。
画面は通常状態と無効状態を確認できる範囲に限定します。
情報が足りない場合は、その箇所を質問へ残してください。
今回の確認対象外:データ保存、認証、外部API、公開。
この依頼文は、実施前に条件をそろえるための手製例です。実務では、自分のアプリの入力値や操作要件へ置き換えます。生成後は、採用した部品、import、props、トークン、初期設定の根拠へ戻り、指定していない別システムの部品が混ざっていないかも確認します。
小さい画面で確認できても、全ページの統一性を確認済みにしません。別のテーマ、長い日本語、狭い画面、エラー表示など、実際に必要な組合せを順に確認します。PCとスマートフォンの実表示は、コードや構文の確認とは別の結果として残してください。
部品の更新と、既存画面の更新を分ける
部品パッケージが更新されたら、どの版の資料、部品API、starterを使うかをそろえます。v0の公式仕様は、保存したDesign Systemの更新だけでは、既存プロジェクトのコードが自動で書き換わらないと説明しています。既存画面への反映は、その画面のチャットで更新内容を指定する別の作業です。v0:Design Systemの使用と更新(新しいタブで開く)
例えばvariantの値が変わったなら、新しい利用例だけでなく、旧画面の使用箇所と変更対象を確認します。新しいskillが保存された表示を、すべての利用アプリの移行完了へ変えません。変更前後の版と、どの画面を確認したかを残します。
社内の実装元を用意できず、一度限りの画面案だけが必要なら、まず既存デザインからUIを作る手順で範囲を決める方が適します。複数画面へ承認済み部品を繰り返し使うことが目的なら、見た目だけでなく、取り込み元・starter・保存範囲・新規画面での利用・更新後の反映を確認できる状態を目指してください。
参考資料
- v0:Design Systems 2.0(新しいタブで開く)
- v0:Legacy design systems(新しいタブで開く)
- v0:Figma(新しいタブで開く)
- v0 API v2:Design Systems(新しいタブで開く)
- Vercel:Storefront prototyping with v0(新しいタブで開く)
公式資料の確認日:2026年10月21日。Buttonの契約、コード2案、依頼文、確認例は独自の架空例です。掲載コードの構文と属性の対応をローカルで検査しました。v0操作、インポート、接続・認証、package導入、型検査、starterの動作、生成精度、公開、料金は未検証です。
