Vibe Codingを続ける限界はどこか — 実践的な見切り方
ログインを修正すると、支払いが壊れ、支払いを修復するとログインのバグが再発します。さらに長いプロンプトを書いても、この循環を断ち切れないことがあります。次の変更を依頼する前に、失敗が繰り返されているか、関連する挙動がテストでカバーされているかを確認してください。
Vibe Codingが効かなくなるポイントは固定ではありません。製品やそのリスク、コードの状態によって答えが異なります。一方、進め方を変えるべき兆候は比較的見つけやすいものです。
機能数ではなく、失敗時のコストで判断する
モックアップや使い捨てのプロトタイプ、小規模チーム向けの社内ツールなら、試行錯誤を許容できます。AIツールも、要求が明確で挙動がテスト可能なCRUDアプリケーションでは、多くの作業を担うことができます。
だからといって、そのアプリを一人で完成させられる保証はありません。重要なのは、失敗しても元に戻せることです。CRUDアプリケーションが個人データを保存したり、有料顧客を相手にし始めると、状況は変わります。
画面上の規模以上にリスクは大きくなる
製品に以下が含まれるようになると、動作する画面だけでは不十分になります：
- 支払い: サーバーは金額を計算し、Webhook署名を検証し、重複するイベント処理を防ぐ必要があります。
- 個人データ: 認証は最初のステップにすぎません。ユーザーごとの認可、データの保持・削除、インシデント対応も重要です。
- 同時ユーザー: 二人が同じデータを変更すると、競合やデータの不整合が起こります。
- 運用上の依存関係: デプロイ、監視、バックアップ、復旧は機能実装とは異なる分野です。
マネージドサービスは書く必要のあるコードを減らしますが、データやアクセス制御、アプリケーション設定のすべての責任を引き受けるわけではありません。Supabaseはこの点を明確に「共有責任モデル」として説明しています。
最終段階は固定のパーセンテージではありません
初期の成果は目に見えやすく、画面が現れて正常系が動き始めます。後半になると、機能間の接点、エラー処理、既存データ、テスト、セキュリティルール、デプロイ上の制約が表面化します。表示される機能数はほとんど変化しない一方で、検証が必要な境界は急速に増加します。
AIモデルのコンテキストに入る会話やコードの量も重要です。Anthropicは、コンテキストが長くなるほど必要な情報を正確に取り出しにくくなる現象を「コンテキストロット」と呼んでいます。ファイル数に共通の上限があるわけではありません。無関係なファイルや長い会話がコンテキストを圧迫したり、変更範囲が曖昧で過去の決定を見落としやすくなったりすると、実務上のリスクが高まります。
完成間近で突然壁にぶつかったように感じるのは、多くの場合、検証すべき接点の数が、残りの機能数より速く増え始めたためです。
作業を止めて助けを求めるべき3つのサイン
修正が再び同じ問題を引き起こす
Aを修正するとBが壊れ、Bを修復するとAが再び壊れる。次の修正を依頼する前に、再現手順とテスト内容を固定してください。重要なのはバグが何日続いたかではなく、それぞれの修正が同じリグレッションチェックに失敗していることです。
結果が正しいか判断できない
認証、認可、支払い、データの復元はUIだけでは判断できません。テストがない、またはログがあっても安全性を判断できる人がいない場合、検証のギャップは実装のギャップよりも大きいです。狭い範囲のコードレビューまたはセキュリティレビューはこの点を補うことができます。
失敗が他人に被害を及ぼす
製品が実際の顧客のお金やデータを扱い始めたり、ダウンタイムが収益に影響するようになったりした場合、「まず公開して、問題は後で直す」という判断の代償が大きくなります。プレリリースのレビュー、バックアップ、ロールバック、監視は今や範囲に含まれるべきです。
アプリ全体ではなく、範囲を絞ったレビューだけを依頼できる
機能作業を一時停止し、現在正常に動いているバージョンを保存してください。再現手順、期待される結果、実際の結果、関連するログを1つのドキュメントにまとめます。これにより、AIツールと開発者に同じ出発点を提供できます。
次に、依頼を小さくしてください：
- 認証とユーザーごとの認可のみをレビュー
- 支払いリクエストとWebhook処理のみをレビュー
- デプロイ設定、APIキー、環境変数のみをレビュー
- 再発する機能のテストを書く
「私のアプリを完成させる」は価格を決めづらく、検証も困難です。対象範囲と受け入れ条件を明記した依頼なら、提案内容と成果を比較しやすくなります。修正後に同じテストを再実行することも依頼内容に含めます。
次のプロンプトの前に記録すべき4つのこと
まだプロジェクトを引き継ぐ段階でなくても、以下を書き留めてください：
- バグを再現する正確なクリックパスとアカウント状態
- 正常動作を確認できた最後のコミット
- AIが変更したファイルとその理由
- 次の変更後にパスしなければならないテスト
この記録はチームが問題を繰り返し再発見することを防ぎ、修正によって別の機能が知らないうちに元の状態へ戻っていないかも分かります。Vibe Codingの限界とは、ツールを捨てる境界線ではありません。次のパッチを作ることより、検証と運用を優先すべき段階に入ったということです。