バイブコーディングプロジェクトの構造的問題と4時間復旧スプリント

バイブコーディングとは、自然言語による指示とAIコーディングツールを活用し、アプリケーションを素早く実装する作業方法を意味する。初期段階では画面や機能が急速に増えていくが、リリースが近づくと、認証・データ・決済・デプロイのように複数のレイヤーを横断する問題が表面化しやすい。

この現象を、特定の技術スタックの欠陥やユーザーのプロンプト能力だけで説明してはならない。重要なのは、誰が構造的一貫性を管理するのか、各コンポーネントの責任が明確か、完了したかどうかを検証するテストがあるかである。

バイブコーディングプロジェクトが後半で行き詰まる理由

画面の完成とサービスの完成は異なる

開発初期には、ボタン、入力フォーム、一覧のように目に見える成果物が素早く作られる。しかし、実際のサービスには次のような目に見えない条件が必要になる。

• ユーザーが自分のデータだけにアクセスできるようにする権限チェック
• 重複リクエストやネットワーク再試行に耐えるデータ処理
• 決済の成功、失敗、キャンセル、返金とWebhook検証
• 入力値の検証とエラー復旧
• データベースの変更および既存データの移行
• 秘密鍵の管理、ログ、モニタリング、バックアップと復元
• デプロイ後も主要機能が維持される自動テスト

画面が動作するという事実だけで、これらの条件が満たされるわけではない。後半で見つかる欠陥は突然生じたものではなく、初期実装で確認されないまま蓄積していた場合が多い。

AIはリポジトリ全体の設計意図を常に維持できるとは限らない

AIコーディングツールは、与えられたファイル、会話の文脈、検索されたコードと指示に従って変更案を生成する。プロジェクトのルールが文書化されていなければ、次のような不整合が生じる可能性がある。

• 同じデータ取得をサーバーコンポーネント、APIルート、ブラウザーコードでそれぞれ異なる方法で実装
• 認証状態をCookie、クライアント状態、外部SDKで重複管理
• 同じ検証ルールを画面とサーバーに異なる形で記述
• エラーを根本的に解決せず、例外処理や条件文だけを追加
• 既存の抽象化を見つけられず、類似した関数とデータモデルを繰り返し生成

この状態で新しいエラーを修正すると、あるレイヤーの変更が別のレイヤーの前提を崩す可能性がある。ユーザーにはAIが同じところを堂々巡りしているように見えるが、実際にはAIが従うべき単一の構造と検証基準が存在しない状況かもしれない。

React・Next.js・Supabaseの組み合わせを正確に理解する

React、Next.js、Supabaseを、単に問題のある組み合わせ型スタックと規定するのは正確ではない。それぞれの技術には、広く利用されている独立した役割と利点がある。

Next.jsは画面だけを担当するツールではなく、サーバー機能も提供する。Supabaseも単なるデータベースではなく、認証やストレージなどを含めることができる。問題は複数の機能を利用する際に、権限とビジネスルールの最終的な責任がどこにあるのかを決めていないことから生じる。

たとえば、注文作成ルールがブラウザーコード、Next.jsのサーバールート、Supabaseのデータベースポリシーに分散していれば、エラーの追跡は難しい。反対に、書き込み処理はサーバーのサービスレイヤーを通し、データベースポリシーは最後の防衛線として使用するというルールを定めれば、同じスタックでも安定して運用できる。

Ruby on Railsが代替案になり得る理由

設定より規約で選択肢を減らす

Ruby on Railsの代表的な原則である設定より規約は、繰り返し下さなければならない構造上の決定を、フレームワークの基本ルールによって統一する。モデル、コントローラー、データベース変更、ジョブ、メール、テストの配置と接続方法が比較的予測しやすい。

AIコーディングでは、この予測可能性が特に有用である。明確な規約に従えば、AIが新機能をまったく異なるパターンで追加する可能性を抑えられ、人間による変更内容のレビューも容易になる。

Webサービスの共通機能を一つの体系で扱う

Railsは、データベースアクセス、ルーティング、サーバーレンダリング、非同期ジョブ、メール、リアルタイム通信、テストとデプロイのための公式コンポーネントおよび手段を提供する。これにより、別々のツール間の接続部分を減らすことができる。

ただし、次のような限界も明確に存在する。

• 決済処理には、Stripeのような外部決済事業者が引き続き必要である。
• 管理画面がすべての要件に合うよう自動的に完成するわけではない。
• 認証機能を生成したりライブラリで構成したりしても、権限設計とセキュリティレビューは別途必要である。
• 複雑なリアルタイムインターフェースや独立したモバイルAPIには、追加設計が必要である。
• Railsの経験がないチームであれば、学習と採用のコストが発生する。

したがってRailsは、AIにすべての問題を解決させるツールではなく、AIと人間が従うべき基本ルートを絞り込む選択肢である。

4時間で何を解決できるのか

ログイン、決済、管理機能、データ移行、セキュリティレビューと本番デプロイを含む任意のサービスを、4時間以内に完成できるという普遍的な根拠はない。現実的な4時間の目標は次のとおりである。

• 現在の構造と障害箇所を把握する。
• 保守と再実装のどちらかを選択する。
• 最も重要なユーザーフローを一つ動作させる。
• テスト可能な新しいベースラインを作る。
• 可能であればステージング環境にデプロイする。
• 残ったリスクと後続作業を一覧として残す。

4時間で再実装できる条件

次の条件を多く満たすほど、短時間での再実装が可能になる。

1. 必要な画面とユーザーフローがすでに確定している。
2. 主要なデータ項目と関係が整理されている。
3. デザインを新たに議論せず、既存画面を参考にできる。
4. リポジトリ、ドメイン、デプロイ環境、外部サービスのアカウントにすぐアクセスできる。
5. 既存データの移行を省略するか、小さなサンプルだけを移せばよい。
6. 決済は、サンドボックスの基本的な成功フローのように狭い範囲に限定する。
7. Railsとデプロイ環境を理解する担当者がAIの出力をレビューする。

数か月にわたって進めてきた既存プロジェクトが役立つ理由もここにある。その期間にユーザーフロー、必須フィールド、失敗事例と優先順位が具体化されていれば、調査にかかる時間を短縮できる。ただし、企画が自動的に完璧になったという意味ではなく、既存プロジェクトで検証済みの要件だけを再利用すべきである。

実践的な4時間復旧スプリント

ステップ1：原本を保全する

修正前にリポジトリの別ブランチまたはコピーを作成し、データベースをバックアップする。AIとの会話にAPIキー、データベースのパスワード、個人識別情報を貼り付けない。すでに漏えいさせた場合は、該当する秘密情報を失効させ、新たに発行するのが安全である。

ステップ2：根拠とともに技術スタックを調査する

AIに単に技術スタックを推測させるのではなく、次の資料を確認するよう要求する。

• パッケージとバージョンが記録されたマニフェストおよびロックファイル
• データベーススキーマとマイグレーション
• 認証とセッションを処理するファイル
• APIルートとサーバー関数
• デプロイ設定、環境変数名、外部サービスのSDK
• 自動テストと継続的インテグレーションの設定

利用できる依頼例は次のとおりである。

リポジトリを読み、フロントエンド、サーバー、データベース、認証、ストレージ、決済、デプロイ、テストツールを表にまとめよ。各判断の根拠となるファイルパスを記載し、ビジネスルールが重複している箇所と、サーバー・クライアント境界に違反している可能性を示せ。コードはまだ修正せず、秘密の値は出力しないこと。

ステップ3：主要な垂直フローを一つだけ選ぶ

垂直フローとは、画面からサーバーロジックとデータ保存までつながる、一つの完全な経路である。たとえば次のようなものがある。

• 会員登録 → ログイン → プロフィール表示
• 商品選択 → 注文作成 → 決済サンドボックス承認
• 管理者ログイン → 投稿作成 → 公開ページへの表示

一度に複数の画面を作るよりも、主要フロー一つを成功・権限なし・不正な入力という条件で検証する方が、構造上のリスクをより早く明らかにできる。

ステップ4：完了条件をテストで固定する

AIに機能実装だけを依頼すると、画面上の成功事例だけに合わせたコードが出てくる可能性がある。最低限、次の条件を自動テストまたは反復可能なチェックリストとして固定する。

• 正規ユーザーは作業を完了できる。
• ログインしていないユーザーは保護されたデータにアクセスできない。
• 他のユーザーの識別子を入力しても、そのデータにアクセスできない。
• 不正な入力は保存されず、理解可能なエラーを返す。
• 同じ決済または書き込みリクエストが繰り返されても重複処理されない。

ステップ5：ステージングまでに限定してデプロイする

4時間スプリントでのデプロイは、一般的に本番確定ではなく、ステージングでの検証と考えるのが安全である。実際のユーザーと決済を受け入れる前に、セキュリティ、データ移行、バックアップ復元、モニタリングと障害対応を別途確認しなければならない。

既存プロジェクトを修正するか作り直すかを決める基準

ファイル数が多い、またはエラーがあるという理由だけで全面的に書き直してはならない。書き直しによって、既存システムで解決済みだった例外的な状況への対応を失い、新しい欠陥を生み出す可能性がある。まずは小さな垂直フローを2つの方式で実装し、開発速度、テスト可能性、コードの理解しやすさ、デプロイリスクを比較するのがよい。

リリース前に別途確認すべき項目

4時間でベースラインが作られても、次の項目が残る可能性がある。

• 権限モデルとRailsのセキュリティ設定のレビュー
• 決済Webhookの署名、重複防止、キャンセルと返金の処理
• 本番データの移行および件数・合計の検証
• データベースのバックアップと実際の復元テスト
• エラー追跡、ログの保存、可用性のモニタリング
• 負荷テストとコスト見積もり
• 個人情報の取り扱い、利用規約と関連する法的レビュー
• アクセシビリティ、ブラウザーおよびモバイル環境の確認
• 障害発生時のロールバック手順と担当者の指定

結論

バイブコーディングプロジェクトが後半で停滞する理由は、AIのコーディング能力だけでは説明できない。自由度の高い構成で、ルール、責任境界、テスト、運用基準を定めなければ、AIが作った局所的な解決策は互いに衝突しやすい。

Ruby on Railsは、規約と統合された構造を通じて、この自由度を減らす実用的な代替案になり得る。しかし、すべてのプロジェクトをRailsで作り直すことが正解ではない。まず現在のスタックを根拠に基づいて調査し、主要フローを定めたうえで、4時間を完成品の制作時間ではなく、構造を検証し、復旧可能なベースラインを作る時間として使うべきである。