■ 1. 3バグ通過の教訓と6段階モデルへの移行背景
- AIにLogic層を任せた結果、本番環境でエッジケース判定漏れ・空配列の扱いミス・外部APIリトライ条件のずれという3バグを通した
- バグを通した本質的な原因は、「AIが見ているから自分は見なくていい」という無意識の判断
- 3層モデル（自動ゲート・AIレビュー・人間レビュー）は粒度が粗く、Logic層に責任が集中する構造だった
- 6段階への切り直しにより、各段階の担当と境界が明確になった
■ 2. 6段階モデルの概要
- 3層モデルとの関係:
- 3層モデルは「誰が何を見るか」の設計図
- 6段階モデルは「AIと人間の境界線をどこで切るか」の解像度を高める補完的な定義
- AI比率の分布:
- Stage 1 - Format: AI 100% / 人間 0%（ツール: pre-commit hook、Prettier）
- Stage 2 - Lint: AI 100% / 人間 0%（ツール: ESLint、Ruff、mypy、tsc）
- Stage 3 - Style: AI 90% / 人間 10%（ツール: CodeRabbit、GitHub Copilot）
- Stage 4 - Logic: AI 60% / 人間 40%（ツール: Claude Code Review）
- Stage 5 - Design: AI 30% / 人間 70%（ツール: ペアレビュー）
- Stage 6 - Architecture: AI 0% / 人間 100%（ツール: シニアエンジニア、テックリード）
- 段階が下がるほど「正解が一意でない問題」へと性質が変化し、AI比率が低下する
■ 3. 各段階の詳細
- Stage 1 - Format:
- インデント・空白・改行コード・末尾セミコロンをpre-commit hookで全自動処理
- 人間の判断は不要
- Stage 2 - Lint:
- 未使用変数・到達不能コード・暗黙的な型変換を静的解析ツールで検出
- FormatとLintの区別: Formatは「見た目」の規約、Lintは「意味」の規約（Lintの違反は動作不良につながる）
- Stage 1-2はPRに到達させない層であり、毎週30分の指摘時間を構造的にゼロにできる
- Stage 3 - Style:
- 命名・関数分割粒度・コメントの過不足・可読性が対象
- コードベース全体の命名規則に依存する判断は完全自動化不可
- AIが90%の指摘を出し、人間が採用・却下を判断する運用
- Stage 4 - Logic:
- N+1問題・SQLインジェクション・未処理例外・エッジケースが対象
- AIバグ検出精度のベンチマーク: Macroscope 48%、CodeRabbit 46%、Cursor BugBot 42%、Greptile 24%
- CodeRabbit vs Copilot比較: CodeRabbit F1 51.5% / recall 52.5%、Copilot F1 44.5% / recall 36.7%
- AIは仕様書を参照できないため、ビジネスロジック由来のエッジケースを「コードとして正しい」と判定する
- 通過した3バグの例: 空配列の処理スキップ仕様の見落とし、外部APIの429限定リトライ条件の誤判定、ページネーション境界の1件ずれ
- 運用ルール: AIが指摘した部分はAIに任せ、AIが指摘しなかった部分こそ人間が念入りに確認する
- AIコメントがゼロのPRほど仕様書を開いて精査する価値がある
- Stage 5 - Design:
- 責務分割・APIの境界・依存関係の方向が対象
- AIはコードベース固有のローカルルール（例: マルチテナントDB固有の制約）を読み取れない
- AIへの期待は機械的なヒント（例: 関数が150行ある旨の通知）に留まる
- ペアレビューにより、設計判断と個人の好みを区別できる
- 設計の方向性はコードに先行する暗黙のチーム合意に依存するため、文章化されていない情報をAIに読ませることは原理的に困難
- Stage 6 - Architecture:
- システム境界・データフロー・認証の責任範囲・デプロイ単位が対象
- アーキテクチャ判断は「正解」ではなく「未来予想」であり、AIは責任を取れない
- GitHub Copilotも公式に「アーキテクチャ上の懸念の多くを見逃す」と明記
- PRレビューではなく、PR前の設計会議（ADR作成・テックリードによるファシリテート）として実施すべき
- ADRを文章化することで、Stage 6の一部がStage 5やStage 4に降りてくる（文章化によりAI比率が上がる）
■ 4. 6段階モデルによるApproveの意味の変化
- 3層モデル時のApproveは「フォーマットOK・AIのOK・ざっと確認」の3点セット
- 6段階モデルでは、Approve前に「どの段階まで責任を持っているか」を自問する
- 各段階の確認（Format・Lint通過、Style同意、Logic仕様照合、Design検証、Architecture事前議論済み）が揃うことでApproveの重みが増す
- Logic・Designに不安がある場合は「Approveしない選択」をしやすくなり、「とりあえずLGTM」が出にくくなる
■ 5. チームへの導入ステップ
- Step 1: Stage 1-2をhooksで固める（1日で完了、即日効果が出る）
- Step 2: Stage 3にCodeRabbitまたはCopilotを導入（1週間慣らす）
- Step 3: Stage 4のための仕様書整備（最も時間がかかる、AI不可視の仕様由来エッジケースを明文化する）
- Step 4: Stage 5-6をチーム文化として育てる（ペアレビューとADRの習慣化）
■ 6. AIへの過度な依存のリスク
- Logic層（Stage 4）が最も危険な理由:
- AIカバー率60%という「中途半端な高さ」が「7割ぐらいは大丈夫」という油断を生む
- カバー率0%なら人間が全部見る、100%ならAIに任せるという明確な判断ができるが、60%はその中間にある
- AIレビュー導入チームに共通する認知的ショートカット: 「AIが見ているから自分は見なくていい」という無意識の判断
- 6段階モデルの最大の効用: Stage 4が「中間ゾーン」として可視化され、人間の集中力が最も必要な場所を認識できる
- AI比率の境界線をどこで引くかは、各チームが自分で決めるべきこと