AIで速くなった。同時にレビューが詰まった

Faros AI が「AI Engineering Report 2026」で、22,000人の開発者と4,000超のチームを対象にした実測値を出している。

増えたもの

スループット側も上がっている。エピック完了数が開発者あたり +66%、チームレベルのコード関連タスクは +210% である。

同時にコスト側も上がっている。PRサイズ +51.3%、開発者あたりのバグ +54%（前回のデータセットでは +9% だった）、PRレビュー時間 +91%。

さらに、本番インシデントの発生確率は3倍になり、レビューを一度も通らずに本番へ到達したコードが +31% 増えた。

で、SEの実務ではどう使うか

「AIで何%速くなったか」を単独の目標に置くと、この表の上半分しか見えない。

数字の形をよく見ると、増えているのは生成量であって完了量ではない。PRが大きくなり、本数が増え、その結果レビューが詰まっている。ボトルネックが書く側から読む側へ移動したという読み方ができる。

目標設定でできることが3つある。

スループットとレビュー滞留を必ず対にして見る。 完了数だけを追うと、レビュー待ちの列が伸びていることが指標に出ない。滞留時間かレビュー待ち件数を並べて置く。

バグ率とインシデントを同じダッシュボードに置く。 +54% と3倍は、速度の指標とは別の場所に出がちである。別の場所にあると、速度の改善報告と品質の悪化報告が別々の会議に出て、突き合わされない。

「レビューなしで本番到達 +31%」を単独で監視する。 これは速度でも品質でもなく、プロセスが飛ばされた回数である。速くなった副作用としていちばん見えにくく、いちばん高くつく。

稟議や振り返りで数字を出すときは、増えたものと詰まったものを同じ表に載せる。 片方だけを出すと、次の四半期に反対側の数字が出てきて説明のやり直しになる。

数字はすべて Faros AI の公開レポートに記載されているものである。