AIで爆速開発した結果、技術的負債が爆発した話

結論: AI爆速開発は、設計とレビューを怠ると負債を10倍速で生む

2025年、あるBtoB SaaSで6ヶ月で機能数を5倍にしたチームがありました。AI爆速開発の成功例として社内で称賛されましたが、半年後に状況は一変。本記事では、AIで作りすぎた結果、技術的負債が爆発した実話と、そこから得た教訓を共有します。同じ轍を踏まないために、ぜひ読んでいただきたい体験談です。

この記事でわかること:

• AI爆速開発で負債が膨らむメカニズム
• 負債爆発の前兆と気づくタイミング
• 実施した返済プロセスとコスト
• AI時代の負債管理の指針

背景: 競合に勝つための爆速モード

SaaSはB2Bマーケティング自動化ツールで、競合がVC調達で機能拡張を加速していました。経営判断で「AIをフル活用して機能数で勝負」と決まり、エンジニア6名でフル稼働が始まりました。1スプリント (1週間) で5〜7機能をリリースし、リリースペースは従来の4倍に達しました。

負債が積み上がるメカニズム

1. レビューの簡略化

あまりに多くのPRが上がるため、人間レビューがついていけなくなりました。「AIが書いたから動くだろう」と、テストが通れば即マージするケースが増えました。

2. 設計議論の省略

「とにかく動くものを」という空気で、設計レビューが行われなくなりました。同じデータを違う場所で違うスキーマで持つ、似た機能が3カ所に重複実装される、といった事態が頻発しました。

3. 共通化の放棄

AIが個別のファイルでパーフェクトに書いてくれるため、共通化への意識が希薄になりました。同じバリデーションロジックがコードベース内に12カ所存在するという惨状になりました。

4. テストの偏り

AIはハッピーパスのテストは大量に書きますが、境界値や異常系のカバレッジは人間が指示しないと薄くなります。テスト件数は増えるのに、本番障害は減らないという矛盾が発生しました。

負債爆発の前兆

• 新機能追加にかかる工数が急に増え始めた (倍以上)
• 1機能の変更が10カ所以上のファイルに波及するようになった
• 本番障害の頻度が月3件から月12件に増加
• 新人のオンボーディング期間が2倍に
• マイグレーション失敗が連発

とくに新機能追加の工数増加は、AI爆速開発のメリットを完全に打ち消し始めました。「速く作ったほうが、結局遅い」という現実が立ち現れたのです。

気づいたタイミング

致命的だったのは、本番で発生したマイグレーション事故です。同じカラム名が3つの異なるテーブルで意味が異なって使われており、データ移行スクリプトが意図しないテーブルを破壊しました。復旧に16時間、顧客への影響は3社。この事故で経営も含めて全員が「これはダメだ」と認識しました。

返済プロセス

Phase 1: 棚卸し (2週間)

全機能、全テーブル、全APIエンドポイントを棚卸し、重複と矛盾をスプレッドシートで可視化しました。不要・重複と判定された機能は全体の22%に達しました。

Phase 2: 削除と統合 (6週間)

機能フラグで段階的に旧実装を無効化し、利用ログで本当に使われていないと確認した機能から順次削除。共通化が必要なドメインロジックは、AIに「全体を見て統合案を提示」させ、人間がレビューして適用しました。

Phase 3: 設計原則の再構築 (継続)

以下のルールをチーム憲法として定めました。

• 全PRに最低1名の人間レビュー必須 (AIレビューは補助)
• 新機能は設計ドキュメント (1ページADR) を必ず先に書く
• 境界値・異常系のテストを必ず含める
• 共通化候補は週1の振り返りで議論
• 負債リファクタの時間をスプリント工数の20%確保

返済にかかったコスト

• 機能削除と統合: エンジニア6名×2ヶ月
• テスト整備: 約400時間
• 本番事故での顧客対応: 推定800万円相当の信頼損失
• 失った機会コスト: 競合に対する優位がほぼリセット

爆速で稼いだ時間が、利息付きで返ってきた形です。

得られた教訓

1. AIは「コードを書く速度」を上げるが、「設計の質」は上げない
2. レビューを省略するなら、AIで書いた意味がない
3. 負債は静かに、しかし指数関数的に増える
4. 「速い」は短期、「健全な速さ」は長期の指標

AI時代の負債管理指針

• レビューはAIではなく人間が最終責任を持つ
• 設計ドキュメント (ADR) を必ず先に書く
• 「重複を許さない」運用ルールを明示
• 四半期に1度、棚卸しの時間を確保
• 負債が見え始めたら、機能追加を一時停止する勇気

まとめ

AIによる爆速開発は、設計とレビューが追いつかないと従来の10倍速で負債を生み出します。速さは強力な武器ですが、それを支える設計原則とレビュー体制があってこそ意味があります。2026年のAI開発では、「速く作る」よりも「健全に速い」状態を目指してください。爆速の落とし穴は、誰にでも降りかかります。