この論文が問うのは、モデルがレビューというタスクをどれだけうまくこなすかではなく、開発者が実際に望む形で大規模言語モデルをコードレビューのワークフローにどう組み込めるか、である。その前提は、システムの規模が拡大しデリバリーが加速するにつれて手作業のレビューが追いつかなくなっていること、そして LLM はコーディング作業にはスムーズに浸透した一方で、レビューでの活用は十分に探究されていないことである。著者らは 2 つの問いを立てている。現在のレビュー実践はどのような特徴を持ち、開発者は AI 支援の余地をどこに見出しているか。そして、開発者は LLM 支援のレビューツールをどのように認識し、どのように使うか。
手法は、開発で AI を使うことが一部のチームにのみ許可されている企業 WirelessCar Sweden AB における、2 フェーズの質的研究である。フェーズ 1 は 7 名の参加者 ── 4 つのチームにまたがるソフトウェアエンジニア、アプリケーション開発者、セキュリティエンジニア、品質保証スペシャリスト ── を対象とした探索的なフィールドスタディで、半構造化インタビューを行い主題分析で分析した。著者らは 7 件目のインタビューでデータ飽和に達したと報告している。フェーズ 1 の知見をもとに 2 つのプロトタイプのインタラクションモードが設計され、フェーズ 2 では 10 名の参加者によるフィールド実験でそれを評価した。うち 5 名はフェーズ 1 からの継続参加者で、5 名は社内の Slack チャンネルを通じて募集された。各参加者は同社のコードベースから選ばれた同程度の規模のプルリクエスト 2 件を、それぞれ異なるモードでレビューした。順序効果を緩和するためにモードの割り当てはローテーションされ、習熟度を比較できるよう、10 名のうち 4 名はそのコードを所有するチームに所属していた。
どちらのモードも同じアーティファクト上で動作した。OpenAI の o4-mini を用いた Web ベースのチャットインターフェースで、LlamaIndex で構築した検索拡張生成（RAG）のインデックスを備えていた。このインデックスは実験の前に手作業で準備・インデックス化する必要があり、3 つのセマンティックツール ── プルリクエストの差分とメタデータ用、リポジトリの全ソースコード用、変更の動機となった Jira チケット用 ── を公開していた。モード A の共同レビュアーは 4 つ目のツールを追加した。これはサブエージェントを含むツールで、プルリクエストの全データをコンテキストに注入したうえで構造化されたレビューを最初に生成するため、検索の取りこぼしによってファイルの変更が見落とされることがない。モード B の対話型アシスタントは受動的なままで、尋ねられたときにだけ答える。著者らがこの設計を選んだのは、軽量でオンデマンドなツールを求めるフェーズ 1 の要望に合わせるためと、自動的に行をハイライトするとレビュアーが他の箇所を見落としてしまうという報告されたリスクを避けるためである。
要点
- フェーズ 1 のインタビューでは、レビューの遅延、レビュアーが手をつけたがらない大規模または複雑なプルリクエスト、コンテキストスイッチ、プルリクエストの説明文におけるコンテキストの欠如が、同社の既存のレビュー実践で繰り返し現れる課題として特定された。
- インタビューしたチームのいずれも、AI をコードレビューに正式に統合してはいなかった。ただし汎用的な AI コーディングツールは開発タスクで広く使われており、使用を許可されたチームは、データが訓練に使われないエンタープライズ契約を通じて利用していた。
- 開発者が望む支援として挙げたのは、プルリクエストの要約、記載された要件とコードの照合、競合状態のような微妙な欠陥の検出であった。懸念は主に、セキュリティ上のリスクと、偽陽性が注意力を損なうことに関するものであった。
- フィールド実験では、AI 主導の共同レビュアーモードが概して好まれ、特に大規模または馴染みのないプルリクエストや低リスクの変更で好まれた。一方、対話型モードは、すでにコードベースに精通している参加者や、完全な制御を保ちたい参加者に好まれた。
- 選好は一様ではなく状況依存であり、レビュアーのコードベースへの習熟度とプルリクエストの重大度によって変化した。両方のモードを組み合わせることを望む参加者もいた。
- 参加者は、アシスタントが自分では見つけられなかったであろう問題を浮かび上がらせたと報告する一方で、誤った提案や不明瞭な提案、長い要約の中で重要な指摘と些細な指摘を区別する難しさ、そして AI 主導モードでは AI による最初の枠組みにアンカリングされるリスクも報告した。
- 参加者は、アシスタントを新しいインターフェースとして提示するのではなく、GitHub、Slack、IDE といった既に使っているツールに組み込むことを求め、応答時間の長さを導入の障壁として挙げた。
- 参加者は研究の設計外の使い方も自発的に提案した。プルリクエストを提出する前の事前レビューの補助として AI 主導モードを使うことや、まず人間主導でレビューを行い、その後で見落としを拾うためにアシスタントを使うことである。
- 著者らは、LLM は人間のレビュアーを置き換えるのではなく意味のある形で補強できると結論づけ、LLM を置き換えとして扱わない主な理由はハルシネーションであると述べている。
補足
これは単一企業での質的研究であり、参加者はフェーズ 1 のインタビューで 7 名、フェーズ 2 で 10 名で、便宜的サンプリングによって募集された。著者らはこの研究を、性能の測定ではなく開発者がアシスタントとどう関わるかを捉えるものと位置づけており、問題の検出を測定したり既存ツールと比較したりした先行研究とは明確に区別している。実験で使った 2 件のプルリクエストは中程度で同程度の規模のものが選ばれており、大規模なプルリクエストに関する論文の記述は参加者の発言に基づいている。アーティファクトは本番システムとしてではなく研究のために構築されたものであり、ある参加者は、そうしたアシスタントが非常に大規模なコードベースや複雑なビジネスロジックに対してどこまで通用するのか疑問を呈していた。