🧠 AI プロダクト動向

従来のコードレビューボットは、プルリクエストのdiffをそのままモデルに渡して指摘を生成する構成が主流だった。2026年に入って主要プロダクトが揃って踏み出したのは、レビュー時にエージェント自身がツール呼び出しでディレクトリ構造や関連コード、過去のPR履歴を動的に取得しにいく設計への転換だ。固定のコンテキストウィンドウに何を詰めるかを事前設計するのではなく、「この変更を評価するのに何が必要か」をエージェントの判断に委ねる。

この転換が起きたのは、diffだけでは「この変更がリポジトリ全体の設計や過去のレビュー基準とどう整合するか」を評価できないという限界に各社が行き着いたからだ。関数の呼び出し元を見なければ副作用の有無は判断できないし、チームのレビュー傾向を踏まえなければ「今回だけ許容すべきか」の線引きもできない。コンテキスト取得そのものをエージェント化することで、リポジトリが大きくなるほど固定ウィンドウ方式が頭打ちになる問題を回避している。

指摘の質を上げるもう一つの軸は、レビューへの人間の反応をどう回収するかだ。GitHub Copilot Code Reviewは2026年8月27日、レビューコメントを解決する際に「Addressed」「Won't fix」「Incorrect」の3択から理由を選ばせる「Resolution reasons」を追加した。Cursor Bugbotは同様の目的を、ダウンボートや開発者の返信をシグナルとして候補ルールを生成し、有効性を検証しながらcandidate→activeへ昇格、逆効果ならdemoteする学習パイプラインで実現している。

両者に共通するのは、「指摘が的外れだった」という情報を捨てずに構造化データとして蓄積し、次のレビュー精度の改善に回すという発想だ。プロンプトの手直しだけで精度を上げる方式は運用者の勘に依存するが、反応をシグナルとして自動的にルール化・重み付けする方式は、利用が増えるほど精度が上がる複利構造を作れる。

単一のプロンプトで「バグも品質もセキュリティもテストも見る」設計は、カテゴリ間で精度がトレードオフになる。Qodo 2.0はこれを、バグ検出・コード品質・セキュリティ・テストカバレッジの専門エージェントを並列実行する多エージェント構成に分割した。一方Cursor BugbotのAutofixは、検出したバグを放置せず、隔離されたVM上のクラウドエージェントに再現・テスト・パッチ提案まで行わせる方向に範囲を広げている。

両者は方向性が異なるように見えて、「検出はゴールではなく通過点」という認識では一致している。責務を分割すれば各エージェントが自分の専門でだけ精度を最適化でき、検出後の修正まで自動化すれば人間のレビュー負荷そのものを減らせる。ただしAutofixのような自動修正は誤った変更を提案するリスクも増えるため、前セクションのフィードバックループとセットで運用する設計が前提になっている。