Ebay の Sachin Gupta 氏、全プルリクエストをスコアリングする実用フレームワーク「ReviewDebt」を提案

AI が生む「見えない負債」：Ebay のエンジニアが提唱するレビュー管理の新基準

AI エージェントによるコード生成が加速する現代において、私たちは「生産性の向上」という名の罠に陥りつつあります。Ebay のソフトウェアエンジニアである Sachin Gupta 氏が提唱した「Review Debt（レビューデット）」という概念は、AI が生成したコードと人間が実際に理解・検証したコードの間に蓄積される巨大なギャップを指します。

この負債は金融的な借金のように複利で膨れ上がり、最終的にチームの技術的健全性を蝕みます。Gupta 氏は、この見えないリスクを数値化し、管理するための実用的なフレームワーク「ReviewDebt」を発表しました。本記事では、その核心となる定義と、LLM の主観に頼らない客観的なスコアリング手法について解説します。

AI が加速させる「レビューデット」とは何か

Gupta 氏が指摘する最大の危機は、AI の導入によってコード生産量は劇的に増えた一方で、人間のレビューへの注目は相対的に減少しているという事実です。GitHub や Faros AI のデータによると、PR（プルリクエスト）のレビュー時間は平均で 4.4 倍に増加し、31% の PR が何らかの形でレビューされずにマージされています。

これは単なる「忙しさ」の問題ではありません。Gupta 氏はこれを「レビューデット」と定義します。

レビューデットとは、AI エージェントが生成したコードと、人間が実際にレビューし、信頼し、理解したコードの間に蓄積されるギャップのことです。

これは技術的負債に似ていますが、より金融的な性質を持ちます。利息は「お金」ではなく「人間の注意力」として支払われます。この負債が増殖するメカニズムには、以下の 3 つのフィードバックループが関与しています。

1. 生成性の増幅: エージェントは過去のコードベースから学習します。昨日深くレビューされなかったコードが、明日の PR の土台となり、欠陥が連鎖的に蓄積されます。
2. 判断の放棄: PR の大半が AI 生成の場合、レビュアーは構文や明らかなバグにしか注目を向けなくなります。大規模なアーキテクチャ判断はレビューの場から消え、「永遠に行われない」状態になります。
3. 速度への適応: リーダーシップが新しいスループットを目にするにつれ、レビューの質を維持する余裕が失われ、負債を返済する猶予さえなくなります。

5 つのシグナルファミリーで負債を可視化する

この見えない負債をどう測定するか。Gupta 氏は LLM（大規模言語モデル）に判断させるのではなく、「決定論的チェック」を用いたフレームワークを提案します。LLM を使わない理由は、スコアがモデルのバージョンによって変動する「移動する標的」になるのを防ぐためです。

このフレームワークは、PR とリポジトリから計算可能な 10 のチェック項目を持つ5 つのシグナルファミリーで構成されています。

1. デブサイズと結合度（Dev Size & Coupling）

変更された行数やファイル数だけでなく、「影響範囲」を測ります。AI エージェントは根本原因ではなく症状への対応に偏りやすく、結果として多数のファイルをまたぐ広範な変更を生みがちです。これはレビュアーのメンタルモデルを混乱させ、レビューコストを急峻に押し上げます。

2. テスト証拠のギャップ（Test Evidence Gap）

単にテスト行数が増えたかどうかではありません。AI が生成するテストは「コードが何をしているか」を断言するだけであり、「本来あるべき動作」を検証していないケースが多発します。Gupta 氏はこれを「テスト用シアター」と呼び、バグを含む動作を固定化するリスクを指摘しています。

3. ディレクトリと所有権の分散（Directory & Ownership Spread）

変更が特定のチームに集中しているか、複数のチームにまたがっているかを計測します。形の良い PR は一つのドメインに収まりますが、AI が生成した広範な変更は調整オーバーヘッドを膨大にし、一人の人間が全体像を把握できなくなります。

4. AI 執作者インジケーター（AI Author Indicator）

これは「責任追及」のためのものではありません。PR のメタデータ（共著者フッター、ブランチ名のプレフィックス、本文内の記述など）から AI が関与している可能性を検出します。これにより、AI 生成の PR は追加のレビュー注意を要する対象としてフラグされます。

5. 証拠と理屈のギャップ（Evidence & Reasoning Gap）

最も重要な指標の一つです。PR の本文が「なぜこの変更が必要なのか」という論理的根拠や、文脈を含んでいるかを評価します。タイトルやコミットメッセージが単なる「更新」で終わる場合、レビューは不可能となり、負債の蓄積に直結します。

0-100 のスコアリングとアクションプラン

これらのシグナルを組み合わせ、Gupta 氏は0 から 100 のスコアを算出するアルゴリズムを構築しました。このスコアは「AI を使ったか」ではなく、「レビュー負荷が高い状態か」を示す指標です。

スコアリングの実践方法

導入を検討しているチームは、まず過去 200 件の PR にこのスキャナーを実行し、重みを調整することをお勧めします。スコアは以下の 4 つのバンドに分類され、異なるアクションが推奨されます。

• 0-24（低負荷）: レビュー負担が極めて低い状態です。通常のフローで問題ありません。
• 25-49（標準）: 通常通りのレビュープロセスを適用します。
• 50-74（中〜高負荷）: シニアレビュアーの事前承認が必要であり、著者には証拠や文書の追加が求められます。
• 75 以上（高リスク）: 文脈の大幅な補足や、ハイプスプリット（大規模変更の分割）を要求するレベルです。

実例で見るスコアの真価

Gupta 氏は、公開リポジトリの PR をこのフレームワークに当てはめた実証結果を示しています。

• 健全な PR: スコアはほぼゼロ。レビュー負担も低く、構造化された出力は「見た目良好」という儀式的な報告のみとなります。ノイズを発生させないのが理想です。
• 負債の高い PR: スコア 60/100。AI が関与している可能性（ソフトな指標）に加え、サイズ主張の不整合やテスト不足がトリガーとなり、「証拠が必要」という具体的なアクションリストが生成されます。
• 高品質な AI 生成 PR: AI で作成されたにもかかわらず、リスクのあるパスを明確に記述し、適切なテストを追加した PR は、スコア 7/100 と低負荷として評価されます。これは「AI を罰する」ツールではなく、「レビュー負荷を管理する」ツールであることを示しています。

結論：生産性だけでなく信頼の速度も測る時代へ

524 件の PR にわたる分析結果から、Gupta 氏は明確な結論を導き出しました。「複雑さが負荷を駆動し、作成者が駆動するわけではない」のです。AI が生成したかどうかに関わらず、大規模な構造的変更や複数チームにまたがるリファクタリングこそがレビューデットの真の原因です。

このフレームワークは、企業に対して AI 導入による潜在的なリスクを数値化し、エンジニアリングチームのリソース配分やレビュープロセスの最適化をデータ駆動型で実行するよう促します。AI エージェントが普及する現代において、私たちは「どれほど速くコードを書けるか」だけでなく、「どれほど信頼できる速度でレビューできるか」という指標を新たに持つ必要があるのです。

レビューデットは複利で増え続けます。今こそ、その負債を可視化し、管理するためのガバナンスモデルを導入する時です。