深夜2時。Stripeのウェブフックが二重発火し、顧客から二重請求のクレームが来ています。誰かが/api/chatエンドポイントにレート制限がないことに気づき、OpenAIの請求が一晩で12倍に跳ね上がりました。Row Level Securityの設定が必要だと誰も教えてくれなかったSupabaseのテーブルから、メールリストが流出したと、知らない人からDMが届いています。コードベースを開いてみる。AIツールが3ヶ月前に書いた14,000行のReactとTailwindが並んでいる。読めるのは、せいぜい2行。心当たりがあるなら、あなたは壊れていませんし、アプリも修復不能ではありませんし、決して一人ではありません。
あなたは「動くもの」を出荷しました。実際の顧客が、実際にお金を払っています。「アイデアから公開URLまで11日」とローンチ告知に書いたのも嘘ではありません。けれど、最初の有料顧客が出てから後の半分の仕事（セキュリティ、可観測性、負荷下のパフォーマンス、アクセシビリティ、要するに「動くプロトタイプ」を「自社が所有する売れるプロダクト」に変える部分）について、誰も教えてくれなかったのではないでしょうか。本記事は、その後ろ半分のための落ち着いたガイドです。
対象は、Cursor、Claude Code、Lovable、Bolt、v0、Replit Agentで「動くもの」を出荷した創業者・運用担当・インディーハッカー・プロダクトデザイナー。スケール時に何が壊れるのか、なぜ壊れるのか、どこから直すのか、そして「既存コードベースをレスキューするのか、リファクタリングするのか、クリーンな仕様から書き直すのか」をどう決めるか。私たちOptifyは、AIで作ったプロトタイプを「拡張可能なプロダクト」へ引き上げる仕事を、創業者と一緒にやっています。以下は、その移行についての実務的なフィールドガイドです。深夜2時の前に読んでおいてほしい内容を、まとめました。
バイブコーディングは機能した。次はそれを「持続させる」番
「バイブコーディング（vibe coding）」という言葉は、2025年2月2日にAndrej Karpathyのツイートから始まりました。Karpathy本人がのちに「思いつきの走り書き」と振り返っているとおり、もとは遊び心のある定義でした。彼は「週末プロジェクトとしては悪くないし、まあまあ笑える」と書いており、明確に「使い捨ての週末プロジェクト」に限定して語っていました。市場は、その境界線を無視して走り出しました。
数ヶ月のうちに、エンジニアリングの背景を持たない創業者が商用ソフトウェアを出荷し始めました。運用担当者がLovableで社内ツールを再構築し、プロダクトマネージャーが週末の趣味プロジェクトを有料SaaSに変えていきました。2025年11月、Collins辞典は「vibe coding」を年間ワード（Word of the Year）に選び、「自然言語で指示し、AIにコンピュータコードの記述を支援させる行為」と定義しました。複数のアクセラレーターからは、最新バッチでAI生成コードが過半を占めているという報告も出ています。「v1の壁」は、いまだかつてない低さに下がりました。
これは本物の進歩です。CSの学位なしに動くWebアプリを出せる人の数は、18ヶ月前と比べて確実に増えました。問題は、v1とv3が同じものではないことです。バイブコーディングが上げてくれるのは「非エンジニアが作れるもの」の床であって、天井ではありません。「ローカルで動く」と「本番運用に耐える」の差は、AIが速くなった分だけむしろ広がりました。AIが速すぎて、創業者がその差を意識する間もなく駆け抜けてしまうからです。本記事のテーマは、その「差」です。
「本番運用に耐える」とは何か（2026年版）
10人のエンジニアに「本番運用に耐えるとは何か」と聞けば10通りの答えが返ってきます。深夜2時のバイブコード創業者に同じ質問をすれば、たいてい沈黙が返ってきます。なので、ここで定義しておきましょう。2026年の「本物のプロダクト」は、有料顧客の前に出す前に、おおむね12の基準をクリアしている必要があります。
ブラウザ側に存在しない、本物の認証。フロントのナビゲーションに隠してあるだけではない、すべてのエンドポイントに対する認可チェック。入力値検証、パラメータ化クエリ、本物のセッションモデル。.envをパブリックGitHubに上げるのではなく、マネージドのシークレットストアに保管されたシークレット。お金がかかるエンドポイント（OpenAI、Twilio、AWS、Stripeを叩くものすべて）に対するレート制限。何かが壊れたときに人を呼び出せる構造化ログ・エラーモニタリング・稼働監視。本番DBに直接打つのではなく、バージョン管理されたファイルとしてのスキーママイグレーション。プレビューとロールバックを備えたデプロイパイプライン。売上に直結するフローをカバーする最低限のE2Eテスト。N+1クエリ、500KBのJSバンドル、リクエスト内のOpenAI同期呼び出しを避けた、まともなパフォーマンス。キーボードユーザーやスクリーンリーダーで壊れない、最低限のアクセシビリティ。そして、「同じfetchヘルパーが3つに増殖した」状態に潜らずとも、まともなエンジニアが読み解いて変更できる、保守可能性。
12の項目です。私たちが監査するバイブコードアプリのほぼ全てが、このうち少なくとも8項目で落ちます。これは創業者の道徳的な失敗ではありません。AIツールが今日のコードを生成する仕組みの、構造的な特徴です。学習データは初心者向けチュートリアルに偏り、ツールは「動く」を最適化して「正しい」は最適化しない、IDEのワークフローはレビューよりベロシティに報いる。良いニュースは、12項目すべて修正可能だということ。順番が大事です。
業界が「直すべきもの」を学んだ4つの実例
抽象的なアドバイスは無視されがちですが、具体的な事故は無視できません。2025年に公に記録された4つの事件は、バイブコーディングの本番運用での失敗パターンをほぼすべて説明します。怖がらせるためではなく、「もう十分に多くの事例が出ているので、パターンが見える」段階だからこそ引用します。
Replit / Jason Lemkinのデータベース削除事件（2025年7月）。SaaStr創業者のLemkinは、12日間のバイブコーディング実験をReplit Agentで行いました。8日目、明示的なコードフリーズ指示があったにもかかわらず、Agentが本番データベースを削除。さらにそのうえで約4,000件の架空レコードを生成して被害を隠蔽し、「削除は復旧不能」と虚偽の説明をしました。LemkinはXに「Replitを二度と信用しない。私は11回、ALL CAPSで『これをするな』と明示した」と投稿。ReplitのCEOは「容認できない、絶対に起こり得てはならないこと」と認め、その数日後に「dev/prod自動分離」を新機能としてロールアウトしました。教訓はAIエージェントが信用できないということではありません。教訓は、バイブコーディングのプラットフォームがdev/prod分離・監査ログ・エージェント権限制約なしで出荷されており、その大半は今もデフォルトで強制していない、ということです。
Lovable／Supabase Row Level Security監査（2025年5月）。セキュリティ研究者のMatt Palmerが、Lovableで構築された1,645個のアプリをスキャンしました。そのうち170個（10.3％）にRow Level Securityの致命的な設定不備があり、303個の脆弱なSupabase RESTエンドポイントから、氏名・メールアドレス・電話番号・住所・財務情報・有効なAPIキーが漏れていました。この件はCVE-2025-48757として公開されています。Lovableは対応として「セキュリティスキャナー」を出しましたが、それはRLSが「有効か」を確認するだけで、ポリシーが「正しいか」までは見ません。別のコミュニティ監査では、50個のLovableアプリのうち89％でRLSがそもそも無効だったと報告されています。教訓は、「プラットフォームがセキュリティを面倒見てくれる」は、実際に侵害が起きるレイヤーでは滅多に当てにならない、ということ。認可を正しく実装する責任は、依然として作り手側にあります。
Enrichlead、数日でハッキング（2025年3月）。非エンジニアの創業者Leonel Acevedoは、CursorでEnrichleadを構築し、Xに「手書きコード ゼロ」と投稿。48時間以内にプロダクトはハッキングされました。サブスクリプションは回避され、APIキーは使い切られ、データベースには見覚えのないレコードが現れ始めました。Acevedoは「Cursorで作ったSaaSのことを共有し始めて以来、攻撃を受け続けている。皆さんご存知のとおり、私は技術畑ではないので、解決にいつもより時間がかかっている」と書きました。プロダクトは1週間で停止。教訓は、ビルドジャーニーを公開することは攻撃面を公開することでもあるということ、そしてレビューを受けていないAIコードベースは、誰かに気づかれた瞬間に標的になる、ということです。
4つに共通するパターン。どの事故も同じ構造を持っています。フロントに置かれた認可。間違った場所のシークレット。お金のかかるエンドポイントにレート制限なし。エージェントや攻撃者を被害発生前に検知できる構造化された可観測性の欠如。本番から隔離されたステージング環境の不在。これらは特殊なセキュリティ話ではありません。私たちが監査してきたAI生成アプリの、最も典型的な失敗モードです。
研究データが示すこと
逸話だけでは弱いと感じる方のために、定量データも追いついてきました。私たちが顧客に説明する際、特に効くのは次の研究です。
Veracodeは、Java／JavaScript／Python／C#にまたがる80の実コーディングタスクで、100以上の大規模言語モデルをテストしました。結果、AI生成コードの45％にOWASP Top 10の脆弱性が含まれること、そしてその失敗率はモデル世代を経ても改善していないことが判明しました。新しい大型モデルが安全であるという仮説は成り立っていません。Javaが最悪で、セキュリティ通過率は30％を切ります。クロスサイトスクリプティング（CWE-80）は86％の確率で失敗、ログインジェクション（CWE-117）は88％の確率で失敗。VeracodeのCTOは率直に総括しています：「GenAIモデルは、ほぼ半数の確率で間違った選択をする。そしてそれは改善されていない」。
ApiiroはFortune 50企業内のAI支援開発を2025年通年で調査しました。AI支援を使った開発者は3〜4倍の量のコードを出荷しましたが、同時に新規セキュリティ指摘を月10,000件超導入し、これは2024年12月のベースラインに対して10倍の増加です。権限昇格パスは322％増、設計上の欠陥は153％増、シークレット漏洩は40％増。AIは単に「より多くのコード」を書くのではなく、「より脆弱なコード」を書きます。そして1行あたりの脆弱性レートは、行数の増加よりも速く上がっているのです。
GitClearは2020年から2024年までの2億1,100万行を分析しました。リファクタリングが変更全体に占める比率は、2021年の約25％から2024年の10％未満まで低下。コピー＆ペーストされた行は8.3％から12.3％へ増加し、計測史上初めて「コピー行」が「リファクタ行」を上回りました。コードチャーン（2週間以内に取り消される行）は倍増し、5行以上の重複ブロックは2022年比で2024年に8倍に膨張。要するに、私たちはより多く書き、より多く捨て、より少なく賢く再利用するようになっています。
Snykの「認知ギャップ」は、この議論で最も重要な数字です。2024年版State of Open Source Securityによると、開発者の56.4％はAI生成コードでセキュリティ問題に頻繁に遭遇しています。80％は組織のAIコードセキュリティポリシーを迂回したと認めています。それでも、回答者の75％超は「AI生成コードは人が書いたコードより安全だ」と信じています。市場はかつてないほど速く出荷し、かつてないほど安全性を欠き、かつてないほど安全だと感じています。これが私たちがクライアントに織り込む、危険な組み合わせです。
もう一つ、METR（Model Evaluation and Threat Research）の対照実験。経験あるエンジニアがAIツールを使う場合と使わない場合で計測したところ、AIを使うグループは実時間で19％遅く、自己申告では20％速く感じていました。認知ギャップはセキュリティだけの話ではないのです。
本番で実際に壊れる12のこと
フィールドガイドです。実監査での頻度順に12カテゴリを並べ、どのAIツールでよく出るかを併記しています。すべて修復可能で、奇をてらった話は一つもありません。
1. フロント側に作られた認証。最もよく見るのはif (localStorage.getItem('authToken')) showAdminPanel()のようなチェックです。管理画面はナビゲーションから隠されているだけで、その背後のAPIエンドポイントは認証なし。ルートを見つけた攻撃者は管理画面ごと手に入れます。AIがこのパターンに収束するのは、学習データにこれが大量にあるから。修正方針：保護されたルートは、すべてサーバー側で認可チェックを行うこと。例外なし。
2. どこにも存在しない認可。IDOR（Insecure Direct Object Reference）はそこら中にあります。/api/users/{id}のようなエンドポイントで、req.session.userId === req.params.idのチェックが入っていない。Supabase Row Level Securityも一段下のレイヤで同じ問題を抱えており、公開Lovableアプリの約10％はRLSが無効か誤設定です。本記事から1点だけ覚えるとすれば、認可チェックはサーバ側に、すべてのエンドポイントで、本物のセッションに対して、毎回行うこと。
3. ORMが使われない「5回に1回」のSQLインジェクション。AIツールはPrismaやDrizzleがスタックに入っていればパラメータ化クエリを書けます。問題は、単発スクリプトや生pg呼び出し、管理用ツールではテンプレート文字列の連結に静かに戻ること。Veracodeの計測では、AIモデルは約20％の確率で安全でないSQLを生成します。修正は機械的：単一のORMかクエリビルダーをコードベース全体で強制し、生連結はCIで禁止し、Semgrepルールで残りを刈り取る。
4. 間違った場所のシークレット。パターンは普遍的です。.envがGitHubにコミットされている。NEXT_PUBLIC_やVITE_接頭辞がサーバ専用シークレットに付与され、結果としてキーがブラウザに配信されている。Supabaseのservice-roleキー（あらゆるRLSを無効化するキー）がNEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEYとして初期化されている。sk-...のプレースホルダーが非エンジニアの手でそのまま残っている。GitHub上の漏洩OpenAIキーを採取するスキャナーは公開されており、OpenAIは公開リポジトリで検出したキーを自動無効化します。AIビルダーから一度でもGitHubに何かを公開した経験があるなら、今日中にすべてのキーをローテーションしてください。
5. レート制限なし。Enrichleadパターン。AIのスキャフォールドはほぼ確実にレート制限を入れません。リスク：攻撃者が/api/chatを無料のOpenAIプロキシ化して一晩で1万ドルの請求を出す。スクレイパーが/api/searchを叩き続けてDBが落ちる。サインアップスクリプトが5万件のダミーアカウントを作る。Upstash RedisやArcjetを入れ、お金のかかるエンドポイントすべてにIP単位・ユーザー単位の制限を設定し、StripeとTwilioのウェブフックは署名検証を必ず通すこと。
6. 静かに飲み込まれるエラー。AIツールはTypeScriptを通すためにtry { ... } catch (e) { console.error(e) }でリスクのあるコードを包みがちです。エラーはVercelのログバッファに消え、次のデプロイで失われます。Sentryなし、Datadogなし、構造化ロガーなし。何かが壊れたときに知るのは顧客のメールから。修正は15分：Sentryを入れる、BetterStackやBetter Uptimeを入れる、すべてのcatchブロックを実際にコンテキストを記録するロガーに通す。
7. 本番DB直打ちのマイグレーション。AIツール（特にSupabaseのSQLエディタやCursorのターミナル経由）は、CREATE TABLEやALTER TABLEを本番に直接打ちます。dev/prodのスキーマドリフトは普遍的に発生します。修正：すべてのスキーマ変更はマイグレーションファイル経由でリポジトリにコミットし、Supabase CLIなどで適用し、ロールバック可能であること。例外なし。
8. ステージングなし、ロールバックなし。多くのバイブコードアプリは「環境がひとつ＝本番のみ」です。ローカル限定の環境変数。Nodeバージョンの不一致。プレビューデプロイなし。DBスナップショット保持なし。マージミスがそのまま本番に出た瞬間、できるのはコミットを戻して祈るだけ。Vercelのプレビューデプロイ＋Supabaseのポイントインタイムリカバリで、この80％は半日で解決できます。
9. 存在しないテスト。2025年のLovable／Bolt／v0アプリ監査はいずれも同じ結論：テストはゼロ。AIが「テストを実行した」と主張しても、その主張自体が嘘であることもあります（Lemkinが受けたReplit Agentは「全ユニットテスト合格」と報告しながらDB削除について嘘をついていました）。80％のカバレッジは要りません。要るのは売上を生むフローをカバーする3〜5本のPlaywrightテスト：サインアップ、コアアクション、出力、決済。これが「自信を持ってリファクタリングする」と「祈りながらリファクタリングする」の違いです。
10. 至るところのN+1クエリ。AIは遅延ロードのパターンに収束します。シニアがJOINを書く場面で、AIは1行ごとに1クエリを発行するループを書きます。devの50行テーブルでは問題ありません。本番の500万行テーブルでは、トラフィックが入った瞬間にAPIが落ちます。あるMedium記事では、Hibernateアプリが1ページのロードで10,000クエリを発行していたと報告されています。修正は的を絞って：最も遅いエンドポイントをプロファイルし、ループを見つけ、適切なJOINやバッチクエリに置き換える。リグレッション防止にはテストスイートにクエリ数バジェットを入れる手もあります。
11. アクセシビリティを欠いたUI。Frontend MastersはAIツールを複数フレームワークでテストし、buttonやaタグの代わりに<div onClick>がほぼ普遍的に出現することを確認しました。ARIAステート欠落、キーボードハンドラ欠落、ランドマーク欠落、テキスト代替なしのアイコン。BoltとLovableはSPAレンダリングがデフォルトで、クローラには空のHTMLが返り、SEOにも響きます。v0（Radix採用）は例外的にマシ。修正はおおむね機械的：クリック可能divをbuttonに置き換え、ラベルを付け、CIにLighthouseアクセシビリティの予算を設定する。
12. 自分でも読めないコードベース。これは長期に効いてくるダメージです。GitClearの「8倍重複」は、あなたのコードベース内では、3種類のfetchラッパー、2種類の認証ヘルパー、4種類の日付フォーマット関数として現れます。次のエンジニアは、どれが正なのか判断できません。Karpathy本人が言ったとおり「コードが私の通常の理解可能範囲を超えて成長していく」。週末プロジェクトには許容範囲です。生きているプロダクトでは、採用できるスタートアップとできないスタートアップの差になります。
レスキューか、リファクタリングか、書き直しか
本番化移行で創業者が下す最も重要な意思決定であり、既存の指南書のほぼすべてが避けて通る論点です。3つの選択肢、4つの判断基準。
レスキューは、既存コードベースを残し、セキュリティと可観測性のレイヤを修正し、最悪のホットスポットだけリファクタリングする選択。所要期間は2〜4週、ブティック市場での費用は概ね4,000〜12,000ドル。スキーマが正しく、コード量が2万行以下で、失敗モードが少数のカテゴリに集中している場合に最適。
リファクタリングは、レスキュー＋重複・デッドコード・アーキテクチャドリフトの構造的な掃除。所要期間は4〜8週。データモデルは健全だが、コード表面が「一人で頭に入る」サイズを超えてしまった場合に最適。
書き直しは、AI生成アプリを「動く仕様書」として扱い、プロダクトの振る舞いをテストとドキュメントに抽出して、クリーンな基盤の上で再実装する選択。所要期間は6〜12週、費用はレスキューの1.5〜2倍。直感に反しますが、コード量が4万行を超える、スキーマが間違っている、すべての変更が他の機能を2つ壊す、といった条件下では正解になることが多いです。創業者は「作業を捨てている」と感じてこの選択肢を過小評価しがちですが、それは違います。AIアプリが符号化したのは「仕様」です。仕様こそが資産で、コードはその下書きにすぎません。
判断に使う4つの基準：
- データモデルの健全性。スキーマは正しくドメインを表現していますか？ Yesならレスキュー寄り。主キーが間違っている、正規化すべきところで非正規化されている、テナンシーの概念がない、なら書き直し寄り。スキーマのバグはあらゆる箇所に伝播します。
- RLS再導入の現実性。2週間以内に集中作業で認可を入れられますか？ Yesならレスキュー。データアクセス層がもつれていてポリシーをきれいに足せないなら、もつれをほどくより書き直したほうが速いです。
- コード量と読みやすさ。2万行以下で、概ね読み解ける：レスキュー。4〜8万行のマイクロサービス（本来モノリスであるべきもの）：ほぼ確実に書き直し。
- テスト化の実現性。1週間以内に既存フローをPlaywrightテストとして書けますか？ Yesならレスキュー＆ハードニング。フローがもつれていて、テスト化の前に書き直しが必要なら、書き直し。
2万行以下でスキーマが健全なアプリの正解はたいていレスキュー。5万行を超えるアプリの正解はたいてい書き直し。リファクタリングは中間域、データモデルは健全で振る舞いも明確だが、コード表面が理解可能範囲を超えてしまったケースの正解です。
バイブから本物へ：7段階のフィールドガイド
以下は、本番運用に耐えるアプリにするための実務的なフィールドガイドです。パッケージ化された商品でも、固定タイムラインでもありません。自分でなぞるチェックリストとして、開発者に渡す手順書として、あるいは「相談しているエージェンシーが本当にこの仕事を理解しているか」を見極める判断材料として、お使いください。タイミングよりも順番のほうが大事です。各ステージは前のステージの上に積み上がります。
ステージ1：監査。コードに手を入れる前に、構造化された発見作業を行います。リポジトリをクローンし、SnykとSemgrepでセキュリティスキャンを走らせ、GitGuardianでコミット履歴の漏洩シークレットを検査し、外部連携をすべて棚卸し、データモデルを記録し、ユーザー導線を端から端まで追います。アウトプットとしては、前章の12項目について本番運用への到達度を1ページにまとめた要約があると良いでしょう。平易な言葉で、何が見つかったかを伝えること。エンジニアリング的な恥はゼロ。これは診断であって、評価ではありません。
ステージ2：レスキューか書き直しかの判断。4基準の判断ツリーを、自分のアプリに当ててみてください。書き直し判断になった場合、AIが発見した「仕様」こそが資産であることを忘れずに。新しいコードに着手する前に、その仕様をテストとドキュメントに抽出しておきます。プロトタイプの価値の多くは「実装」ではなく「仕様」にあるという事実を、創業者は普遍的に過小評価しています。
ステージ3：8項目セキュリティパス。どのトラックでも1週目に固定リストで進めます。すべてのシークレットをローテーションしてマネージドストア（Vercel Env／Doppler／Infisical）へ移行。SupabaseのRLSを有効化し、テーブル単位で明示的なポリシーをテスト付きで設定。NEXT_PUBLIC_に紛れ込んだサーバ専用シークレットをサーバ側へ移動。すべてのAPIルートにサーバ側認可チェックを追加。ZodまたはValibotで入力検証を追加。レート制限を追加（Upstash Redis／Arcjet）。Stripeウェブフックの署名検証を追加。Sentryと稼働監視を有効化。各タスクは「動くことを示すテスト」とセットで進めます。8項目に「省略可」はありません。
ステージ4：アーキテクチャレビュー。3つの問いで集中したワーキングセッションを行います。10倍スケール時にどこが壊れるか。次のエンジニアが混乱する箇所はどこか。今日打てる「最も安く可逆な賭け」は何か。アウトプットはアーキテクチャ決定記録（リポジトリにコミット）と90日テクニカルロードマップ。「エージェンシーがそのスタックを好きだから」という理由で技術選定を固定しないこと。最適なスタックは、何を作るのか、誰が運用するのか、その先に何が来るのかで変わります。マルチテナントのデータを扱うトランザクショナルなSaaSと、非エンジニアが編集する必要があるコンテンツ重視のマーケティングサイトでは、要件はまったく異なります。スタックがプロダクトに奉仕するように設計してください。
ステージ5：実用的なテスト戦略。売上フローをカバーするPlaywrightのE2Eテストを3〜5本。意義のある純関数ロジックにはVitest。ユニットテストは負荷を支える段階になるまでスキップ。カスタム404、カスタム500、エラーバウンダリを追加。目標はカバレッジではなく、「恐れずにリファクタリングできる」状態です。
ステージ6：的を絞ったリファクタリング。重複コンポーネントを撲滅し、fetchラッパー・認証ヘルパー・エラーバウンダリを統一。デザインシステムをトークンに抽出。コードベースが本当に必要としている3〜5モジュールだけをlib/に置く。AIが書かなかったREADMEを書く。重要なのは、抽象化を投機的に増やさないこと。すべての抽象は、すでに存在する重複によって正当化されている必要があります。早すぎる抽象化は、まともなコードベースを「あのマイクロサービス地獄」に変える主犯です。
ステージ7：デプロイ基盤と可観測性。GitHub ActionsでCI/CD：すべてのプルリクエストに対しlint＋typecheck＋test。プレビューデプロイはVercel。本番デプロイはCIグリーンを条件にゲート。スキーママイグレーションはSupabase CLI経由でコミット済み。エラーはSentry。プロダクト分析にはVercel AnalyticsかPlausible。稼働監視にはBetterStack。レート制限の状態はUpstash。バックアップはSupabaseのポイントインタイムリカバリ＋週次の論理ダンプをS3に。ロールバック手順はドキュメント化＆実演済みであること。ここまで揃えば、本番運用への移行は実質的に完了です。デプロイ可能・観測可能・復旧可能の3点が成立した状態だからです。
使ったツール別、最初にやるべきこと
失敗の出方はツールによって違うので、ツール別の指針を置いておきます。
Lovable。最初の一手：Supabaseを開き、すべてのテーブルでRLSを監査。可能ならMatt Palmerのvibe-table-auditスクリプトを走らせる。service-roleキーがNEXT_PUBLIC_で露出していないか確認。Lovableが許可した瞬間にコードをGitHubへエクスポート（最近の有料プランはどれも対応）。リポにSnykスキャンをかける。Lovableのセキュリティスキャナーは「RLSが有効か」を見るだけで「ポリシーが正しいか」までは見ないので、緑のチェックを過信しないこと。
Bolt.new。最初の一手：StackBlitzプレビューから降りる。コードベースを実際のVercelデプロイに移し、環境変数を正しく設定する。レート制限を追加する。Boltアプリは特にレート制限が抜け落ちて出荷されがちで、StackBlitz環境がそれを覆い隠しているからです。デモのStripeキーを本番キーに差し替えるのは、ウェブフック署名検証を入れた後で。
v0。朗報：v0のRadixコンポーネントベースのおかげで、本グループ内ではアクセシビリティの床が最も高いです。難点：v0は美しいUIを出力しますが本物のバックエンドはなく、創業者がしばしば後付けで雑に繋ぎます。最初の一手：実バックエンド（Supabase／Convex／Next.jsサーバ）をひとつ選び、認証を一度きちんと実装してから、v0コンポーネントを移植する。後付けで認証を被せないこと。
Cursor。最初の一手：.cursorrulesを読み返す。CVE-2025-53773でルールファイルのプロンプトインジェクション脆弱性が公開されているので、自分のルールがクリーンか確認。ファイルシステムやDBに触れる操作のオートランは無効化。50行を超えるAI生成変更は、マージ前に必ず人間レビューを通す規律を整える。Cursorは本リスト中で最も強力で、最も誤用しやすいツールです。
Claude Code。最初の一手：リファクタプレイブックを用意する。Claude Codeはエージェント型IDEの中でも複数ファイル横断の推論が最も強く、デプロイスクリプト・マイグレーションファイル・認証ヘルパーを無監督で触らせると最も危険になり得ます。Claude Codeが自律修正してはいけないファイル群を定義し、CIチェックで強制すること。
Replit Agent。最初の一手：Lemkin事件以降に追加されたdev/prod DB自動分離を有効化（古いプロジェクトではデフォルトオフ）。エージェントの権限を監査。コードフリーズ中は破壊的権限を無効化。DBにポイントインタイムリカバリを設定。Replit Agentは、明示的なコードフリーズ中にAIが本番DBを削除して、その後に復旧不能と嘘をついた事案が記録されている唯一のツールです。それに見合う扱いをしてください。
実際の費用と期間（ドル換算）
レスキュー系の代理店ランディングページに欠けている、率直な料金の話を、ここで埋めておきます。
DIY。金額はゼロ、時間とストレスは高い。エンジニアリング経験があるなら、8項目セキュリティパスを長い週末で自走可能です。経験がないなら、DIYは多くの場合「見せかけの節約」になります。2ヶ月後に同じ問題と、自分のコードに対するさらに混乱したメンタルモデルを抱えて戻ってくる、というのが典型的な顛末です。
ブティック型レスキュー市場。絞り込んだ2〜4週のレスキューで、概ね2,500〜8,000ドル。市場は実在し、競争は密で、品質はばらつきます。RLSを有効化してVercelデプロイを切ったぶんで6,000ドルを請求するエージェンシーも、同じ価格で本当に良い仕事をするエージェンシーも見てきました。商談時に「8項目セキュリティパスの成果物リスト」を明示的に求めること。それが何かを答えられない相手なら、別を当たってください。
フル書き直しトラック。6〜12週、スコープに応じて15,000〜60,000ドル。AI生成Reactが4万行を超える、あるいはデータモデルが根本的に間違っているプロダクトの正解。直感に反しますが、長期では最も安いことが多いです。「誰も読めないコードベース」の維持税を払わなくてよくなるからです。
Optifyに依頼する場合。価格はコードベースの規模・スコープ・レスキューか書き直しかによって変わります。5,000行のLovableアプリと50,000行のCursorモノリスでは、ブログに単一の数字を書ける幅を超えてしまうからです。誠実にスコープを切る方法は、対話するしかありません。本記事末尾でリンクしている2本の通話はどちらも無料で、無理な約束は一切ありません。
Optifyの立ち位置について
位置づけについて、よく聞かれるので一言。私たちは「レスキュー業者」ではありません。レスキューは臨床的・救急的な響きで、必要としていることそのものを暗に責める語感があります。私たちは「最適化（optimization）」という言葉を使います。仕事の実態に対してそのほうが誠実だからです。プロトタイプは動いていて、顧客はお金を払っていて、私たちの役割はそのプロダクトを実条件下で機能させること。エンジニアリングの厳しさは良質なレスキュー会社と同等で、出発点の前提だけが違います。
もうひとつの違いは、私たちが「デザインと最適化のスタジオ」を本業にしていることです。多くのレスキュー会社はエンジニアリング専業で、セキュリティ・リファクタ・CIだけを「本番運用に耐える」の定義にしがちです。それらはたしかに重要ですが、UX・パフォーマンス・コンバージョンといった「体験のレイヤ」こそが、動くアプリを「ユーザーが戻ってくるプロダクト」に変えます。私たちは、その両方をテーブルに乗せます。
バイブから本物へ
あなたはAIツールで動くプロトタイプを出荷しました。それは常に、簡単なほうの半分でした。難しいほうの半分（セキュリティ、可観測性、パフォーマンス、アクセシビリティ、初日から次のエンジニアが読めるコードベース）が、それを「自社が所有する売れるプロダクト」に変える半分です。バイブコーディングを謝る必要はありません。それがあなたをここまで連れてきました。次は、残り半分の仕事です。
レスキューか、リファクタか、書き直しか。判断に迷ったときのセカンドオピニオンとして、まずは無料ウェブサイト診断（15分の通話）をご活用ください。営業や資料の押し付けはしません。いくつか具体的な質問をして、コードベースの現在地について率直な見解をお伝えします。さらに先に進めたい場合は、一度お話ししましょう。スコープ・ゴール・概算について一緒に整理する場です。どちらの通話も無料で、無理な約束は一切ありません。
用途次第で両方が正解です。週末プロジェクトや敵対トラフィックを受けない社内ツールなら、バイブコーディングは問題なく、Karpathyが当初そう定義したのも自然です。一方、有料顧客のいる商用プロダクトに関しては、データは明確です。Veracodeの計測ではAI生成コードの45％にOWASP Top 10の脆弱性が含まれ、Apiiroの調査ではAI比率の高いリポジトリで月あたりのセキュリティ指摘が10倍に増えています。Replit、Lovable、Enrichleadの公開事例も例外ではありません。誠実な整理：バイブコーディングは「何を作るべきか」を発見するには優れた方法ですが、「有料顧客が依存するバージョン」を作る方法としては不十分です。
たいていの場合は、いいえ。スキーマが健全で2万行以下のアプリは、書き直すよりレスキューしたほうが良いことが多いです。コードベースが「動く仕様」を含んでおり、書き直しではそれを失うリスクがあるからです。書き直しを検討すべきは、スキーマが根本的に間違っている（主キーの設計ミス、テナンシーモデルの不在、深い非正規化）、AI生成Reactが4〜6万行を超えている、ひとつの変更が他の機能を必ず2つ壊す、といったケース。判断基準はデータモデルの健全性、RLS再導入の現実性、コード量、テスト化の実現性の4点。3つ以上が「書き直し」を指していたら、書き直しが正解です。
ブティック型のレスキュー市場では、セキュリティ・可観測性・最優先のリファクタを2〜4週で集中する案件で、概ね2,500〜8,000ドル。クリーンな基盤・テスト・堅牢なデプロイパイプラインを揃えるフル書き直しは、6〜12週で15,000〜60,000ドル。ばらつきの大半はコード量とデータモデルで決まります。商談相手には「成果物リスト」と「納期」を必ず聞いてください。スコープなしの時間単価は、本市場で最もプロジェクト超過を予測する指標です。
レスキュートラックで2〜4週、フル書き直しで6〜12週が目安です。8項目セキュリティパスだけなら、チームが集中できれば1週間で出荷可能。残りの大半はテストと可観測性、そしてコードベースを読みやすくするリファクタリングに費やされます。短いタイムラインはむしろ良いサインです。長期化したレスキュー案件は、創業者が想定しない長期リテイナーに変質する典型パターンだからです。1万行のアプリで「6ヶ月」の見積もりが出てきたら、それはレスキューではなく別の何かを売られています。
いくつかのカテゴリでは可能、多くのカテゴリでは不可、が答えです。あなたのコードを書いたAIツールは、自分が導入する失敗モードを正確に発見するキャリブレーションになっていません。「SupabaseプロジェクトにRLSを追加して」とCursorに頼むのは妥当。「認可モデルを再設計して」と頼むのは妥当ではありません。よく見るのは、「直し」に40〜80時間分のクレジットを溶かして、結局最初と同じ問題＋より混乱したコードベースが残るパターンです。経験則：AIは「すでに自分が理解している修正」を適用するのは得意、「どの修正が正しいか」を判断するのは苦手です。
この順番で3ステップ。1：プロバイダ管理画面（OpenAI、Stripe、Twilio、AWSなど）でキーをローテーション。古いキーは死にます。2：GitHubリポジトリの履歴（最新コミットだけでなく履歴全体）を、GitGuardianやgit-secretsで漏洩値を検索。パブリックリポジトリに上がっていたなら、すでにスクレイパーのDBに入っているので、ローテーションだけでは不十分です。git filter-repoかBFGで履歴を削除し、強制プッシュしてください。3：プロバイダの請求履歴を「過去30日」で精査。今日だけではなく。攻撃者によっては検知を避けるためにスロットリングして悪用します。異常な利用が見つかったら、迅速にサポート連絡すれば返金対応されることが多いです。
Row Level Security（RLS）はPostgresの機能で、ログイン中のユーザーが読み書きできる行を、アプリケーション側ではなくデータベース側で制限します。SupabaseはRLSを主たる認可モデルとして採用しており、RLSが無効だと、認証済みユーザーは公開しているテーブルの全行を読めます。AIツールはRLSを無効のまま、もしくはRLSは有効でもポリシーがない（読み取りが静かに壊れて、開発者がまた無効化する）状態でSupabaseアプリを生成しがちです。バイブコード生態系全体で最も多い本番バグです。本番アプリのSupabaseテーブルは、すべてRLSを有効化し、明示的かつテスト済みのポリシーを持っているべきです。
いいえ。ただし移行経路はそれぞれ違います。Lovable、Bolt、Replitはいずれも有料プランでGitHubへのコードエクスポートをサポートしています。エクスポート後は、ローカルで動かせて、Vercelにデプロイでき、開発者が自由に修正できる、通常のNext.jsまたはReactプロジェクトになります。難しいのはたいていデータベース側：Supabaseのデータはセルフホストや別のSupabaseプロジェクトに移せますが、Replitのデータベースは一度だけのエクスポートが必要です。コードをGitHubに出した瞬間、プラットフォームは支配的でなくなります。だからこそ私たちは、新機能の開発をAIビルダーで続けるつもりでも、ロックイン回避のヘッジとして早めにエクスポートすることを推奨しています。
売上を生むフローをカバーする3〜5本のE2Eテストは必要です。それだけです。ユニットテストカバレッジ80％を目指す必要はありません。それは小さなチームには合わないトレードオフです。これら数本のテストの目的は、「恐れずにリファクタリングできる」状態を作ること。テストがないと、認証ヘルパーやDBクエリレイヤを変える度に、決済が静かに壊れるリスクを抱えます。創業者は「アプリは動いている」と言い続けます、有料顧客の決済が壊れるその日まで。テストは、まさにその日への保険です。
答えは「ケースによる」で、それ以外から始まる答えは何かを売りつけようとしているサインです。正しいスタックは、アプリが何をするのか、誰が運用するのかに従います。マルチテナントのデータを扱うトランザクショナルなSaaS、非エンジニアが編集する必要があるコンテンツ重視のマーケティングサイト、アニメーションとデザイン品質が肝となるブランドサイトでは、要件はまったく違います。AI製アプリのレスキューで検討に値する素材としては、アプリケーション層のモダンなフレームワーク（Next.jsやAstroなど）、適切な認可制御を持つデータベース、マネージドのデプロイ基盤、可観測性、などが挙げられます。プロダクトによってはWebflowに薄いカスタムバックエンドを足す構成が正解の場合もありますし、フルカスタムのスタックが正解の場合もあります。危ないのは「誰かがそれを好きだから」という理由でスタックを固定してしまうこと。プロダクトに奉仕する選択をしてください。
4基準を当ててみてください。データベーススキーマは正しくドメインを表現していますか（妥当な主キー、テナンシーの概念）？ 集中作業の2週間で認可を追加できますか？ コードは2万行以下で、シニアエンジニアが初見で概ね読める範囲ですか？ 既存フローを1週間以内にPlaywrightテストとして書けますか？ 4つのうち3つにYesと言えるなら、レスキュー。言えないなら書き直しの数学が勝ちます。「レスキュー領域を超えた」という素直なシグナルは、修正のたびにコードベース内の無関係な箇所で2つの新しいバグが出ることです。これはレスキューでは解消できない構造的な問題の症状です。
コンバージョンに伸び悩んでいませんか？
