--- title: "「コードレビューは死んだ」のか？AIエージェント時代のコードレビュー不要論を読み解く" date: "2026-03-04T12:00:00+09:00" slug: "posts/2026/03/04/how-to-kill-the-code-review" ogIcon: "infra" description: "Latent.Spaceの「How to Kill the Code Review」を起点に、AIエージェント時代のコードレビュー不要論の主張と批判を整理し、エンジニアとしてどう向き合うべきかを考察する。" themes: ["team"] private: true --- ## はじめに 2026年2月、Latent.Spaceに掲載されたAnkit Jain氏の「[How to Kill the Code Review](https://www.latent.space/p/reviews-dead)」が業界で大きな議論を呼んでいます。AIコーディングエージェントが大量のコードを生成する時代に、人間によるコードレビューはもはやボトルネックでしかないと主張するこの記事は、Hacker Newsでも活発な議論を巻き起こしました。 この記事では、元記事の主張を整理したうえで、賛否両方の意見を紹介し、「コードレビューは本当に死ぬのか」を考えます。 ## 元記事の主張 ### データが示すボトルネック Jain氏は、Faros.aiが10,000人以上の開発者（1,255チーム）を対象に収集したデータを引用しています。 - AI採用率の高いチームはタスク完了数が21%増加 - PRマージ数は98%増加 - しかしレビュー時間は91%増加 コードの生成速度が劇的に上がった一方で、レビューという人間のプロセスがスループットの律速段階になっている、というのが元記事の問題意識です。 ### 「レビューを殺す」ための5つの提案 Jain氏は従来のコードレビューに代わる5層の検証フレームワークを提案しています。 1. 複数エージェントによる比較: 同じタスクを複数のエージェントに実行させ、検証成功率とdiffサイズでランク付けする 2. 決定論的ガードレール: テスト、型チェック、コントラクト検証を合格/不合格の明確な基準で自動実行する 3. 仕様駆動開発: 人間がコードを書く前に受け入れ基準を定義し、「仕様が正であり、コードは仕様の成果物にすぎない」とする。元記事ではBDDを具体的な手法として例示している 4. 権限システムとしてのアーキテクチャ: エージェントの変更範囲を細かく制限し、機密性の高い変更にはエスカレーションを要求する 5. 敵対的検証: コーディングと検証を別々のエージェントに担当させ、レッドチームアプローチで品質を担保する 従来の「このコードは正しく書かれているか？」から、「正しい問題を解いているか？」への転換を求めるものです。 ### 背景にあるStrongDMの事例 元記事の主張を補強する事例として、Simon Willison氏が[懐疑的な評価とともに紹介した](https://simonwillison.net/2026/Feb/7/software-factory/)StrongDMの「Dark Factory」があります。Willison氏は$1,000/日のトークンコストの経済的持続可能性に疑問を呈しつつも、検証手法自体には関心を示しています。StrongDMは以下のルールで開発を行っています。 - コードは人間が書いてはならない - コードは人間がレビューしてはならない - エンジニア1人あたり最低1,000ドル/日のトークン消費 StrongDMはOkta、Jira、Slackなどのサードパーティサービスの「Digital Twin（デジタルツイン）」を構築し、1時間に何千ものシナリオを人間の介在なしに実行して品質を検証しています。従来のテストの合否（boolean）ではなく、エンドユーザーシナリオに対する「満足度」を測定する仕組みを導入しています。 ## 賛同する声 ### 形骸化したレビューの実態 元記事への賛同は、現場でのコードレビューの形骸化を経験しているエンジニアから多く寄せられています。経験的に言えば、「PRが来たら、実質的にはざっと見てApproveを押すだけ」という運用になっているチームは存在します。もしレビューがすでに形式的な承認行為に過ぎないのであれば、それを自動化された検証に置き換えるのは合理的な判断です。 ### 生産性データの裏付け Faros.aiのデータが示す「AI採用チームは21%多くのタスクを完了する」という数字は、量的なスループット向上を示しています。レビュー待ちでPRが滞留する時間が開発速度のボトルネックになっている現場にとって、レビューの省略や自動化は切実な課題です。 ただし、同じFaros.aiのレポートは「[AI Productivity Paradox](https://www.faros.ai/blog/ai-software-engineering)」も報告しています。AI採用チームではバグが開発者あたり9%増加し、平均PRサイズは154%増加しています。レポートの結論は「AIコーディングアシスタントは開発者のアウトプットを増やすが、組織の生産性は向上しない」というもので、スループットの向上がそのまま成果に結びつくわけではありません。 ### 「人間が書いたコードも人間はレビューした方がいいのでは？」 Hacker Newsのコメントで「人間が書いたコードも人間がレビューした方がいいのでは」という指摘がありましたが、Latent.Space編集者のswyx氏は「業界の議論はすでにAIエージェントの生産性向上に伴う人間のレビューボトルネックの解消に焦点が移っている」と応答しています。Hacker Newsでは「人間が書いたコードは2025年に死んだ。コードレビューは2026年に死ぬ」という挑発的なコメントも見られました。 ## 批判と懸念 ### AI生成コードの品質問題 AI生成コードの品質に関する具体的なデータとしては、CodeRabbitの「[State of AI vs Human Code Generation Report](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)」がある。オープンソースの470PR（AI共著320、人間のみ150）をCodeRabbit自身のツールで分析した結果は以下の通りです。 - ロジック/正確性の問題が1.75倍。ビジネスロジックの誤り、依存関係の間違い、制御フローの欠陥など、下流で障害を引き起こしやすい問題 - 可読性の問題が3倍以上。一見整っているが、プロジェクト固有の命名規則や構造パターンに従わないコード。データセット全体で最大の差が出た項目 - エラーハンドリングの問題が約2倍。nullチェック、早期リターン、例外処理の欠落。本番環境での障害につながるリスク - セキュリティの問題が最大2.74倍。パスワードの不適切な取り扱いや安全でないオブジェクト参照が目立つ - パフォーマンス（I/O）の問題が約8倍。過剰なI/O操作の発生。AIが効率性よりも可読性を優先する傾向に起因 - 命名の一貫性の問題が約2倍。曖昧な命名、用語の不統一、汎用的すぎる識別子によるレビュアーの認知負荷増大 AI生成コードは全体で人間のコードと比べて1.7倍多くの問題を含んでいます。特にセキュリティ問題が最大2.74倍という数字は、「レビューなしで出荷する」という方針に対する警告材料です。ただし、このレポートにはいくつかの留意点があります。サンプルはオープンソースリポジトリに限定されていること、CodeRabbit自身が認めているように「人間のみ」とラベル付けされたPRにAI利用が含まれている可能性があること、そして分析がCodeRabbit自身のツールで行われているため検出バイアスの可能性があることです。 ### 文脈理解の限界 [Hacker Newsの議論](https://news.ycombinator.com/item?id=47231139)では、AIが理解できない文脈の重要性が繰り返し指摘されています。 compacct27氏は「意図（intention）だけではコードレビューの代替にならない」と主張し、AIにアーキテクチャの概要分析をさせつつ、重要なアーキテクチャ上の判断には人間の目を残すハイブリッドアプローチを提案しています。 thomascountz氏はより根本的な指摘をしています。「コードレビューはエンジニアリングと知識管理のプラクティスであり、Pull Requestのメカニクスとは別物」であると。コードレビューはツールが一般化した2012〜2014年より遥か前から存在しており、「PRがマージされる段階では、ほぼラバースタンプで通せる状態になっているべき」だと指摘しています。問題はコードレビューそのものではなく、開発プロセスの中でレビューが遅すぎるタイミングで行われていることだというのです。 ### 循環的検証の問題 元記事が提案する「敵対的検証」やStrongDMのDigital Twinアプローチには、より根本的な問題がある。Stanford Law Schoolの[分析記事](https://law.stanford.edu/2026/02/08/built-by-agents-tested-by-agents-trusted-by-whom/)が指摘するように、AIがコードを書きAIがそれを検証する構造では、ビルダーとインスペクターが同じ技術的限界を共有するため、盲点が一致するリスクがあります。「テストスコアを最大化せよと指示すれば、エージェントはソフトウェアが実際に動くかどうかに関係なくスコアを最大化する」という指摘は、検証の自動化が万能ではないことを示唆しています。 さらに、人間がコードを読まなくなることで生じるスキル劣化の問題も見逃せません。障害発生時に原因を特定・修正できる人間がいなくなるリスクは、検証の自動化だけでは解決できません。 ### 仕様駆動開発の難しさ 元記事が提案する「仕様駆動開発」には、根本的な疑問が残ります。完全な仕様を書くこと自体が、コードを書くのと同じかそれ以上に難しいのです。仕様を明確化する過程では、曖昧さの解消、エッジケースの発見、トレードオフの判断が必要であり、これらは従来コードレビューで行われてきたことと本質的に同じです。仕様の品質を誰が検証するのかという問題は残り続けます。 ### 知識共有の喪失 元記事やHacker Newsの議論で目立つのは、コードレビューが持つメンタリングと知識移転の機能への言及がほとんどないことです。コードレビューは品質保証の手段であると同時に、チーム内でのコンテキスト共有、ドメイン知識の伝達、設計判断の議論の場でもあります。 レビューを廃止した場合、これらの機能を何で代替するのかは未解決の課題です。LLMはジュニアエンジニアのように「レビューを通じて成長する」ことはありませんが、ジュニアエンジニア自身にとっては、シニアのレビューコメントから学ぶ機会がなくなるリスクがあります。 ### AI生成コードのレビュー負荷 日本でもAI生成コードのレビューに関する議論は活発化しています。AI生成コードの量が増えるほど、レビュアーの認知負荷は増大します。従来の「人間が書いたコードを人間がレビューする」前提で設計されたレビュープロセスは、AI生成コードの特性（一度に大量の変更、表面的には正しいが文脈を欠くコード）に適合していない可能性があります。 しかし、だからといって「レビューをなくす」のではなく、「レビューの方法を変える」べきだという立場も強くあります。 ## 論点の整理と考察 ### コードレビューの「目的」を分解する この議論を整理するには、コードレビューが果たしている複数の目的を分解する必要があります。 1. バグ・セキュリティの検出: 自動テスト、静的解析、AIレビューツールで一部代替可能。ただしCodeRabbitのデータが示す通り、AI自身のコードに対するレビューはまだ不十分 2. 設計・アーキテクチャの検証: AIが最も苦手とする領域。ビジネス文脈、技術的負債、チームのコンテキストを踏まえた判断が必要 3. 知識共有・メンタリング: コードレビュー以外の仕組み（ペアプログラミング、設計ドキュメントレビュー、ADR）で補完可能だが、意識的な設計が必要 4. ガバナンス・コンプライアンス: 規制産業では人間によるレビューが法的に求められる場合がある ### 「レビューを殺す」のではなく「レビューの対象を変える」 元記事の提案を仔細に見ると、実際には「レビューをなくす」のではなく、「コードのレビュー」を「仕様のレビュー」に置き換えるものです。仕様を正とし、コードを成果物として扱う以上、仕様自体の品質保証が最重要になります。これは結局、レビューの対象がコードから仕様に移動しただけとも言えます。 StrongDMのDigital Twinアプローチも、「レビューしない」のではなく「検証の自動化に莫大な投資をしている」のが実態です。エンジニア1人あたり1日1,000ドルのトークン消費という数字が示す通り、人間のレビューを排除するには、それに代わる検証インフラへの相当な投資が必要です。 ### 利害関係の考慮 この議論に登場する主要なプレイヤーは、いずれも利害関係を持っています。 - Ankit Jain氏はAviatorのCEO。Aviatorは「AI-native engineering teams」のためのインフラを提供する企業であり、「コードレビューは不要になる」という主張はビジネスに直結する - CodeRabbitはAIコードレビューツールを販売する企業。「AI生成コードは問題が多い→AIレビューツールが必要」というナラティブは自社の存在意義を裏付ける - Faros.aiはエンジニアリングインテリジェンスプラットフォームを提供する企業。AI採用によるメトリクスの変化を可視化するデータは自社プロダクトの価値訴求に使える いずれも主張が誤りであることを意味しませんが、各データソースがどのような立場から発信されているかを意識しながら読むべきです。 ## おわりに 「コードレビューは死んだ」という主張は、問題の核心を突いている部分もあります。AI生成コードの量的爆発に対して、従来のレビュープロセスがスケールしないという指摘は的確です。 しかし、レビューの形は変わっても、「正しい問題を、正しい制約のもとで解いているか」を人間が検証する必要性は変わりません。それがコードレビューと呼ばれるか、仕様レビューと呼ばれるか、あるいは設計レビューと呼ばれるかは、本質的な問題ではないでしょう。 私自身は、コードの行単位のレビューはAIツールに任せつつ、設計意図とビジネス文脈の検証は人間が担うハイブリッドモデルが現実的な着地点だと考えています。「レビューを殺す」のではなく、人間がレビューすべき対象を「コードの正しさ」から「判断の妥当性」に再定義する。その転換が、この議論の本質ではないでしょうか。 ## 参考文献 - [How to Kill the Code Review - Latent.Space](https://www.latent.space/p/reviews-dead) - [Simon Willison - Software Factory](https://simonwillison.net/2026/Feb/7/software-factory/) - [CodeRabbit - State of AI vs Human Code Generation Report](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) - [Hacker News Discussion](https://news.ycombinator.com/item?id=47231139) - [Faros AI - The AI Productivity Paradox Research Report](https://www.faros.ai/blog/ai-software-engineering) - [Stanford Law School - Built by Agents, Tested by Agents, Trusted by Whom?](https://law.stanford.edu/2026/02/08/built-by-agents-tested-by-agents-trusted-by-whom/)