1人開発で「レビュー」をどうするか「AIコードレビューの実践」

1
チーム開発:
2
  コード → PR → レビュー → 修正 → 承認 → マージ → デプロイ
3
                   ↑
4
              ここで問題を検出
5

6
1人開発（Before）:
7
  コード → commit → push → デプロイ
8
  （レビューなし。問題は本番で発覚）

1
事故1: except Exception で全エラーを握りつぶし
2
  → 16日間、特定機能が無効化されていることに気づかなかった
3

4
事故2: API keyをconfig辞書にハードコード
5
  → Gitにコミットされ、pushする直前に気づいた
6

7
事故3: 循環的複雑度60の関数を追加
8
  → 3週間後、修正しようとしたが理解不能

1
## Post-Implementation QA Workflow
2
コード変更完了後、Git commit前に自動実行:
3
1. /sc:analyze → 品質・セキュリティ・パフォーマンス分析
4
2. /sc:test → テスト実行・カバレッジ確認
5
3. /sc:improve → 改善提案をユーザーに提示
6
4. /sc:document → 変更箇所のドキュメント更新
7

8
例外（スキップ可）: md/設定ファイルのみの変更

1
実行例:
2
  品質:
3
    - 循環的複雑度: 最大 19（閾値20以下: OK）
4
    - 関数の行数: 最大 45行（閾値50以下: OK）
5
    - 未使用インポート: 0件
6

7
  セキュリティ:
8
    - ハードコードされたシークレット: 0件
9
    - 安全でないデシリアライズ: 0件
10
    - SQLインジェクションリスク: 0件
11

12
  パフォーマンス:
13
    - N+1クエリパターン: 0件
14
    - 不要なループ内計算: 0件
15

1 collapsed line
16
  結果: PASS（全項目クリア）

1
改善提案:
2
  1. [パフォーマンス] calculate_metrics() 内のDataFrame操作を
3
     vectorized operationに置き換えると約30%高速化の見込み
4
     → 適用しますか？ [Y/n]
5

6
  2. [可読性] config_validator.py の validate() メソッドを
7
     validate_required_keys() と validate_value_ranges() に分割すると
8
     テスタビリティが向上
9
     → 適用しますか？ [Y/n]
10

11
  3. [堅牢性] api_client.py の retry ロジックに
12
     exponential backoff を追加すると API制限超過時の安定性が向上
13
     → 適用しますか？ [Y/n]

1
# 1. 循環的複雑度が高い関数
2
def process_event(data, config, system_state, resources, ...):
3
    if system_state == "active":
4
        if data["metric"] < 30:
5
            if config["use_filter"]:
6
                if resources < config["max_resources"]:
7
                    # ... 深いネスト
8
    # → AIが検出: "cyclomatic complexity 35, 閾値20を超過"
9

10
# 2. 未使用のインポート
11
import pandas as pd          # 使用されている
12
import numpy as np           # 使用されている
13
from datetime import timedelta  # 未使用 ← AIが検出
14

15
# 3. except Exception の握りつぶし
7 collapsed lines
16
try:
17
    result = api_client.get_resources()
18
except Exception:
19
    pass  # ← AIが検出: "例外を握りつぶしています"
20

21
# 4. ハードコードされたシークレット
22
API_KEY = "sk-1234567890abcdef"  # ← AIが検出: "ハードコードされたAPI key"

1
# 1. ビジネスロジックの妥当性
2
def calculate_resource_allocation(capacity, usage_ratio):
3
    return capacity * usage_ratio * 100  # ← この "* 100" は正しいのか？
4
    # AIはコードの文法は検証できるが、
5
    # 「割り当て量の計算で100倍すべきか」は判断できない
6

7
# 2. 実環境でのパフォーマンス影響
8
def fetch_all_items():
9
    for item in ALL_ITEMS:  # 28件
10
        data = api.get_records(item, interval="1m", limit=10000)
11
    # AIは「ループ内のAPI呼び出し」を検出できるが、
12
    # 「28回 × 10,000行の取得が本番のレートリミットに引っかかるか」
13
    # は実環境の知識がないと判断できない
14

15
# 3. 既存システムとの整合性
3 collapsed lines
16
# ADR-015で「終了処理ロジックは resource_manager.py に集約する」と決定した
17
# 別モジュールに終了処理ロジックを書いてもAIは指摘しない
18
# → ADR（Architecture Decision Records）で補完

1
ビジネスロジックの妥当性
2
  → テストの期待値を人間が設定する（AIはテストを実行するだけ）
3

4
実環境でのパフォーマンス
5
  → Dry-Run/Practice期間で実環境テスト
6

7
既存システムとの整合性
8
  → ADR（Architecture Decision Records）をCLAUDE.mdから参照
9
  → AIがADRを読み込んで整合性をチェック

1
ワークフロー:
2
  1. AIが feature ブランチにコードをcommit
3
  2. AIが develop ブランチへのPRを作成
4
  3. PRの説明文もAIが自動生成
5
  4. 人間がPRを確認し、承認してマージ

1
## PR説明文（AI自動生成）
2

3
### 変更内容
4
- resource_manager.py: リトライ制御の状態機械を追加
5
- config.py: retry_control_config セクションを追加
6

7
### テスト結果
8
- 新規テスト: 24件追加
9
- 全テスト: 4,174件 PASS / 0件 FAIL
10
- カバレッジ: 82% → 83%
11

12
### 影響範囲
13
- リソース管理の解放処理に新しい分岐を追加
14
- 既存のタイムアウト/リトライロジックには影響なし（テストで確認済み）

1
AIに承認させない理由:
2
  1. ビジネスロジックの正しさはAIが保証できない
3
  2. 「テストが通る」ことと「正しく動く」ことは別
4
  3. 責任の所在が曖昧になる
5
  4. 人間がPRを読む習慣がなくなると、コードの理解が失われる

1
月あたりのインシデント: 8〜12件
2
主な原因:
3
  - except Exception の握りつぶし: 3件
4
  - 未テストの変更: 4件
5
  - ドキュメント未更新による設定ミス: 2件

1
月あたりのインシデント: 1〜3件
2
主な原因:
3
  - 実環境固有の問題（API仕様変更など）: 1〜2件
4
  - AIが検出できないビジネスロジックの不整合: 0〜1件