まだAIコードをレビューするか、しないかで言い争ってるの？
AIが生成したコードをレビューするべきかどうか、という議論は定期的に起こります。
3カ月以上その問題に悩んでいる人は、たぶんとっくに何らかの結論に達していると思います。
私の結論
- AIコードのレビューが必要ないプロセスを確立するしかない
これは、すでにレビューしなくて済むようになったとか、いまレビューしていないという話ではありません。近い将来、そこに到達しなければならないという話です。
これは、少なくとも次の3つの確定的な事実に基づいています。
- 今後コードレビュワーは育てられない
- AIはレビュワーを物量でひき殺す
- 人がレビューを続ける組織は、レビューしない組織に淘汰される
そのために必要なことも、いくつかわかっています。
- 高品質なコードを生成できるコンテキストを開発・維持する開発プロセス
- 高品質なコードを生成できるハーネス
- コードより高いレイヤーの評価基準で品質を評価・保証するプロセス
今後コードレビュワーは育てられない
コードレビュワーの育成方法として、コードを書いて経験を積む以外の道は、いまだ確立されていません。
既存のレビュワーがレビュー能力を維持すること自体は、努力次第で可能でしょう。
しかし現実的には、いまのレビュワーと同程度にコードに向き合う時間を確保することは、今後ほぼ不可能です。
したがって、現在のレビュワーと同程度のコードレビュー能力を持つ人材を今後育てるのは難しいはずです。
AIはレビュワーを物量でひき殺す
GPT-5.4にもOpus 4.6にも、高速モードがあります。
現時点でも、AIが生成するコードの物量に押され気味なのに、これからはさらに生成量が増えることは確実です。
人間中心のレビューを続けるなら、AIによる生成量にブレーキをかける必要があります。
人がレビューを続ける組織は、レビューしない組織に淘汰される
仮に、レビューをしない、もしくは軽量なレビューだけで、同等の品質を保てる組織が作れたとします。
その組織は、レビューを続ける組織を淘汰するでしょう。疑う余地はありません。
高品質なコードを生成できるコンテキストを開発・維持する開発プロセス
レビューを軽量化、あるいは不要にするには、大前提としてAIが高品質なコードを生成できる状態を作る必要があります。
そのために重要なものの一つが、品質の高い入力コンテキストです。
ただ、それが単一の形に収束することはないとも思っています。
少なくとも、比較的高い頻度で改善が求められるサービスと、社会インフラに近いサービスとでは、まったく異なるアプローチになると思います。
私はどちらかと言えば後者ですが、ビジネス要件の可視化からソフトウェアの手前までを文書化し、その文書化自体もAIが支援する形を想定しています。というより、それを目指して動いています。
高品質なコードを生成できるハーネス
同じコンテキストを与えても、AIが生成するコードの品質はハーネスの品質に大きく依存します。
ここでいうハーネスには、Claude CodeやCodex CLIのような汎用ツールだけでなく、プロダクト固有のアーキテクチャやアプリケーションフレームワークも含まれます。
私はその一例として、高品質なローコードプラットフォームが台頭してくると面白いと思っています。ローコードプラットフォームがハーネス兼サンドボックスとして機能するイメージです。
コードより高いレイヤーの評価基準で品質を評価・保証するプロセスを確立する
前の二つはコード品質を高めるためのプロセスですが、どこまで進んでも品質保証のプロセスそのものがなくなることはないと思っています。
その際に必要なのは、コードレビューのような低レイヤーの評価基準ではなく、コード品質を保証するための高いレイヤーの評価基準です。
前述のコンテキストそのものをインプットにして、コード生成とは別プロセスで評価システム自体もAIが生成することを想定しています。最終的に人が評価するのは、要求、もしくは最上位要件への適合度だけになるかもしれません。
また、人間がコードレビューをする機会は減るでしょうが、レビューという考え方自体がプロセスから消えるわけではありません。Lintや静的解析のような自動化されたコード品質保証プロセスを、さらに拡充していく必要があります。
まとめ
人がレビューを続ける組織は、レビューしない組織に淘汰される
最初にこのように書きましたが、これは「悪貨が良貨を駆逐する」という意味ではありません。今後、レビューしない組織の方が品質自体も高くなっていく可能性が高いと思っています。
AIのコードをレビューし続けるかどうかを議論するフェーズは、もう終わったと思います。これからは、AIコードのレビューが必要ないプロセスを確立するフェーズに入ると思います。
いち早くそこに到達した組織が大きく飛躍し、遅れた組織は淘汰されていくと確信しています。
Discussion
linux kernelのPRをAIにレビューさせてみると、問題提起における前提条件の誤りに気付けると思います。
残念ながら世界は低品質な車輪の再発明で溢れています。AIがレビューで指摘できるのは、低品質な車輪の再発明による、低品質で使い古された間違い方だけです。なぜそのPRに至ったのかという、本質的なバリューはAIは推論できません。
なぜなら本質的な議論は一般的に高度なメタ文脈を総動員して問題解決の提案骨子を形成していくため、文意を含めた総文を議事録として全記述するのは可処分時間として現実的に不可能であり、また訓練データとしても存在しないからです。
今AIの物量に圧されているように見えるのは、実際には低品質な車輪の再発明の淘汰であり、バリューの産出ではないのです。
AI Slopなどとは別の文脈ですし、別に今すぐすべてのコードレビューを止めろとは言っていませんし、なんなら将来的にすべて廃止すべきと断定する話でもありません。
生成AIを使って従来同等以上の品質のコードを短時間で生成することは、十分に現実的な中、従来の濃淡でコードレビューはできないし、する必要のない解決策も一定程度以上に存在する。
その中で従来のやり方だけに拘っていたら淘汰されるという趣旨です。
記事の主張の方向性には概ね同意します。コードレビューを前提としたプロセスが今後維持できなくなるという見立ては、おそらく正しいと思います。
一点気になったのは、品質保証の議論がベリフィケーション（作ったものが仕様通りか）の視点に寄っていて、バリデーション（そもそもその仕様がユーザーの要求を満たしているか）の視点が薄いように感じました。
「コードより高いレイヤーの評価基準」という方向性は共感しますが、そこで重要になるのはブラックボックステストの設計方針だと思います。そしてその大方針の策定は、AIに委ねられる部分ではなく、人間が担うべき領域として残り続けるはずです。
「評価システム自体もAIが生成する」と書かれていますが、何をもって「正しい」とするかの判断基準そのものは人間が定義するしかありません。ベリフィケーション&バリデーションの両輪を意識した上で、人間が担うべき部分とAIに委ねる部分の線引きがもう少し具体的に示されると、記事の説得力がさらに増すのではないかと思います。
ご指摘ありがとうございます。
ご指摘の箇所は少し端折り過ぎました。
本文にあるよう、私は要件定義書等をガッツリ書く文化の中にいます。その前提で、文書に言語化されている範囲であれば、近い将来人よりAIのテストの方が信頼できるときがくるのではないかと考えています。
ここは徐々にそうなっていくと書くべきで、今現時点で全面的にそうなっている、そうするという意味ではありませんでした。
ご指摘の内容は同意で、下記の一文にそれを込めたつもりでしたが、ちょっと本文見直すかもしれません。
ありがとうございました！