AIによるコードレビューやリファクタリングは魔法ではありません。むしろ、ドメイン知識を持たないAIの「もっともらしいクリーンコードの提案」を鵜呑みにすると、システムは根底から崩壊してしまうと感じています。
全体で20万行と60万行規模の2つのプロジェクトにおいて、デモ直前にAIの指摘に従ってリファクタリングを実施した結果、システムが完全に動かなくなり、残業を伴うデスマーチに発展した失敗談と教訓を共有します。
課題の背景：AIによる「完璧な」レビューへの過信
あるプロジェクトで、画面遷移、保存処理（排他制御含む）、ローカルへのインポート/エクスポート、そして DBContext のリファクタリングをAIに依頼しました。
AIからは、非常に「教科書的で美しい」指摘が返ってきました。
* 「セキュリティと責務分割の観点から、クラスやインターフェースを小さく分割すべき」
* 「画面遷移のコードはパラメータ化したほうが良い」
* 「保存処理が肥大化しているため、クラスを分割すべき」
これらの指摘はアーキテクチャの原則に照らし合わせれば正論であり、実際に単体テストも通っていたため、私は多少油断して修正をマージしてしまった。
発生した悲劇（テストをすり抜けた崩壊）
いざ動かしてみると、システムは信じられないほど壊れていました。ビックリするレベルです。
- ログイン直後に画面遷移が死ぬ
パラメータ化して綺麗になったはずの画面遷移が、ログイン直後の時点で全く動かなくなりました。 - インポート/エクスポートの権限エラー
SQL Expressを使用していたデータ処理で、テーブルの権限周りの例外が突然発生し始めました。 - DI登録漏れによる即死例外
AIの提案でDBContextを綺麗にクラス分割した結果、複数のDI（依存性の注入）登録が漏れており、デバッグ起動直後に即座に例外を起こしました。
最大の罠：「ドメインルール」を破壊するリファクタリング
最も致命的だったのは、保存処理の分割です。
このプロジェクトには「一気に複数テーブルを保存する（A画面とB画面の編集内容を、C画面で一括保存する）」という、プロジェクト特有のルール（醍醐味的な処理）が存在しました。
しかしAIは、この肥大化した処理を見て「単一責任の原則に反している」と判断したのか、私の意図を無視し、「開いている画面のデータだけを保存する処理」へと勝手に書き換えてしまっていた。
結果、C画面で保存ボタンを押しても、C画面のデータしか保存されないという致命的な業務バグを生み出しました。「これは嫌だ」とルールにも書いていたのに、です。
結論と教訓
デモ間近だったこともあり、急いで修正することになり、残業が発生しました。あまりの理不尽な壊れっぷりと焦りから、思わずAIへのプロンプトに「クソが」と書き込んで八つ当たりしてしまったほどです。
この地獄から得た教訓は以下の3つです。
- イベント前（デモ前）に大きな改修をしてはいけない
基本中の基本ですが、少しずつ進めてテストもある状態だったのに、ここまで壊れるとは思いませんでした。 - 「良さそうな提案」だからと短絡的に取り入れない
リファクタリングもレビュー内容も吟味して「良くなるなら実施しよう」と短絡的にやるのはダメだなと強く感じました。AIはドメインの背景を知りません。 - 1日に少しずつ進める慎重さを持つ
AIがあるからといって慢心せず、「1日にちょっとだけリファクタリングする」という人間のペースと慎重さが必要です。
コメント