AI開発2026-08-25

バイブコーディングのデバッグ｜迷走を止める5つの手順

株式会社Atsumell|8分で読めます

はじめに

画面が真っ白になった。AIに「直して」と頼む。修正案が出る。今度はログインが壊れる。もう一度頼むと、最初に直した箇所まで元に戻る。

バイブコーディングで怖いのは、最初のバグではない。直すたびに問題の形が変わり、何を検証しているのか分からなくなることだ。

AIは修正を速く提案できる。一方で、見えていない実行環境や直前の変更を推測で補う。材料が足りないまま会話を続ければ、もっともらしい変更が増えていく。

デバッグを立て直すには、プロンプトを工夫する前に証拠をそろえる。ここでは、迷走した調査を5つの手順で立て直す。

1. 症状ではなく再現条件を固定する

「動きません」だけでは、AIも人間も原因を絞れない。最初に、同じ失敗を繰り返せる状態を作る。

最低限、次の6点を一組にする。

実行したコマンドや操作
入力した値
期待した結果
実際の結果
エラー全文とスタックトレース
実行環境と対象のコミット

たとえば「保存できない」では情報が足りない。「管理者で商品名を空欄にして保存すると、HTTP 500になり、サーバーログのこの行で例外が出る」と書けば、調べる入口ができる。

MistralのVibe Codeドキュメントも、失敗したテストやスタックトレースを渡し、関連する文脈を読ませる使い方を示している。エラーを要約しすぎないのがコツだ。途中の警告や呼び出し元に原因が残っている場合がある。

再現しないバグなら、発生時刻、利用者の権限、端末、入力、直前の操作を記録する。画面録画だけで終えず、サーバーログやリクエストIDと結び付けたい。

ここで一度、再現手順を別の人が読んで実行できるか確認する。できなければ、AIへ渡すにはまだ早い。

2. 直前の差分を小さく切る

次に見るのはコード全体ではなく、最後に正常だった状態からの差分だ。

バイブコーディングでは、一つの依頼で複数ファイルが変わりやすい。認証エラーを直す依頼なのに、画面、API、データ型、設定まで書き換わることもある。この状態で追加修正を重ねると、原因候補が掛け算で増える。

まず変更を役割ごとに分ける。

表示だけの変更
業務ロジックの変更
データ構造や移行の変更
認証・権限の変更
依存関係や環境設定の変更

そして、問題と関係の薄い差分を検証対象から外す。元に戻す場合も、作業中の成果を丸ごと捨てない。小さなコミットや作業用の退避先を作り、どの差分で症状が出たか比較できるようにする。

AIへの依頼も狭くする。「全部直して」ではなく、「この失敗テストを通すために、対象関数と直接の呼び出し元だけを調査し、変更前に原因仮説を示して」と頼む。変更可能なファイルを明示すると、無関係な書き換えを抑えやすい。

CloudflareのAI Vibe Coding Platform構成は、AI生成コードを信頼済みとみなさず、隔離された環境で実行する前提を置いている。そこから実務へ置き換えると、本番データや本番権限から離した再現環境は、条件を固定する場所としても使える。

3. AIには修正案より原因仮説を出させる

いきなりコードを書き換えさせると、当たったか外れたかを判断しにくい。先に原因仮説を並べ、各仮説をどの証拠で否定できるか聞く。

依頼文は次の形にすると扱いやすい。

> 期待値、実測値、再現手順、エラー全文、直前差分を示します。原因候補を最大3つに絞り、それぞれ確認するログまたはテストを提案してください。まだコードは変更しないでください。

見るべきなのは、説明の滑らかさではない。仮説と証拠が対応しているかだ。

たとえば「キャッシュが原因」と言うなら、キャッシュを無効化した場合の観測結果を決める。「権限不足」と言うなら、失敗した主体、必要権限、拒否ログを確認する。どの結果でも説明できる仮説は、検証可能な仮説ではない。

一つ確認するたびに、残った候補を更新する。新しいエラーが出たら、古い会話へ継ぎ足すだけでなく、現在のコード、現在のエラー、確認済みの事実を短く再提示する。How to Vibe Codeのデバッグ手引きでも、修正後は変化したエラーと現在の状態を渡し直すことが勧められている。

同じ仮説で2回修正しても改善しないなら、会話を続けるより切り分けをやり直す。モデルを替える前に、最小構成で再現するか、入力を固定できるか、外部サービスを模擬できるかを確認したい。

4. 修正と同時に失敗テストを残す

目視で直っただけでは、次の変更で同じバグが戻る。修正前に失敗し、修正後に成功するテストを残す。

テストは大きく始めなくてよい。

関数の入出力が原因なら単体テスト
API間の契約が原因なら結合テスト
権限や画面遷移が原因なら操作テスト
本番だけの差なら設定検証や監視条件

重要なのは、テスト名に業務上の期待を書くことだ。「test case 3」ではなく、「閲覧者は請求書を更新できない」「同じ処理IDの再送で注文が増えない」とする。修正前に失敗し、修正後に通ることを確認したら、対象の仕様や受け入れ条件と一緒に保存する。何を守るテストなのか、後から読んでも分かる。

バイブコーディングで作ったコードの品質保証でも扱った通り、生成速度と検証責任は別物だ。AIがテストを書いた場合は、実装と同じ誤解をテストにも複製していないか確認する。正常系だけでなく、空値、境界値、権限違い、再試行、外部サービス停止を含める。

研究報告でも、バイブコーディングは生成、結果の評価、アプリケーションテスト、手動編集を往復し、デバッグは人とAIの混成作業になると整理されている（Vibe coding: programming through conversation with artificial intelligence）。AIへ任せる範囲より、誰が結果を受け入れるかを決める方が先だ。

5. 直せない条件と引き継ぎ材料を決める

すべてのバグを同じ会話で直そうとしない。時間と変更回数に上限を置く。

たとえば、次のどれかに当たったらエスカレーションする。

同じ原因仮説で2回修正しても再現する
認証、決済、個人情報、権限に触れる
データ移行や削除を伴う
再現条件が固定できない
変更範囲が当初の想定を超える

人へ渡すときは、「AIが直せませんでした」だけでは足りない。再現手順、期待値と実測値、エラー全文、試した仮説、否定できた原因、現在の差分、失敗テストを一つの束にする。SIer案件なら、開発担当は技術原因、レビュー担当は変更範囲、顧客側の責任者は業務上の受け入れ可否を確認する。役割を分ければ、引き継いだ人が同じ調査を繰り返さずに済む。

バイブコーディングに必要な設計書で整理した仕様の境界も、ここで効く。機能の目的、禁止条件、入出力、責任範囲が残っていれば、「動いたように見える修正」が本来の仕様を壊していないか判断できる。

デバッグ記録は長文の日記にしなくてよい。次の表を埋めれば十分だ。

項目	記録する内容
再現	操作、入力、環境、対象コミット
期待	業務上の正しい結果
実測	エラー、ログ、画面、応答
仮説	原因候補と確認方法
差分	変更したファイルと理由
検証	修正前に失敗し、修正後に通るテスト
判断	続行、切り戻し、人への引き継ぎ