実際のユーザーが来たときにAIで構築したアプリが壊れた：次にすべきこと（強化、再構築、または放棄）
2026年、アプリを作るのに開発者はもう必要ありません。Lovable、Replit、Bolt、v0、Cursor、そして同様のツールが数十種類あり、英語の段落を午後だけで動く製品に変えてくれます。何千人もの創業者や小規模事業者がまさにそれを実行してきました――そしてそのうちの増えている割合が今、同じものを探しています：それを直す人。
このガイドはその立場にいる人々のためのものです。AIで構築されたコードベースを引き受けて生計を立てているチームが執筆しており、毎日同じAIツールを使用しています。私たちは「バイブコーディングは間違いだった」と言うためにいるのではありません。何が通常壊れるのか、修正と再構築のどちらを選ぶべきか、各パスのコスト、そして二度支払うことを避ける方法を伝えるためにいます。
デモではうまくいき、実運用で壊れた理由
AIコードジェネレータは一つのことに最適化されています：要求されたものを画面に表示させること。この点に関しては非常に優れています。最適化されていないのは、実際の製品の見えない80％――つまり、見知らぬユーザーが使い始めたときに初めて重要になる部分です。
AIで作られたアプリは通常、以下の条件下で完璧に動作します：
- 同時に1ユーザーだけ
- クリーンで期待通りの入力
- 少量のデータ
- 何も問題が起きないフレンドリーな環境
本番環境はこれらすべての反対です。失敗はランダムではなく、私たちが引き継ぐほぼすべてのコードベースで見られるパターンに従います。
通常間違っている7つのポイント
1. フロントエンドにシークレットが残っている
APIキー、データベース認証情報、支払いトークンがクライアント側コードに置かれ、ブラウザから誰でも読める状態です。AI支援コミットの調査では、人間が書いたものの約2倍の頻度でシークレットが漏洩していることが分かっています。これが最初にチェックする項目で、ほとんどの場合で問題があります。
2. 存在しない認可
ログインは機能するが、アクセス制御が機能しない。ユーザーAがURLのIDを変えるだけでユーザーBのデータを取得できる。2025年には、ある人気AIアプリプラットフォームでこの種の欠陥が原因で、170以上の本番アプリのデータが一度に流出しました。
3. 実体のないバックエンド
ビジネスロジックがブラウザにあり、回避可能です。サブスクリプションチェック、制限、バリデーションがクライアント側だけで実装されているため、実際には強制されません。
4. テストもステージングもない
変更が直接本番にデプロイされます。行き先がないからです。すべての修正がギャンブルになります。
5. 設計されていないデータモデル
テーブルがプロンプトごとに作成されました。マイグレーションも制約もなく、スキーマ変更時の計画もありません。
6. すべてがハードコーディング
URL、制限、価格、AIモデル名自体がコードに埋め込まれています。これらを変更するには開発者とデプロイが必要です。
7. 仕組みを誰も知らない
作った本人でさえも。ドキュメントもアーキテクチャもなく、書いたAIも覚えていません。
独立したスキャンがこれを裏付けています。あるセキュリティ企業が5,600件のAI構築アプリを監査した結果、2,000件以上の脆弱性が見つかり、別の分析ではAI生成コードのほぼ半数に少なくとも1つのセキュリティ弱点が含まれていることが判明しました。
本当の質問：ハードニング、再構築、あるいは手放すか？
多くの人はフルリビルドが必要だと想定しますが、ほとんどが間違いです。正直な答えはコードに何があるかに依存し、唯一の方法は決定前の監査です。
監査とは、シニアエンジニアが1〜3日かけてコードを読み、アプリを実行し、脆弱性をスキャンし、アーキテクチャをマッピングする作業です。成果物は、所見を3つのバケットに分類した書面レポートです。
ハードニング（最も一般的な結果）
製品ロジックは健全で、フロントエンドは使えるが、セキュリティ、バックエンド、インフラは適切に実装する必要がある。典型的な範囲：シークレットをサーバ側へ移す、実装された認可を導入する、ビジネスロジック用の本格的バックエンドを追加する、ステージングとテストを設定する、モニタリングを追加する。シニアエンジニアで2〜4週間。
部分的リビルド
一層が回復不可能――通常はデータモデルまたはバックエンド――しかしフロントエンドと製品フローは残す価値がある。壊れた層だけを再構築し、機能する部分は保持する。4〜8週間。
フルリビルド
アーキテクチャが全体的にテープで止められ、変更のたびに他の2つが壊れる。クリーンな基盤から再構築し、AIで作られたバージョンを詳細な仕様書として利用する方が、パッチ適用より速く安価です。元のコードは無駄ではなく、開発者に渡す最高の製品仕様です。
手放す
監査で製品アイデアがまだ検証されていないことが判明した場合、プロトタイプはプロトタイプとして使い続け、本番化に費用をかけない方が賢明です。
良いパートナーは見積もりを出す前にどのバケットに入るかを教えてくれます。コードを読まずにリビルドと見積もる人は、営業数字でありエンジニアリング数字ではありません。
コスト
2026年時点での、典型的な中小規模AI構築アプリの概算コスト（プロフェッショナルチームの場合）：
| パス | 典型的なコスト（USD） | タイムライン |
|---|---|---|
| 監査のみ | 1,500 – 4,000 | 2–5日 |
| ハードニングスプリント | 5,000 – 15,000 | 2–4週間 |
| 部分的リビルド | 15,000 – 40,000 | 4–8週間 |
| フルリビルド（MVP範囲） | 25,000 – 80,000 | 8–16週間 |
比較として、セキュリティ侵害、データベース消失、投資家の技術審査失敗のコストは、私たちの経験上、上表のいずれかの金額の何倍にもなります。2025年に広く報道された事例では、AIコーディングエージェントが明示的なコードフリーズ中に本番データベースを削除しました。事業は何とか存続しましたが、多くはそうではありませんでした。
監査を依頼すべきタイミング
構築が完了したときではなく、何かが危機に瀕しているときです：
- 本番ユーザーが間もなく来る（ローンチ、マーケティングプッシュ、アプリストア掲載）
- 本格的な金銭の流れが始まる（支払い、サブスクリプション）
- 本格的なデータが保存される（個人情報、事業データ、規制対象データ）
- 投資家、パートナー、またはエンタープライズ顧客がコードを確認しようとしている時
任意のものが瞬間です。その前に、バイブコーディングを続けてください — これまでに作られた中で最速の検証ツールです。
誰が修正するかの選び方
赤信号:
- 誰もコードを読んでいない段階での固定価格
- 「ゼロから作り直し」を唯一の選択肢として提示
- 修正もバイブコードで行うチーム — 6か月後に戻ってくる
- 提案書にテスト、ステージング、モニタリング、ドキュメントの記載がない
- コードとインフラを自分が所有するという明確な表記がない
欲しいもの:
- まず監査、次に意思決定、最後に見積もり
- AIツールを使い、かつ自分たちのミスを理解しているシニアエンジニア
- 他のチームに渡せる書面レポート
- 2週間ごとのインクリメントで、各期間の終わりに何かをデプロイ
- すべて自分のアカウント内：リポジトリ、クラウド、アプリストア、ドメイン
UmaySoftwareでのAI構築コードベースの扱い方
既存コードの引き継ぎは私たちの仕事の核心であり、2026年にはその大部分が Lovable、Replit、Bolt、Cursor からやってきます。私たち自身も同じツールを使用しますが、違いはシニアエンジニアがアーキテクチャ、セキュリティモデル、レビューを所有し、AI がタイピングを担当する点です。
プロセスは上記と同じです：まず固定価格の AI構築アプリ監査、次に「強化 / 部分的再構築 / 完全再構築 / 待機」のいずれかを示す書面レポート、そしてスコープされた見積もり。監査で「自分で続けるべき」と判断された場合は、そう伝えます。
アプリが稼働中で内部が不明な場合は、リポジトリのリンクを送ってください。監査は数日で完了し、正確な現状が把握できます。
よくある質問
Lovable、Replit、Bolt で作ったアプリは本番に出せますか？
はい、しかしほとんどの場合そのままでは出せません。フロントエンドとプロダクトフローは概ね問題ありませんが、セキュリティ、バックエンド、インフラは専門的な作業が必要です。最も一般的な道はハードニングスプリントです。
バイブコードで作ったアプリをゼロから作り直す必要がありますか？
通常は不要です。経験上、ほとんどの AI 構築アプリはハードニングまたは部分的再構築で済み、完全な書き直しは必要ありません。判断は監査に基づくべきで、推測ではありません。
AI 生成アプリの修正費用はどれくらいですか？
監査は 1,500–4,000、ハードニングスプリントは 5,000–15,000、部分的再構築は 15,000–40,000。MVP スコープの完全再構築は 25,000–80,000 です。これらは 2026 年時点のプロフェッショナルチームの価格帯です。
AI 生成コードで最も一般的なセキュリティ問題は何ですか？
クライアント側コードに埋め込まれたシークレット、認可の欠如または破損（他ユーザーのデータにアクセス可能）、ブラウザ内だけで実装されたビジネスルールです。ハードコードされた認証情報が最も頻繁に見つかります。
AI コーディングツールの使用をやめるべきですか？
いいえ。これらはこれまでで最速のアイデア検証手段です。プロトタイプ作成に使い、実際のユーザーや資金、データが関わる段階でエンジニアリングを投入してください。
既存のコードを使いますか？それとも最初からやり直しますか？
まず監査し、健全な部分は残します。AI 構築版は最低でも優れた仕様書であり、多くの場合それ自体が再利用可能です。