AIで作ったMVPは顧客に出せる状態か？ローンチ前に確認すべき12項目

最初のバージョンは見栄えがよく仕上がっています。ダッシュボードを見せ、サンプルのレコードを作成し、チェックアウトまでクリックして進められます。より難しいのは、あなたのアプリを一度も見たことがない人が、明日同じことをできるかという問題です。このAI MVP本番チェックリストは、まさにそのギャップのためのものです。Lovable、Bolt、Replit、Base44、その他どのビルダーから始めた場合でも使えます。

MVPにとって「本番運用できる状態」とは？

本番運用できるMVPとは、適切なアクセス制御と現実的な復旧計画を備え、想定する顧客に対して範囲を絞った約束を確実に果たせるものです。ロードマップ上のすべての機能や、まだ存在しない規模のユーザーを想定したインフラは必要ありません。

以下のチェックはリリースの根拠として扱ってください。各項目について、誰がテストしたか、どのURLとバージョンを使ったか、何が起きたかを記録します。テストしていない項目は「不明」とします。見た目が整ったUIや、AIの「問題を修正しました」というメッセージは、テスト結果ではありません。

新規ユーザーは主要な利用フローを完了できるか？

新規顧客は、あなたの手助けなしにプロダクトの価値ある成果にたどり着けるべきです。既存の権限、保存済みのセッション、サンプルデータを持たないアカウントで、公開済みアプリの利用フロー全体をテストしましょう。

• チェック1 — 初回利用： サインアップし、必要であればメールアドレスを確認し、最初の有用なアイテムを作成し、一度離れてから戻ってきます。口頭で説明しなければならなかった指示をすべて記録し、フローか文言を改善しましょう。
• チェック2 — アカウント復旧： サインアウトし、対応している場合はパスワードをリセットし、期限切れのリンクを開き、セッション終了後に戻ってきます。復旧後に本番ドメインへ遷移し、顧客が作業を続けられることを確認しましょう。

ユーザーは本来アクセスすべきデータにだけアクセスできるか？

認証はユーザーが誰かを識別し、認可はそのユーザーが何にアクセスできるかを決めます。ログインが動作していても、顧客のレコード、アップロードされたファイル、管理者向けの操作が保護されていることにはなりません。

Supabaseを使っているアプリであれば、その行レベルセキュリティのドキュメントで、データベースのポリシーによって行へのアクセスを制限する方法が説明されています。実際の所有権ルールに照らして実装をレビューしてもらいましょう。他のバックエンドでも、それぞれの権限モデルを使って同等のチェックが必要です。

• チェック3 — 顧客間の分離： 一般ユーザーを2人作成し、それぞれに非公開のレコードを持たせます。リクエスト内のレコードIDを書き換えても、もう一方のユーザーのレコードが見えたり変更されたりしないことを、開発者に確認してもらいましょう。
• チェック4 — 特権操作： 一般ユーザーが自分に有料プランを付与したり、管理者を招待したり、URLを推測して非公開のアップロードにアクセスしたりできないことを、サーバー側で確認します。サインアウトした状態でも同じチェックを繰り返しましょう。

決済や外部連携は障害に耐えられるか？

信頼できる連携とは、障害や再試行が起きても、作業を失ったり誤ったアクセス権を付与したりしないものです。チェックアウトのアニメーションで成功を判断するのではなく、アプリケーションに保存された状態を確認しましょう。

Stripeを使っている場合、そのWebhookのドキュメントで、非同期の決済イベント、署名の検証、重複配信について説明されています。連携側では受信したイベントを検証し、同じイベントを二重に処理しないようにする必要があります。具体的にどのイベントが関係するかは、あなたの決済フローによって異なります。

• チェック5 — 決済状態： 決済プロバイダーのテスト環境で、成功、失敗、キャンセル、遅延した決済をテストします。適切な検証済みのサーバー側イベントが届いたときにだけアクセス権が変わることを確認しましょう。
• チェック6 — 外部サービスの障害： メール配信サービス、AIサービス、その他必須の連携を、管理されたテストで意図的に失敗させます。ユーザーには理解できる結果が表示され、二重請求や重複レコードを生まずに安全に再試行できる手段があるべきです。

本番アプリは正しいデータを保持し続けられるか？

公開済みのアプリは、想定どおりの本番データベースを参照し、顧客のファイルには永続的なストレージを使う必要があります。プレビューにデータが入っていても、本番アプリが同じ構成になっているとは限りません。

• チェック7 — 環境の分離： 各環境がどのデータベースを使っているかを特定します。機能のテストで本番の顧客レコードが変更されないことを確認し、承認されたスキーマ変更が本番に反映される手順を文書化しましょう。
• チェック8 — 永続化と復旧： レコードを保存しファイルをアップロードしたうえで、管理された再起動やデプロイの後もそれらが利用できるかをテストします。バックアップの担当者を明確にし、そのプロセスに頼る前に、安全なコピーを使って復旧のリハーサルを行いましょう。

Replitは開発用と本番用のデータベースの分離を明示的にドキュメント化しています。どのビルダーを使う場合でも、同じ実務的な問いを立ててください。本番データはどこにあるのか、誰が変更できるのか、どうやって復旧するのか。すべてのプラットフォームが同じように動くと決めつけず、アカウントで利用できる機能を確認しましょう。

障害を検知し、リリースを元に戻せるか？

顧客の利用フローが失敗したときに誰かが気づき、次に何をすべきかを把握している必要があります。エラーの可視化と復旧手順があれば、小規模なローンチの運用はずっと楽になります。

• チェック9 — 役立つエラーの記録： 無害なテスト用の障害を発生させ、対応するサーバーエラーや失敗したリクエストを見つけます。パスワード、非公開の文書、決済情報をログに残さずに、発生時刻と操作内容を記録しましょう。
• チェック10 — リリースの復旧： 最後に正常に動作していたコードのバージョン、それを復元できる担当者、そのバージョンが前提とするデータベース変更を特定します。コードを復元しても、データの変更が自動的に元に戻るわけではありません。両方の手順を別々にリハーサルしましょう。

デモ環境の外でもプロダクトは動くか？

顧客向けリリースは、最初のユーザーが実際に使うデバイスやネットワーク環境で動作する必要があります。短いサンプル名や高速なオフィス回線だけでなく、現実的なコンテンツでプロダクトを確認しましょう。

• チェック11 — 日常的な使いやすさ： 幅の狭いスマートフォン画面とキーボード操作で、主要な利用フローを完了させます。長い名前、空のリスト、バリデーションエラー、中断されたアップロードも試しましょう。読み込み中や失敗時の状態をわかりやすくします。
• チェック12 — 想定されるローンチ時の負荷： 最初の対象ユーザーについて合意し、代表的なデータ量と同時アクセスでテストします。応答時間とリソース使用量を観察しましょう。対応している場合は支出上限やアラートを設定し、誰がどのタイミングで調査すべきかを決めておきます。

顧客を招待する前に何を直すべきか？

対象ユーザーを広げる前に、壊れている主要フロー、誤った決済アクセス、不適切なデータアクセスを修正しましょう。オプション機能や見た目の改善は、これらの優先事項に合わせて計画します。

仮の予約アプリで考えてみましょう。創業者が使うと予約はできるものの、新規ユーザーはアカウントを復旧できず、決済に失敗しても予約が確定扱いになり、2つのタブから同じ枠を予約できてしまいます。次のリリースでは、これらの経路を修正すべきです。チャット機能の追加やダッシュボードの再デザインでは、ローンチの障害は解消されません。

デバッグ自体が行き詰まっている場合は、LovableとBoltの修正ループに関するガイドをご覧ください。次のステップにモバイルが含まれる場合は、既存のLovableアプリをApp Storeで公開するガイドを確認しましょう。実務的なサポートが必要な場合は、MVPの本番化について相談を予約してください。アプリのリンクと、失敗したチェック項目をお持ちいただければ、根拠に基づいて次のリリースの範囲を定めます。