AIでコードを書くときに品質を落とさない基本ルール

はじめに

AI を使うと開発が高速化しますが、品質を落とさないことが重要です。本記事では、AI 生成コードの品質を維持するための基本ルールを説明します。

品質が落ちる理由

❌ よくあるシナリオ：
AI にコード生成を依頼
  ↓
「とりあえず動く」コードが出てくる
  ↓
時間がないから deploy
  ↓
後から保守が大変
  ↓
負債が溜まる

基本ルール 5 つ

ルール 1：テストが通るまでは「完成」ではない

❌ 基準を下げたやり方：
「AI が実装した」
→ deploy

✅ 品質を維持するやり方：
「AI が実装」
→ テストが全部パス
→ deploy

チェックリスト：

□ 既存テストがすべてパスしているか
□ 新しい機能のテストは十分か
□ エッジケースをテストしたか
□ テストカバレッジは 80% 以上か

ルール 2：差分（git diff）を絶対に確認する

❌ 危険なやり方：
AI が実装した
  ↓
すぐに commit

✅ 安全なやり方：
AI が実装した
  ↓
git diff で確認
  ↓
意図しない削除がないか
  ↓
ロジックが壊れていないか
  ↓
commit

確認項目：

□ 意図しない削除がないか
□ インデント・フォーマットは正しいか
□ 余計なコメント削除がないか
□ ロジックの意図は理解できるか
□ パフォーマンスに問題ないか

ルール 3：コード規約を守らせる

❌ 品質が下がる：
AI の出力をそのまま使用

✅ 品質を維持する：
AI に「コード規約を守って」と明示指示
  ↓
Linter で検証
  ↓
使用 OK

指示例：

「以下のコード規約を守って実装：
- 関数名は snake_case
- 変数名は英語
- 複雑さ（ABC メトリクス）は 15 以下
- 関数行数は 50 行以下
- docstring は必須」

ルール 4：依存関係を増やさない

❌ 品質が下がる：
AI が「このライブラリを使えば簡単」と提案
  ↓
新しいライブラリを追加
  ↓
依存関係が増える
  ↓
保守が複雑に

✅ 品質を維持する：
「既存ライブラリのみを使用」と制約
  ↓
複雑になっても既存技術スタックで実装

チェック：

□ 新しいライブラリを追加していないか
□ requirements.txt に反映されているか
□ セキュリティアップデートはカバーされているか

ルール 5：レビュー工程を省かない

❌ 品質が下がる：
AI 実装
  ↓
すぐに deploy

✅ 品質を維持する：
AI 実装
  ↓
人間がレビュー（コード品質、セキュリティ）
  ↓
テスト実行
  ↓
deploy

レビュー項目：

□ 機能は要件を満たしているか
□ コードは読みやすいか
□ セキュリティリスクはないか
□ パフォーマンスは問題ないか
□ ドキュメントは充実しているか

1 日の品質管理ワークフロー

【09:00-10:00】AI で実装

【10:00-10:30】テスト実行
テストが全部パス ✅

【10:30-11:00】差分確認
git diff で詳細確認 ✅

【11:00-11:30】Linter & コード規約確認
flake8, mypy 実行 ✅

【11:30-12:00】セキュリティレビュー
セキュリティリスク確認 ✅

【12:00-13:00】昼休憩

【13:00-13:30】最終確認
すべてのチェック OK ✅

【13:30-14:00】commit & push
本番環境へ

よくある失敗

❌ 失敗1：テスト数を減らす

「AI が実装したからテスト数を減らそう」
  ↓
後でバグが出る
  ↓
修正に時間がかかる

✅ 改善：テスト数を増やす

「AI が実装したからこそ、テストを充実させる」
  ↓
バグを事前に発見
  ↓
品質が高い

❌ 失敗2：差分確認をスキップ

「AI が正確だから差分確認スキップ」
  ↓
意図しない変更が入る
  ↓
本番で動作しない

✅ 改善：差分確認を厳格に

「全部の変更を確認」
  ↓
問題をすぐ発見
  ↓
安心できる

チェックリスト：AI 開発の品質ゲート

【実装後】
□ テストがすべてパスしているか
□ 新しいテストを追加したか
□ git diff で確認したか
□ Linter をパスしているか
□ セキュリティリスクを確認したか
□ コード規約を守っているか
□ ドキュメントを更新したか
□ パフォーマンスを確認したか
□ 依存関係を増やしていないか

すべてチェック ✅ → deploy OK
1 つでも ❌ → 修正してから deploy

まとめ

AI 開発で品質を落とさない基本ルール：

5 つのルール：

1. テストが通るまでは「完成」ではない
2. 差分（git diff）を絶対に確認
3. コード規約を守らせる
4. 依存関係を増やさない
5. レビュー工程を省かない

効果：

• バグが少ない
• 保守が簡単
• 技術債が少ない
• 後続の開発が効率的

Claude Codeで既存コードを壊さないための確認手順と合わせることで、高品質な AI 開発が実現します。