LovableやBoltがバグ修正ループから抜け出せない？MVPを完成させる方法

ビルダーにサインインの修正を頼むと、サインインは動くようになったものの、今度はダッシュボードが空になった。別のプロンプトでダッシュボードを戻すと、またサインインが壊れる。LovableやBoltが同じバグを直し続けているなら、次にやるべきことは、1つの不具合にまつわる証拠を充実させることです。変更を重ねれば前進するとは限りません。

なぜAIアプリは修正ループに陥るのか？

修正ループは、根本原因を特定・検証しないまま、目に見える症状だけに対処する変更を繰り返すと起こります。同じ画面がいくつもの異なる不具合から生じうるため、大まかな依頼ではビルダーが変更できそうな箇所が多くなりすぎます。

ダッシュボードが空なのは、リクエストの失敗、権限ポリシー、接続先データベースの誤り、あるいは本当にデータが存在しないことが原因かもしれません。コンポーネントを変更すると、失敗したリクエストはそのままでメッセージだけが消える可能性があります。目指すべきは、ブラウザ、サーバー、認証プロバイダー、データベース、外部連携のうち、どの境界で失敗しているのかを特定することです。

実用的な中止ルールを決めておきましょう。焦点を絞った修正を1回試しても同じ症状が再発したら、同じプロンプトを繰り返すのをやめ、別の種類の証拠を集めます。これはプラットフォームが定めた制限ではなく、作業上の習慣です。何が失敗しているのか誰も説明できないまま、小さなプロジェクトに無関係な変更が積み重なるのを防げます。

壊れているのはビルダーのプレビューか、アプリそのものか？

コードを書き直す前に、ビルダーの環境とアプリケーションを切り分けて確認しましょう。プラットフォームの障害やプレビューの接続問題は、プロダクトのアーキテクチャを作り替える必要がある証拠にはなりません。

Boltの現行のプレビューのトラブルシューティングガイドでは、サービスステータスの確認、ブラウザコンソールのエラー収集、本番ビルドの試行、不足している環境変数の確認が推奨されています。また、最初の試みが失敗した後に同じプレビュー修正のプロンプトを何度も送っても、効果は期待しにくいと説明されています。

この表は次に何を調べるかを選ぶためのもので、診断を確定するためのものではありません。ネットワークリクエストの失敗がアプリケーションのコードに起因することもあり、画面が真っ白になる原因も1つではありません。後続のエラーに埋もれる前に、最初の意味のあるエラーを記録しましょう。

次の修正を試す前に何を保存すべきか？

直近で役に立っていたコードの状態を保存し、修正によって影響を受けうるデータを把握しましょう。コードの履歴とデータベースのバックアップは、それぞれ別の復旧問題を解決するものです。

Lovableのバージョン履歴のドキュメントでは、コードのバージョンのプレビュー、ブックマーク、復元について説明されています。そこでは、コードを復元してもデータベースのデータはロールバックされないと明記されています。バージョンを復元する前に、その後の作業でレコードや権限、あるいは古いコードが前提とするスキーマが変更されていないか確認しましょう。

1. 主要なユーザーフローが最後に動作していた状態を、タイムスタンプまたはコミットIDとともに記録する。
2. 現在の不具合を記録し、役立つ未コミットの作業はプロジェクトがサポートする方法で保存する。
3. データやスキーマを変更する作業の前に、適切なデータベースのバックアップまたは安全なテスト用コピーを作成する。
4. 実際のユーザーがいるプロジェクトと環境を書き留め、そこから離れた場所で修正をテストできるようにする。

役立つ修正プロンプトとはどのようなものか？

役立つ修正プロンプトは、再現可能な不具合を1つに絞り、関連する証拠を示し、提案される変更の範囲を限定します。自分で評価できない実装を許可する前に、まず原因の説明を求めましょう。

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

これは架空の例です。詳細は実際に観察した内容に置き換えてください。403レスポンスはアクセスの失敗を示す手がかりであり、認可チェックを取り除いてよいという意味ではありません。パスワード、トークン、接続文字列、顧客レコードは、プロンプトやスクリーンショットに含めないでください。

Lovableのプロジェクトでは、バックエンドログのガイドで、プロジェクトで利用できる各サービスのリクエストとエラーを確認する方法が説明されています。エラーは、操作を行った時刻と環境に照らし合わせましょう。フィルタリングしていない大量のログをそのまま渡すより、機密情報を取り除いた関連エントリを1つ示すほうが役に立ちます。

修正が本当に成功したかどうかはどう判断するか？

修正が成功したと言えるのは、元の手順で期待どおりの結果が得られ、かつ重要な周辺フローも正しく動作し続けている場合です。一時的な成功メッセージだけでなく、リロード後に保存された状態もテストしましょう。

1. 新しいアカウントと同じ入力で、元の不具合を再現する手順を繰り返す。
2. アプリをリロードするか開き直し、結果が正しく保存されていることを確認する。
3. 2つ目の一般アカウントで同じ手順を繰り返し、想定どおりの所有権の境界が守られているか確認する。
4. 安全なテスト環境で、無効な入力や中断されたリクエストなどの失敗ケースを1つ試す。
5. 変更されたコードを共有する周辺フローを確認し、プロジェクトの関連チェックと本番ビルドを実行する。

開発者に依頼すべきタイミングは？

重要な処理経路への変更を自信を持って説明・検証できないとき、あるいは焦点を絞って調査しても原因を特定できないときは、開発者に依頼しましょう。決済へのアクセス、アカウントをまたいだデータ漏えい、繰り返されるデータベースの変更には、特に注意が必要です。

範囲を限定したレビューによって、問題が設定の問題なのか、小さな実装上の欠陥なのか、より大きな設計上の問題なのかを判断できます。診断結果、変更が提案されるファイルやサービス、受け入れテスト、ロールバックの方法を求めましょう。作り直しに合意する前に、そうしたレビューだけを依頼することもできます。

良い引き継ぎ資料には、アプリのURL、サポートされた方法でのプロジェクトまたはリポジトリへのアクセス、再現手順、短い画面録画、機密情報を取り除いたエラー、最後に動作していたバージョンが含まれます。次の顧客向けマイルストーンと、手を加えてはいけない機能も追記しましょう。認証情報は、適切なシークレット共有の仕組みやアカウントアクセスの手続きを通じてのみ共有してください。

次のリリースには何を含めるべきか？

次のリリースでは、壊れているユーザーフローのうち、小さく測定可能な範囲を確実に直しましょう。それらのフローを公開済みのアプリでテストし終えるまで、機能追加の要望は切り離しておきます。

修正後は、MVPローンチのための12項目チェックプランを使って周辺の抜け漏れを洗い出しましょう。プレビューでは動くのにReplitで公開すると壊れる場合は、Replitデプロイのチェックリストを参照してください。実践的なサポートが必要な場合は、LovableまたはBoltのページから出発点を選び、通話を予約してください。失敗しているフローを持ってきていただければ、最初の会話で有効な次の一手を明確にするお手伝いをします。