AIが書くコードは「それっぽい」だけ？セミナーで学んだ、保守性を落とさないためのAI駆動開発
本日参加したセミナーで、AI駆動開発（AI-Driven Development）における非常に重要な視点を得られたので、忘備録として共有します。
AIにコードを書かせるのが当たり前になった今だからこそ、「動くコード」と「運用できるコード」の差をどう埋めるべきかが焦点でした。
1. AIは「本番環境の苦労」を知らない
GitHub CopilotやChatGPTなどのAIは、QiitaやStack Overflowにあるコードを大量に学習しています。しかし、ここには落とし穴があります。
- 学習元の多くは「断片的なスニペット」： 解説のために簡略化されたコードや、特定の機能だけを切り出した記事が多いため、**実際のSaaSとして24時間365日動かし続けるための「泥臭い保守コード」や「徹底的な脆弱性対策」**を十分に学習できているわけではありません。
- リスク： AIが生成するコードは、一見きれいに見えても、長期的な保守性やセキュリティリスクを抱えている可能性があります。
2. ユニットテストの落とし穴：コードから作るのはNG
AIに品質を担保させるために「ユニットテスト」を書かせるのは有効ですが、その順序が重要です。
❌ やってはいけない：コード → ユニットテスト
既存のコードを読み込ませて「これのテストを書いて」と頼むのはNGです。
なぜなら、元のコードに潜在的なバグがあった場合、AIはそのバグを「正しい挙動（仕様）」として認識し、バグを正当化するテストを書いてしまうからです。
✅ 推奨されるフロー：コード → 詳細設計書 → ユニットテスト
品質を担保するためには、一度「人間の意図（設計）」を介する必要があります。
- コード → 詳細設計書： 既存コードから「本来何をすべきロジックなのか」をAIに抽出・整理させる。
- 設計の確認： 人間がその設計書を見て、意図通りか、脆弱性がないかを確認する。
- 詳細設計書 → ユニットテスト： 修正・確定した設計書を元に、テストを生成させる。
このステップを踏むことで、「実装が間違っているのか、テストが間違っているのか」を正しく判断できるようになります。
3. 「Vibe Coding（雰囲気実装）」を卒業する
最近、要件を伝えるだけで勢いでアプリを作る「Vibe Coding（バイブス・コーディング）」という言葉が話題ですが、実務レベルのプロダクトではそれだけでは不十分です。
AI駆動開発を成功させるには、以下の2セットが不可欠です。
- 要件： 何を作るか
- 開発ルール（規約）： どう作るか（ディレクトリ構成、エラーハンドリング方針、命名規則など）
要件だけを与えると、AIはその場の「バイブス」でコードを生成するため、プロジェクト全体の一貫性が失われ、スパゲッティコード化します。**「AIが迷わないためのレール（ルール）」**を人間が整備して初めて、保守性の高い開発が可能になります。
まとめ
AIは魔法の杖ではなく、あくまで「強力なツール」です。
- AIが学習しているのは必ずしも「ベストプラクティス」ではない。
- テストは「コード」からではなく「設計」から作る。
- 「要件＋ルール」のセットでAIをコントロールする。
これからのエンジニアには、コードを書く力以上に、**「AIに正しいレールを敷くための設計力」**が求められるのだと痛感したセミナーでした。