AI駆動開発で個人開発するなら、リファクタリングをしろ
はじめに
AI駆動開発（Vibe Coding）で個人アプリを開発する中で、開発スピードを最大化するための気づきがあったので、共有します！
一回作って終わりではなく、継続的に新機能を追加していく前提で開発していると、「どうすれば保守性を保ちながら開発スピードを上げられるか？」という課題に直面します。
結論から言うと、リファクタリングこそが、AI駆動開発のボトルネックを解消する方法だと考えています。
AI駆動開発の真のボトルネック
私がAIでコードを作成する際、開発に時間がかかっていたのは以下の二つです：
- レビュー
- バグ修正
AIは新規コード作成では圧倒的な力を発揮しますが、細かいバグ修正やデグレチェックなどの「細かいチェック」は私たち人間の仕事です。
つまり、この「細かいチェック」の時間をいかに減らすかが開発スピード向上の鍵と考えました。
最重要ポイントは、影響範囲を狭くして、人が細かく確認する量を減らすことです。
AIができる限界を理解する
AIには明確な苦手分野があると考えています。
1. 論理的バグの検出不能
文法上は問題ないが、業務上バグっているコードを検出できません。基本的に文法チェックしかできないため、「業務観点から見たバグ」は見落としがちです。
また、そもそもAIが全てのバグを解決できるとは限りません。
2. 既存コードの修正が苦手
「この実装をこう修正して」というざっくり指示も苦手な印象です。特にフロントエンドでは、文法上は問題ないが実際はバグっている、という状況が頻発していました...
これらの問題が生じた場合は、ほとんどの場合は、人間が確認・修正する必要があると考えています...(2025年7月16日 現在)
なぜリファクタリングが効果的なのか？
答えは単純です。上記2つの工数を削減できるから、になります。
具体的な例で説明します！
今回は、既存実装の「A機能」に関連した、「B機能」を追加するケースを考えてみます。
関連機能なので、既存ロジックを使い回す方針とします。
【悪い例】リファクタリングなしの開発
負のスパイラル
- B機能をAIで作成 → サクサク完成
- A機能にも修正が必要 → B機能追加の影響で既存機能も変更
- A機能がデグレ → AIは論理バグを検出できないため、人間がデバッグ
- 今度はB機能がデグレ → A機能修正の影響でB機能が壊れる
- デバッグ地獄 → AIが作ったB機能の詳細が分からず、コードを隅々まで調査
「AIにバグ修正もやらせればいいじゃん」と思うかもしれませんが、論理バグは文法上問題ないため、人間が修正する必要が度々出てきます。
このループが延々と続くことで、開発効率が著しく低下します。
また、レビュー時も、A機能との共有ロジックの変更が、影響ないかを細かく調べる必要があり、レビュー時の検討事項が増えて負荷が増大します。
【良い例】リファクタリング後の開発
事前にリファクタリングを行った場合は、以下の流れになります。
正のスパイラル
- A機能をリファクタリング → B機能の追加時、A機能への影響を最小限にする設計に
- B機能をAIで作成 → サクサク完成
- A機能の修正 → 既に影響範囲を最小限にしているため、影響範囲が小さく、原因切り分けが容易
- B機能がデグレ → A機能とB機能に影響のある範囲だけ確認すれば問題なし
結果、A機能やB機能がデグレしたとしても、原因切り分けがすぐに出来るため、バグ修正の負荷が低減します。
また、レビュー時の負荷も、上記の流れであれば、「1. A機能をリファクタリング」の段階で、事前にA機能への影響範囲を確認できているため、「A機能はデグレしていない」という担保がしやすいです。
その結果、B機能のみのレビューに集中することができ、レビューの負荷を減らすことができます。
リファクタリングを先に行った時のメリット
メリット1：影響範囲の限定
「A機能には影響しない」ことがある程度保証されるため、B機能だけをチェックすれば済みます。
メリット2：デバッグの効率化
A機能とB機能で共通部分があっても、「A機能への影響はその共通部分だけ」と特定できるため、デバッグ範囲が明確になります。
メリット3：レビュー品質の向上
影響範囲が限定されているため、レビュー負荷が激減し、その結果「質の高いレビュー」が可能になると考えています。
リファクタリングのベストプラクティス
新機能追加の直前に行う
新機能を追加する前にリファクタリングを実施します。
「新機能が追加しやすくなる」ような設計に変更し、既存機能への影響を最小化する設計(構造)をこのタイミングで作ります。
理想の状態は、「新機能は追加するだけ、他の機能には影響しない」です。
「何をどうリファクタリングするか？」は、人間がコントロール
リファクタリングの方針は人間が決めることが重要です。
AIは「減らす」「整理する」といった作業が苦手な傾向があります。そのため、どうリファクタリングするかは、まだ人間が主導した方が良さそうです。
今後のプロダクトの方向性に合わせた、リファクタリングをしましょう。
機能追加とリファクタリングは分離する
「機能追加とリファクタリングは同時にやるな」を徹底します。
同時に行うと、どこでバグったか特定できず、AIが作った理解不十分なコードを延々と調査することになります...(実体験)
まとめ
リファクタリングは一見遠回りに見えますが、AIの得意分野を最大限活用しつつ、人間の負担を最小化する上で、有効な方法だと考えています！
他にも、もっと良い進め方が沢山あると思います、ぜひ教えていただきたいです！
次回、「~~ AI駆動開発で個人開発するなら、設計をしろ ~~ バイブコーディングでのレビュー負荷を低減する方法」編でお会いしましょう！
Discussion
ためになりました！次回を楽しみにしています
コメントありがとうございます！
次回も頑張って作成します！
バイブコーディング作って終わりがちだったのですが、いじり始めるとノーコードでは限界が出て最近コード学習の必要性を痛感します。
コメントありがとうございます！
そうですよね…
「痒いところに手が届かない」は、誰もが感じてると思います…
理想は、AIにエラーの原因や対処法を聞いた際、その回答の内容が理解できるレベルまで行けると、かなり楽になると思います…
（それが難しいのですが…😭）
エンジニアであれば、「そのバグ自体を出しにくくするには、どうしたらいいか？」などを考えて、コードの書き方やファイル構成などを工夫できると、ベストだと思います！
テストはどんな感じでやってますでしょうか?
コメントありがとうございます！
テストコードと、動作確認時のテストの二つの観点から、回答します！
テストコード
単体テスト、結合テストは、基本的に全て作成しています！
（特に単体テストは、必ず作ってます）
コードもAIに作らせています。ある程度、網羅したテストを作ってくれるので、信頼して大丈夫だと思います。
ただ、エッジケースは漏れがちな印象です。数値計算ロジックなど、厳密な計算が必要な場合は、テストケースを具体的に指示したりしてます！
E2Eテストは、僕の個人開発アプリでは導入してます。
ただ、アプリの規模次第によりますが、無理してE2Eテストは導入しなくていいと思います。（テストのメンテコストや、CIの時間が伸びるコストに見合ったメリットが得られない）
ただ、E2Eテストの導入自体は、AIを使えば簡単にできるので、ひとまず作成する価値はあると思います！
動作確認時のテスト
フロントエンドの開発時は、PlayWightMCPを使っています。
PlayWightMCPは、AIにWEBブラウザを操作させるためのMCPです。
実際にアクセスする時のURL等と、操作させる内容を指示すると、AIにWEBブラウザ上で動作確認を行わせることが出来ます。
これにより、そもそもビルドエラーが出ていれば、その修正をしてくれます。
また、挙動に問題がないか？もAIがテストし、正しく動いてない場合は、修正してくれます。
ただ、スタイルのデグレなどは検知できないので、あくまで「ロジックは問題ないか？」を判定するものになります。
バックエンドの実装は、TDDなど先にテストケースを作成する方法も有効です！
上記の回答でよろしいでしょうか？
もし疑問点や不明点があれば、教えて頂きたいです！
返信ありがとうございます。
テストはリファクタリングとセットだと思ってるので、当然やってるだろうと思うも、
記載がなかったので念の為質問しました。
イメージできました。ありがとうございました。