チームを加速させるPdMのAI活用術:V0編

シンプルでかっこいいロゴや・・・

本記事は、プロダクト開発の最前線にいるすべての方、特にこれからPdM（プロダクトマネージャー）を目指す方や、デザイナーやエンジニアではないけれど「アイデアを素早く形にしたい」と考えるビジネスサイドの方に、ぜひ読んでいただきたいと思い執筆しました。

PdMの仕事は、単なる企画書づくりや進行管理にとどまりません。プロダクト開発の現場においては、「アイデアを形にしてチームに伝える」という極めて重要な役割を担っています。

しかし現実には、同じ言葉を使っていてもメンバーごとに頭の中のイメージは微妙に異なります。

たとえば「新しいダッシュボードを作る」と一口に言っても、それぞれの立場で見えているものはこれだけ違います。

• エンジニア： データ構造やAPI設計を思い浮かべる
• Bizサイド： 顧客の利用シーンを想像する
• PdM自身： UIの流れを考えているかもしれない

言葉が一致していても、その裏にある像は必ずしも一致していないのです。

このズレはプロジェクト初期、いわゆる0→1フェーズで特に顕著です。
その結果、手戻りが増え、議論が堂々巡りし、貴重な時間が失われてしまうことが少なくありません。

このような齟齬を埋めるもっとも効果的な方法は、抽象的な言葉や図ではなく「具体的な形」を見せることです。

仕様書やFigmaのワイヤーフレームも一定の役割は果たしますが、動くプロトタイプを一つ提示するだけで、チームの共通理解が一気に加速することを私たちは何度も経験してきました。

PdMの仕事は「言葉を尽くす」ことではなく、むしろ「まず形にして議論を前に進めること」。

ただし、課題はここで終わりません。私たちのチームには専任のデザイナーがいませんでした。

そのため「では具体的な形をどうやってつくるのか？」という新しい問題に直面しました。Figmaで1枚ずつ画面を描くこともできますが、スピードと手間のバランスを考えると限界がある。そんな時に出会ったのが V0 でした。

V0は、頭の中のイメージをそのまま言葉にして入力するだけで、数分後には画面遷移まで備えたプロトタイプを生成してくれます。以前はFigmaでの時間のかかる作業が、一気に短縮され、しかも納得感のあるアウトプットとして返ってくる。これに触れた瞬間、私たちの開発スタイルは大きく変わりました。

「考え込むより、まず作って見せる」

このサイクルを加速させてくれるのが、V0をはじめとするAIプロトタイピングです。実際に導入して試してみたとき、チームメンバーからも顧客からも「これならわかる」「これならすぐ試したい」という反応をもらえたのは、大きな転機でした。

多様なAIツールが次々と登場する今こそ、PdMという役割の在り方も進化しなければなりません。

本記事では、AIプロトタイピングを活用することでPdMがどのように課題を突破できるのか、そしてそれがチーム全体にどのような影響を与えるのかを整理し、ナレッジとして共有します。

なぜ数あるAIツールの中でv0なのか

最近スマホアプリも出たよ

ここ1年ほどで、AIを活用したプロトタイピングツールは爆発的に増加しました。
たとえば、以下のようにそれぞれ得意分野が異なります。

• デザイン寄りのツール

  • Lovable や Bolt など。プロトタイピングに特化し、直感的なUI作成を得意とします。

• コーディング寄りのツール

  • Devin、Cursor、Claude Code、Codex CLI など。よりコーディングに近いアシストを提供し、エンジニアリング力を活かしたワークフローを可能にします。

このように選択肢が広がった結果、実際にどのツールを使うかは、利用者の志向やスキルセットによって大きく分かれます。

コードを書きながらプロトタイピングしたい人であればCursorやClaude Codeを、デザインの雰囲気を重視したい人はBoltやLovableを選ぶかもしれません。

その中で私たちが V0 を推す理由は、単なる機能比較ではなく「チームやPdMとの相性」にあります。

具体的には以下のような点です。

• 生成されるデザインの雰囲気が、PdMの言語感覚と自然にマッチする
• Next.jsベースかつshadcn/uiを採用しているため、現場の技術スタックにスムーズに流用可能
• 「とりあえず作る」ことに適したシンプルな操作性とスピード感

ただし、最初から完璧に使えたわけではありません。会社立ち上げ直後にV0を試した際は「すごいけれど実務では使いにくい」という印象でした。デザインが崩れていたり、画面完成度が低かったりと、実験的なおもちゃに近い存在だったのです。

ところが半年後に再度試すと、状況は一変していました。「十分実用に耐えられるレベル」にまで改善が進んでおり、その進化スピードに強い衝撃を受けました。早期から継続的に触れていたからこそ、この成長を肌で実感できたのは大きな経験です。

もちろん、V0にも課題はあります。プロトタイプを作り込みすぎると極端に重くなり、操作がもっさりして「これ以上は限界」と感じることも少なくありません。

そこで私たちは実務の中で、V0で素早く形を出し、その後DevinやCursor、Claude Codeで改良を加えるという運用に落ち着きました。

この経験からわかったのは、AIツールは単体で完結させるものではなく、複数を組み合わせて使うのが現実的ということです。それぞれのツールの得意分野を活かし、ワークフローにどう組み込むかが成功の鍵になります。

v0のランタイムがNextの軽量のものらしく、プロジェクトが大きくなってきてうまく動かないことが増えてきたので、最近はCursor & Claude Codeを使ってます、、、😢

それでも、AIプロトタイピングがもたらす価値は圧倒的です。

• 顧客に「動くもの」を見せるまでの時間が劇的に短縮される
• 打ち合わせ中に出たアイデアをその場で形にできる
• 非エンジニアでも「触れる形」を出せるため、議論が一気に前進する

この体験を一度でもすると、従来の仕様書ベースのやり取りにはもう戻れません。

AIプロトタイピングの本質は、美しいデザインやコード品質にあるのではなく、共通認識を圧倒的なスピードで作り上げる力にあります。

KENCOPA流：AIツールを文化として根付かせる方法

弊社Slackの投稿：いろんなツール使っている

弊社Slackの投稿：Soraをみんな使おうね～
私たちKENCOPAが開発文化として大切にしているのは、単に「最新のツールを導入する」ことではなく、新しい技術をどうワークフロー全体に組み込み、チームに浸透させるかという視点です。

まず根本にあるのは「新しいツールはとにかく試してみる」という姿勢です。個人が勝手に試すのも自由ですし、チーム全体として「まず触ってみよう」という雰囲気を奨励しています。

PdM自身が率先して試し、その結果を社内に共有する。正直、周囲から「また変なの触ってる」と思われるくらい頻繁に紹介しているのですが、そうした継続的な試行が新しい文化を生み出すと考えています。

ただし、「試す」ことと「導入する」ことは別です。

• まずは軽く触ってみて価値を検証する
• セキュリティなどの懸念点を調べる
• 有効と判断すれば導入し、標準化してルール化する
• 微妙であれば即座に切り捨てる

このようにフィルタリングを重ねることで、無秩序なツール導入を避けつつ、現場に合った選択ができます。

さらに重要なのは、ツール単体ではなくワークフロー全体をどう設計するかです。

• どの段階でどんなドキュメントを作成し、AIやエンジニアに渡すのか
• 実装をどこまでAIに任せ、どこで人間がレビューを行うのか
• プロトタイプを誰がどう引き継ぐのか

こうした流れを体系化することで、スピードと品質を両立させています。

ここで私たちが特に重視しているのがドキュメントの扱いです。V0のようなツールでプロトタイプをすぐに生成できるのは強力ですが、それだけでは「一過性の共有」で終わってしまう可能性があります。
そのためKencopaでは、必ずドキュメントを整備し、それをチームに渡すことを習慣にしています。

この流れの中で重要なのは、PdM自身が常にツールに触れ、AIを自分の手で試すことです。

AIプロダクトを考える立場の人間が「こういう体験ができるはず」と理屈で語るだけでは説得力がありません。実際に触れて「AIがどこまで助けてくれるのか」「どこで人間の判断が必要なのか」を体感することが、PdMとして正しい判断につながります。

つまり、「まず触ってみる」ことを避けるPdMには、AI時代のプロダクトは語れない。

私たちはそう考え、実践しています。

PdMがAIプロトタイピングを行うとチームに起きる4つの変化

AIプロトタイピングをPdMが率先して導入すると、その効果は想像以上に広がり、チーム全体に波及します。

弊社ではV0がすごくて、プロダクトのモック＝v0という用語が定着していて
「V0作った？」「とりあえずV0でやってみる」みたいな会話が頻繁に行われています。

まず大きいのは、仕様の齟齬が大幅に減ることです。

文章や口頭で「こういう機能を作りたい」と説明しても、人によってイメージは異なり、後から「それってその機能のことだったの？」「いや、別の要件だと思っていた」と認識のズレが明らかになることは珍しくありません。そのたびに修正工数が発生し、チームの負担は増えていきます。

ところが、V0やCursorでサッと作った画面を見せれば、その場で全員が同じ像を共有できます。「ああ、これなら理解できる」と即座に合意が得られ、議論が一気に前に進むのです。この即時性は社内だけでなく、顧客との打ち合わせでも非常に有効で、特に要件が曖昧になりがちな受託開発やPoCの場面では大きな武器になります。

次に重要なのが、エンジニアにとっての負担が軽減されることです。

従来であれば「この画面をこう作りたい」と口頭やFigmaで説明されても、エンジニアはUI構造を改めてコードに落とし込む必要がありました。しかしAIプロトタイピングでは、最初からコードベースで雛形が生成されます。つまり、ゼロから設計するのではなく、すでに存在する基盤を読み取りつつ修正・拡張する形になる。

エンジニアにとっては「抽象的なデザインを解釈する」より「コードを読み取りつつ直す」方がはるかに効率的です。PdMがAIを使って最低限の形を提示することで、エンジニアは余計な想像や設計の手間を省き、本質的な開発に集中できるのです。

さらに、デザイナーにとっての価値も高まります。

PdMが最低限のプロトタイプを用意することで、デザイナーはゼロから探索する必要がなくなり、「どう洗練させるか」「どう体験を高めるか」に注力できます。デザイナー不在の場面ではPdMが最低限をカバーし、デザイナーがいる場合には創造性を引き出す。どちらのケースでも強みを発揮できる構造です。

そして何より、開発サイクル全体が高速化する点は見逃せません。

アイデア → プロトタイプ → フィードバック → 実装 → 検証、この一連の流れが短縮されることで、顧客に触ってもらうまでの時間が圧倒的に速くなります。その結果、検証サイクルが加速し、プロダクト全体の学習スピードが上がります。

副次的な効果として、心理的安全性の向上もあります。

PdMが「まず形にして見せる」という姿勢を示すと、エンジニアやデザイナーも「完璧ではないが、とりあえず試してみよう」というマインドを持ちやすくなります。完成度よりスピードを優先する文化が根づき、チーム全体が柔軟かつ前向きに提案できるようになるのです。

AIプロトタイピングの落とし穴と向き合う

一方で、AIプロトタイピングの導入には注意すべき点も存在します。

まずは、役割の変化リスクです。

PdMがある程度までプロトタイプを作れるようになると、「デザイナーは不要なのでは？」「エンジニアの仕事が減るのでは？」といった誤解を招くことがあります。これはチームによってはポジティブにもネガティブにも働き得る変化であり、意図をきちんと説明しないと反発を生む可能性があります。

次に、コスト面の課題です。

V0やDevinといったツールは安価ではありません。チーム全員が契約すると、毎月数十万円規模のランニングコストになることもあります。したがって「試すこと」と「本格導入」を分け、投資判断を冷静に行う必要があります。

また、最低限の技術理解が必須という点も忘れてはいけません。

AIツールは「完全ノーコードで誰でも自由自在」と誤解されがちですが、実際にはフロントエンドやAPIの基礎知識がなければ十分に使いこなせません。PdM自身もある程度コードを理解しておくことで、AIの出力を現場に流用できるレベルに引き上げることができます。逆に知識ゼロだと「一時的なおもちゃ」で終わってしまいます。

さらに、ツール依存リスクもあります。

実際、V0でもMockを増やすと処理が重くなったり、アップデートで挙動が変わったりすることがあります。特定ツールに過度に依存すると、サービス終了や仕様変更の影響を大きく受ける可能性があります。そのため、常に複数ツールを比較・検証し、柔軟に切り替えられる体制を保つことが重要です。

そして最後に、「過剰な装飾・機能追加」のリスクです。

AIが自動的にUIを装飾したり、不要な機能を実装したりするケースも見られます。一見リッチに見えるものの、実際には本来の目的から外れ、仕様の肥大化やメンテナンスコスト増につながることがあります。
削れば済む話ではあるものの、「余計なことまでやってくるAI」は開発現場では少なからずストレス要因となり得ます。したがって、AI出力をそのまま受け入れるのではなく、人間側が“削ぐ力”を持つことが重要です。

V0を現場で活かすための実践Tips

V0は日々アップデートされています。内容が古くなっている場合があります。

ここまで、AIプロトタイピングの背景やメリット・デメリットを整理してきました。
最後に、実際にv0を現場で使うときに意識しておくと成果が出やすいポイントを、いくつかTipsとして紹介します。

• 1. プロジェクト単位での管理を徹底する
     V0は、単発で試すよりも「Project」を単位にして文脈を積み上げていくと本領を発揮します。
     プロジェクトごとにナレッジやAPIキー、環境変数を整理しておくと、後々の拡張性が格段に上がります。外部インテグレーションまわりはまだ不安定なところもありますが、「最初に管理ルールを決めておく」だけでも混乱を防げます。
• 2. GitHub連携は必須
     ブランチを切り、プッシュ・プルまでできるので、PdMが作ったプロトタイプをそのままチームのコード資産に渡せます。CursorやDevinなど、他のAI開発環境と連携する上でもこの連携は欠かせません。
• 3. デザインモードは補助
     最近追加されたデザインモードは、色味調整や軽微なUI修正には便利です。
     ただし現時点では挙動が不安定な部分もあり、メインの開発フローに組み込むのはまだ早い印象です。「最終微調整用ツール」として割り切って使うのが現実的。今後のアップデートには期待したいところですね。
• 4. プロンプトはシンプルかつ体験ベースで書く
     実は、「Enhanced Prompt」を細かく書くよりも、欲しいUXや利用シーンを素直に書いた方が良い結果が出ることが多いです（筆者の体感）。
     “こんな体験にしたい”とか、“こういう操作感を目指したい”という文脈を伝えるだけで、Vibe Promptがうまく汲み取ってくれます。
     もし参考になる画像があれば、それを一緒に渡すのも効果的です。

  最近Enhanced PromtがEnhancedされたみたいです。

• 5. AIが余計なことまでやってくる問題
     これは一見リッチに見えますが、現場では「仕様が膨らんで逆にやりづらい」原因にもなります。
     削れば済む話ではあるものの、AIが“良かれと思って”やりすぎることはあるので、最終的には人間が取捨選択して整える意識が大事です。

こうしたポイントを押さえるだけでも、AIプロトタイピングが「単なるおもちゃ」から「チームの武器」へと変わります。
v0を使うなら、「どこまでAIに任せ、どこから人が仕上げるか」を意識するだけで、プロジェクト全体の生産性と完成度が大きく変わるはずです。

大生成AI時代のPdM像

AIプロトタイピングは、もはやPdMにとって特別なスキルではなく、必須の基本動作になりつつあります。

言葉や図だけでは伝わらないイメージを「動く形」で示すことで、チームの共通理解が劇的に早まり、顧客の反応も最速で得られるようになります。結果として、プロダクトの学習サイクル全体が加速します。

もちろん、コストやツール依存、最低限の技術理解といった課題は存在します。しかし、これらは「どう活用するか」を設計することで十分に乗り越えられるものです。試行錯誤を続けることで、PdMは「仕様を書く人」から「プロダクトを動かす人」へと進化できます。

まずは手を動かし、形を出す。その積み重ねが、チームを前進させ、ユーザーに価値を届ける最速の方法です。

AIを活用するかどうかではなく、どうAIを組み込み、プロダクト開発の当たり前にするかが問われる時代に入っています。PdMもエンジニアもデザイナーも、AIを前提とした開発を取り入れることで、これまでにないスピードと質を同時に実現できるはずです。

これからも、PdMだけでなく、エンジニア・デザイナー・そしてAIやテックに強くなりたいすべてのメンバーに向けて、これからも実践的な記事を発信していきます。

もしこの記事が少しでも参考になったら、ぜひ「いいね」やシェアで応援してもらえると嬉しいです。
また、株式会社KENCOPAでは一緒にこうした挑戦を進めていく仲間も探しています。
興味のある方は、ぜひこちらからご連絡ください

https://kencopa.com/recruit
カジュアル面談も歓迎です！