差分を読む代わりに意図を検証してAIコードをレビューする

Aviatorのエンジニアは、AIによって生成されたプルリクエスト（PR）が4倍に増加したことに伴い、コードレビューのプロセスを再構築しました。すべてのコード行を読むことから、意図、受け入れ基準、システムの不変条件（インバリアント）の検証へと焦点を移すことで、チームは中央値でのマージ時間を2.1日から3.4時間に短縮しました。このアプローチにより、ルーチンなチェックを自動化しつつ人間の監督を維持し、9人のエンジニアで週あたり400件以上のマージ済みPRを管理できるようになりました。

何が起きたか

Aviatorの開発ワークフローが「AI支援による人間作成コード」から「人間によるガイダンス付きAI生成コード」へと変化した結果、変更のボリュームが急増しました。週あたりのマージ済みPR数は約100件から400件以上に跳ね上がり、PRサイズの中央値は640行に達しました。これは、バグ検出率が一般的に低下する400行という閾値を超えていました。従来のレビュー手法はスケールしませんでした。AIレビュアーを追加すると、重要な設計判断が些細な指摘に埋もれてしまい、4時間のレビューSLA（サービスレベルアグリーメント）を課すと、エンジニアが期限を守るために内容をざっと見るだけで承認してしまう「空の承認」が発生しました。

チームは、バグを捉えることがコードレビューの主目的ではなかったことに気づきました。2013年のMicrosoftの研究を引用し、レビューコメントのうち欠陥に対応するのはわずか14%であることを指摘しました。レビューの核心的価値は、知識共有とシステムの最新のメンタルモデルを維持することにあります。AIエージェントがコードの大部分を書くようになった現在、この知識転送機能はリスクにさらされていました。何が変わったかは示すがなぜ変わったかは示さない差分をよりうまく読もうとする代わりに、チームは差分のレビュー自体をやめました。

仕組み

新しいワークフローでは、コードレビューのジョブを異なるメカニズムで処理される明確なステージに分割します。まず、PRが存在する前にレビューエージェント同士が相互にクロスチェックを行い、実装詳細について議論し、意見の相違を記録します。命名規則など未解決の問題のみが人間にエスカレーションされます。次に、システムはコーディングセッションから直接意図と受け入れ基準を捕捉します。エンジニアがエージェントを修正したり、エージェントの質問に答えたりするたびに、これらのインタラクションは検証可能な基準となります。意図は変更が行われる理由を説明し、受け入れ基準はその動作方法を定義します。

第三に、チームは繰り返されるレビューコメントをシステムの不変条件として体系化しました。1年間のレビュー履歴を分析し、11,400件のコメントを64件の承認済み不変条件（例：設定変更には監査ログのエントリーが必要）に抽出しました。これらの不変条件は、ast-grepなどのツールを使用して決定論的なルールにコンパイルされ、確率的なモデルチェックと同時に数秒で実行されます。最後に、すべての受け入れ基準は証拠によって証明されます。エージェントはプレビュー環境を起動し、ユーザーのようなシナリオを実行して、スクリーンショットやログを記録し動作を検証します。これにより、CIチェックを通過するだけでなく、機能が意図通りに動作していることを具体的に証明できます。

主要な詳細

• スループットの向上: 同じ9人のエンジニアが週あたり4倍のプルリクエストをマージできるようになり、約100件から400件以上へ増加しました。
• スピードの改善: マージまでの中央値時間が2.1日から3.4時間に短縮されました。
• 品質指標: PR100件あたりのロールバック数が40%減少し、初期コード品質の向上を示唆しています。
• レビュー効率: PRあたりの人間のコメントスレッド数が6.2から1.3に減少し、高レベルの意思決定のみに焦点が当たりました。
• 不変条件の作成: 11,400件の過去のコメントを分析し、64件の承認済み不変条件と212件の候補ルールを作成しました。
• 検証速度: 19の主要な不変条件が0.3秒で決定論的に実行され、モデルの遅延なしに迅速なフィードバックを提供します。

なぜ重要なのか

AIコーディングエージェントを導入しているエンジニアリングチームにとって、このケーススタディは、人間が評価する内容を変えることで、従来のレビューボトルネックを解消できることを示しています。PRサイズが詳細な検査に対する人間の認知的限界を超えて拡大するにつれ、差分への依存は非効果的になります。ルールと動作の検証を自動化することで、エンジニアはアーキテクチャ上の意思決定とシステム理解に集中できます。この変化は、長期的な保守性にとって不可欠であるレビューの知識共有側面を保護しつつ、制約の反復的な検証を機械に任せることができます。

また、このアプローチは開発サイクルの早い段階で意図を捕捉することの重要性も浮き彫りにします。受け入れ基準がエンジニアとAIエージェント間のリアルタイムのインタラクションから導き出される場合、事後テスト作成よりも実際の要件をより正確に反映します。これにより、検証プロセスはビジネスロジックにとって重要なものをテストし、単に自動化しやすいものだけをテストするわけではありません。AIネイティブなワークフローを構築するチームは、品質を犠牲にせずに速度を維持するために、ルール適用と意思決定を分離することを検討すべきです。

実施できること

• レビューコメントの監査: 過去のPRコメントをルール、意思決定、一回限りの修正に分類し、自動化の候補を特定してください。
• システム不変条件の定義: コードベースから繰り返し現れる制約を抽出し、ast-grepなどのツールを使用して決定論的なチェックとしてエンコードしてください。
• コーディング中の意図の捕捉: エンジニアとAIエージェント間の対話を保存し、受け入れ基準を自動的に生成してください。
• 証拠に基づく検証の実装: 自動化されたエージェントを使用してプレビュー環境でユーザーのようなシナリオを実行し、ログを証拠として記録してください。
• 人間のレビュー焦点のシフト: レビュアーに対し、行単位の差分をスキップし、代わりに意図、証拠、未解決の設計判断を評価するように訓練してください。
• PR前のエージェント討論: AIエージェントがPR作成前に実装詳細について議論し、些細な問題を自動的に解決するように設定してください。