AI 導入の効果は PR 数や速度ではなく、Rework Rate とレビュー時間・障害数と並べて測る
AI で個人の速度は上がっても、組織では手戻りとレビュー負荷として後から返ってくる。速度の指標だけで判断せず、Four Keys に Rework Rate とコード品質の指標を足して追う。
どんな時に使う？
- AI ツールの導入効果を「PR が増えた」「速くなった」で報告している
- レビュー待ちが増えた、障害が増えた気がするが、数字で見ていない
- チームの AI 活用の「質」をどう評価するか決めたい
記事が引いている数字（すべて記事中の出典どおり）
- Stanford の研究: PR 数が14%増えた企業で Rework Rate が2.6倍になった事例
- Faros AI（2026）: PR のレビュー時間は441%増、本番インシデントは242.7%増、開発者1人あたりのバグは54%増
- Opsera（2026、25万人）: AI が書いたコードは脆弱性が15〜18%多く、重複が10.5〜13.5%増えた
- Anthropic の実験: 未習得のライブラリを使う課題で、AI を使った群の理解度クイズは平均50%、手で書いた群は67%（特にデバッグの問いで差が大きい）
何を測るか
- Four Keys（デプロイ頻度、変更のリードタイム、変更失敗率、復旧時間）
- Rework Rate（マージ後すぐに書き直された変更の割合）
- PR のレビュー時間と、レビューなしでマージされた PR の数
- 重複コードや静的解析の警告などのコード品質
- 可能なら、LLM プロキシのログから個人の AI 活用の中身を見る
注意点
- 記事は複数の調査をまとめたもの。数字を社内で使うときは、元の調査を確認してから引く
- 手戻りを減らす具体策は 「終わった」と言われたら、検証可能な証拠を出させてから受け取る、AI が書いたコードのレビュー観点を「ポリシー」ファイルにまとめ、レビュー役のエージェントに渡す（takt の ai-antipattern.md）
- トークン量の実測は エージェントが1回に何トークン送っているかを、ログ用プロキシを挟んで実測する（Claude Code と OpenCode の比較）
出典
- @nihonbuson 2026-05-03: @nihonbuson · 2026-05-03
- Kosuke Kuzuoka「AIは速度を前払いし、失敗を後払いにする」（note）: note.com