コードレビューは、時間がかかり品質にもばらつきがあります。diffはキューで待機し、フィードバックは誰がオンラインかに左右されます。

AIコードレビューが役立つのは、レビュアーが実際のコードベースのコンテキストを持っている場合だけです。

AIコードレビューは、レビュアーがリポジトリ全体、最近の変更、テスト、明確なルール一式を把握しているときに最も効果を発揮します。このコンテキストがあれば、単一のdiffだけを見るスタンドアロンのボットでは決して見つけられない問題も検出できます。レビューは、変更を生み出したシステムの一部として行うことで、最も効果を発揮します。

#コードレビューで何が変わったのか

コーディングエージェントが長大なPRを生み出したわけではありません。ですが、従来のレビューの前提は、より早く通用しなくなりました。

コーディングエージェントを使う開発者は、より大きな変更を出すようになっています。数百万件のCursorセッションのデータによると、PRあたりの追加行数 (p75) は前年比で約2.5倍に増加しました。変更行数1,000行超のメガPRがマージに占める割合も伸びており、2026年1月にはエージェントとモデルの改善に伴って明確に増加しています。エージェントのセッションもより深くなっています。直近2か月では、セッションあたりの平均ツール呼び出し数が約30%増加しました。AIが書いたコードも、より多くがそのまま残るようになっています。受け入れられたAIのコード行のうち、60分後も残っている割合は、2026年初頭以降、およそ76%から81%に上昇しました。別途手動でdiffを受け入れる工程を挟まず、そのままコミットに至ったエージェント生成の変更も、この期間で5倍超に増えています。

人間のレビュー能力は、その変化に合わせて拡大しませんでした。従来のピアレビューの指針では、品質を保てるのは、注意深く読める範囲である数百行程度までだと、以前から考えられてきました。

AIコードレビューは、変更量がすべてのdiffを読めるシニアエンジニアの人数でさばける範囲を超えても、品質ゲートを維持するための手段です。

レビュー対象のコードのうち、AI支援を受けて書かれたものの割合が増えています。人間は、「これはこのチームの作り方に合っていない」と見抜くのは得意です。一方で、大きく、もっともらしく、ほぼ正しいエージェントのパッチの中から、ひとつの微妙な破綻を見つけるのは苦手ですが、まさにそこで、実際のリポジトリのコンテキストを持つレビュアーが役立ちます。大きな変更を書くことと、それを検証することは別のスキルであり、レビューはその検証にあたります。

#AIコードレビューを開始する前のご質問

AIコードレビューツールを評価している場合は、まずこれらのポイントを確認してください。

#AIコードレビューとは？

AIコードレビューは、変更内容 (通常はPR、ときにはローカルのdiff) を読み取り、マージ前にバグやリグレッション、リスクを指摘するソフトウェアです。役に立つものは、目の前の変更行だけでなく、その先の文脈まで踏まえて判断します。関連するファイル、テスト、config、チームルールも参照します。質の低いものは、diffを文章で言い換えるだけだったり、コメントや命名について細かくうるさく指摘したりするだけです。

#リンティングや CI とどう違うのですか？

Linter や型チェッカーは、すでにルール化できるとわかっていることをコード化したものです。CI は、自動化したチェックを実行します。AIレビュー は、その取りこぼしを拾うためのものです。たとえば、ロジックの誤り、race conditions、認証のミス、数個離れたフォルダで壊れる問題、docs と挙動の不一致などです。CI と重なる部分はあります。ですが、置き換えるものではありません。

#AIコードレビューは人間によるレビューに取って代わりますか？

いいえ。変わるのは、人間がどこに時間をかけるかです。実際、人間によるレビューコメントのうち、同じPRで実際の変更につながるのは半分ほどにすぎません。健全なレビュー文化には、後で直せばよい指摘や、参考までに共有するコンテキストも含まれます。確信度が高く機械で扱いやすいバグを先に片づけることで、人がアーキテクチャ、プロダクトのリスク、そしてモデルがまだ持っていない暗黙知に集中できるようにします。

#AIレビューがノイズになりやすいのはなぜでしょうか？

ノイズは、人々がボットから受け取りたくないコメントから生まれます。スタイルに関する細かな指摘、失敗するテストを伴わない曖昧な「テストを追加して」という指摘、バグを検出できないリライトの提案は、いずれもレビューを無視するよう人々を慣れさせます。モデルが検出できることと、人々が実際に指摘してほしいことを分けて捉えましょう。AIコードレビューでは、本物のバグ、意図しないコミット、パフォーマンスやセキュリティ上のIssue、そしてドキュメントとコードの内容が食い違っている箇所を指摘すべきです。GraphiteがAIレビューの対象をその重なる部分に絞ったところ、約52%のコメントがコード変更につながり (人間のレビュアーとほぼ同じ割合) 、低評価は4%未満でした。

#何を測定すべきでしょうか？

解決率: マージ時点で、指摘されたIssueは最終コードで実際に修正されているか。解決率はコメント数より重要です。

これは、CursorがBugbotの改善に使った指標でもあります。40回の実験を通じて、解決率は52%から70%以上へ、1回の実行あたりに指摘されるバグは0.4件から0.7件へ、PRあたりで解決されるバグはおよそ0.2件から約0.5件へと向上しました。対象は月間200万件を超えるレビュー済みPRです。2026年5月までには、default-effortでの解決率は、マージ時点で約80%に達していました。解決率が下がっているのにコメント数が増えているなら、そのボットはノイズを生み出しています。

Bugbotダッシュボードでは、リポジトリごとに解決率の推移と、見つかったIssueおよび修正されたIssueの件数をグラフ表示します。これにより、ボットがコメントする範囲を広げる前に、レビューが実際の問題を検出し、解決につながっているかを確認できます。

#レビューはいつ実行すべきか: ローカル、PR 上、あるいは両方？

両方です。ただし、それぞれ役割が異なります。ローカルレビューは (エージェントのタスク後、プッシュ 前に) 、コンテキストがまだ新鮮で、スレッドもまだ存在しない段階で Issue を検出します。PR レビューはチームとしての約束事です。共有ルール、共有の履歴、そして共有のマージゲートになります。セキュリティ重視のチェックは、どのようにリリースするかに応じて、どちら側にも置けます。

#レビューツールはエージェントと同じ製品にある必要がありますか？

スタンドアロンのレビューツールを購入することもできます。実際、多くのチームがそうしています。その代わりに生じるコストは、コンテキストスイッチと、コードがどのように作られたかの把握が浅くなることです。変更を生成したのと同じシステムでレビューが実行されるなら、開いているファイル、リポジトリマップ、そしてコードと一緒に管理しているルールをすでに把握しています。修正はエディタ内の該当箇所へディープリンクしたり、指摘内容を読み込んだエージェントを起動したりできます。こうしたループは、後付けの仕組みでは再現しにくいものです。

#CursorでAIコードレビューを実行する方法

Cursorでは、エディタ内でローカルレビューを行い、PRでBugbotを実行し、同じツールチェーンで修正を繰り返します。

ローカル。 エージェントでの作業後、Agent Reviewを実行します。エージェント入力欄で/agent-reviewと入力するか、Source Controlタブから実行してローカルの変更をメインブランチと比較するか、コミットごとに自動レビューを有効にできます。プッシュ前には、/review-bugbotおよび/review-securityスキルを使って、BugbotまたはSecurity Agentをローカルで実行することもできます。セッションにコンテキストが残っているうちに、明らかな問題を解消しましょう。

PR上。 Bugbotは、GitHub、GitLab、Bitbucket上のPRをレビューします。チームの不変条件は、チームルールやリポジトリルールに加え、.cursor/BUGBOT.mdに記述します。学習ルール (@cursor remember) は、フィードバックを今後の実行に反映します。コメントカテゴリを広げる前に、Bugbot Automationsで解決率を確認してください。

修正ループ。 指摘は、Cursorに戻るためのリンク (Fix in CursorおよびFix in Web) とともにPRに表示されます。Bugbot Autofixは、修正案を作成するクラウドエージェントを起動できます。セキュリティについては、CursorのSecurity Agentsが2つの役割を担います。Security Reviewerはマージ前にPRをチェックし、Vulnerability Scannerは保存状態のコードベースをスキャンします。

開始。 ドキュメントでは、リポジトリの接続、レビューをトリガーするリポジトリとユーザーの選択、作業量の設定、.cursor/BUGBOT.mdなど、セットアップを一通り説明しています。cursor.com/docs/bugbotを参照して進めてください。

#振り分けと承認を自動化

バグを見つけるだけがレビューの仕事ではありません。2つのCursor自動化機能が、定型的な作業を処理します。

低リスクの変更を自動承認。 Approval Agentsは各PRのリスクを評価し、設定した基準を満たすものを承認します。文言の微調整や設定の更新は、人間の承認を待たずにマージできます。リスクしきい値を超えるものは保留されます。BugbotとSecurity Agentの指摘もこの判断に反映されるため、リスクのある変更がそのまま承認されることはありません。

適切なレビュアーに振り分け。 PRに人の対応が必要な場合、Approval Agentsは、定義した領域ごとのルーティングポリシーに基づき、変更が影響するコードベースの箇所に応じてレビュアーを割り当てます。変更は共通キューではなく、そのコードを担当するチームに送られます。

#コードの近くでレビューする

AIコードレビューは、エージェントによって変更の規模とスピードが増しても、チームが品質ゲートを維持するための手段です。うまく機能するものには、リポジトリのコンテキスト、絞り込まれたコメントポリシー、そして指摘が修正されているかを確認する指標があります。

レビューは、コードが生まれた場所の近くに置き、同じルールと同じ修正フローに乗せるべきです。変更の多いリポジトリでBugbotを有効にし、Bugbot Automationsで1週間ほど解決率を確認してから、どのカテゴリにより多くの量を割くべきかを判断してください。