バイブコーディングアプリ リリース前検証チェックリスト

最も空きやすい場所です。ログインはたいてい作り込まれますが、ログイン後の境界はよく抜けます。アカウントを二つ作り、Aで作ったデータのURLをBのブラウザにそのまま入れてみます。開けば、画面で隠していただけの状態です。管理画面のURLを一般アカウントで直接開き、ログアウト後に戻るボタンで前の画面がよみがえるかも確認します。パスワード再設定やメールアドレス変更のように、アカウントを他人へ渡せる流れは別に踏みます。役割が複数あるなら、組み合わせごとに一度ずつ確認します。

正常な入力は作る過程で既に確かめられているので、ここで見るものではありません。必須項目を空のまま送り、数量に0と負の数を入れ、日付を過去に設定し、非常に長い文字列と絵文字を名前欄に入れます。画面で止まるかではなく、リクエストがサーバーに届いた時点で止まるかを見ます。画面側の検証しかないアプリは、リクエストを直接送れば通ってしまいます。同じリクエストを素早く二回送り、決済や申込が二件できるかも確認します。ファイルアップロードがあれば、形式と容量の制限を超えたファイルで一度試します。

外部モデルの呼び出しやSMS送信、地図や翻訳のように件数で課金される連携は、使用量がそのまま請求額になります。一つの画面を開くときに呼び出しが何回出るかを数えます。再読み込みのたびに繰り返される呼び出し、失敗時に無限に再試行するコード、ログインしていない利用者からも呼べる経路が、費用の漏れる三か所です。利用者一人あたりと一日全体の上限を定め、その上限に達したときに何を見せるかも併せて決めます。課金アラートを先に設定しておけば、請求書ではなく通知で先に気づけます。

外部連携を切って同じ画面をもう一度踏みます。反応がない、あるいは白い画面になると、利用者は同じ操作を繰り返し、その繰り返しがさらに課金と重複データを生みます。エラーメッセージに内部のパスやデータベースの文がそのまま出ていないかも見ます。決済や保存のように途中で切れてはいけない流れは、切ったうえで再開したときどの状態で残るかを確認します。失敗したリクエストがログに残るかも併せて見ます。利用者に見せる文言とログに残す内容は別に決めます。

収集している項目を画面の順に書き出します。実際には使っていないのに受け取っている項目は削ります。氏名と連絡先、決済情報がどの保管先にどんな形で残るか、外部サービスへ送る値に個人情報が混ざっていないかを確認します。会話履歴を外部モデルへ送るアプリなら、何が一緒に送られているかを一度は自分で見る必要があります。退会したときにデータが消える経路があるかも項目に入れます。アップロードされたファイルが、URLを知っていれば誰でも開ける状態かも確認します。

デプロイは最後の関門ではなく、独立した検証の対象です。アクセスキーやパスワードがコードやリポジトリにそのまま入っていないか探します。開発用に開いたままのデバッグ画面や試験用アカウントが残っていないか確認します。試験用の決済設定が本番に切り替わっているか、ドメインと証明書が付いているか、問題が起きたときに前のバージョンへ戻す方法があるかを最後に踏みます。ここで引っかかった項目が複数の筋に散らばっているなら、一人で埋めるより外部検証に回す範囲として読むほうが早く進みます。