v0 で料金シミュレーションサイトを作った話

はじめに

こんにちは。dfplus.io の開発チームでフロントエンドエンジニアをしている shiro_pon です。

2025 年 5 月に dfplus.io の料金シミュレーションサイトを公開しました。

この料金シミュレーションサイトは Vercel の v0 という UI 生成系 AI ツールのプロトタイプから始まったものです。

今回の記事では、v0 を使って料金シミュレーションサイトを開発し、プロダクションリリースを行った経験から得られた v0 の活用法についてお話しします。

きっかけは CS チームの負担

dfplus.io の料金体系はやや複雑です。

複数のプランがあり、プランごとに使える機能が異なり、さらに容量追加による料金変動もあります。

Slack でカスタマーサクセスチーム(以下 CS チーム)が料金見積もり対応に苦労しているのを見て、「v0 でサクッと料金シミュレーションを作れそうだな」と思ったのが始まりでした。 v0 の存在は知っていたものの、実際にどう活用できるか検討していたタイミングでもあり、ちょうど良い機会でした。

1 行のプロンプトでプロトタイプを生成

最初に v0 に投げたプロンプトはたった1行です。

https://dfplus.io/pricing の料金シミュレーションを作成してください

v0 は料金ページを解析し、サービスサイトのデザインに即した料金シミュレーターを生成しました。

単価・金額も正確に読み取られており、計算も正しく動作していました。

高速フィードバックサイクル

生成した UI は簡単にデプロイして URL を共有できます。

早速 CS チームに共有すると、すぐに好感触を得られました。

その後、細かな要件を追加実装し、それに対するフィードバックを CS チームに依頼しました。実際に動くものを触ってもらうことで具体的なフィードバックを得ることができました。

「プラン選択式ではなく数量に応じて最適なプランが表示されて欲しい」
「容量追加する項目に対しての補足文言が欲しい」
「入力の初期値はこうあって欲しい」
「Shopify プランの場合は UI の切り替えができるとよさそう」

お客様と関わる機会の多い CS チームの意見を参考にすることで、「お客様が本当に求めているもの」が明確になりました。

このスピード感のある改善を実現できるのは v0 の大きな強みだと思います。

v0 の落とし穴

生成されるコードの品質

プロンプトによる修正を都度加えていくと50 回目の修正あたりから問題が発生しました。

コード生成が極端に遅くなる
ローディング状態でフリーズが多発
未使用コードの蓄積によるパフォーマンス低下

v0 は適宜リファクタリングを行わないため、追加実装を重ねるほどコードが複雑化・肥大化していきます。

コードの中身を見ると useEffect の多用による過剰な再レンダリングなど、実際のプロダクションコードで使用するには問題がありました。

デザインレビューで発覚した問題

見た目の良い UI に満足していましたが、デザイナーのレビューで以下の問題が明らかになりました。

プロダクトのデザインシステムに沿っていない
プロダクトに存在しない用語が使われる
根拠のない配色やレイアウト

「それっぽい見た目」に惑わされて、デザインの原則や情報設計の観点を見落としてしまわないように注意が必要です。

プロダクションコードへの移行

実際に動くものは出来ていたので v0 コードをローカルに落として AI Agent によるリファクタリングをしていく方針にしました。

v0 で生成したコードはshadcn addコマンドでローカルに落とすことができます。

参考までに v0 コードは下記の技術スタックで生成されています。

TypeScript
React
TailwindCSS
shadcn/ui

まずはガードレールから

最初にやったのは「ガードレール」の設定です。 v0 で生成したコードは複雑になっており、そのまま AI Agent でリファクタリングする前にテストによる動作の担保を実施しました。

まず、v0 内で仕様書を生成してもらいました。実験的にプロンプトを投げてみると、おおよその機能を網羅した仕様書が生成されました。

ただし、生成された仕様書にはフィードバック段階で消した機能の記載など、不要なものも含まれていたので人間によるレビュー、手直しは必須です。

次に、その仕様書を元に Cursor の Agent でテストケースを作成しました。ここでのテストケースの作成は作業工程の中で最も重要で、網羅性が担保されていないと後のリファクタリング時に動作が壊れてしまうリスクがあります。

そして、完成したテストケースを元に React Testing Library を使って動作を担保するブラックボックステストを実装するという流れです。

振り返ってみると、このテストコード自体は使い捨てでも良かったです。リファクタリング時の動作を担保するガードレールとしての役割があれば十分であるため、コードの品質にこだわるよりも速度を重視するべきでした。

AI 駆動のリファクタリング

ガードレールができたので、いよいよリファクタリングです。

以下のようなアプローチで AI Agent によるリファクタリングを実施しました。

コンポーネント、ロジックの分割
ファイルごとにリファクタリング計画を立ててもらう
リファクタリング実施
さらに改善が必要な部分を指定して、再度リファクタリング

まずはファイル分割をしてコンテキストを狭めた上でリファクタリングできるようにします。その上で AI Agent にリファクタリングの計画を立ててもらいました。 Cursor には Cline のような Plan モードがないため（2025 年 6 月時点）、明示的にプロンプトにプランを立てるように指示しています。

ガードレールを用意していたので、動作を担保した上でリファクタリングができて安心でした。

v0 コードをプロダクションコードに落としてみて

今回やってみての感想ですが、結論として v0 からプロダクションコードへは落とさない方が良いと思いました。

理由はガードレールの設定、リファクタリングが想像以上に大変だったからです。

v0 で生成した仕様書のレビュー、テストケースの網羅性の確認など、人間のチェックが必要な場面が多くなってしまいました。また、コードの品質が悪いと AI Agent のパフォーマンスも落ちるため、ゼロベースで生成した方が高速で高品質なものを作れる可能性が高いでしょう。

「せっかく動いているものがあるし、それを使えれば良いだろう」という考えは捨てたほうが良さそうです。

v0 駆動開発について

下記、v0 からプロトタイプ生成〜プロダクションコードへの移行をしてみての所感です。

v0 を使うべき場面

要件定義・プロトタイピング段階
ステークホルダーとの認識合わせ
単発的な機能やツールの作成

v0 を使わない方が良い場面

プロダクションコード開発
既存デザインシステムへの準拠が必要
長期的な保守が必要なコード

v0 は要件定義段階でプロトタイプをサッと作って動くものを見てもらうフェーズで威力を発揮します。

一方、生成されるコードの品質は低いためプロダクションへの流用は避けた方が良いでしょう。

また、v0 を効果的に使えるのは必ずしも開発者だけではないと感じました。

特にデザイナーやビジネスメンバーが使ってみても面白いのではないでしょうか。デザイナーの知見があった上で v0 へのプロンプトを渡せばより高品質な UI を生成できるでしょうし、ビジネスメンバーが「こんな機能が欲しい」という要望を伝える時にも活用できます。言葉で説明するより、実際に動くものを見せた方が伝わりやすいですよね。