Slide 1

Slide 1 text

PdMによる Liveバイブコーディング 〜プロトタイプ開発実践〜 前⽥拡 / @kakumaeda

Slide 2

Slide 2 text

(C)PharmaX Inc. 2025 All Rights Reserve 2 ⾃⼰紹介 前⽥ 拡(まえだ かく) PharmaX株式会社 YOJOカンパニー プロダクト&マーケティング責任者 / PdM 新卒Gunosyで広告営業‧広告運⽤、 エン‧ジャパンで転職サイトのPdMを担当した後、 現職PharmaXでtoCヘルスケアプロダクトのPdM、 AIエージェントの開発‧設計、プロンプトエンジニアリング、 Vibe codingでプロトタイプ開発などに従事。 #開発未経験 #PdM経験3年弱 @kakumaeda

Slide 3

Slide 3 text

(C)PharmaX Inc. 2025 All Rights Reserve 3 医療業界を横断する 2つの事業領域 YOJO toC事業 BtoC/BtoB両事業で AIエージェントを実装することで患者満足度世界一の医療体験を実現 AX toB事業 “まだ誰も見たことのない ”10Xな医療体験の実現 既存医療インフラの AIによる劇的なアップデート

Slide 4

Slide 4 text

4 (C)PharmaX Inc. 2025 All Rights Reserve 医療アドバイザーに体調 のことをいつでも気軽に相 談できる 相談型医療体験 30種類以上の漢方薬からあ なたに合ったものを月毎に 提案 パーソナライズ漢方薬 定期的に漢方をお届けし、 一人ひとりに寄り添うかか りつけ医療を提供 継続的なかかりつけ 一生涯にわたって寄り添うかかりつけ漢方薬局「 YOJO」

Slide 5

Slide 5 text

(C)PharmaX Inc. 2025 All Rights Reserve 5 患者向けチャットシステムと薬剤師向け管理画⾯を⾃作 患者とのスムーズなコミュニケーション 薬剤師向け管理画面 チャット形式での診断・相談・購入 患者向けチャットシステム

Slide 6

Slide 6 text

(C)PharmaX Inc. 2025 All Rights Reserve 6 本⽇の構成 1. AI時代のプロトタイプについて(前回イベント内容おさらい) 2. データ駆動プロトタイピングについて 3. 某Y◯UTRUSTさんのキャリアシミュレーション機能を再現してみよう 4. 名刺管理サービスを作ってみよう(時間あれば) 冒頭10分程度は説明パートですが、それ以降は基本的には「Liveバイブコーディング」 という形で実際に画⾯映しながら、お⾒せできればと思います💪 ただオンラインということもあり、反応が⾒えなくて不安なので、 ぜひチャットで気軽にコメント‧質問ください󰢛

Slide 7

Slide 7 text

(C)PharmaX Inc. 2025 All Rights Reserve 7 ⚠セキュリティについての注意点 本イベントで紹介する⼿法‧ツール‧サービスの利⽤に際しては、 各⾃の判断と⾃⼰責任のもと、所属組織のポリシー および関連法令などを遵守してご利⽤ください。 参加者の皆さまによる利⽤や運⽤の結果については 責任を負いかねますので、あらかじめご了承ください。

Slide 8

Slide 8 text

(C)PharmaX Inc. 2025 All Rights Reserve 8 本⽇の構成 1. AI時代のプロトタイピングについて(前回イベント内容おさらい) 2. データ駆動プロトタイピングについて 3. 某Y◯UTRUSTさんのキャリアシミュレーション機能を再現してみよう 4. 名刺管理サービスを作ってみよう(時間あれば)

Slide 9

Slide 9 text

(C)PharmaX Inc. 2025 All Rights Reserve 9 みなさん普段プロトタイプ作ってますか??

Slide 10

Slide 10 text

(C)PharmaX Inc. 2025 All Rights Reserve 10 世の中の変化 海外事例 ● Google: ライティング優先の⽂化からビルディング優先の⽂化へと移⾏ ● Shopify: PdMの⾯接にコーディングセクションを追加 ● Lovable: PM組織もPRDもない「Just build it.」の⽂化 — Product Leader at Google - Gemini. — Opendoor CEO, 元Shopify COO — Lovable - Growth 前回イベントスライドのおさらい

Slide 11

Slide 11 text

(C)PharmaX Inc. 2025 All Rights Reserve 11 なぜ今、この変化が起きているのか? 🔧 従来の制約 • “忠実度の⾼い”プロトタイプ作成は コストが⾼かった • 特にエンジニアの⼯数が必要 • このコスト構造は数⼗年変わってい なかった • その中でFigmaがここ数年、主要な ツールであった 🚀 AI時代の変化 • Lovable、Bolt、V0、Figma Make などの登場によりコストと便益のバ ランスが変わった • 特にライブデータプロトタイプの コストが劇的に引き下がった ○ 従来のFigmaで作成していた ユーザープロトタイプより ⾼速‧安価な場合も —『The Purpose of Prototypes』:https://www.svpg.com/the-purpose-of-prototypes/ 前回イベントスライドのおさらい

Slide 12

Slide 12 text

(C)PharmaX Inc. 2025 All Rights Reserve 12 プロトタイプの種類 ① 実現性プロトタイプ ⽬的: 技術的実装可能性の検証 特徴: 機能限定‧コード中⼼、UI最⼩限 ② 低忠実度ユーザープロトタイプ ⽬的: アイデアの早期検証、初期探索、コン セプト検証 特徴: スケッチ、ワイヤーフレーム ③ ⾼忠実度ユーザープロトタイプ ⽬的: ユーザビリティ‧ユーザー体験の検証 特徴: 本番に近い⾒た⽬と動作 データは⾮常にリアルだが、現実ではない ④ ライブデータプロトタイプ ⭐ ⽬的: 実データでのKPI影響検証、定量的価値 検証 特徴: 実装コスト⾼いが、結果の信頼性も⾼い —『Flavors of Prototypes』:https://www.svpg.com/flavors-of-prototypes/ 前回イベントスライドのおさらい

Slide 13

Slide 13 text

(C)PharmaX Inc. 2025 All Rights Reserve 13 PdMがプロトタイプを作ることについて ● ⼀般的なプロダクトの場合、多くのPdMは、 ○ 顧客からの1次情報を最も多く持っている ○ ドメイン固有の知識を有している ○ プロダクト開発の素養を持っている → 結局プロトタイプ作る際、   コーディングエージェントやプロトタイプツールに   上記コンテキストを渡していく必要があるため   PdMが適任の場合は多そう   (顧客のことを最も理解し、1次情報を持つ⼈が作るべき、    そのため、ドメインやプロダクトによって最適な⼈は違う    もちろん、どのくらいの忠実度にしたいかにもよる) 前回イベントスライドのおさらい

Slide 14

Slide 14 text

(C)PharmaX Inc. 2025 All Rights Reserve 14 AI時代のプロトタイプとは?について 詳しくは前回イベントのスライドをご覧ください🙏 Vibe codingで作る、“忠実度の⾼い” プロトタイプのススメ

Slide 15

Slide 15 text

(C)PharmaX Inc. 2025 All Rights Reserve 15 本⽇の構成 1. AI時代のプロトタイピングについて(前回イベント内容おさらい) 2. データ駆動プロトタイピングについて 3. 某Y◯UTRUSTさんのキャリアシミュレーション機能を再現してみよう 4. 名刺管理サービスを作ってみよう(時間あれば)

Slide 16

Slide 16 text

(C)PharmaX Inc. 2025 All Rights Reserve 16 従来の「Vibe Coding」の課題 AIプロトタイピングツールを使⽤する際、曖昧で感覚的な指⽰(プロンプト)に頼り がち。 「モダンでクールな旅⾏アプリを作って」といった指⽰は迅速だが、以下のような深 刻な問題を引き起こす。 1. 品質が安定しない 2. 詳細な要件が満たされない 3. 何度もやり直しが発⽣する など

Slide 17

Slide 17 text

(C)PharmaX Inc. 2025 All Rights Reserve 17 解決策としてのデータ駆動プロトタイピング ● TinderのCPOであるRavi Mehta⽒が提唱。 ● 「データ駆動プロトタイピング」という⼿法は、UIのデザインや機能要件を ⾃然⾔語で記述するのではなく、まず構造化されたデータ(JSON)を定義する ことから始めるアプローチである。 ● LLMに⾃然⾔語で指⽰し、データ構造を作成する。 (例:旅程、ユーザー属性、⽇付範囲などを定義) まずデータ構造(JSON)を固めることで、 AIは「データの捏造」から解放され、 UIとUXの構築という単⼀のタスクに集中できる。 これにより、アウトプットの精度と、 整合性が劇的に向上する。

Slide 18

Slide 18 text

(C)PharmaX Inc. 2025 All Rights Reserve 18 データ駆動プロトタイピングのメリット 1. 品質の安定:データ構造がUIの背⾻となるため、デザインのブレが極⼩化され、 ⼀貫性のあるUXが保証できる。 2. 圧倒的な効率:素材探しや微調整の⼿作業が激減し、本質的な体験設計に時間を 使える。 3. ハルシネーション排除:整合性の取れた構造化データを使⽤するため、デモ中の エラーを防げる。 4. 実装への近道: ここで作成したJSONスキーマは、そのまま本番開発のAPI仕様や フロントエンドのモックデータとして再利⽤可能。 参考動画:https://youtu.be/_yQMGHHl49g?si=VVhjWkaVAvJR6p0K

Slide 19

Slide 19 text

(C)PharmaX Inc. 2025 All Rights Reserve 19 先週までは、この「データ駆動プロトタイピング」 の考え⽅がベストだと思ってました🙌 ただ現在は、、、

Slide 20

Slide 20 text

(C)PharmaX Inc. 2025 All Rights Reserve 20 Gemini Pro 3の登場によって考え⽅を変えました🧠 とりあえず、Gemini使ってVibeで作ればいいのでは?󰱢

Slide 21

Slide 21 text

(C)PharmaX Inc. 2025 All Rights Reserve 21 個⼈的現時点での最適解 ● まずは、「Vibe」でいろんなツールで⽣成、修正を繰り返しながら発散する Gemini Pro 3だとポンだしでの完成度がかなり⾼いので。 ただLLMの出⼒は⾮決定論的であるので、余裕があれば並列で複数実⾏して ⼀番良い出⼒を選択する ● そのあと要件‧データ構造を固め、それに従って再⽣成または修正を⼊れ収束さ せるのが良さそう ● 引き続きデータ駆動で進めるのは有⽤、 ライブデータに近い忠実度の再現や、 品質の安定性が⾼まる

Slide 22

Slide 22 text

(C)PharmaX Inc. 2025 All Rights Reserve 22 個⼈的ツール使い分け(プロトタイプ作る場合) 1. Google AI Studio(基本無料!助かる!) a. とにかく簡単にLLM組み込んだ機能作りたい b. Cloud Runへのデプロイが容易 2. Figma Make(利⽤可能なプランでは現時点では無料!) a. Figmaデザインファイル読み込み可 →既存プロダクトの簡易的なプロトタイプ作成が容易 b. Supabase連携 3. Cursor(+ Codex / Claude code) a. Figmaデザインファイル読み込み可(Figma MCP) b. Google以外のLLMモデル使⽤可、Composerが速くて素敵 c. バックエンド実装まで⾃分でやる場合 モデル選択・シ ステム構成の柔 軟性低い 柔軟性高い

Slide 23

Slide 23 text

(C)PharmaX Inc. 2025 All Rights Reserve 23 本⽇の構成 1. AI時代のプロトタイピングについて(前回イベント内容おさらい) 2. データ駆動プロトタイピングについて 3. 某Y◯UTRUSTさんのキャリアシミュレーション機能を再現してみよう 4. 名刺管理サービスを作ってみよう(時間あれば)

Slide 24

Slide 24 text

(C)PharmaX Inc. 2025 All Rights Reserve 24 某Y◯UTRUSTさんのキャリアシミュレーション機能 ユーザーのキャリア情報をInputにAI(おそらくLLM)でキャリアシミュレーションし てくれる機能 🧠

Slide 25

Slide 25 text

(C)PharmaX Inc. 2025 All Rights Reserve 25 本⽇の構成 1. AI時代のプロトタイピングについて(前回イベント内容おさらい) 2. データ駆動プロトタイピングについて 3. 某Y◯UTRUSTさんのキャリアシミュレーション機能を再現してみよう 4. 名刺管理サービスを作ってみよう(時間あれば)

Slide 26

Slide 26 text

(C)PharmaX Inc. 2025 All Rights Reserve 26 PdMがプロトタイプを作ることについて ● ⼀般的なプロダクトの場合、多くのPdMは、 ○ 顧客からの1次情報を最も多く持っている ○ ドメイン固有の知識を有している ○ プロダクト開発の素養を持っている → 結局プロトタイプ作る際、   コーディングエージェントやプロトタイプツールに   上記コンテキストを渡していく必要があるため   PdMが適任の場合は多そう   (顧客のことを最も理解し、1次情報を持つ⼈が作るべき、    そのため、ドメインやプロダクトによって最適な⼈は違う    もちろん、どのくらいの忠実度にしたいかにもよる) 再掲

Slide 27

Slide 27 text

(C)PharmaX Inc. 2025 All Rights Reserve 27 まとめ ● 結局プロトタイプツールに与えるJSONスキーマ、JSONデータも、 コンテキストの⼀種であり、それがなければLLMの学習データに依存した出⼒に しかならないよねという整理 ● 満⾜いく出⼒が得られない理由の多くは、コンテキスト不⾜または、 コンテキスト(プロンプト)エンジニアリングが下⼿だからでは? ○ Lost in the Middle(コンテキストの中間部分が抜け落ちる問題) ○ Multi-turn Degradation(マルチターンの会話における性能劣化) ● PdMまたは企画者としては、結局実現したいことに対して、 適切な要件を決め、必要なコンテキストを適切に渡していくことが⼤事 プロトタイプ作成においては、それを渡す先が各種ツールであるだけ ● ただ変化が激しいので、「前提⾃体が変わることを前提」として柔軟に対応する