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