「人間が書いたコードは2025年に死んだ。コードレビューは2026年に死ぬ」——そんな過激な声がエンジニアコミュニティに広がっている。AIがコードを生成し、人間はそれを読むだけになる世界で、レビューにはまだ意味があるのか？ Zennに投稿されたこの記事は、その問いに正面から向き合っている。
コードレビューはバグ探しではない
まず著者が指摘するのは、多くの開発者が「コードレビューの目的＝バグ発見」と思い込んでいるという事実だ。しかし研究データはそれを否定する。
- Bacchelli & Bird の研究：開発者の44%が「欠陥発見」を最重要動機と回答したが、実際のレビューコメントを分析すると欠陥に関するものは わずか14%
- Czerwonka et al. の研究：レビューコメントの50%以上は保守性に関するフィードバックであり、論文タイトルは「Code Reviews Do Not Find Bugs」
- バグ発見はテスト・Lint・静的解析に任せるべきであり、レビューにそれを期待するのは「筋が悪い」
Google の SWE ブックでも、レビュー内の教育的コメントは「FYI」として位置づけられており、あくまで コードベース全体の健全性確保 が主目的とされている。
コードレビューの本質は「メンタルモデルの共有」
著者がこの記事で最も力を入れているのが、Peter Naur の論文 「Programming as Theory Building」 の引用だ。
Naur の主張はシンプルかつ深い：
プログラムの本質はソースコードにはない。プログラマの頭の中にある「理論」（＝メンタルモデル・ドメインモデル）こそが本体だ。ソースコードはそのモデルの不完全な記述に過ぎない。
つまり、そのモデルが失われたとき、プログラムは「死んだプログラム」になる。修正はできても、設計やその理解が欠落しているからだ。
ここからコードレビューの再定義が導かれる：
コードレビュー＝書き手のメンタルモデルをチームで共有する行為
レビュアーはコードを読むことで書き手の意図に触れ、自分のモデルと照合し、設計の妥当性・トレードオフ・変更の影響範囲を共有する。これがレビューの核心だ。
AIが書いたコードこそ、レビューが必要になる
David Poll はこの核心をさらに鮮明に定式化している：
- テスト：コードが作者の意図通りに動くかを確認する
- 本番監視：システムが実際に意図通りに動いているかを確認する
- コードレビュー：「これは自分たちのプロダクトに組み込むべきか」を問う
レビューが求めるのは正誤ではなく 判断（judgment） だ。そしてこれは自動化で代替できない希少なリソースである。
AIがコードを生成する時代、むしろこの「判断」の重要性は増す。AIは「動くコード」を高速に生成できるが、「このプロダクトにとって正しい設計か」「チームのメンタルモデルと整合しているか」を判断するのは人間の仕事だ。責任を取るのが人間である以上、そのコードがどういう「理論」に基づいているかをチームで共有・検証するプロセス——つまりコードレビュー——は消えるどころか、より本質的になると著者は主張する。
まとめ——「何のためのレビューか」を問い直すべき時
この記事が面白いのは、AIコーディング論争に対して「レビュー不要論」でも「レビュー必須論」でもなく、「そもそもコードレビューとは何か」を問い直すという立場を取っている点だ。
バグ探しのためのレビューなら、確かにAIとツールに任せればいい。しかしチームの知識・設計意図・判断をコードベースに織り込んでいくプロセスとしてのレビューは、AI時代においてこそ価値を持つ。
元記事では参考文献が丁寧に示されており、Bacchelli & Bird の研究や Google のガイドラインなど、一次情報へのリンクも充実している。AI時代のエンジニアリングプロセスを考えるすべての開発者に一読を勧めたい。