AIコーディング
vibe codingのデバッグワークフロー
再現可能なバグレポート、根本原因の分析、回帰テスト、AIコーディング用プロンプト、より安全な修正を使って、vibe codingで構築したアプリをデバッグするための実践的なワークフローです。
vibe codingで構築したアプリのデバッグは、自分で1行ずつ書いたコードのデバッグとは異なります。AIは、確認が追い付かない速さでファイル、状態の流れ、ヘルパー関数、スタイル規則、データに関する前提を作っている可能性があります。修正を急いで依頼すると、ツールが症状だけを取り繕い、2つ目のバグを生む場合があります。
このガイドでは、vibe codingで構築したアプリのための、繰り返し使えるデバッグワークフローを説明します。バグを再現し、動作を切り分け、根本原因を特定し、実用的な場合は回帰テストを追加し、最小限の修正を加え、元のユーザー経路を検証します。目標は、アプリの半分を書き直させずにAIコーディングツールをデバッグへ活用することです。
このガイドの対象者
- AIでプロトタイプを構築し、壊れた動作を修正する必要がある創業者
- ローンチ前にAI生成アプリのコードをレビューする開発者
- AIアプリビルダーを使い、技術レビューに向けてより明確なバグレポートを必要とするデザイナーやオペレーション担当者
- vibe codingで構築したプロトタイプを保守可能なアプリへ変えるプロダクトチーム
- 無作為なリファクタリングを減らすAIデバッグ用プロンプトを求める人
ステップごとのワークフロー
- 開始URL、アカウントの状態、ブラウザ、入力値、期待する結果を含む正確な手順でバグを再現します。
- エラーメッセージ、スクリーンショットの説明、コンソール出力、失敗したテストで実際の結果を記録します。
- 編集前に関連ファイルを調査するようAIに依頼します。
- 壊れた前提、関数、コンポーネント、ルート、クエリ、スタイル規則を具体的に示す根本原因の説明を必須にします。
- 既存の動作を保つ最小限の修正を求めます。
- 実用的な場合は、ルート、検証、データへの書き込み、認証、請求、SEO、重要なUI動作に回帰テストを追加します。
- 対象を絞ったテストまたは手動の再現手順を実行します。
- 無関係なリファクタリング、依存関係の変更、広範な書き直し、環境の変更がないか差分を確認します。
- 修正後に元のユーザー経路をもう一度実行します。
- 次回、似た問題を診断しやすくするため、バグレポートと修正用プロンプトを保存します。
推奨ツール
デバッグ用プロンプトテンプレート
AI生成アプリが正しく動作しないときは、次のプロンプトを使います。
I need to debug this vibe coded app bug: [bug description]. Reproduce the bug from these steps: [steps]. Expected result: [expected]. Actual result: [actual]. Before editing files, inspect the relevant route, component, state, API, and styling code. Explain the root cause in concrete terms. Then propose the smallest fix and the verification command or manual path that proves the bug is fixed. Do not refactor unrelated code or change environment variables.
If this affects behavior, add or update a regression test before implementing the fix. After the fix, summarize the exact files changed and the remaining risk.
バグレポートのチェックリスト
- どのページまたはルートでバグが発生しますか?
- どのユーザー操作がバグを引き起こしますか?
- どのような入力値を使いましたか?
- 問題はビジュアル、状態、API、認証、データ、ビルドのどれに関係していますか?
- どのような結果を期待していましたか?
- 実際には何が起きましたか?
- モバイル、デスクトップ、または両方で発生しますか?
- コンソールエラー、ネットワークエラー、サーバーログ、失敗したテスト、壊れたビルド出力はありますか?
- バグが現れる前に、最近何が変わりましたか?
よくある間違い
- 再現手順を示さず、AIへ"fix this"と依頼する
- 1つの状態条件が間違っているだけなのに、コンポーネント全体をAIに書き直させる
- UIが単純に見えるという理由で、生成されたコードを確認しない
- 本当のバグがデータ構造や条件付きレンダリングにあるのに、スタイル上の症状を修正する
- 元の失敗した経路を実行せずに修正を受け入れる
- 重要なワークフローの回帰テストを省く
- デバッグの近道として環境変数や依存関係を変更する
実践例
弱いプロンプト:the save button does not work, fix it.
改善したプロンプト:on the prompt detail page, clicking Save while signed in shows a success toast but the saved item does not appear in history after refresh. Reproduce the bug with a signed-in user, inspect the save button, API route, persistence helper, and history query. Explain whether the issue is client state, API payload, database write, or history filtering. Add a regression test if the route behavior is wrong, make the smallest fix, then run the targeted test and describe the manual verification path.
改善したプロンプトは、具体的な経路、期待する結果、実際の結果、調査するファイル、根本原因を説明する要件、検証基準をAIへ示しています。
FAQ
Q: バグ修正と同時にAIへリファクタリングさせるべきですか? A: 通常は避けてください。まずバグを修正します。テストまたは明確な手動確認の経路で動作を保護してから、リファクタリングしてください。
Q: バグのテストを書けない場合はどうすればよいですか? A: 正確な手動の再現手順を使います。UIの問題なら、ビューポート、状態、入力値、期待する正確なビジュアル動作を含めてください。
Q: AIが変更するファイルを増やしすぎないようにするにはどうすればよいですか? A: 最初に調査し、根本原因を説明し、最小限の修正を提案するよう伝えます。無関係なリファクタリング、依存関係、マイグレーション、環境の変更を避けるよう指示してください。
Q: vibe codingで構築したアプリのデバッグが混乱しやすいのはなぜですか? A: AI生成コードは、コンポーネント、状態、API呼び出し、スタイルにまたがって前提を隠す場合があります。ツールの進行を抑え、一連の動作を説明させると、デバッグは進めやすくなります。