vibe-codingでアプリを作った初日は、人生最高のデモになるはずです。プロンプトは機能し、画面はクリーンで、データベースにはデータが入っており、画面録画を添えてツイートまで完了します。私たちはそんな日を何度も経験してきました。それをあなたから奪いたいわけではありません。
私たちが話したいのは「2日目」のことです。なぜなら、誰のローンチスレッドもそこには触れないからです。2日目とは、実際のユーザーがログインし、あなたがテストすることを想定していなかった操作を行い、アプリが「生成されたもの」と「設計されたもの」の間の溝に直面する日です。
2日目に実際に起こること
それは、めったにクラッシュから始まりません。まずは奇妙な現象から始まります。ゴミのような入力値を受け付けるフォーム、特定のユーザーだけページが崩れる現象、誰も再現できないが数値が間違っている箇所。あなたはエラーをチャットに貼り付けます。AIは自信満々にそれを修正します。すると、その修正が別の何かを壊します。
プロンプトのモグラ叩きへようこそ。AIは根本原因ではなく症状を修正するため、パッチの上にパッチが重ねられ、コードベースは開発者が「フランケンシュタイン・コード」と呼ぶものに静かに変わっていきます。矛盾するスタイル、重複する関数、データベースクエリがインターフェースコードの中に混在するもつれたロジックの継ぎ接ぎです。プロジェクトがAIのコンテキストウィンドウを超えると、モデルは自身の以前の決定を忘れ始め、それと矛盾するコードを提案します。あなたはもうアプリをメンテナンスしているのではありません。アプリと交渉しているのです。
さらに残酷なパターンがあります。静かなデプロイ失敗です。ホスティングのビルドが軽微なエラーで失敗し、公開URLには古いバージョンが表示され続けているのに、あなたには変更が見えないため、AIに修正が「機能しなかった」と伝えます。するとAIは、すでに解決済みだった問題に対して、全く別のより複雑な解決策を生成します。数ラウンド後には、v1で十分だったコードが、肥大化したv5になっています。
目に見えない部分
デバッグの無限ループは、少なくとも目に見えます。しかし、セキュリティの問題は見えません。だからこそ、ビジネス向けの構築において私たちはこの点に厳しくなるのです。
この分野の研究結果は、実に不快なものです。LLMが生成したコードは約90%の確率で正常にコンパイルされますが、その約45%にOWASP Top 10の脆弱性、つまりバイパス可能なログインチェックやインジェクションの欠陥が含まれています。AIツールは「デモが動作すること」を最適化するため、予測可能なショートカットを切り取ります。例えば、ユーザーがページを編集するだけでバイパスできるブラウザ側でのアクセス制御、ビルド中にエラーが出ないように全開放されたデータベース権限、そして開発者が環境変数の概念を知らないためにファイルにハードコードされたAPIキーなどです。これらのファイルは公開GitHubリポジトリにプッシュされ、資格情報スクレイパーによって予定通りに発見されます。
これがなぜ特に「2日目」の問題になるかというと、脆弱性のあるアプリは完璧に動作するからです。「クライアントAが技術的にクライアントBのレコードを読み取れる」というエラーメッセージは出ません。運が良ければユーザーから気づかされますが、運が悪ければ最悪の結果になります。そして「ただテストすればいい」という標準的なアドバイスは現実に衝突します。非技術的な開発者はハッピーパスをテストしますが、不具合はエッジケース、つまり同時実行バグや、デモに不要だったためAIが生成しなかったパスワードリセットフローなどに潜んでいます。
誰も項目化しないメンテナンス負債
数ヶ月にわたってこれらのメカニズムを積み重ねると、私たちが「技術的負債の消費者金融」と考える状態になります。今すぐソフトウェアを手に入れ、後で複利の利息を支払う仕組みです。AIが取ったあらゆるショートカットは、将来の修正事項となります。修正のたびにクレジットを消費し、コードはさらに肥大化します。プラットフォームのアップデートが配信され、触ってもいない箇所が壊れます。プロンプトからアプリを生成するプラットフォームの長期利用者は、プラットフォーム自体のデグレードを処理するためだけに、クライアントから月額のメンテナンス費用を請求していると報告しています。
これが中心にある皮肉なジョークです。vibe codingはソフトウェアを民主化すると約束しましたが、プロダクションアプリにおいては、主に技術的負債を民主化しただけでした。非技術的な開発者は、AIを使って避けたはずのもの、つまり「開発者の判断を必要とするコードベース」を最終的に抱えることになります。しかも、それがビジネスの根幹を支えており、自分では読めない状態で。
正直な分岐点
では、実際どうすればいいのでしょうか。多くの構築経験といくつかの傷跡を経て、私たちはそれが2つの正直な道への分岐点に集約されると考えています。不誠実な中間地点こそが、唯一の間違った答えです。
道1：コードのメンテナンス方法を学ぶ。 もし十分に情熱があるなら、vibe codingは罠ではなく正当な加速装置になります。エージェントが書いたものを読みましょう。アプリをリリースする前に、RLSが何を意味するのかを学んでください。プロンプト専用ツールから Cursor や Replit に移行し、コードをインターフェースとして扱い、本物の判断力を養ってください。この道は本当に素晴らしいものです。ただ、そこには数ヶ月の歩みが伴います。読んでいないコードをクライアントに納品しながら、その道にいるふりをすることが罠なのです。
道2：危険な部分は生成されない基盤に置く。 自分のアプリがビジネスツール、つまりクライアントポータル、トラッカー、内部CRMであることを認め、その80%がAIが最も苦手とする配管部分、すなわち認証、権限、パスワードリセット、データアクセスであることを認識してください。これらのカテゴリーを Softr のようなノーコードプラットフォームで構築してください。そこでは配管は視覚的に設定するテスト済みインフラであり、AI Co-Builderによって初日のスピードを維持できます。カスタムのデザインが欲しいときは、vibe-codingブロックによって生成コードを単一のコンポーネントに限定できるため、AIは屋根を崩さずに家を装飾できます。この道における2日目は、考古学的な発掘ではなく、単なる編集になります。だからこそ、Softrは私たちの クライアントポータルランキング でトップとなっているのです。
楽しい部分は、プロトタイプや玩具、週末の実験として、思う存分vibe codingしてください。これらのツールが最も輝く場面です。ただ、実際のユーザーが現れる前に、自分が分岐点のどちら側に立っているかを決めてください。2日目は、礼儀正しく待ってはくれません。