はじめに
前回は、バイブコーディングにおけるプロンプトの「型（パターン）」を紹介しました。
今回は、「デバッグ」と「リファクタリング」について解説します。
AIを使った開発は速いですが、その分、バグや技術的負債も積み上がります。これらをどのようにコントロールするかが、プロダクトの品質を左右します。
AIとデバッグする
エラーが発生したとき、AIは非常に優秀なパートナーですが、使い方を間違えると迷走します。
エラーログだけでは不十分
よくある失敗は、エラーログだけを渡すことです。
AIは文脈を忘れやすいため、そのエラーが「いつ」「何をしたときに」起きたのかを知りません。
エラーを報告するときは、以下の3点をセットで伝えます。
- 期待した動作: 「保存ボタンを押したら、一覧画面に戻るはずだった」
- 実際の動作: 「何も起きず、コンソールにエラーが出た」
- エラーログ: （ログのコピペ）
これだけで、AIの回答精度が改善されます。
Linter駆動開発
私がよくやるのは、Linter（静的解析ツール）のエラーをAIへのフィードバックとして使う方法です。
AIが書いたコードを貼り付け、Linterが警告を出したら、それをAIに渡します。
「型定義が間違っている」「未使用の変数がある」といった指摘をAIに修正させることで、コードの品質を保てます。
AIとリファクタリングする
機能追加を繰り返すと、コードは徐々に複雑になり、読みづらくなります。
定期的なリファクタリングが必要ですが、ここでも注意が必要です。
リグレッション（先祖返り）のリスク
「このコードを綺麗にして」と頼むと、AIは喜んで書き直してくれますが、既存機能を壊すことがあります。
これを防ぐ方法は、「テストを先に書く」ことです。
この関数のリファクタリングをしたいです。
最初に、現在の挙動を保証するためのテストケースを作成してください。
まずテストを書き、それがパスすることを確認してから、リファクタリングを依頼します。
そうすれば、リファクタリング後にテストを実行するだけで、機能が壊れていないか確認できます。
「説明させる」ことで理解度を測る
もう一つは、修正前にコードを説明させることです。
このコードをリファクタリングしたいです。
最初に、このコードが何をしているか、詳細に説明してください。
AIの説明が間違っていたら指摘し、認識を合わせます。
それから修正を依頼することで、意図しない変更を防げます。
AIが読みやすいコードを書く
「人間にとって読みやすいコード」は「AIにとっても読みやすいコード」です。
- 関数を小さく保つ
- 変数名を明確にする
- 一般的なデザインパターンを使う
これらを意識すると、AIはコードの意図を理解しやすくなり、結果としてより良い提案をしてくれます。
まとめ
- デバッグ時は「期待」と「現実」のギャップを伝える
- LinterのエラーはAIへの良いフィードバックになる
- リファクタリング前には必ずテストを書く（あるいは書かせる）
- AIにコードを説明させて、理解度を確認する
次回は、プロダクトレベルの複雑なロジックをどのように実現するかについて記載します。