2025.07.16
AI駆動開発で個人開発するなら、リファクタリングをしろ
AI駆動開発(Vibe Coding)で個人アプリを開発する中で、開発スピードを最大化するための気づきがあったので、共有します!
はじめに
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駆動開発で個人開発するなら、設計をしろ ~~ バイブコーディングでのレビュー負荷を低減する方法」編でお会いしましょう!