バイブコーディングプロジェクトの構造的問題と4時間復旧スプリント ================================ バイブコーディングプロジェクトがリリース直前で行き詰まる原因は、プロンプトのスキルよりも、不明確な構造、一貫性のないコード、外部サービス間の境界にある可能性があります。4時間復旧は完成したサービス全体を保証する方法ではなく、範囲を固定し、核心となるフローを再実装して実行可能なベースラインを作る条件付きスプリントとして理解する必要があります。 - React、Next.js、Supabase自体が問題なのではなく、責任の境界と実装ルールを定めずに組み合わせると、複雑性が急速に増大する。 - AIはリポジトリ全体の設計意図と運用条件を自動的に保持しないため、同じ機能が異なるパターンで実装される可能性がある。 - Ruby on Railsは慣例と統合された構成要素によって選択肢を減らすが、決済、セキュリティ検証、運用準備まですべて自動的に解決するわけではない。 - 4時間復旧は、確定した要件、絞り込まれた核心範囲、準備済みのアカウントとインフラ、熟練した作業者がそろっている場合に可能な、初期再構築または安定化作業である。 - 既存コードの修正を続けるか作り直すかは、コードの状態だけでなく、データ移行、外部連携、テスト、チームの能力、リリースリスクを併せて比較した上で判断しなければならない。 バイブコーディングとは、自然言語による指示とAIコーディングツールを活用し、アプリケーションを素早く実装する作業方法を意味する。初期段階では画面や機能が急速に増えていくが、リリースが近づくと、認証・データ・決済・デプロイのように複数のレイヤーを横断する問題が表面化しやすい。 この現象を、特定の技術スタックの欠陥やユーザーのプロンプト能力だけで説明してはならない。重要なのは、誰が構造的一貫性を管理するのか、各コンポーネントの責任が明確か、完了したかどうかを検証するテストがあるかである。 バイブコーディングプロジェクトが後半で行き詰まる理由 画面の完成とサービスの完成は異なる 開発初期には、ボタン、入力フォーム、一覧のように目に見える成果物が素早く作られる。しかし、実際のサービスには次のような目に見えない条件が必要になる。 ユーザーが自分のデータだけにアクセスできるようにする権限チェック 重複リクエストやネットワーク再試行に耐えるデータ処理 決済の成功、失敗、キャンセル、返金とWebhook検証 入力値の検証とエラー復旧 データベースの変更および既存データの移行 秘密鍵の管理、ログ、モニタリング、バックアップと復元 デプロイ後も主要機能が維持される自動テスト 画面が動作するという事実だけで、これらの条件が満たされるわけではない。後半で見つかる欠陥は突然生じたものではなく、初期実装で確認されないまま蓄積していた場合が多い。 AIはリポジトリ全体の設計意図を常に維持できるとは限らない AIコーディングツールは、与えられたファイル、会話の文脈、検索されたコードと指示に従って変更案を生成する。プロジェクトのルールが文書化されていなければ、次のような不整合が生じる可能性がある。 同じデータ取得をサーバーコンポーネント、APIルート、ブラウザーコードでそれぞれ異なる方法で実装 認証状態をCookie、クライアント状態、外部SDKで重複管理 同じ検証ルールを画面とサーバーに異なる形で記述 エラーを根本的に解決せず、例外処理や条件文だけを追加 既存の抽象化を見つけられず、類似した関数とデータモデルを繰り返し生成 この状態で新しいエラーを修正すると、あるレイヤーの変更が別のレイヤーの前提を崩す可能性がある。ユーザーにはAIが同じところを堂々巡りしているように見えるが、実際にはAIが従うべき単一の構造と検証基準が存在しない状況かもしれない。 React・Next.js・Supabaseの組み合わせを正確に理解する React、Next.js、Supabaseを、単に問題のある組み合わせ型スタックと規定するのは正確ではない。それぞれの技術には、広く利用されている独立した役割と利点がある。 技術 基本的な役割 プロジェクトで決定すべき事項 React ユーザーインターフェースを構成するライブラリ 状態管理、データリクエスト、コンポーネント境界 Next.js ReactベースのフルスタックWebフレームワーク レンダリング方式、サーバー・クライアント境界、キャッシュとAPI構成 Supabase PostgreSQL、認証、ストレージなどを提供するバックエンドプラットフォーム アクセスポリシー、データモデル、セッション処理、サービス権限 Ruby on Rails サーバー中心の統合型Webアプリケーションフレームワーク Railsの規約に沿ったモデル、コントローラー、ジョブ、メールおよびデプロイ構成 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時間で再実装できる条件 次の条件を多く満たすほど、短時間での再実装が可能になる。 必要な画面とユーザーフローがすでに確定している。 主要なデータ項目と関係が整理されている。 デザインを新たに議論せず、既存画面を参考にできる。 リポジトリ、ドメイン、デプロイ環境、外部サービスのアカウントにすぐアクセスできる。 既存データの移行を省略するか、小さなサンプルだけを移せばよい。 決済は、サンドボックスの基本的な成功フローのように狭い範囲に限定する。 Railsとデプロイ環境を理解する担当者がAIの出力をレビューする。 数か月にわたって進めてきた既存プロジェクトが役立つ理由もここにある。その期間にユーザーフロー、必須フィールド、失敗事例と優先順位が具体化されていれば、調査にかかる時間を短縮できる。ただし、企画が自動的に完璧になったという意味ではなく、既存プロジェクトで検証済みの要件だけを再利用すべきである。 実践的な4時間復旧スプリント 時間 作業 最小成果物 0:00~0:30 リポジトリと運用状態の保全、技術スタックの調査 バックアップ、コンポーネント一覧、秘密情報の漏えい確認 0:30~1:00 主要フローとデータモデルの確定、修理・再実装の決定 一文で示した範囲、完了条件、リスク一覧 1:00~2:00 Railsのベースラインまたは既存プロジェクトの構造的修正 実行可能なアプリ、データモデル、認証の骨格 2:00~3:15 主要ユーザーフローの垂直実装 画面からデータ保存までつながった一つのフローとテスト 3:15~3:45 外部連携の最小構成とステージングへのデプロイ サンドボックス連携、デプロイURL、環境変数の構成 3:45~4:00 スモークテストと引き継ぎ 成功・失敗結果、未完了項目、次の作業順序 ステップ1：原本を保全する 修正前にリポジトリの別ブランチまたはコピーを作成し、データベースをバックアップする。AIとの会話にAPIキー、データベースのパスワード、個人識別情報を貼り付けない。すでに漏えいさせた場合は、該当する秘密情報を失効させ、新たに発行するのが安全である。 ステップ2：根拠とともに技術スタックを調査する AIに単に技術スタックを推測させるのではなく、次の資料を確認するよう要求する。 パッケージとバージョンが記録されたマニフェストおよびロックファイル データベーススキーマとマイグレーション 認証とセッションを処理するファイル APIルートとサーバー関数 デプロイ設定、環境変数名、外部サービスのSDK 自動テストと継続的インテグレーションの設定 利用できる依頼例は次のとおりである。 リポジトリを読み、フロントエンド、サーバー、データベース、認証、ストレージ、決済、デプロイ、テストツールを表にまとめよ。各判断の根拠となるファイルパスを記載し、ビジネスルールが重複している箇所と、サーバー・クライアント境界に違反している可能性を示せ。コードはまだ修正せず、秘密の値は出力しないこと。 ステップ3：主要な垂直フローを一つだけ選ぶ 垂直フローとは、画面からサーバーロジックとデータ保存までつながる、一つの完全な経路である。たとえば次のようなものがある。 会員登録 → ログイン → プロフィール表示 商品選択 → 注文作成 → 決済サンドボックス承認 管理者ログイン → 投稿作成 → 公開ページへの表示 一度に複数の画面を作るよりも、主要フロー一つを成功・権限なし・不正な入力という条件で検証する方が、構造上のリスクをより早く明らかにできる。 ステップ4：完了条件をテストで固定する AIに機能実装だけを依頼すると、画面上の成功事例だけに合わせたコードが出てくる可能性がある。最低限、次の条件を自動テストまたは反復可能なチェックリストとして固定する。 正規ユーザーは作業を完了できる。 ログインしていないユーザーは保護されたデータにアクセスできない。 他のユーザーの識別子を入力しても、そのデータにアクセスできない。 不正な入力は保存されず、理解可能なエラーを返す。 同じ決済または書き込みリクエストが繰り返されても重複処理されない。 ステップ5：ステージングまでに限定してデプロイする 4時間スプリントでのデプロイは、一般的に本番確定ではなく、ステージングでの検証と考えるのが安全である。実際のユーザーと決済を受け入れる前に、セキュリティ、データ移行、バックアップ復元、モニタリングと障害対応を別途確認しなければならない。 既存プロジェクトを修正するか作り直すかを決める基準 状況 既存構造の維持・修理 Railsなどによる再実装を検討 主要機能とテスト 大部分が動作し、テストがある 主要フローさえ繰り返し壊れる データ 本番データが多く、移行リスクが高い データがないか、移行範囲が小さい 構造 責任境界とパターンが概ね一貫している 同じ機能が複数のレイヤーに重複している フロントエンド要件 複雑なインタラクションと既存のReact資産が重要 サーバー中心のCRUDと業務フローが中心 チームの能力 現在のスタックを運用できる人材がいる Railsの規約がチームの作業方法により適している 外部連携 多数の安定した連携がすでに運用中 連携が初期段階にあるか、置き換え可能 ファイル数が多い、またはエラーがあるという理由だけで全面的に書き直してはならない。書き直しによって、既存システムで解決済みだった例外的な状況への対応を失い、新しい欠陥を生み出す可能性がある。まずは小さな垂直フローを2つの方式で実装し、開発速度、テスト可能性、コードの理解しやすさ、デプロイリスクを比較するのがよい。 リリース前に別途確認すべき項目 4時間でベースラインが作られても、次の項目が残る可能性がある。 権限モデルとRailsのセキュリティ設定のレビュー 決済Webhookの署名、重複防止、キャンセルと返金の処理 本番データの移行および件数・合計の検証 データベースのバックアップと実際の復元テスト エラー追跡、ログの保存、可用性のモニタリング 負荷テストとコスト見積もり 個人情報の取り扱い、利用規約と関連する法的レビュー アクセシビリティ、ブラウザーおよびモバイル環境の確認 障害発生時のロールバック手順と担当者の指定 結論 バイブコーディングプロジェクトが後半で停滞する理由は、AIのコーディング能力だけでは説明できない。自由度の高い構成で、ルール、責任境界、テスト、運用基準を定めなければ、AIが作った局所的な解決策は互いに衝突しやすい。 Ruby on Railsは、規約と統合された構造を通じて、この自由度を減らす実用的な代替案になり得る。しかし、すべてのプロジェクトをRailsで作り直すことが正解ではない。まず現在のスタックを根拠に基づいて調査し、主要フローを定めたうえで、4時間を完成品の制作時間ではなく、構造を検証し、復旧可能なベースラインを作る時間として使うべきである。 FAQ Q. バイブコーディングのプロジェクトは、最初は速いのに後半になると遅くなるのはなぜですか？ A. 初期には目に見える正常系のフローを作る作業が多い一方、後半には権限、データの一貫性、障害復旧、決済、デプロイ、セキュリティなど、複数のレイヤーをつなぐ問題が集中するためです。構造上のルールとテストがなければ、AIが追加した局所的な修正が既存のコードと衝突し、速度がさらに低下する可能性があります。 Q. React、Next.js、Supabaseの組み合わせを使用すると、必ずスパゲッティコードになりますか？ A. いいえ。3つの技術はそれぞれ明確な役割を持つツールであり、熟練したチームであれば安定したサービスを構築できます。問題になるのは、データアクセス、認証、ビジネスルール、エラー処理の責任範囲を定めないまま、同じ機能を複数のレイヤーで重複して実装するやり方です。 Q. Ruby on Railsに切り替えると、すべての外部サービスが不要になりますか？ A. いいえ。Railsでは、データアクセス、ジョブ処理、メール、リアルタイム通信、テスト、デプロイを一貫した仕組みで扱えますが、決済事業者、メール送信インフラ、クラウドホスティング、モニタリングなどの外部サービスは依然として必要になる場合があります。 Q. アプリ全体を本当に4時間で作り直すことはできますか？ A. 一般的に保証することはできません。要件とデータモデルが確定し、コアフローが非常に限定的で、外部アカウントとデプロイ環境が準備され、熟練者がAIの出力をレビューする場合には、実行可能なベースラインや小規模なMVPを作成できます。本番運用レベルのセキュリティ、決済の例外処理、データ移行、障害対応には通常、追加の時間が必要です。 Q. 既存のコードを捨てて書き直すべき兆候は何ですか？ A. 中核となるビジネスルールが複数の箇所で重複し、小さな修正によって無関係な機能が繰り返し壊れ、自動テストがなく、データがまだ少なくて移行コストが低い場合は、再実装を検討できます。運用データと安定した外部連携が多い場合や、現在の構造にテストがある場合は、段階的な修正のほうが安全な可能性があります。 Q. AIに現在のプロジェクトの技術スタックをどのように調査させればよいですか？ A. パッケージファイル、ロックファイル、データベーススキーマ、認証コード、APIルート、デプロイ設定、テストファイルを読み、技術ごとの役割と根拠となるファイルを表にまとめるよう依頼する必要があります。すぐにコードを修正せず、機密値を出力せず、重複したビジネスルールや境界違反の可能性も示すようにするとよいでしょう。 Q. 4時間の復旧作業で最初に実装すべき機能は何ですか？ A. サービスの価値を代表する中核的なユーザーフローを1つ選ぶ必要があります。画面を作るだけでなく、認証、サーバー側の検証、データ保存、エラー処理までつなぎ、正規ユーザーと権限のないユーザーの条件をテストすることで、構造の妥当性を迅速に判断できます。 Q. Railsを使用すると、セキュリティ上の問題は自動的に解決されますか？ A. いいえ。Railsは複数のセキュリティに関するデフォルト設定や保護機能を提供しますが、権限設定の漏れ、機密情報の漏えい、脆弱な外部連携、誤ったデプロイ設定まで自動的に防止するわけではありません。フレームワークのセキュリティガイドに従い、アプリケーションごとの権限とデータフローを別途確認する必要があります。 Sources - Reactを学ぶ: https://react.dev/learn - Next.jsドキュメント: https://nextjs.org/docs - Supabaseドキュメント: https://supabase.com/docs - Railsのドクトリン: https://rubyonrails.org/doctrine - Ruby on Railsガイド: https://guides.rubyonrails.org/ - Active Jobの基礎: https://guides.rubyonrails.org/active_job_basics.html - Action Mailerの基礎: https://guides.rubyonrails.org/action_mailer_basics.html - Action Cableの概要: https://guides.rubyonrails.org/action_cable_overview.html - Ruby on Railsセキュリティガイド: https://guides.rubyonrails.org/security.html - Railsアプリケーションのテストガイド: https://guides.rubyonrails.org/testing.html Images - 絡み合うシステム接続と整然とした階層構造の間に立つ開発者: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI0OSwicHVyIjoiYmxvYl9pZCJ9fQ==--671c6671ab2b4dd55a12c8db4a32cd95021e1402/ai-ff797ac5.webp - 崩れた崖と安定した基盤を結ぶ橋を修復する開発者と、セキュリティやデプロイのアイコン: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NDI1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--dd1b9b18b3b924f01625710e0b4bafd8fbbd0002/ai-74d32191.webp --- Category: ハウツー Source: https://injoys.com/ja/articles/vibe-coding-project-architecture-and-four-hour-rescue-sprint License: cc_by Translation-Status: reviewed