Sourcegraph、AI活用でプルリクエストレビュー効率化へ

Sourcegraphは、ソフトウェア開発におけるプルリクエスト（PR）レビューのボトルネック解消を目指し、AIエージェントを活用した承認ボットの開発とその運用経験を報告した。

近年、コーディングエージェントの利用が進み、コード生成の速度は向上している。しかし、生成された変更の影響を理解し、それが本番環境に投入されるべきか否かを判断するレビュー工程に多くの時間が費やされ、開発フロー全体のボトルネックとなっているとSourcegraphは指摘する。同社ではこれまで、小規模なPRに対して「スタンプグループ」と呼ばれる仕組みを設けていたものの、レビュー担当者を探し、その都度コンテキストを切り替える必要があり、効率化が求められていた。GitHubの運用要件としてマージ前の承認が必須であるため、ルーチン的な変更も詳細な議論が必要な変更も同じ承認ステップを経る状況を課題としていた。

同社は、AIエージェントが変更のレビュー要否とそのタイミングを判断できる可能性に着目した。エージェントが差分と周辺コードを検査し、社内ルールに基づいて変更を評価、レビューパス選択の根拠を提供することで、レビュープロセスを改善できると考えた。具体的には、「Ship（レビュー不要）」「Show（マージ後に確認）」Ask（マージ前にレビュー必須）という三段階のレビューパスを導入した。

初期段階では、AIエージェントは推奨のみを行い、人間によるレビューは通常通り継続された。この期間に得られたフィードバックを基に、レビュールールと熟知度を判断する証拠要件を調整。これにより、実際に承認プロセスに組み込む前にボットの判断を検証する機会を得たという。Sourcegraphは、類似の研究として、コミット前後でのレビューを比較したシミュレーション研究や、MetaのRADARが示すリスクチェック、さらには2021年の「Ship/Show/Ask」に関する記事を参照している。

エージェントの仕組みは、PRの差分、関連コード、および変更作成者の過去の貢献を分析する。これらの分析結果に基づき、根拠とともに所見を返し、アプリケーションコードが Sourcegraph のルールを適用してレビューパスを選択し、その結果をPRに投稿する。コンポーネントへの熟知度は、他者によってレビューされた2件のマージ済みPRと、過去30日間のコード、テスト、または技術文書における関連する貢献を基準に評価される。このワークフローはGitHub Actions上で実行される。認証チェックや機密データの公開方法に関する変更は、作成者の経験に関わらず必ずレビューが必要となる。人間によるレビューが必要な際には、SourcegraphのCompareページを活用し、差分を検査し、関連コードをナビゲートする。

この取り組みから、レビューが問題発見、コンテキスト共有、顧客向け情報確認といった複数の目的を持つことが明らかになった。これらの目的を明確にすることで、他者の注意がいつ有用であるかを判断しやすくなったという。また、熟知度の境界設定には慎重さが求められる。貢献履歴は有効な証拠となるが、その経験が変更されるコードとどの程度密接に関連しているかを確認する必要があり、システムの一部での作業が全体への熟知を意味するわけではない。ボットの推論を示すことで、その前提を問い、ルールや評価の変更が必要か否かを判断するフィードバックループが確立された。また、ボットが人々の注意を引く頻度（コメントや繰り返し評価）が、新たな中断を引き起こす可能性があり、ボットがいつ発言し、更新し、あるいは沈黙すべきかを設計の一部として考慮する必要があることも学んだ。

現在、Sourcegraphでは「quick stamp」のリクエストが減少しており、これは肯定的な兆候と捉えられている。同社はこの取り組みを社内実験として継続し、共同作業のあり方がどのように変化するかを理解することを目指している。特に「Show」パスでは、マージ後に誰かが変更を確認することに依存するため、これらの変更が適切な注意を受け、作者とレビュー担当者が次の作業に進んだ後も同僚が情報共有を維持できるかを確認していく。さらに、ボットによる中断への対処と、人員やコードベースの変化に応じてボットの熟知度に関する見解を最新に保つことも課題としている。スタンプリクエストの減少だけではレビューの品質については判断できないため、今後のフォローアップ記事で、マージ後のレビューの行方やボットが中断に与える影響について詳述する予定だという。

---

参考: Sourcegraph Blog (アーカイブ) — 2026年11月10日 09:00 (JST)