バイブコーディングで生まれた技術的負債をどうリファクタリングするか
バイブコーディングの「その後」を誰も語らない
バイブコーディングの記事は世の中に溢れている。「30分でアプリを作った」「ノーコードの次はバイブコーディングだ」。華やかな成功談ばかりだ。
だが、その3ヶ月後にコードベースがどうなったかを語る人は驚くほど少ない。
我々はクライアントのプロジェクトを通じて、その「3ヶ月後」を何度も見てきた。結論から言えば、バイブコーディングで生まれたコードの多くは、放置すれば半年以内に保守不能になる。
バイブコーディングの3ヶ月の壁で詳しく分析したように、AIが生成するコードには構造的な問題がある。ファイル間の責務が曖昧、命名が一貫しない、テストがない。動いてはいるが、誰も全体像を把握していない。
ではどうするか。捨てて作り直すのか。それとも、救う方法があるのか。
この記事では、バイブコーディングで生まれたコードベースを実用的にリファクタリングするための戦略を解説する。
---
なぜバイブコーディングのコードは負債化するのか
リファクタリング戦略の前に、問題の構造を理解しておこう。
バイブコーディングでは、開発者がAIに自然言語で指示を出し、AIが即座にコードを生成する。このプロセスには3つの構造的な問題がある。
1. 設計判断の記録が残らない
「ユーザー認証を追加して」と指示したとき、AIは何らかの方法で認証を実装する。JWTなのかセッションなのか、リフレッシュトークンの戦略は何か。AIは黙って判断し、コードを書く。
その判断の根拠がどこにも残らない。3ヶ月後に「なぜこ の実装になっているのか」を誰も説明できない。
2. 局所最適の積み重ね
AIは指示されたタスクを最短距離で解決しようとする。「決済機能を追加して」と言えば、決済だけを見て最適なコードを書く。だが、その実装が認証やユーザー管理とどう整合するかは考慮しない。
機能を追加するたびに、コードベース全体の整合性が少しずつ崩れていく。
3. テストなき実装
バイブコーディングの速さは、テストを書かないことで成り立っている部分が大きい。動作確認はブラウザで手動で行い、「動いた」で次に進む。
テストがないコードのリファクタリングは、セーフティネットなしの綱渡りだ。
---
5ステップのリファクタリング戦略
ここからが本題だ。我々がクライアントのプロジェクトで実践してきた、バイブコーディング後のリファクタリング戦略を紹介する。
ステップ1：現状のコードから「逆仕様書」を作る
通常の開発では、仕様書を書いてから実装する。だがバイブコーディング後のリファクタリングでは逆になる。既にあるコードから仕様書を起こすのだ。
これは仕様駆動開発（SDD）の考え方を逆向きに適用したアプローチだ。
具体的には、AIに既存コードを読ませて以下を抽出する。
- 機能一覧: このコードは何ができるのか
- データフロー: データはどこからどこへ流れるのか
- 依存関係: どのモジュールがどのモジュールに依存しているのか
- 暗黙の設計判断: なぜこの実装方法が選ばれたのか（推測を含む）
この「逆仕様書」が、リファクタリングの地図になる。地図なしにコードをいじり始めるのは、知らない街を目的地なしに歩くのと同じだ。
ステップ2：テストで現在の動作を固定する
リファクタリングの鉄則は、「動作を変えずに構造を変える」こと。そのためには、現在の動作を保証するテストが不可欠だ。
ここでもAIを活用する。ステップ1で作った逆仕様書をベースに、AIに「現在の動作を保証するテスト」を生成させる。
ポイントは、理想的なテストを書こうとしないこと。今のコードの動作をそのまま記録する スナップショット的なテストでいい。リファクタリングの過程で何かが壊れたとき、すぐに気づけることが目的だ。
ステップ3：責務の境界を引き直す
逆仕様書とテストが揃ったら、コードの構造に手を入れる。最優先は責務の境界の整理だ。
バイブコーディングで生まれたコードの最大の問題は、1つのファイルやコンポーネントが複数の責務を持っていることが多い点にある。認証処理の中にUI表示のロジックが混じっている。データ取得と加工と表示が1つの関数に詰め込まれている。
これを、明確な境界を持つモジュールに分離する。
この段階では、AIに「このコードを責務ごとに分離して」と丸投げするのではなく、仕様書に基づいて「認証はこのモジュール、データ取得はこのモジュール」と人間が方針を決め、AIに実装させるのが重要だ。
AIツールはなぜ上流に向かうのかで書いたように、設計判断は人間の仕事であり、その判断を正確に実装に落とすのがAIの仕事だ。
ステップ4：命名とインターフェースを統一する
責務の分離ができたら、次は命名規則とインターフェースの統一だ。
バイブコーディングでは、機能追加のたびに異なるプロンプトでコードを生成するため、命名規則がバラバラになりやすい。`getUserData`と`fetchUserInfo`と`loadUserProfile`が同じコードベースに共存している、といった状況が頻発する。
これはAIが最も得意とする作業の1つだ。「このコードベース全体で、以下の命名規則に統一して」と指示すれば、高い精度で一括変換できる。
ただし、一度に全部変えようとしないこと。モジュール単位で変更し、ステップ2のテストを通してから次に進む。
ステップ5：仕様書を「正」として管理体制を敷く
リファクタリングが完了したら、ステップ1で作った逆仕様書を正式な仕様書に昇格させる。以後の開発は、この仕様書を起点にして進める。
ここが最も重要なポイントだ。リファクタリングは一度やれば終わりではない。仕様書なしに開発を続ければ、同じ問題が再発する。
バイブコーディング vs SDDで解説したように、仕様書を起点にした開発フローに移行することで、「動くけど触れない」コードの再発を防げる。
---
リファクタリングすべきか、作り直すべきか
正直に言えば、リファクタリングが正解でないケースもある。判断基準はシンプルだ。
リファクタリングが有効なケース:
- コアのビジネスロジックが正しく動いている
- ユーザーが既に使っており、データが蓄積されている
- 問題が構造（ファイル分割、命名、テスト不足）に限定されている
作り直しが有効なケース:
- ビジネスロジック自体に根本的な誤りがある
- 技術選定が根本的に間違っている（スケールしないDB、合わないフレームワーク）
- コード量が少なく、作り直しても1〜2週間で終わる
多くの場合、バイブコーディングで作ったプロトタイプは前者に該当する。動作自体は正しいが、構造が破綻しているのだ。これは仕様書を軸にしたリファクタリングで救える。
---
AIでリファクタリングするときの落とし穴
AIを使ったリファクタリングには、特有の落とし穴がある。
一度に大きく変えすぎる。 AIに「このプロジェクト全体をリファクタリングして」と指示すると、AI は喜んで全ファイルを書き換える。だが、その変更が正しいかを人間が検証するのは不可能に近い。小さな単位で変更し、毎回テストを通すこと。
AIの提案を鵜呑みにする。 AIは「ベストプラクティス」を提案するのが得意だが、そのプロジェクトの文脈を完全に理解しているわけではない。AIの提案は参考にしつつ、採用するかどうかは仕様書と照らし合わせて人間が判断する。
リファクタリングと機能追加を同時にやる。 「ついでにこの機能も追加して」が最大の敵だ。リファクタリングと機能追加は必ず別のフェーズとして分ける。
---
仕様書があれば、次のリファクタリングはもっと楽になる
バイブコーディングで素早くプロトタイプを作り、ユーザーの反応を見てから仕様書を整備し、リファクタリングで品質を上げる。このサイクルを回せるようになれば、スピードと品質の両立が可能になる。
重要なのは、リファクタリングを「後片付け」ではなく、開発プロセスの一部として設計することだ。
SDDの入門ガイドで紹介しているcc-sddを使えば、仕様書の作成からAIへの実装指示までをシームレスに行える。最初からSDDで始めるのが理想だが、既にバイブコーディングで作ったコードがあるなら、この記事で紹介した戦略でリカバリーできる。
---
まとめ
バイブコーディングは悪ではない。素早く仮説を検証するための強力な手段だ。問題は、バイブコーディングで作ったコードを「そのまま」本番運用し続けることにある。
リファクタリングの戦略を整理しよう。
- 逆仕様書を作り、コードの全体像を可視化する
- テストで現在の動作を固定する
- 責務の境界を引き直す
- 命名とインターフェースを統一する
- 仕様書を正として管理体制を敷き、再発を防ぐ
この5ステップを踏めば、バイブコーディングの速さを活かしつつ、保守可能なコードベースを維持できる。
---
AIネイティブな開発体制を構築したい方へ
株式会社Atsumellは、バイブコーディングの先にある「仕様駆動開発（SDD）」の実践を支援しています。
- Kakusill（AI仕様書エディタ）: 既存コードからの逆仕様書生成、仕様書を起点としたAI開発を実現
- AIエージェント: リファクタリング計画の策定から実行まで、AIが開発チームの一員として参加
- アツメルプラットフォーム: AI開発に対応したパートナーとのマッチング
「バイブコーディングで作ったコードをどうにかしたい」というご相談も歓迎です。
