コードレビューを殺す方法 — アビエーターのアンキット・ジャイン氏

コードレビューを殺す方法：AI エージェント時代における「意図」の再定義と品質保証の変革

現在のコードレビューは、生成 AI によるコード量増加に追いつかず、開発プロセス全体のボトルネックとなっています。アンキット・ジャイン氏（Aviator 共同創設者）は、従来の「仕様→実装→検証」というウォーターフォール型のアプローチや、単なる差分のチェックに固執する現状を打破し、「AI エージェントとの対話履歴」こそが真の意図であると主張します。この論考では、コード行ごとのレビューから「意図と検証結果」への焦点シフトを実現するための具体的なフレームワークを解説します。

コードレビューの危機：ボトルネック化と形骸化

まず、現在のコードレビューが抱える深刻な現実を確認する必要があります。コード生成量は日々増加していますが、人間のレビューリソースはそれに対応しきれていません。その結果、レビュー待ち時間が以前よりも 4 倍に伸びるなど、開発フローが停滞しています。

「実質的に私たちはもうコードを一行ずつ読むことをやめてしまっています」

データが示すのは厳しい現実です。コードの改変量（churn）は驚異的なペースで増加しており、PR に対するインシデント比率も上昇しています。最も問題視すべき点は、現在の変更の 30% 以上がレビューなしでマージされているという事実です。

AI がコードを生成し、別の AI がレビューを行う現状でも問題は解決しません。GitHub の UI で AI と往復するプロセスは、結局のところ人間が「AI がレビューしたから大丈夫だろう」と確認するだけで、本質的な検証が行われていないケースが多発しています。「AI がレビューして誰も読んでいない」状態こそが、システム設計の誤りなのです。

真の「意図（インテント）」はどこにあるのか？

コードレビューの本質は、バグの発見やセキュリティチェックだけではありません。チームでの知識共有、メンタリング、アーキテクチャへのフィードバック、そして何より「アライメント（方向性の一致）」を確保する場です。

従来の「スペクトラム開発」のように、事前に完璧な仕様書を作成して AI に実装させるアプローチは、1970 年代のウォーターフォールモデルと同じ欠陥を抱えています。仕様書が完成した時点で全ての決定が下されたことになり、AI の非確定的な性質（LLM がその場で独自の判断を下すこと）を無視しています。

真の意図は、静的なドキュメントには存在しません。それは以下の対話の中で形成されます：

• Jira チケット：プロジェクトのゴール
• PRD（製品要件定義）：詳細な計画
• AI エージェントとのプロンプトと会話履歴：実装中の意思決定

「現在の開発プロセスでは、対話の中で行われた重要な意思決定を記録したプロンプトを捨ててしまい、変更点だけを残してしまいます。これが最大の損失です」

エンジニアが AI と往復する過程で生じる「なぜこのロジックなのか」「この実装は適切か」という判断こそが、レビューの核心となるべき意図なのです。

「AI スロップレジストリ」：反復ミスを学習させる仕組み

コードの文脈的な正確性（Semantic Accuracy）を保証するためには、人間のレビュー経験を活かした仕組みが必要です。ジャイン氏は「AI スロップレジストリ」という概念を提案します。

これは、過去のコードレビューで人間が発見し指摘した反復するミスを記録・学習させるデータベースです。単なるコメントの蓄積ではなく、これらのパターンを分析してシステムが自動的に学習させます。

「繰り返されるレビューコメントは、将来の自動ガードレール（安全装置）として機能します」

このレジストリを活用することで、同じミスを人間が逐一指摘する必要がなくなります。システムが過去の失敗から学び、標準的な LLM 以上の精度で潜在的なバグを事前に検知できるようになるのです。

レビューの転換：コード差分から「意図と検証結果」へ

アライメント（意図）とセマンティック・アクuracy（正確性）を統合し、レビュープロセスを根本から変革する新しいワークフローが提案されます。これは以下の 3 つのステップで構成されます。

1. 対話履歴からの承認基準の抽出

AI エージェントとのセッションログを分析し、そこで交わされた意思決定やフィードバックを「承認基準（Acceptance Criteria）」に変換します。LLM を活用して、自然言語の会話から明確な要件を抽出します。

1. 自動生成されるテスト計画

抽出した承認基準と、AI スロップレジストリで学習した不変条件（インバリアント）を組み合わせて、動的にテスト計画を作成します。これにより、手動でテストコードを維持する負担から解放されます。

1. 証拠に基づく検証

作成されたテスト計画に基づき、プレビュー環境で実際にアプリケーションが動作するかを検証します。AI エージェントが画面を操作し、フォームの入力や決済フローなどをシミュレーションしてスクリーンショットやデータベースのスナップショットを「証拠」として取得します。

「レビューの表面（レビュー対象）は、コードの差分ではなく、意図が実装されたか、承認基準を満たす動作をしたかの『証拠』に変わります」

このアプローチにより、レビュー担当者はコードの行を追うのではなく、「アーキテクチャ上の判断が適切だったか」「要件定義通りの機能が作られたか」という高次元の確認を行います。テスト計画は英語で記述されるため、プロダクトマネージャーやデザイナーも参加できる透明性の高いプロセスへと進化します。

まとめ：人間の役割は「ガバナンス」へ

この新しいモデルは、システムが 100% 確定的である必要はないという前提に立っています。複雑な UI や非構造化データの処理には LLM を活用し、確定すべき部分（テストの実行と証拠の取得）を自動化します。

コードレビューの未来は、「誰が書いたか」ではなく「なぜその判断を下したか」という意図の検証にあります。開発チームのリソースをコードの正しさからアーキテクチャと意図の整合性へシフトさせることで、生成 AI 時代における品質保証プロセスの変革が可能となります。