2025.07.16

AI駆動開発で個人開発するなら、リファクタリングをしろ

AI駆動開発(Vibe Coding)で個人アプリを開発する中で、開発スピードを最大化するための気づきがあったので、共有します!

はじめに

AI駆動開発(Vibe Coding)で個人アプリを開発する中で、開発スピードを最大化するための気づきがあったので、共有します!

一回作って終わりではなく、継続的に新機能を追加していく前提で開発していると、「どうすれば保守性を保ちながら開発スピードを上げられるか?」という課題に直面します。

結論から言うと、リファクタリングこそが、AI駆動開発のボトルネックを解消する方法だと考えています。

AI駆動開発の真のボトルネック

私がAIでコードを作成する際、開発に時間がかかっていたのは以下の二つです:

  1. レビュー
  2. バグ修正

AIは新規コード作成では圧倒的な力を発揮しますが、細かいバグ修正やデグレチェックなどの「細かいチェック」は私たち人間の仕事です。

つまり、この「細かいチェック」の時間をいかに減らすかが開発スピード向上の鍵と考えました。

最重要ポイントは、影響範囲を狭くして、人が細かく確認する量を減らすことです。

AIができる限界を理解する

AIには明確な苦手分野があると考えています。

1. 論理的バグの検出不能

文法上は問題ないが、業務上バグっているコードを検出できません。基本的に文法チェックしかできないため、「業務観点から見たバグ」は見落としがちです。

また、そもそもAIが全てのバグを解決できるとは限りません。

2. 既存コードの修正が苦手

「この実装をこう修正して」というざっくり指示も苦手な印象です。特にフロントエンドでは、文法上は問題ないが実際はバグっている、という状況が頻発していました…

これらの問題が生じた場合は、ほとんどの場合は、人間が確認・修正する必要があると考えています…(2025年7月16日 現在)

なぜリファクタリングが効果的なのか?

答えは単純です。上記2つの工数を削減できるから、になります

具体的な例で説明します!

今回は、既存実装の「A機能」に関連した、「B機能」を追加するケースを考えてみます。

関連機能なので、既存ロジックを使い回す方針とします。

【悪い例】リファクタリングなしの開発

負のスパイラル

  1. B機能をAIで作成 → サクサク完成
  2. A機能にも修正が必要 → B機能追加の影響で既存機能も変更
  3. A機能がデグレ → AIは論理バグを検出できないため、人間がデバッグ
  4. 今度はB機能がデグレ → A機能修正の影響でB機能が壊れる
  5. デバッグ地獄 → AIが作ったB機能の詳細が分からず、コードを隅々まで調査

「AIにバグ修正もやらせればいいじゃん」と思うかもしれませんが、論理バグは文法上問題ないため、人間が修正する必要が度々出てきます。

このループが延々と続くことで、開発効率が著しく低下します。

また、レビュー時も、A機能との共有ロジックの変更が、影響ないかを細かく調べる必要があり、レビュー時の検討事項が増えて負荷が増大します。

【良い例】リファクタリング後の開発

事前にリファクタリングを行った場合は、以下の流れになります。

正のスパイラル

  1. A機能をリファクタリングB機能の追加時、A機能への影響を最小限にする設計に
  2. B機能をAIで作成 → サクサク完成
  3. A機能の修正 → 既に影響範囲を最小限にしているため、影響範囲が小さく、原因切り分けが容易
  4. B機能がデグレ → A機能とB機能に影響のある範囲だけ確認すれば問題なし

結果、A機能やB機能がデグレしたとしても、原因切り分けがすぐに出来るため、バグ修正の負荷が低減します。

また、レビュー時の負荷も、上記の流れであれば、「1. A機能をリファクタリング」の段階で、事前にA機能への影響範囲を確認できているため、「A機能はデグレしていない」という担保がしやすいです。

その結果、B機能のみのレビューに集中することができ、レビューの負荷を減らすことができます。

リファクタリングを先に行った時のメリット

メリット1:影響範囲の限定

「A機能には影響しない」ことがある程度保証されるため、B機能だけをチェックすれば済みます。

メリット2:デバッグの効率化

A機能とB機能で共通部分があっても、「A機能への影響はその共通部分だけ」と特定できるため、デバッグ範囲が明確になります。

メリット3:レビュー品質の向上

影響範囲が限定されているため、レビュー負荷が激減し、その結果「質の高いレビュー」が可能になると考えています。

リファクタリングのベストプラクティス

新機能追加の直前に行う

新機能を追加する前にリファクタリングを実施します。

「新機能が追加しやすくなる」ような設計に変更し、既存機能への影響を最小化する設計(構造)をこのタイミングで作ります。 理想の状態は、「新機能は追加するだけ、他の機能には影響しない」です。

「何をどうリファクタリングするか?」は、人間がコントロール

リファクタリングの方針は人間が決めることが重要です。

AIは「減らす」「整理する」といった作業が苦手な傾向があります。そのため、どうリファクタリングするかは、まだ人間が主導した方が良さそうです。 今後のプロダクトの方向性に合わせた、リファクタリングをしましょう。

機能追加とリファクタリングは分離する

機能追加とリファクタリングは同時にやるな」を徹底します。

同時に行うと、どこでバグったか特定できず、AIが作った理解不十分なコードを延々と調査することになります…(実体験)

まとめ

リファクタリングは一見遠回りに見えますが、AIの得意分野を最大限活用しつつ、人間の負担を最小化する上で、有効な方法だと考えています!

他にも、もっと良い進め方が沢山あると思います、ぜひ教えていただきたいです!


次回、「~~ AI駆動開発で個人開発するなら、設計をしろ ~~ バイブコーディングでのレビュー負荷を低減する方法」編でお会いしましょう!