より良い Bugbot を構築する
コーディングエージェントが高機能になるにつれて、私たちはレビューに費やす時間が増えていることに気付きました。これを解決するために、私たちは Bugbot を構築しました。Bugbot はコードレビューエージェントであり、本番環境に入る前にプルリクエストを解析して、ロジックバグ、パフォーマンス問題、セキュリティ脆弱性を検出します。昨夏の時点で十分にうまく機能していたため、ユーザー向けにリリースすることにしました。
Bugbot の構築プロセスは、まずは定性的な評価から始まり、その後、品質を高めるために独自の AI 駆動型メトリクスを用いた、より体系的なアプローチへと徐々に進化していきました。
ローンチ以降、私たちは 40 件の大規模な実験を行い、Bugbot の解決率を 52% から 70% 超まで引き上げるとともに、プルリクエストあたりに検出されたバグの平均件数を 0.4 件から 0.7 件に向上させました。つまり、PR あたりに解決されたバグの件数は、およそ 0.2 件から約 0.5 件へと 2 倍以上になりました。
ささやかな始まり
最初にコードレビュー用のエージェントを作ろうとしたとき、モデルの性能はレビューが有用と言えるほど十分ではありませんでした。しかしベースラインとなるモデルが改善されるにつれ、バグ報告の品質を高めるためのさまざまな手段があることに気づきました。私たちはモデル、パイプライン、フィルター、そしてコンテキスト管理戦略のさまざまな構成を試し、その過程で社内のエンジニアから継続的にフィードバックを集めました。ある構成で誤検知が少ないように見えた場合は、その構成を採用しました。
初期に見つけた最も効果的な品質改善のひとつは、複数のバグ検出パスを並列で走らせ、その結果を多数決で統合する方法でした。各パスには異なる順序に並べた diff を与え、モデルが異なる筋道で推論するように誘導しました。複数のパスが独立に同じ問題を指摘した場合、そのバグが実在するというより強いシグナルとして扱いました。
数週間にわたる社内での定性的な検証と反復を経て、市場にある他のコードレビューツールを上回り、安心してローンチできるレベルの Bugbot のバージョンにたどり着きました。そこで採用したフローは次のとおりです。
- ランダム化した diff の順序で 8 回のパスを並列実行する
- 類似したバグを 1 つのバケットにまとめる
- 1 回のパスでしか検出されなかったバグを多数決でふるいにかける
- 各バケットを 1 つの明確な説明に統合する
- コンパイラ警告やドキュメントの誤りなど、不要なカテゴリをフィルタリングする
- 検証用モデルに結果を通し、誤検知を検出して取り除く
- 以前の実行で報告済みのバグと重複しているものを除外する
プロトタイプからプロダクションへ
Bugbot を実務で使えるレベルにするために、コアのレビューロジックと並行して、一連の基盤システムにも投資する必要がありました。具体的には、Rust で Git 連携機能を再構築して取得データ量を最小限に抑えることでリポジトリへのアクセスを高速かつ信頼性の高いものにし、さらに GitHub の制約の中で動作させるために、レート制限のモニタリング、リクエストのバッチ処理、プロキシベースのインフラを追加しました。
利用が拡大するにつれて、チームは unsafe なマイグレーションや内部 API の誤使用といった、コードベース固有の不変条件をコードとして表現する方法も必要としていました。これに応えるため、そうしたチェックをシステムにハードコードせずに実現できるよう、Bugbot rules を追加しました。
これらの要素を組み合わせることで、Bugbot は現実のコードベースで実行しやすく、かつ適応性の高いツールになりました。しかし、それだけでは品質が実際に向上しているかどうかは分かりません。進捗を測る指標がなければ、実環境における Bugbot のパフォーマンスを定量的に評価することはできず、どこまで改善を進められるかに上限が生まれてしまいます。
本当に重要なものを測る
この問題を解決するために、私たちは「解決率」という指標を考案しました。これは、PR がマージされるタイミングで、最終的なコードの中でどのバグが実際に PR の作成者によって解決されたかを AI を使って判定するものです。この指標を開発する際、私たちはすべての例を社内で PR の作成者とともにスポットチェックし、LLM がそれらのほぼすべてを「解決済み」か「未解決」か正しく分類できていることを確認しました。
チームからは、Bugbot がどの程度効果を発揮しているかをどう評価すればよいかとよく質問されるため、この指標を ダッシュボード上で目立つように表示しています。効果を評価したいチームにとって、これは、個々の体験談にもとづくフィードバックやコメントへのリアクションよりも、はるかに明確なシグナルになります。解決率は、Bugbot がエンジニアが実際に修正する実在の問題を見つけているかどうかを直接示します。
ヒルクライミング
解決率を定義したことで、Bugbot の構築方法が変わりました。初めて、単なる感覚ではなく実際のシグナルに基づいて、ヒルクライム的に改善を重ねられるようになりました。オンラインでは実際の解決率を用いて変更を評価し、オフラインでは BugBench（人手でバグが注釈された実際のコード差分を集めたベンチマーク）を用いて評価を行いました。
私たちは、モデル、プロンプト、反復回数、バリデータ、コンテキスト管理、カテゴリフィルタリング、エージェント指向の設計など、さまざまな観点で何十もの実験を行いました。驚いたことに、多くの変更は指標を悪化させてしまいました。結果的に、初期の定性的分析から得た多くの判断が正しかったことが分かりました。
エージェント型アーキテクチャ
この秋、Bugbot を完全なエージェント型の設計に切り替えたときに、最も大きな改善が見られました。エージェントは diff を読み解き、ツールを呼び出し、決められた固定の手順に従うのではなく、どこを深掘りするかを自律的に判断できるようになりました。
このエージェントループによって、プロンプト設計を根本から見直す必要が出てきました。初期バージョンの Bugbot では、誤検知を最小限に抑えるためにモデルを抑制する必要がありました。しかしエージェント型アプローチでは逆の問題に直面しました――モデルが慎重すぎたのです。そこで、疑わしいパターンをすべて調査し、潜在的な問題を積極的にフラグ付けするようエージェントを促す、より攻めたプロンプトに切り替えました。
さらに、エージェント型アーキテクチャによって、よりリッチな実験の余地が生まれました。静的コンテキストに固定していた情報の多くを dynamic context に移し、モデルが事前に受け取るコンテキスト量を変え、その適応の仕方を観察できるようになりました。モデルは、事前にすべてを与えなくても、実行時に必要な追加コンテキストを一貫して自分で取り込めることが分かりました。
同じセットアップにより、ツールセット自体にも直接イテレーションを回せます。モデルの挙動は呼び出せるツールによって形作られるため、ツールの設計や利用可否のわずかな変更でも、結果に予想以上のインパクトが生じました。複数回のイテレーションを通じて、そのインターフェースを調整・洗練させた結果、モデルの挙動は私たちの期待と一貫して整合するようになりました。
今後の展望
現在、Bugbot は Rippling、Discord、Samsara、Airtable、Sierra AI などの顧客向けに、月あたり 200 万件を超える PR をレビューしています。また、Cursor 社内のすべてのコードにも Bugbot を適用しています。
今後は、他社プロバイダーのものと自社でトレーニングしたものの両方から、異なる長所と短所を持つ新しいモデルが定期的に登場すると見込んでいます。継続的な進歩には、モデル、ハーネス設計、レビュー構造の最適な組み合わせを見つけることが不可欠です。現在の Bugbot は、リリース時点の Bugbot と比べて何倍も優れています。数か月後には、そこからさらに大きく進化していると考えています。
私たちはすでに、その未来に向けて開発を進めています。先日、PR レビュー中に見つかったバグを修正するために自動的に Cloud Agent を起動する Beta 版の Bugbot Autofix をリリースしました。次の大きな機能としては、Bugbot が自らのバグレポートを検証するためにコードを実行できるようにすること、そして複雑な問題に直面したときにより深い調査を行えるようにすることなどが含まれます。また、プルリクエストを待つのではなく、コードベースを継続的にスキャンし続ける常時稼働バージョンの実験も進めています。
ここまでの大きな前進は、Lee Danilek、Vincent Marti、Rohan Varma、Yuri Volkov、Jack Pertschuk、Michiel De Jong、Federico Cassano、Ravi Rahman、Josh Ma をはじめとする主要メンバーの貢献なしには実現できませんでした。私たちの目標はこれからも一貫して、AI 開発ワークフローがスケールしていく中で、皆さまのチームがコード品質を維持できるよう支援し続けることです。
ドキュメントを読む または 今すぐ Bugbot を試す。