この論文が問うのは、モデルについてではなくフェーズについての問いである。すなわち、LLM がコードをレビューできるかどうかではなく、プルリクエストのライフサイクルのどの段階で開発者が実際に LLM を使うのか、そしてその結果プルリクエストがより早くクローズされるのかである。著者らは、先行研究がコードレビューへの LLM のタスク固有の応用を研究してきた一方で、プロセスの効率に対するフェーズ固有の影響は十分に検討されていないことを、研究上のギャップとして位置づけている。
データセットは、9,254 の GitHub プロジェクトから抽出した 25,473 件のプルリクエストである。プルリクエストは、コントリビューターがそう述べている場合に GPT 支援とみなされる。著者らはキーワードマッチングと正規表現によるフィルタリングでそれらを検出し、ラベル付けの精度が 95% に達するまで手作業で検証した。評価者間の一致度は「かなりの一致（substantial）」の水準であり、不一致は著者間の合意によって解決したと報告している。全体的な解決時間に関する問いについてはマージされたプルリクエストのみを残し、その結果残った 1,367 件の GPT 支援プルリクエストを、マッチングした非支援のプルリクエスト群と比較している。分析は、マージまでの時間を GPT 支援の指標変数に回帰させ、コミット数、変更の規模、変更されたファイル数、プロジェクトの年数を統制変数とする重回帰分析であり、フェーズごとの比較には Mann-Whitney の U 検定を併用している。
主要な結果は時間の差である。GPT 支援のプルリクエストはマージまでの時間の中央値が約 9 時間で、非支援のものの約 23 時間に対して 61% 短く、回帰分析でも GPT の指標変数は有意であった。フェーズ別に見ると、レビューフェーズは中央値 3 時間から 1 時間に、変更が行われるまでの待ち時間は 24 時間から 3 時間に短縮されている。一方、変更フェーズそのものには有意な差は見られず、提出時や承認後に GPT が使われた形跡もなかった。310 件の GPT 支援プルリクエストのラベル付きサンプルは、支援が何のために使われているかを示している。レビューフェーズでは、既存コードの改善がリクエストの約 60%、バグ修正が約 26%、ドキュメントが約 12% を占め、新規実装やテストは比較的まれである。
要点
- GPT 支援のプルリクエストを、コントリビューター自身による明示的な言及によって特定している。キーワードと正規表現で検出し、手作業で 95% のラベル付け精度まで検証しているため、測定されているのは利用そのものではなく、開示された利用である。
- GPT 支援のプルリクエストは、マージまでの時間の中央値が約 9 時間で、非支援のものの約 23 時間に比べ、ライフサイクル全体で 61% 短いと報告している。
- コミット数、プルリクエストの規模、変更されたファイル数、プロジェクトの年数も統制した、マージまでの時間の重回帰分析において、GPT 支援の指標変数が統計的に有意であり、係数は負であることを示している。
- レビューフェーズは 66.7% 短く（中央値 1 時間対 3 時間）、論文の表で「変更待ち（waiting for change）」と呼ばれるフェーズは 87.5% 短い（3 時間対 24 時間）ことを示しており、いずれも Mann-Whitney の U 検定で有意である。論文のアブストラクトと結論では、この同じ短縮を「承認前の待ち時間」として説明している。
- 変更フェーズには有意な差はなく、両群とも中央値は 1 時間である。
- 提出時や承認後の待機中に GPT が使われた形跡はなく、その利用はレビュープロセスの反復的な中盤に集中していると結論づけている。
- 310 件の GPT 支援プルリクエストのラベル付きサンプルから、レビューフェーズでは改善が約 60%、バグ修正が約 26%、ドキュメントが約 12% を占め、実装やテストは比較的まれであると報告している。1 件のプルリクエストが複数のカテゴリを持ちうるため、カテゴリは重複し、合計が 100% を超えることがある。
- この資料における GPT を、新しいコンポーネントを作るためではなく、既存のコードを改善するための支援ツールとして特徴づけている。
- レビューにおける GPT への過度の依存を未解決の研究課題として挙げ、開発者が提案を受動的に採用するのではなく判断できるよう、提案の品質、確信度、関連性を報告するツールを提案している。
補足
この研究は観察研究であり、著者らはそれがもたらす限界を率直に述べている。短縮を GPT のみに帰することは依然として難しい。タスクの単純さ、開発者の経験、チームの力学が同じパターンを生み出しうるからである。回帰分析はこれらの一部を統制しているものの、著者らは残余交絡が残りうると述べ、より強力な設計としてマッチングや傾向スコア分析を提案している。また、時間の短縮が GPT の貢献ではなく、より効率的な開発者や本質的に単純なタスクを反映している可能性も挙げている。
検出方法は、この知見が意味しうる範囲を限定している。プルリクエストは誰かが GPT に言及した場合にのみ GPT 支援とラベル付けされるため、開示されていない利用は比較群に含まれ、無関係な文脈でその語が出現した場合も拾われうる。著者らはこの両方を妥当性への脅威として挙げている。フェーズの測定は GitHub のタイムスタンプとイベントに基づいており、著者らはこれを客観的な基盤としつつも、やり取りの複雑さといった質的な側面は捉えられないと説明している。一般化は GitHub、それもスター数 10 以上のリポジトリに限られており、著者らはこの選択によって、レビューの慣行が異なる、あまり人気のないリポジトリや非公開リポジトリが除外されている可能性があると指摘している。
数値を確認する読者のために、内部の食い違いを 1 つ記しておく。アブストラクトではタスク目的のサンプルを 300 件のプルリクエストとしているが、手法のセクションでは 310 件としている。また、アブストラクトはタスクの割合を、論文自身の表が付しているフェーズの限定なしに提示している。