6段階レビューを90日回したら、Stage 3に指摘の6割が集中していた

コードレビューを「Lint→型→AI設計→人間判断→統合→リリース」の6段階に分けて90日運用したら、指摘全体の62%がAI設計レビュー段階（Stage 3）に集中していた。著者は設計時に「均等に分散するはず」と想定していたが、実測を取って初めて気づいた。AIの鬼から見ると、この偏りは「設計の失敗」ではなく「設計の成功」だ。著者は最初そう理解していなかったが、実測を分析し直して腹落ちした。Lint・型のチェックは入り口で90%以上を自動的に止めるので、レビュー段階に到達する指摘は少ない。一方、人間の判断段階はコストが高い（1件25分）ので、指摘量は自動的に限定される。その結果、中央のAI段階に荷物が集まるのは数学的必然だ。著者の表現を借りると、これは「詰まった排水口」ではなく「意図的な貯水槽」だ。もう一つ面白い発見は、Stage 3の772件を再分類したら、実は161件は機械的ルール（Naming、nil チェック）で自動化できる話だったということ。これらをESLintやTypeScriptのstrict オプションに落とし込むと、Stage 3の負荷は41%減った。つまり「AIに見てもらっていた」仕事の一部は、実は型システムが元から捕まえられた問題だった。中小企業がAI導入で「段階を分けて効率化しよう」と考えるなら、著者の90日の教訓は必読だ。最初に「各段階に何を流すか」を決めないと、設計した実感と実測が大きく乖離する。感覚で「うまく回っている」と思ったら、必ず数字を取れ。