AIの「もっともらしいクリーンコードの提案」を採用したら、ログイン直後の画面遷移が止まり、DBContextの分割ではDI登録漏れの例外も出ました。プロジェクト固有のルールまで壊れていて、ビックリするレベルでした。
全体で20万行と60万行規模の2つのプロジェクトにおいて、デモ直前にAIの指摘に従ってリファクタリングを実施した結果、システムが完全に動かなくなり、残業を伴うデスマーチに発展した失敗談と教訓を共有します。
課題の背景：AIによる「完璧な」レビューへの過信
あるプロジェクトで、画面遷移、保存処理（排他制御含む）、ローカルへのインポート/エクスポート、そして DBContext のリファクタリングをAIに依頼しました。
AIからは、非常に「教科書的で美しい」指摘が返ってきました。
* 「セキュリティと責務分割の観点から、クラスやインターフェースを小さく分割すべき」
* 「画面遷移のコードはパラメータ化したほうが良い」
* 「保存処理が肥大化しているため、クラスを分割すべき」
これらの指摘はアーキテクチャの原則に照らし合わせれば正論であり、実際に単体テストも通っていたため、私は多少油断して修正をマージしてしまった。
発生した悲劇（テストをすり抜けた崩壊）
いざ動かしてみると、システムは信じられないほど壊れていました。ビックリするレベルです。
- ログイン直後に画面遷移が死ぬ
パラメータ化して綺麗になったはずの画面遷移が、ログイン直後の時点で全く動かなくなりました。 - インポート/エクスポートの権限エラー
SQL Expressを使用していたデータ処理で、テーブルの権限周りの例外が突然発生し始めました。 - DI登録漏れによる即死例外
AIの提案でDBContextを綺麗にクラス分割した結果、複数のDI（依存性の注入）登録が漏れており、デバッグ起動直後に即座に例外を起こしました。
最大の罠：「ドメインルール」を破壊するリファクタリング
最も致命的だったのは、保存処理の分割です。
このプロジェクトには「一気に複数テーブルを保存する（A画面とB画面の編集内容を、C画面で一括保存する）」という、プロジェクト特有のルール（醍醐味的な処理）が存在しました。
しかしAIは、この肥大化した処理を見て「単一責任の原則に反している」と判断したのか、私の意図を無視し、「開いている画面のデータだけを保存する処理」へと勝手に書き換えてしまっていた。
結果、C画面で保存ボタンを押しても、C画面のデータしか保存されないという致命的な業務バグを生み出しました。「これは嫌だ」とルールにも書いていたのに、です。
結論と教訓
当時は単体テストの通過を見て、修正をマージしました。同じ改修をもう一度受け入れるなら、テスト結果に加えて、今回壊れた次の操作と結果まで確かめたいです。
- 起動とログインを通し、DIで分けたクラスを実際の画面遷移から呼び出せるか。
- インポートとエクスポートを実際の利用条件で動かし、権限エラーが出ないか。
- AとBの両画面で値を変え、Cから一括保存した後も、A・B・Cそれぞれの値が保存されているか。
C画面の保存ボタンが動くことに加え、AとBで変更した値も保存されているかを見る必要があります。
デモ間近だったこともあり、急いで修正することになり、残業が発生しました。あまりの理不尽な壊れっぷりと焦りから、思わずAIへのプロンプトに「クソが」と書き込んで八つ当たりしてしまったほどです。
この地獄から得た教訓は以下の3つです。
- イベント前（デモ前）に大きな改修をしてはいけない
基本中の基本ですが、少しずつ進めてテストもある状態だったのに、ここまで壊れるとは思いませんでした。 - 「良さそうな提案」だからと短絡的に取り入れない
リファクタリングもレビュー内容も吟味して「良くなるなら実施しよう」と短絡的にやるのはダメだなと強く感じました。AIはドメインの背景を知りません。 - 1日に少しずつ進める慎重さを持つ
AIがあるからといって慢心せず、「1日にちょっとだけリファクタリングする」という人間のペースと慎重さが必要です。
AIを使う開発で、実装以外の判断が重要になったと感じた背景は、AIによって業務のレイヤーが一段上がった今に書いています。
AIの修正で通常の更新まで壊れ、詳細ログを出して調べ直した例は、WPFの商品名同期を直した記録に残しました。
モデルや層の判断で立ち止まった時のことは、DDDの用語を知っていても、AIのコードをレビューできなかった経験に書いています。
確認した情報
2026年10月11日、本文で使う用語・仕組みを次の公式資料で確認しました。
- Microsoft Learn: Dependency injection in .NET：サービスの登録と解決。
コメント