AIで作ったプロトタイプを本番運用するまで

AIで作ったプロトタイプを本番運用するには、「試すと動く」から「多くの人が使っても動き続ける」へのギャップを埋める必要があります。具体的には、変更のたびに主要な操作の流れをテストすること、誰が何を見て何を変更できるかを固めること、ユーザーより先にエラーに気づけるようにすること、データをバックアップし復元できることを確かめること、そしてスマホでも十分に速く動くようにすることの5つです。作り直す必要はありません。プロトタイプを作ったAIと一緒に、このチェックリストを順番にこなしていけば十分です。

プロトタイプと本番で何が変わるのか

プロトタイプには、注意深く使う利用者が1人、つまりあなただけです。どのボタンを押せばいいか分かっていて、適切な入力をし、何かが壊れてもAIに直してもらえばいいと考えられます。本番には、不注意なユーザーが大勢いて、好奇心の強いユーザーもいれば、悪意のあるユーザーが現れることもあります。コードを「大企業向け」にする必要はありませんが、プロトタイプでは遭遇しない状況に対応できる必要があります。

このガイドの残りでは、この表の各項目を順に説明します。

ステップ1：範囲を固定し、主要な操作の流れを書き出す

何かを強化する前に、バージョン1で何を提供するかを決めましょう。最も重要な操作の流れを3〜6個リストアップします。たとえば「会員登録、プロジェクト作成、チームメンバーの招待、支払い」などです。これらが、テストの台本、監視の対象、変更のたびに確認すべき項目になります。

リストにないものは、削るか、明確にベータ版として表示しましょう。14個の流れを安定させるより、4個の流れを安定させる方がずっと簡単です。

ステップ2：見知らぬユーザーのように試し、それを繰り返せるようにする

AIビルダーは、正常な操作の流れ（ハッピーパス）で動くコードを作るのが得意です。本番での問題は、想定外の操作の流れで起きます。主要な流れのそれぞれを、次のような条件で試しましょう。

• 不正な入力：必須項目が空、5,000文字の名前、@のないメールアドレス、マイナスの数量、過去の日付。
• 再読み込みと戻るボタン：決済の途中で再読み込みする。送信後に戻るボタンを押す。二重に作成されるものはないか。
• 2つのタブと2人のユーザー：2つの異なるアカウントでログインし、URLのIDを変えて相手のページを開けないか確認する。
• 小さな画面と遅い回線：スマホの画面サイズと、通信速度を制限した状態（ブラウザの開発者ツールで再現できます）。
• 空の状態：データが何もない新規アカウント。プロトタイプはサンプルデータで作られていることが多く、データがないと壊れて見えることがあります。

そのうえで、チェックを繰り返せるようにします。最低限、書き出したチェックリストを作り、リリースのたびに実行しましょう。さらに良いのは、最も重要な流れについて、AIに自動テストを書いてもらうことです。

次の流れについて、エンドツーエンドの自動テストを追加してください。メールアドレスでの会員登録、プロジェクトの作成、2人目のユーザーの招待、Stripeのテストモードでの決済完了。さらに、URLを変えても別のユーザーのプロジェクトを閲覧・編集できないことを確認するテストも追加してください。

「ユーザーが何かを『できないこと』」を確かめるテストは、プロトタイプにほとんどないものなので、特に重要です。

ステップ3：プロトタイプで見落としがちなセキュリティの基本

AIで作ったアプリのセキュリティ上の問題の多くは、特殊なものではありません。チェックが抜けているだけです。次の一覧を確認しましょう。より詳しくはAIで作ったアプリのセキュリティチェックリストをご覧ください。

• サーバー側での認可。ボタンを隠すことはセキュリティではありません。データを読み書きするすべてのリクエストで、サーバー側でログインユーザーに権限があるかを確認する必要があります。行レベルのルールを持つデータベースを使っている場合は、それが有効になっていて、テストされているかを確認しましょう。
• 秘密情報をブラウザに出さない。決済、メール、AIプロバイダーのAPIキーは、サーバー側の環境変数に置くべきで、フロントエンドのコードに含めてはいけません。意味が分からなければ、環境変数と秘密情報とはを読んでください。
• サーバー側での検証。ブラウザ側のチェックは回避できるため、重要なチェックはサーバーでも繰り返しましょう。
• ログインを適切に実装する。パスワードの保存を自分で書くのではなく、十分にテストされた認証ライブラリやサービスを使いましょう。ログインの選択肢については、アプリにログインを追加する方法をご覧ください。
• レート制限：ログイン、会員登録、パスワードの再設定、メールを送る処理や有料APIを呼び出す処理に必ずかけます。
• わかりやすいエラー表示：利用者には「問題が発生しました」と表示し、詳細はログに残して画面には出さないようにしましょう。
• 漏えいしたものはローテーションする。本番のキーがチャット、コミット、スクリーンショットに一度でも貼られたことがあれば、提供元で再発行してください。

広い範囲をまとめて確認するためのプロンプトの例です。

このアプリを本番向けのセキュリティの観点でレビューしてください。すべてのAPIルートが、読み書きするレコードの所有者がログイン中のユーザーであることを確認しているか、秘密キーがブラウザに送られていないか、入力値がサーバー側で検証されているか、ログインとパスワード再設定にレート制限があるかを確認してください。変更する前に、見つけた問題を一覧にしてください。

先に一覧を出してもらうと、問題を確認し、対応の順番を決められます。一度に巨大な変更を受け取るより安全です。

ステップ4：障害に気づく仕組み：ログと監視

プレビューでは、エラーが起きるとその場で見えます。本番では、アプリ側から知らせてもらう必要があります。3つの層があり、手軽なものから有用なものへ順に並んでいます。

1. サーバーログ：どのルート、どのユーザーID（パスワードやカード番号は除く）、どんな入力の形だったかなど、再現に必要な情報とともにエラーを記録します。アプリがコンソールに出力するだけなら、構造化されたログを追加するようAIに頼みましょう。
2. エラートラッキング：Sentryなどのサービスがフロントエンドとバックエンドのエラーをとらえてグループ化し、通知を送ってくれます。小規模なアプリなら、無料プランで十分なことも多いです。現在の制限は各サービスのサイトで確認してください。
3. 死活監視（アップタイムチェック）：外部のサービスが数分おきにトップページと重要なAPIルートを読み込み、失敗すると通知します。アプリがログを残せなくなるような障害も検知できます。

もう1つ習慣にしてほしいことがあります。リリースのたびに、プレビューではなく公開されている実際のURLでアプリを開き、主要な流れのチェックリストを実行しましょう。

ステップ5：バックアップと元に戻す方法

守るべきものは2つあり、混同しやすいので注意してください。

• コード。どの変更も元に戻せるように、プロジェクトをバージョン管理に入れておきましょう。多くのAIビルダーはファイルのチェックポイントを保存しています。Gitリポジトリと同期すれば、ビルダーの外にもコピーが残ります。
• データ。コードを元に戻しても、データベースは元に戻りません。不具合のあるマイグレーションや、誤って動くように作られた削除ボタンによって、どのコードのチェックポイントでも復元できない行が消えることがあります。

データについては、アプリのホスティング先とは別の場所に、定期的なバックアップを保存しましょう。Postgresデータベースなら、別のストレージへの定期的なpg_dumpが一般的な方法です。マネージドのデータベースホストには、自動バックアップやポイントインタイム復旧を提供しているものもあります。そのうえで、多くの人が省いてしまう作業を行ってください。バックアップを検証用のデータベースに復元し、データが正しく残っているかを確認します。

また、破壊的な操作を安全にするようAIに頼みましょう。削除時には確認ステップを設け、ユーザーが復元したくなる可能性のあるものには「論理削除」（行を消さずに削除済みとしてマークする）を使います。

ステップ6：スマホでも維持できる速度

プロトタイプが速く感じるのは、利用者があなただけで、データ量も少ないからです。公開前に次の点を確認しましょう。

• 実際の規模に近いデータを読み込む。数千行のデータをAIに投入して、どのページが遅くなるかを確認します。一覧にはページネーションが必要になることが多く、データベースでは絞り込みや並び替えに使う列にインデックスが必要になることが多いです。
• 画像を小さくする。大きすぎる画像は、ページが遅くなる最も一般的な原因です。サイズを縮小し、圧縮した画像を使い、画面の下に入るまでは読み込まない遅延読み込みを求めましょう。
• 計測する。Chromeの開発者ツールでLighthouseを実行し、モバイルモードで公開URLを確認します。Googleのコアウェブバイタルが目安になります。最大コンテンツの描画（LCP）は2.5秒以内、インタラクションから次の描画（INP）は200ミリ秒以下、累積レイアウトシフト（CLS）は0.1以下です。
• 「起動待ち」による遅延に注意する。アイドル時にスリープするホスティングは費用を抑えられますが、しばらく使われていない後の最初のアクセスが遅くなります。新しいアプリなら多くの場合は妥当なトレードオフですが、そうなることを把握しておきましょう。

5,000行あるとプロジェクトのページが遅くなります。サーバー側のページネーション（1ページ25件）を追加し、絞り込みと並び替えに使う列にデータベースのインデックスを追加して、次のページの読み込み中にローディング表示を出してください。

ステップ7：運用の基本

趣味のアプリと、人が信頼するアプリを分けるのは、いくつかの小さなことです。

• 独自ドメインとHTTPS。独自ドメインの接続方法をご覧ください。
• トランザクションメール：会員登録の確認や、パスワード再設定のメールは、認証済みのドメインから送信します。アプリからメールを送る方法で解説しています。
• 実際に収集している内容を説明するプライバシーポリシーと利用規約。達成していないコンプライアンス上の主張を、他からコピーしてはいけません。
• サポートの窓口：監視されているメールアドレスでも構いません。
• 決済とメールのテスト用キーと本番用キーを分け、どの環境でどのキーを使うかを明記しておきましょう。

ステップ8：きれいな引き継ぎ

遅かれ早かれ、ほかの人がそのアプリに関わることになります。フリーランス、新しい共同創業者、または半年後のあなた自身です。引き継ぎを簡単にするために、次のものを用意しましょう。

• READMEファイル：起動方法、必要な環境変数（名前のみ。値は書かない）、デプロイ方法を記載します。
• 主要な流れのチェックリストと自動テスト。
• 簡単な構成メモ：フロントエンド、バックエンド、データベース、外部サービス、それぞれのホスティング先。
• アクセス権の一覧：ドメイン、ホスティング、データベース、決済、メールのアカウントで誰が管理者か。これらのアカウントは、個人のメールではなく事業用のメールで管理しましょう。
• Gitでのコード管理。できれば自分が所有するリポジトリに同期します。将来ホスティングを移す可能性があるなら、AIで作ったアプリをエクスポートしてセルフホストする方法をご覧ください。

これらの多くは、AIに下書きしてもらうこともできます。

このプロジェクトについて、まったく見たことのない開発者向けのREADMEを書いてください。アプリの内容、技術スタック、ローカルでの起動方法、読み込んでいるすべての環境変数（名前と用途のみ）、データベーススキーマの構成、デプロイ方法を含めてください。

本番運用準備チェックリスト

• 主要な流れを書き出し、「ほかの人のデータにアクセスできない」ことを含めてテスト済み
• すべてのデータ処理ルートで、サーバー側の認可と検証が行われている
• フロントエンドのコードに秘密キーがなく、漏えいしたキーはローテーション済み
• ログインと、費用がかかる処理すべてにレート制限がある
• エラートラッキングと死活監視の通知が、実際に確認しているメールボックスに届く
• データベースのバックアップがホスティング先とは別の場所にあり、一度は復元テストに成功している
• 現実的なデータ量でページネーションとインデックスを確認済み
• 独自ドメイン、認証済みの送信ドメイン、プライバシーポリシーが準備できている
• 次に引き継ぐ人のためのREADMEとアクセス権の一覧がある

Mythexでの進め方

Mythexでプロトタイプを作った場合、ここで紹介した多くのステップは、同じプロジェクト内のプロンプトとして実行できます。/testと入力すると、Mythexがライブプレビューを利用者のように操作し、壊れている流れを報告します。詳しくはアプリテストをご覧ください。キーはチャットではなくプロジェクトの秘密情報に入力し、AIエージェントが1回の処理を成功させるたびに、ファイルのチェックポイントが保存されるので、そこに戻せます。公開すると、ライブURLが得られ、ホスティングとデータベースは同じクレジット残高から課金されます。アプリやデータベースがスリープと起動をどう行うかはホスティングの制限で説明しています。チェックポイントはファイルを保存するもので、データベースの行は含まれないので、データのバックアップは別に計画してください。Proプランでは、独自ドメインを接続したり、コードをエクスポートしたり、引き継ぎのために自分のGitHubリポジトリと同期したりできます。

よくある質問