「MVPは1ヶ月で公開できる」と言われても、何をどこまで削れば1ヶ月になるのかは、実例を見ないと分かりません。本記事では、Wildcardが開発した睡眠管理アプリTrisleepを題材に、1ヶ月でApp Storeへ初期リリースし、3ヶ月で実ユーザー検証まで進めた実際の進め方を公開します。
この記事のポイント
- 事業仮説の検証に必要な最小限の機能に絞り、1ヶ月でApp Storeへ公開
- 「オープンβ」と「クローズドβ」の2段階公開で、価値検証と安全性検証を分離
- 3ヶ月でユーザーインタビュー・アンケート3回、クローズドβテストユーザー10人
- モデル切り替え可能なアーキテクチャとLLM評価基盤で、健康領域のAI活用を安全に検証
プロジェクトの背景
睡眠関連事業を検討するヘルスケア企業において、どのユーザー層に・どの課題が・どの文脈で存在するのかの理解に課題がありました。機能の完成度を高めること自体を目的とせず、事業性を見極めるためのテストマーケティングとしてβプロダクトを開発する方針を取りました。
LEANの原則に基づき、まず実ユーザーへ迅速に届け、反応から学ぶことを重視しています。
検証したかったこと
Trisleepの検証目的は、次の二つに整理されます。
- 価値の検証 — ユーザーの睡眠データをもとにAIが生成する睡眠レポートは、ユーザーにとって実際に価値を生むか
- 安全性の検証 — 健康という慎重さが求められる領域で、AI(LLM)を安全に活用できるか
この二つは求められる慎重さが違います。後述するとおり、公開範囲そのものを分けることで、両方を同時に検証できる設計にしました。
1ヶ月で公開するために、何を入れて何を削ったか
初期リリース(W1-4)に入れたのは、事業仮説を検証するための最小限の機能です。
- 入れたもの — Apple Watchと連動した睡眠データの取得、睡眠データをもとにした睡眠レポートの生成
- 後の段階に回したもの — レポートページの拡張、LP、AIチャット機能
- 限定公開に回したもの — LLMによる睡眠アドバイス(精度・安全性の検証が必要なため)
削り方の考え方は「機能を薄く広げる」ではなく、一つの価値(睡眠レポート)を実ユーザーが体験できる状態を最短で作ることです。この最小スコープ×最大完成度の考え方が、1ヶ月という期間の土台になっています。
公開範囲の設計 — オープンβとクローズドβ
Trisleepの特徴は、機能ではなく公開範囲を検証設計に組み込んだことです。
| 段階 | 公開範囲 | 検証したこと |
|---|---|---|
| オープンβ | App Storeで一般公開 | 実際の睡眠データから生成されるレポートの内容・表現が有益か |
| クローズドβ | 限定ユーザー(10人)のみ | AIレポート・チャット機能のリスクと可能性 |
睡眠レポートは一般公開して広く利用データを集める一方、LLMを使ったアドバイス機能は、精度や安全性の観点からクローズドβとして限定ユーザーのみに提供しました。リスクの大きさに応じて公開範囲を変えることで、安全性を確保しながら検証の範囲を最大化しています。
3ヶ月の進め方
| 期間 | フェーズ | 実施内容 |
|---|---|---|
| W1-4 | 初期リリース | 最小限の機能で開発、App Store公開、テストユーザーの確保と初期反応の取得 |
| W4-8 | ユーザー理解の深化 | ユーザーインタビュー・アンケートによる定性調査、オープンβでの課題・期待・利用背景の深掘り、レポートページとLPの開発 |
| W8-12 | 仮説検証の拡張 | LLMチャット機能を追加、クローズドβでFeature単位にテストユーザーを集めて反応を比較 |
検証の実数は次のとおりです。
- App Storeへの初期リリースまで: 1ヶ月
- ユーザーインタビュー・アンケート: 3回
- クローズドβのテストユーザー: 10人
10人という数字は小さく見えますが、全員の利用文脈と反応を追える規模だからこそ、定量データとインタビューを組み合わせた濃い一次情報が取れます。少人数での測り方はMVP検証のKPI設計で解説しています。
技術面の設計 — 変化の速いLLMを前提にする
健康領域×LLMという構成のため、技術設計にも検証を支える工夫を入れています。
- サーバーサイドにAI基盤を置く — モデルの進化ごとにアプリを更新しなくて済むよう、AI基盤とプロンプト管理をサーバーサイド(FastAPI + LangChain)に分離。アプリを触らずにモデルを切り替えられる
- LLM出力の評価基盤 — LangSmithのEval機能でLLM Judgeの評価基盤を構築し、モデルの出力品質を継続的にモニタリング。健康領域でAIを安全に使うための「前提ゲート」として機能
MVPだからといって技術品質を落とすのではなく、検証を続けるために必要な品質(安全性・変更容易性)には投資するという判断です。
この事例から一般化できること
- 公開範囲は機能と同じくらい重要な設計変数 — 全公開か非公開かの二択ではなく、リスクに応じてオープンβ・クローズドβを併用する
- 1ヶ月は「削る勇気」の結果 — 技術力だけでは1ヶ月にならない。一つの価値に絞る意思決定が先にある
- リリースは検証計画の入口 — 1ヶ月の公開はゴールではなく、3ヶ月の検証計画の最初のマイルストーン
プロダクトの詳細はWorks: Trisleep、プロジェクトの支援内容は10X BUILDで公開しています。MVP開発全体の進め方はMVP開発とはを参照してください。
よくある質問
同じ期間・体制で自社のアプリも作れますか
対象範囲・連携・品質条件によります。Trisleepの1ヶ月は、価値を一つに絞り、リスクの高い機能を後段のクローズドβへ分離した結果です。条件の違いによる期間の変わり方はMVP開発の期間で解説しています。
なぜ最初からAIチャットを公開しなかったのですか
健康領域のアドバイスは誤りのリスクが大きく、品質評価の仕組みを整えてから限定ユーザーで検証する方が、学びを止めずに安全を確保できるためです。安全性は検証のKPIではなく前提条件として扱っています。
