より優れたバグボットの構築

コーディングエージェントの能力が高まるにつれ、私たちはレビューに費やす時間が増えていることに気づきました。これを解決するために、Bugbot を構築しました。これは、本番環境に到達する前にプルリクエスト内のロジックバグ、パフォーマンスの問題、セキュリティの脆弱性を分析するコードレビューエージェントです。昨年の夏までにはその成果が非常に良好だったため、ユーザー向けに公開することを決定しました。 Bugbot の構築プロセスは定性的な評価から始まり、徐々に品質を高めるためにカスタム AI ドライブ型の指標を用いたより体系的なアプローチへと進化していきました。 リリース以降、40 件の主要な実験を実施し、Bugbot の解決率は 52% から 70% を超えるまでに向上しました。一方、1 回の実行あたりでフラグされるバグの平均数は 0.4 から 0.7 に引き上げられました。これは、プルリクエストあたりの解決済みバグ数が約 0.2 から約 0.5 と、ほぼ倍増したことを意味します。 バージョン 1 は 2025 年 7 月に、バージョン 11 は 2026 年 1 月にリリースされました。新しいバージョンでは、偽陽性の顕著な増加を伴わずに、より多くのバグを検出できるようになりました。 #Humble beginnings（謙虚な始まり） コードレビューエージェントの構築を試みた当初は、モデルがレビューを有益なものにするには十分ではありませんでした。しかし、ベースラインモデルが改善されるにつれ、バグ報告の品質を高めるためのさまざまな方法があることに気づきました。 私たちは、モデル、パイプライン、フィルタ、そして巧妙なコンテキスト管理戦略の異なる構成を実験し、その過程で社内のエンジニアに意見を求めました。ある構成の方が偽陽性が少ないように見える場合、それを採用しました。 私たちが初期に見つけた最も効果的な品質向上策の一つは、複数のバグ発見パスを並列実行し、その結果を多数決投票で統合することでした。各パスには異なる差分の順序が割り当てられ、モデルが異なる推論経路へと誘導されるようにしました。複数のパスが独立して同じ問題を指摘した場合、それはバグが実際に存在するというより強いシナルとみなしました。 内部での定性的な試行錯誤を数週間行った後、私たちは市場にある他のコードレビューツールよりも優れた性能を発揮し、リリースへの自信を持たせる Bugbot のバージョンにたどり着きました。そのフローは以下の通りでした： ランダム化された差分順序で 8 つの並列パスを実行 類似するバグを一つのバケットに統合 一度だけのパスで見つかったバグをフィルタリングするための多数決投票 各バケットを単一の明確な記述にマージ 不要なカテゴリ（コンパイラー警告やドキュメントエラーなど）をフィルタリング 偽陽性を検出するために結果を検証モデルに通す 過去のランで投稿されたバグとの重複排除 #プロトタイプから本番環境へ Bugbot を実用可能にするために、コアとなるレビューロジックに加えて、一連の基盤システムへの投資が必要でした。これには、Rust で Git 統合を再構築してデータ取得量を最小化し、GitHub の制約内で運用するためにレート制限モニタリング、リクエストバッチ処理、プロキシベースのインフラストラクチャを追加することが含まれていました。 採用が進むにつれ、チームは、不安全なマイグレーションや内部 API の誤った使用など、コードベース固有の不変条件をエンコードする手段も必要としていました。これに対応するため、システムにハードコーディングすることなく、これらのチェックをサポートする Bugbot ルールを追加しました。 これら一連の機能により、Bugbot は実行可能で現実のコードベースに適応可能なものとなりました。しかし、それだけでは品質が実際に向上しているかどうかは示されませんでした。進捗を測定する指標がないため、現場における Bugbot のパフォーマンスを定量的に評価できず、これが Bugbot をさらに推し進める際の上限となっていました。 # 重要なのは測ること この問題を解決するため、「解決率」と呼ばれる指標を考案しました。これは AI を用いて、PR マージの時点で、最終コードにおいて著者が実際に解決したバグがどれであったかを判定するものです。この指標を開発する際、内部で PR 著者と共にサンプル事例をすべてスポットチェックしましたが、LLM はほぼすべての事例を「解決済み」または「未解決」として正しく分類していました。 チームからは、Bugbot が自分たちに与えている影響をどう評価すべきかという質問をよく受けます。そのため、この指標をダッシュボードで目立つように表示しています。効果性を評価するチームにとって、これは逸話的なフィードバックやコメントへの反応よりもはるかに明確なシグナルです。解決率とは、Bugbot がエンジニアが修正する実際の課題を見つけているかどうかを直接的に示すものです。 チームの時間経過に伴う解決率とその他の主要指標を示す Bugbot ダッシュボード。 解決率の定義変更により、Bugbot の構築方法が変わりました。初めて、単なる感覚ではなく、実際の信号に基づいてヒルクライムを行うことが可能になりました。私たちは、オンラインでは実際の解決率を用い、オフラインでは人間が注釈をつけたバグを含む実コードの差分を厳選したベンチマークである BugBench を用いて変更を検証し始めました。 モデル、プロンプト、反復回数、バリデータ、コンテキスト管理、カテゴリフィルタリング、そしてエージェント型設計にわたって数十回の実験を行いました。驚くべきことに、多くの変更が指標を悪化させました。その結果、初期の定性的分析から得た私たちの多くの判断は正しかったことが明らかになりました。 # エージェント型アーキテクチャ 今秋、Bugbot を完全にエージェント型の設計に切り替えた際、最も大きな改善が見られました。このエージェントは差分を推論し、ツールを呼び出し、固定されたパスの列順に従うのではなく、どこをさらに深く掘り下げるかを判断できます。 エージェント型のアプローチにより、プロンプトの再考を迫られました。以前の Bugbot のバージョンでは、偽陽性を最小限に抑えるためにモデルを抑制する必要がありました。しかし、エージェント型のアプローチでは逆の問題が発生しました：あまりにも慎重すぎるのです。私たちは、疑わしいパターンをすべて調査し、潜在的な問題がある場合にフラグを立てる側に誤りを犯すよう促す、攻撃的なプロンプトへとシフトしました。 さらに、エージェント型アーキテクチャは実験のためのより豊かな表面領域を開拓しました。私たちは、静的コンテキストから動的コンテキストへ情報をより多くシフトさせることが可能になり、モデルが事前に受け取る初期コンテキストの量を調整し、それに応じてどのように適応するかを観察することができました。モデルは、すべてを事前に入力する必要なく、実行時に必要な追加コンテキストを自動的に取り込んでいます。 同じセットアップにより、ツールセット自体に対して直接イテレーションを行うことも可能になりました。モデルの振る舞いは、呼び出せるツールによって形成されるため、ツールの設計や利用可能性における小さな変化でも、結果に大きな影響を与えます。複数のイテレーションラウンドを通じて、私たちはそのインターフェースを調整・洗練させ、最終的にモデルの振る舞いが一貫して私たちの期待と一致するようにしました。 現在、Bugbot は Rippling、Discord、Samsara、Airtable、Sierra AI などの顧客に対して、月間 200 万件以上のプルリクエスト（PR）レビューを行っています。また、Cursor の社内コード全体においても Bugbot を稼働させています。 今後、他のプロバイダーや私たちの独自のトレーニング努力によって、異なる強みと弱みを持つ新しいモデルが定期的に登場すると予想されます。継続的な進展には、適切なモデルの組み合わせ、ハッチ（harness）設計、およびレビュー構造を見出すことが不可欠です。現在の Bugbot は、ローンチ時の数倍の性能を誇ります。数ヶ月後には、さらに大幅に改善されることを期待しています。 私たちはすでにその未来に向けて構築を進めています。このほど、PR レビュー中に発見されたバグを自動的に修正するために Cloud Agent を起動する「Bugbot Autofix」のベータ版をリリースしました。今後の主要な機能としては、Bugbot が自身のバグ報告を検証するためにコードを実行できるようにすることや、複雑な問題に直面した際に深い調査を行えるようにすることが含まれます。また、プルリクエストを待たずに継続的にコードベースをスキャンする常時稼働バージョンの実験も行っています。 これまでに大きな進歩を遂げてきましたが、Lee Danilek、Vincent Marti、Rohan Varma、Yuri Volkov、Jack Pertschuk、Michiel De Jong、Federico Cassano、Ravi Rahman、Josh Ma といった重要なチームメンバーの貢献がなければ実現できなかったことです。私たちの共通の目標は、AI 開発ワークフローがスケールするにつれて、あなたのチームがコード品質を維持できるよう支援し続けることです。 ドキュメントを読むか、今日から Bugbot をお試しください。 ![](/marketing-static/_next/image?url=https%3A%2F%2Fptht05hbb1ssoooe.public.blob.vercel-storage.com%2Fassets%2Fuploads%2Fbugbot-blog-image-1.jpg&w=1920&q=70) ![](/marketing-static/_next/image?url=https%3A%2F%2Fptht05hbb1ssoooe.public.blob.vercel-storage.com%2Fassets%2Fuploads%2Fbugbot-blog-image-2.png&w=1920&q=70)

より優れたバグボットの構築

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト