パラドックスの定義#
Claude Code、Copilot、Cursorなどのツール導入後、一人あたりのコミット数は30〜60%増加するが、Lead Time for Changesはそのままで、Change Failure Rateは数ポイント上昇するケースが多い。
三つのメカニズム#
1. コードレビューのボトルネック#
以前は1日8PRを出していたチームが、いまは18PRを出す。レビュアーは旧来のペースのまま — キューは線形に伸び、平均レビュー待ち時間は指数的に伸びる。
2. テスト範囲の爆発#
自動生成コードは動くが、必ずしも著者のローカルな思考的検証を通っていない。CIだけが唯一のフィルタになる。遅いか不安定なら、不具合は通過する。
3. オーナーシップの低下#
「自分のAIのコード、自分のじゃない」となった瞬間、エンジニアは本番障害に立ち向かう意欲を失う。MTTRが伸びる、なぜ動いていたかを誰も知らないからだ。
対策#
- レビューループにAIを組み込む — リスクの高い変更をフラグし、テストを提案し、アサーションのないコミットをブロックするボット。
- バッチサイズを小さく — PRの行数に固定上限（例: 400）を設けて分解を強制。
- 失敗予算 — CFRが10%を超えたらその日のマージを停止。
- オーサーシップ・ローテーション — AI生成のPRには14日間責任を持つ「human reviewer of record」を必ず置く。
計測対象#
AIアシスタントを導入するなら、次の4指標を同時に設定すること：
- 1エンジニア・1週間あたりのPR数（採用率プロキシ）
- Lead Time for Changes（ボトルネック・プロキシ）
- CFR（品質プロキシ）
- MTTR（オーナーシップ・プロキシ）
この4つがなければ「AI生産性」の議論は単なる逸話で、経営層は逸話を買わない。