v0でnpm プライベートパッケージを活用する：社内コンポーネント再利用の実践ガイド

v0は、チームがすでに費用をかけて構築したnpm プライベートパッケージを利用できるようになりました。これにより、プロトタイプは後でエンジニアが差し替える代用品ではなく、実際のコンポーネントから作り始められます。Vercelは2026年9月18日17:00 UTCに認証情報を渡す仕組みをリリースしました。共有のDevelopmentまたはPreview環境変数としてNPM_TOKENかNPM_RCを設定すれば、認証情報をモデルに見せたり、Sandboxのファイルシステムへ書き込んだりせずにパッケージをインストールできます。

変更は小さくても、ハンドオフへの影響は大きい

npm プライベートパッケージとは、ダウンロード権限を確認するレジストリを介して配布されるJavaScriptまたはTypeScriptです。チームでは、デザインシステムのコンポーネント、トークン、認証ヘルパー、アナリティクスのラッパー、社内ユーティリティなどにプライベートパッケージを利用しています。

今回のリリースまでは、このレジストリ認証がv0のワークフローを分断していました。公開パッケージは通常どおりインストールできても、プライベートなコンポーネントライブラリにはアーカイブをアップロードするなどの回避策が必要でした。あるいは、レビューには十分似ている新しいコンポーネントをプロトタイプ用に作ることになります。後者はデモの間こそ速く見えますが、コードを実際のリポジトリへ移す段階で差し替え作業が発生します。

v0の新しい仕組みでは、認証をSandboxの境界へ移しています。v0はVercel Sandbox内で、リポジトリがすでに使っているパッケージマネージャーを実行します。プライベートレジストリへのインストールリクエストが送信されると、Vercelがネットワーク境界で認証情報を適用します。モデルやエージェントはその値を読み取れず、ローカルの.npmrcファイルにも書き込まれません。

ここが重要です。パッケージはビルドに入りますが、シークレットはプロンプトにもファイルシステムにも入りません。

ただし、パッケージへアクセスできても、そのシステムをどう使うべきかまでv0が理解するわけではありません。Buttonコンポーネントを取得できても、不適切なバリアントを選んだり、プロバイダーを省いたり、テーマラッパーを見落としたりする可能性はあります。だからこそ、パッケージには最新のドキュメント、サンプル、実際に利用しているアプリを添える必要があります。コーディングエージェントにデザインシステムを渡す方法で扱った全体的な運用原則も変わりません。コードが再現可能な仕組みを担い、ガイダンスが判断基準を伝えます。

削減すべきコストはコンポーネントの差し替え

ビジネス上の意味は、パッケージのインストールが速くなることではありません。プロトタイプの承認から本番開発までの間にあった、別工程の作り直しをなくせる可能性にあります。

v0が見た目だけ似たコンポーネントを生成すると、プロトタイプと製品は別物になります。エンジニアリング側では、importの差し替え、propsの再マッピング、テーマコンテキストの復元、状態の再テストに加え、承認済みの画面が変わった理由の説明まで必要です。最初から実際のパッケージを使えば、ハンドオフは再構築ではなくレビューと調整の工程に変えられます。

次はVercelのベンチマークではなく、試算例です。1つのプロトタイプで、これまでコンポーネントの差し替えに4時間かかっていたとします。エンジニアリング時間を1時間あたり$100と評価し、認証情報の設定と検証に1時間かかるなら、削減できる想定時間は3時間、金額では$300です。

この削減効果は保証されません。パッケージ設定の不備、プロバイダーの不足、使い方の説明不足があれば、別の場所で同じ3時間を失う可能性があります。自社のコンポーネントでリポジトリの差分と修正時間を測り、その結果をもとに、このワークフローを採用するか見送るかを決めてください。

公開パッケージしか使わないチームには影響しません。リポジトリに入ることのない、使い捨てのコンセプト画面を作るチームも同様です。承認されたv0のプロトタイプを、保守対象のソフトウェアへ発展させる場合に最も効果があります。

npm プライベートパッケージの配置先で認証情報を選ぶ

基本は、registry.npmjs.org上のプライベートパッケージにはNPM_TOKEN、接続先の振り分けにはNPM_RCです。フォールバック目的で両方を追加しないでください。プライベート依存関係のドキュメントによると、両方がある場合はNPM_RCが優先されます。そのため、古いカスタム設定が有効なnpmトークンを見えにくくすることがあります。

必要最小限の権限で設定する

1. 1

   実際に使っているパッケージを1つ選ぶ

   本番リポジトリですでに使われているコンポーネントから始めます。既知のimport、期待どおりの見た目、確認すべき実際のハンドオフがそろうためです。デモ専用のパッケージでも認証の動作は証明できますが、手戻りを減らせるかどうかまでは判断できません。

2. 2

   共有変数を作成する

   Vercelでチームを選び、Settingsを開いてからEnvironment Variablesへ進みます。共有変数としてNPM_TOKENまたはNPM_RCを追加し、Development、Preview、またはその両方をスコープに指定します。機密情報としてマークしてください。

   v0のドキュメントでは、この設定の管理にVercel Developer以上のロールが必要です。トークンには、プロジェクトがインストールするすべてのプライベートパッケージへの読み取り権限を与え、レジストリが必要とする範囲を超えないようにします。

3. 3

   カスタムレジストリへの接続先を設定する

   GitHub Packagesについて、Vercelはサンプルの@acmeスコープ向けに次のNPM_RC値を案内しています。

   @acme:registry=https://npm.pkg.github.com/
   //npm.pkg.github.com/:_authToken=${GITHUB_PACKAGES_TOKEN}

   GITHUB_PACKAGES_TOKENは別の共有変数として保存します。インストール中、NPM_RCは${VAR}参照を展開でき、参照先の値にも同じ認証情報保護が適用されます。JFrog Artifactoryでは、対応するレジストリURLとトークン変数を使ってください。

4. 4

   v0との連携を確認する

   v0でSettingsを開き、Integrationsへ進んでnpmを探します。v0は、対応する共有変数を自動的にリンクします。選んだコンポーネントをインストールして表示するよう依頼し、プレビューで想定したスタイル、プロバイダー、動作が使われていることを確認してください。

5. 5

   リポジトリへのハンドオフを点検する

   結果を実際のリポジトリへ送ります。package.json、ロックファイル、importパス、プロバイダー設定、グローバルスタイル、ソースの差分を確認し、リポジトリで従来から使っているチェックを実行します。プレビューが動くことは有力な材料ですが、ブランチが承認済みのコンポーネントを無理なく使えて初めて、ハンドオフは完了です。

明日から活用できる4つのチーム

ダッシュボードを開発するSaaSプロダクトチーム

プロダクトデザイナーは、フロントエンドチームがすでに本番で使っているものと同じプライベートコンポーネントで、新しい請求フローを試作できます。価値は、生成結果がきれいになることではありません。実際のButton、Table、Modalの動作を見ながら承認を進め、その後のソース差分を小さくできる点にあります。

全社向けにv0を準備するデザインシステムリード

リードはDesign Systems 2.0のインポートの前にプライベートパッケージを追加し、ソースリポジトリ、実際に利用しているアプリ1つ、最新の利用ドキュメントをv0へ渡せます。v0はスターターを構築し、システムを保存する前にレビューを待ちます。リードは、後続のすべてのチャットへ設定が引き継がれる前に、フォント、プロバイダー、トークン、非推奨のコンポーネントパターンを一度で見つけられます。

複数のレジストリを管理するエージェンシーのプラットフォームリード

エージェンシーは各プロトタイプへトークンをコピーする代わりに、NPM_RCを使って組織のスコープを適切なレジストリへ振り分けられます。認証情報の設定を管理しやすくなり、クライアントごとの代用コンポーネントも減らせます。それでも、クライアントのパッケージごとにアクセス境界とレビュープロセスは必要です。

GitHub PackagesまたはJFrogを使うエンタープライズのフロントエンドチーム

プラットフォームチームは、インポートしたリポジトリと同じ社内依存関係をv0にインストールさせられます。パッケージ解決、テーマ設定、importの問題がハンドオフ後ではなくプロトタイプの段階で表面化するため、プレビューの信頼性が上がります。共有認証情報がポリシーで禁止されている場合は、ドキュメントに記載された.tgz方式が、より小さく始められるパイロットになります。

アクセス権と料金は別々に考える

プライベートパッケージのドキュメントには、この機能に必要なv0の有料プランや個別のアドオンは記載されていません。示されているのは権限の条件で、共有変数を管理する人にはVercel Developer以上のロールが必要です。Vercelのロールドキュメントでは、チームレベルのDeveloperロールはProおよびEnterpriseプランで利用できます。

これは、現在のv0プランとは別の話です。Freeは月額$0で、毎月$5分のクレジットと1日7メッセージの上限があります。Plusは1ユーザーあたり月額$30で、1ユーザーあたり毎月$30分のクレジットと、1ユーザーあたり1日$2分のログインクレジットが付きます。Businessは1ユーザーあたり月額$100で、記載されているクレジット額は同じ、学習への利用はデフォルトでオプトアウトされます。Enterpriseは個別見積もりです。旧Premiumプランはドキュメント上では月額$20で残っていますが、提供終了に向かっており、新規ユーザーは利用できません。

Vercel Proには、月額$20のプラットフォーム料金、デプロイ可能なシート1つ、毎月$20分の利用クレジットが含まれます。OwnerまたはMemberの追加シートは、それぞれ月額$20です。公表されている価格はすべて税別の米ドル表記です。

試算例として、v0 Plusのシート1つとVercel Proのプラットフォーム料金を合わせると、税および従量課金を除いて月額$50です。これは、この機能を使うための最低料金ではありません。リリース文書には両方の有料プランが必要とは書かれていないため、アップグレードする前に既存アカウントとロールを確認してください。

限界も把握しておく

プライベートパッケージへのアクセスで、障壁は1つ取り除かれます。しかし、コンポーネントライブラリが完全なデザインシステムに変わるわけでも、生成コードがそのまま本番品質になるわけでもありません。パッケージが変わったときに、既存プロジェクトが自動で更新されることもありません。

実務上の制約は次のとおりです。

• Shared Environment Variablesは、ブランチごとに異なる値を設定できません。
• NPM_RCとNPM_TOKENが両方ある場合は、NPM_RCが優先されます。
• トークンには、選んだパッケージが内部で参照するプライベート依存関係を含め、プロジェクトがインストールするすべてのプライベートパッケージへの権限が必要です。
• 認証情報を保護できても、生成された実装が正しいとは限りません。
• プロバイダー、グローバルCSS、フォント、トークン、コンポーネントの状態、テスト、アクセシビリティ、レビューは、引き続きハンドオフで扱う必要があります。

セキュリティ上の保証は範囲が限定されていますが、有用です。v0は認証情報をモデルやエージェントへ公開せず、Sandboxのファイルシステムにも書き込みません。一方で、レジストリトークンをこのワークフローで使ってよいか、権限をどこまで絞るか、どうローテーションするかは、各社が判断する必要があります。

月曜日に着手すること

プライベートなコンポーネントパッケージがすでにあり、v0のプロトタイプを日常的にリポジトリへ引き継いでいるなら、今週動く価値があります。読み取り専用のレジストリ認証情報をセキュリティ責任者がまだ承認していないなら待ってください。認証情報を共有できない場合は、.tgz方式で範囲を限定したパイロットを行います。公開パッケージしか使わない場合や、v0の成果物が使い捨てのコンセプトで終わる場合は、今回のリリースを見送って構いません。

月曜日に、実際のプライベートコンポーネントを1つインポートします。必要最小限の読み取り専用認証情報をDevelopmentへ設定し、npm連携を確認して、v0にそのコンポーネントを表示させます。その結果をリポジトリへ引き継ぎ、依存関係、ロックファイル、import、プロバイダー、表示状態、ソース差分を確認してください。そのコンポーネントが代用品への差し替えなしでハンドオフを通過すれば、ワークフローは変わったと判断できます。その後、対象を広げる前に削減時間を測定します。

次のプラットフォーム変更と、その背景にあるビジネス上の試算を知りたい方は、ニュースレターにご登録ください。