ソフトウェア自動開発のメモ帳

コードレビューはバグを見つけない

「AI にコードレビューを任せたら品質が下がるのではないか」——取引先やマネジメント層からこう問われたことのあるエンジニアは多いだろう。人間のレビューこそが品質の最後の砦だという信念は根強い。

だが、その砦は本当に機能しているのか？ Microsoft Research が 2015 年に発表した論文のタイトルは、まさにこの問いに対する回答だった。「Code Reviews Do Not Find Bugs（コードレビューはバグを見つけない）」——Microsoft 内部のデータが示した現実は、多くのエンジニアの直感に反するものだった。

レビューコメントの 85% はバグと無関係

Microsoft の Bacchelli と Bird による 2013 年の研究では、17 人の開発者を観察し、570 件のレビューコメントを分類した。レビューコメントのうち実際のバグに関するものはわずか 14%（570 件中 78 件）だった。最も多かったカテゴリは「コード改善」で 29%——命名規則、可読性、デッドコードの指摘だ。バグに関するコメントの中でも、83% は if 文の条件式の誤りなどの低レベルの論理的問題で、セキュリティに関するものはわずか 5 件だった。

Czerwonka らによる 2015 年の追跡研究でも同様の結果が出ている。レビューコメントのうち 15% だけが欠陥の可能性を示すもので、50% 以上は長期的な保守性に関するフィードバックだった。

これらの研究が示しているのは、レビュアーの認知リソースの大半がバグ検出ではなくスタイル指摘に消費されているという事実だ。Czerwonka らはこの結果をもとに、コードレビューの主たる価値はバグ発見ではなく知識共有とコード改善にあると結論づけている。

400 行を超えると人間はレビューをやめる

普段のコードレビューで、差分が数千行ある PR を受け取ったことはないだろうか。そのとき、どこまで丁寧に読んだだろうか。

SmartBear 社が Cisco Systems で行った大規模調査は、この直感を裏付けるデータを提示している。最適なレビューサイズは 200〜400 行で、それを超えると欠陥検出能力が大幅に低下する。毎時 500 行を超える速度でレビューすると発見率が顕著に落ち、レビュー開始から 60 分を超えると認知疲労によって効果が下がる。

Google のエンジニアリングプラクティスでも「CL（変更リスト）は 200 行程度が適切で、1,000 行は大きすぎる」と明記されている。Google では変更の 35% が単一ファイルの修正であり、レビュアーは 75% のケースで 1 人だけだ。

では、1,000 行を超える PR が来たとき何が起きるか。形式的に LGTM を出して次に進む——これは怠慢ではなく、人間の認知的限界に起因する構造的な問題だ。

「品質のためのレビュー」という幻想

コードレビューに意味がないと言いたいわけではない。知識の共有、設計の議論、チームの学習——レビューにはバグ発見以外の重要な価値がある。

問題は、レビューが実際に果たしている役割と、組織がレビューに期待している役割のギャップだ。

Czerwonka らの研究では、レビュー対象のコードベースに馴染みがないレビュアーのコメントは 33% しか有用と判断されなかった。3 回目のレビューでようやく 67% に上がる。つまり、「担当外だけどレビューしておいて」という依頼の多くは、品質保証としては心もとない。

さらに、Bacchelli と Bird の研究ではインタビュー対象者自身がこう認めている。

「フォーマットのミスばかり指摘するレビュアーがいる。見つけるのが簡単だからだ。（中略）本当のバグがあるのにフォーマットの指摘しか出てこないのは、正直恥ずかしい」

人間のレビュアーは、認知的に楽なフィードバック（スタイル、命名規則）に偏る傾向がある。これは意志の問題ではなく、理解コストが低い指摘ほど出しやすいという認知バイアスだ。

では何がバグを見つけるのか

人間のレビューだけでは不十分だとして、では何がバグを見つけるのか。

航空業界の安全が劇的に向上したのは、人間は必ずミスをするという前提に立ち、多層防御を導入してからだ。自動診断システム、チェックリスト、乗員相互確認——複数のレイヤーが重なることで、一つのレイヤーに穴があっても別のレイヤーが補う。コードレビューを「唯一の品質ゲート」として運用することは、パイロットの目視確認だけでエンジンの異常を検知しようとするのと同じだ。

ソフトウェア開発でも同じ構造が機能する。AI レビューはこの多層防御の一つのレイヤーとして、すでに実績を出し始めている。

Google は社内で AutoCommenter を 2022 年 7 月から展開し、人間レビュアーが歴史的に引用してきたベストプラクティスの 68% をカバーしていると報告している。そのうち 66% は従来の静的解析ツールでは検出できないものだった。GitHub の 2023 年の調査では、Copilot Chat を使ったレビューは 15% 高速化し、202 人の Python 開発者を対象にした別の調査では AI 支援で書かれたコードのブラインドレビュー通過率が 10% 以上改善している。ByteDance の BitsAI-CR は 12,000 人以上の週次アクティブユーザーに対して 75% の精度でレビューコメントを生成している。

重要なのは、これらのツールが「人間の代替」ではなく「人間の補強」として導入されている点だ。AI が一貫性のある機械的チェックを行い、人間はアーキテクチャや設計判断に集中する——人間の認知バイアスを、機械の一貫性で補完する構造だ。

世界で最も厳しい規制業界の選択

「うちはセンシティブなデータを扱っているから AI は使えない」——この主張は、もはや事実と合致しない。

Bank of England と FCA の 2024 年調査によれば、規制対象の金融企業の 75% がすでに AI を利用しており、保険会社の 95%、国際銀行の 94% が導入済みだ。130 万人以上の顧客を持つ Saxo Bank はほぼすべての新規アプリケーションに AI 生成コードを使用している。防衛産業でも Lockheed Martin は 8,000 人以上のエンジニアが社内 AI プラットフォームでソフトウェア開発を行っていると公表している。

これらの組織は「AI を使わないリスク」を評価した結果、導入を選んだ。人間だけに頼る品質管理は、レビュアーの体調、時間帯、締め切りのプレッシャーに左右される。一貫性のない品質ゲートは、品質ゲートがないのと同じだ。

日本でも、経済産業省が AI 事業者ガイドラインを整備しており、「AI を使ってはいけない」ではなく、「AI をどう安全に使うか」がすでに議論の中心に移っている。

まとめ

人間のコードレビューを「品質の保証」として信じることは、データに基づかない信仰に近い。レビュアーの注意の 85% はバグ以外に向かい、400 行を超えると検出能力は著しく落ち、馴染みのないコードのレビューは 3 分の 2 が有用なフィードバックにならない。

品質を本当に守りたいなら、人間のレビューに自動化されたチェックを組み合わせる多層防御が必要だ。世界で最も規制の厳しい業界がすでにその選択をしている。

参考リンク