{
  "issue": "2026-09-01",
  "generated_at": "2026-09-01T07:00:00+09:00",
  "theme": {
    "title": "コードレビューエージェントの設計 — 差別化は検出率ではなく、文脈の取り方と『直すところまで』の範囲に移った",
    "category": "code-review-agent",
    "lede": "GitHub Copilot Code Reviewは2026年3月にdiff単体からエージェント型のツール呼び出しへアーキテクチャを刷新し、8月27日にはレビューへの反応を構造化して回収する「Resolution reasons」を追加した。同時期にCursor BugbotはAutofixとルール学習ループを、QodoはPR履歴を踏まえた専門エージェント合議を、それぞれ独自に実装している。「バグを検出できるか」がコモディティ化した結果、各社の実装は文脈をどこまで動的に取りに行くか、指摘への反応をどう次のレビューに反映するか、検出後にどこまで自動で直すか、という3つの軸で分岐し始めている。",
    "tldr": [
      "GitHub Copilot・Qodo・Cursor Bugbot・Cloudflareの内製ツールが、diff単体の解析から脱却し、リポジトリ全体・PR履歴・過去の指摘への反応まで動的に文脈を取りに行く設計へ収束している",
      "レビューコメントへの反応（Won't fix・Incorrectなどの解決理由、ダウンボート、返信）を構造化データとして回収し、次のレビュー精度に反映するフィードバックループの実装が各社で進んでいる",
      "検出だけで終わらせず、隔離VM上のクラウドエージェントがテスト・パッチ提案まで行うAutofixや、責務ごとに専門エージェントへ委譲する多エージェント構成が、2026年前半に相次いで一般提供された"
    ],
    "sections": [
      {
        "heading": "コンテキストの取り方 — diff単体から「動的取得」「PR履歴」まで",
        "body_html": "<p>従来のコードレビューボットは、プルリクエストのdiffをそのままモデルに渡して指摘を生成する構成が主流だった。2026年に入って主要プロダクトが揃って踏み出したのは、レビュー時にエージェント自身がツール呼び出しでディレクトリ構造や関連コード、過去のPR履歴を動的に取得しにいく設計への転換だ。固定のコンテキストウィンドウに何を詰めるかを事前設計するのではなく、「この変更を評価するのに何が必要か」をエージェントの判断に委ねる。</p><p>この転換が起きたのは、diffだけでは「この変更がリポジトリ全体の設計や過去のレビュー基準とどう整合するか」を評価できないという限界に各社が行き着いたからだ。関数の呼び出し元を見なければ副作用の有無は判断できないし、チームのレビュー傾向を踏まえなければ「今回だけ許容すべきか」の線引きもできない。コンテキスト取得そのものをエージェント化することで、リポジトリが大きくなるほど固定ウィンドウ方式が頭打ちになる問題を回避している。</p>",
        "examples": [
          {
            "product": "GitHub Copilot Code Review",
            "approach": "diff解析からエージェント型のツール呼び出しアーキテクチャへ刷新",
            "detail": "2026年3月5日、レビュー時にディレクトリ構造や関連コード・参照箇所を動的に取得する構成へ変更。GitHubは「変更が大きな設計にどう収まるかを評価できるようになった」と説明している",
            "source_url": "https://github.blog/changelog/2026-03-05-copilot-code-review-now-runs-on-an-agentic-architecture/"
          },
          {
            "product": "Qodo 2.0",
            "approach": "Context EngineにPRレビュー履歴を一級市民として組み込み",
            "detail": "2026年2月4日発表。チームのレビュー基準が時間とともにどう変化してきたかを踏まえて指摘を出せるようにした、と公式ブログが明記している",
            "source_url": "https://www.qodo.ai/blog/introducing-qodo-2-0-agentic-code-review/"
          }
        ],
        "takeaway": "レビューエージェントを選ぶ・作るなら、diffの外側にどこまで動的にアクセスできる設計かを最初に見る。固定コンテキストに詰め込む方式は、リポジトリが育つほど精度が頭打ちになる。"
      },
      {
        "heading": "フィードバックを構造化して閉じるループ",
        "body_html": "<p>指摘の質を上げるもう一つの軸は、レビューへの人間の反応をどう回収するかだ。GitHub Copilot Code Reviewは2026年8月27日、レビューコメントを解決する際に「Addressed」「Won't fix」「Incorrect」の3択から理由を選ばせる「Resolution reasons」を追加した。Cursor Bugbotは同様の目的を、ダウンボートや開発者の返信をシグナルとして候補ルールを生成し、有効性を検証しながらcandidate→activeへ昇格、逆効果ならdemoteする学習パイプラインで実現している。</p><p>両者に共通するのは、「指摘が的外れだった」という情報を捨てずに構造化データとして蓄積し、次のレビュー精度の改善に回すという発想だ。プロンプトの手直しだけで精度を上げる方式は運用者の勘に依存するが、反応をシグナルとして自動的にルール化・重み付けする方式は、利用が増えるほど精度が上がる複利構造を作れる。</p>",
        "examples": [
          {
            "product": "GitHub Copilot Code Review",
            "approach": "コメント解決時に3択の解決理由を選ばせ、反応を構造化データとして回収",
            "detail": "2026年8月27日公開。ボットが開いたPRのレビューやbot作成PRのレビューにも対応範囲を広げ、300ファイル・2万行だった大規模PRの上限も同時に撤廃した",
            "source_url": "https://github.blog/changelog/2026-08-27-copilot-code-review-resolution-reasons-and-expanded-capabilities/"
          },
          {
            "product": "Cursor Bugbot（学習機能）",
            "approach": "ダウンボート・返信・人間レビュアーの見落としをシグナルにルールを自動生成し、有効性で昇格・降格",
            "detail": "2026年4月8日時点で11万超のリポジトリが学習機能を有効化し、4.4万超のルールを生成。2025年7月の機能公開時点で52%だった解決率は同時点で約78%まで上昇したとCursorは報告している",
            "source_url": "https://cursor.com/blog/bugbot-learning"
          }
        ],
        "takeaway": "レビューエージェントを継続運用するなら、指摘への反応（解決理由・リアクション）を捨てずに構造化して回収する仕組みを最初から組み込む。後付けでは学習の起点になるログが残っていない。"
      },
      {
        "heading": "責務の分割と自動修正 — 検出後の範囲をどこまで広げるか",
        "body_html": "<p>単一のプロンプトで「バグも品質もセキュリティもテストも見る」設計は、カテゴリ間で精度がトレードオフになる。Qodo 2.0はこれを、バグ検出・コード品質・セキュリティ・テストカバレッジの専門エージェントを並列実行する多エージェント構成に分割した。一方Cursor BugbotのAutofixは、検出したバグを放置せず、隔離されたVM上のクラウドエージェントに再現・テスト・パッチ提案まで行わせる方向に範囲を広げている。</p><p>両者は方向性が異なるように見えて、「検出はゴールではなく通過点」という認識では一致している。責務を分割すれば各エージェントが自分の専門でだけ精度を最適化でき、検出後の修正まで自動化すれば人間のレビュー負荷そのものを減らせる。ただしAutofixのような自動修正は誤った変更を提案するリスクも増えるため、前セクションのフィードバックループとセットで運用する設計が前提になっている。</p>",
        "examples": [
          {
            "product": "Qodo 2.0",
            "approach": "バグ・品質・セキュリティ・テストカバレッジの専門エージェントを並列実行する多エージェント構成",
            "detail": "単一タスクではなく責務ごとにエージェントを分割。公式ブログはCode Review Bench比較でF1スコア60.1%が最高、重大issueとルール違反の精度・再現率は他ツール比+11%だったと主張している",
            "source_url": "https://www.qodo.ai/blog/introducing-qodo-2-0-agentic-code-review/"
          },
          {
            "product": "Cursor Bugbot Autofix",
            "approach": "検出したバグを隔離VM上のクラウドエージェントに再現・テスト・パッチ提案までさせる",
            "detail": "2026年2月26日一般提供。承認後にマージするか自動プッシュするかを選べる設計で、提案された変更のうち35%超がベースPRにそのままマージされているとCursorは報告している",
            "source_url": "https://cursor.com/changelog/02-26-26"
          }
        ],
        "takeaway": "検出精度だけを見て導入を決めない。責務を分割できる構成か、修正まで自動化する場合はフィードバックで誤りを是正する仕組みとセットになっているかを確認する。"
      }
    ]
  },
  "editorial": "コードレビューエージェントの競争軸は、もう「バグを見つけられるか」ではない。どこまで文脈を動的に取りに行き、指摘への反応をどう次に活かし、検出後どこまで自動で直すか——この3層で実装が分かれ始めている。次の分水嶺は、Autofixのような自動修正ループを人間の承認なしにどこまで回せるかという信頼設計になりそうだ。",
  "quick_picks": [
    {
      "title": "Cloudflareの内製コードレビュアー、リスク階層で専門エージェントに委譲",
      "summary": "MRをtrivial/lite/fullの3段階に振り分け、セキュリティ・品質・Engineering Codex準拠の専門エージェントへ委譲し、指摘に具体的なルールIDを添えて追跡可能にしている。本文で扱った「責務の分割」を、規則ベースの説明可能性まで一歩進めた実装だ。",
      "url": "https://blog.cloudflare.com/internal-ai-engineering-stack/"
    },
    {
      "title": "Bugbot、3倍速・22%コスト減・検出10%増を専用モデルで実現",
      "summary": "Cursor Bugbotが専用モデルComposer 2.5とハーネス改善で高速化・低コスト化を達成したと2026年6月に発表。本文のAutofixや学習ループを毎PRで回す際の推論コストを支える基盤側の変化にあたる。",
      "url": "https://cursor.com/blog/bugbot-updates-june-2026"
    },
    {
      "title": "Copilotコードレビュー、GitHub Actions利用時間を消費する課金へ",
      "summary": "2026年6月1日からプライベートリポジトリでのレビュー実行がGitHub Actions利用時間を消費する仕様に変更されたと4月27日に公式発表。エージェント型レビューが「無料の付加機能」からコスト構造の一部になったことを示している。",
      "url": "https://github.blog/changelog/2026-04-27-github-copilot-code-review-will-start-consuming-github-actions-minutes-on-june-1-2026/"
    }
  ]
}