プロンプト一つで、わずか数分で動作する画面が完成する快感は誰もが経験したことがあるでしょう。サイドプロジェクトにおいて、そのスピード感はほぼ「反則」と言えるほどです。
しかし、クライアントからログイン機能や権限管理、請求データ、そしてクリーンな引き継ぎを求められたとき、その「楽しい部分」は「午前2時に叩き起こされる悪夢のような部分」へと激変します。
デモが「本当のリスク」を隠してしまう理由
ローカル環境でのデモであれば、生成されたアプリのほとんどが完成しているように見えます。フォームは送信され、ダッシュボードは読み込まれ、「ハッピーパス（正常系）」さえ機能していれば、商談中のクライアントを十分に見舞うことができるからです。
問題は、本番環境のアプリは「失敗ケース」「エッジケース」、そして「セキュリティ境界」で評価されるという点です。研究によると、大規模言語モデルはコードのコンパイルに約90%の確率で成功しますが、生成されたコードの約45%にOWASP Top 10の脆弱性が含まれているとされています。実際の顧客データを取り扱うクライアントポータルや社内ツールをリリースする場合、最初の画面がいかに早く表示されたかよりも、この「格差」こそが致命的な問題となります。
「お金」と「ユーザー」が関わった瞬間に変わること
クライアントが対価を支払うようになると、仕事は単に「ソフトウェアを出現させること」ではなくなります。認証が正しく機能し、権限管理が徹底され、データが適切なユーザーにのみ限定され、そして小さな修正が全く関係のないフローを壊さないことを保証することが仕事になります。
ここに、完全生成コードの「コストの罠」があります。AIツールに次から次へと修正（パッチ）を依頼していると、見た目を直したはずなのに、別の場所でビジネスロジックが静かに書き換わっているというループに陥ることがあります。コードベースがモデルのコンテキストウィンドウを超えると、ドリフト（意図しない乖離）は増える一方です。「速く作れること」と「安定して所有（維持）できること」は全く別物です。
セールスビデオでは誰も触れない「引き継ぎ」の問題
クライアントが購入するのは、劇的な「初回のビルド」ではありません。彼らが本当に求めているのは、リリース後に運用し続けられるシステムです。もしあなただけが「再プロンプト」してアプリを形にできる状態なら、たとえリリースがスムーズだったとしても、その引き継ぎは不完全と言わざるを得ません。
私たちはまさにこのパターンで、1ヶ月分のクレジットを使い果たしたことがあります。小さな要望が新しいプロンプトの連鎖に変わり、回帰テストを行い、そして前の修正が予期せぬ箇所に影響を与えたため、さらに別の修正を行う……。生成コードを管理できるエンジニアチームを持たないクライアントのために構築する場合、メンテナンスコスト（技術的負債）が、当初節約できたはずの時間的に相殺してしまう可能性があります。
直面しているプロジェクトで「より安全な道」を選ぶ方法
現実的な近道は、「リスクに合わせてツールを選ぶ」ことです。カスタムプロダクトを構築しており、クライアント側にリポジトリを管理できるエンジニアがいる場合は、コードファーストのツールが適しています。一方で、ユーザー、ロール、ビジネスデータを扱う運用アプリを提供する場合、それらの機能がネイティブに組み込まれているプラットフォームを優先すべきです。
ログイン、ロール、実データが必要なビジネスアプリなら、認証や権限、データ管理が「生成コード」ではなく「プラットフォームの機能」として設定できる Softr が最適です。対して、エンジニアチームが保守するコードファーストの構築には、Cursorがより誠実な選択肢となるでしょう。決定前にさらに幅広い候補を知りたい方は、エージェンシー向け最強のvibe codingツール ランキングから始めてください。ルールは単純です。「カスタマイズが製品であるなら生成コードを使い」、「信頼性が製品であるならプラットフォームのガードレールを使いましょう」。