エージェント型コードレビュー

• コーディングエージェントの急激な性能向上により、エンジニアリングの難所はコードを書くことから、そのコードを信頼してよいか判断することへ移り、レビューが最もレバレッジの高い作業になった
• AIはアウトプットを大幅に増やす一方で品質とレビューしやすさを下げ、4倍のコードに対して実際の価値は約10%しか増えないというギャップが測定されている
• 必要なレビュー強度は変更の**blast radius（影響範囲）**によって変わり、ソロ開発者と10年物の大規模システムを保守するチームでは制約がまったく異なる
• エージェントは推論するが、その推論はPRに添付されず捨てられるため、レビュアーは失われた意図（intent）を最初から再構成しなければならない負担を負う
• 書くことは安くなったが理解することは依然として高コストであり、信頼できるレビューシステムを構築したチームが今後優位に立つ

---

2026年のデータが実際に示していること

• 何年も逸話や議論にとどまっていた主張が、いまや利害の異なる（中には競合関係にある）組織によって大規模に測定され、AIはアウトプットを急増させる一方で品質とレビュー可能性を下げるという同じ結論に達している

• Faros AIの測定（2026年3月データ）

  • 4,000チーム・22,000人の開発者を対象に、低AI導入から高AI導入への移行を追跡
  • 良い面: 開発者はより多くのPRをマージし、より多くの作業を完了し、エンジニア1人あたりの処理量が増加
  • 悪い面の数値
    • コードchurn 861%増加
    • インシデント対PR比率 242.7%増加
    • 開発者あたりの欠陥率 9% → 54%
    • レビュー所要時間の中央値 441.5%増加（初回レビューまでの時間・平均レビュー時間ともに約2倍）
    • レビューなしでマージされたPRが31.3%増加
  • レビューなしのマージは誰かが選んだのではなく、レビュアーが物量に追いつけず、読まれていないコードがマージされることが常態化した結果である
  • 成熟して規律あるエンジニアリング慣行を持つチームでも同様に打撃を受け、良いプロセスでも守れない（物量がプロセス設計の速度を上回って流れ込むため）

• CodeRabbitの研究（2025年12月）

  • オープンソースPR 470件（AI共同作成320、人間のみ150）を分析し、AIによる変更は約1.7倍多くの問題を伴っていた
    • ロジック・正確性の問題は約75%増加
    • セキュリティ問題は1.5〜2倍増加
    • 可読性の問題は3倍以上増加
  • AIディレクターのDavid Lokerは「予測可能で測定可能な弱点であり、組織は積極的に緩和すべきだ」と述べる — 既知で位置特定可能な弱点なので、レビュー工程をそこへ正確に向けられる

• GitClearの生産性データ（2025年まで）

  • 毎日AIを使うユーザーは非利用者に比べて約4倍の生のアウトプットを出すが、1年前の自分と比べた実際の生産性向上は約**12%**にすぎない
  • 4倍のコードを人間がすべてレビューしなければならない構造である
  • Bill Hardingは、その12%ですら一部は選択バイアス（強い開発者がAI利用群に集中）だと明言している

• GitHubの報告

  • Copilotレビューは累計6,000万件超実行され、1年で10倍に増加、プラットフォーム上のレビュー5件に1件以上でエージェントが関与
  • もはやニッチな慣行ではなく、コードが作られる方法そのものになっている
• 4つのデータセット・4つの方法論が1つの結論へ収束している。ボトルネックは消えたのではなく、検証（verification）段階へ移動したのである

みんな別々の問題を解いている

• 上の警告的データの大半はエンタープライズのテレメトリーと、圧倒されているオープンソースメンテナーから出てきたものであり、少人数向けのものを作る1人開発者にはかなりの部分が当てはまらない

• 位置を決める3つの変数

  • blast radius: 壊れたときに何が起きるか — 何も起きないのか、怒ったユーザー・金銭・PII流出なのか
  • コードの寿命: 来週また書き直す使い捨てプロトタイプなのか、何年も保守するコードベースなのか
  • 理解しなければならない人数: 全部を頭に入れている自分1人だけなのか、時間をかけて所有権を共有するチームなのか

• ソロ・グリーンフィールド・ユーザーなし

  • レビューの第二の役割であるチーム内の知識分配が存在しない（自分がそのままチームだから）
  • 合理的な選択は、テストと自動化に強く依存し、本当に重要な部分だけレビューし、残りは軽く触れること
  • ただし、これはテストが本物である場合にしか機能しない。セーフティネットなしでレビューを飛ばすと、仕事が消えるのではなく**より高いコストで先送り（defer）**される
  • 「ユーザーがいない」はレビューを先送りする許可であって、検証を省略する許可ではない

• 危険な中間地帯

  • プロジェクトにユーザーがついた瞬間、バグを見つける役割が突然重要になり（バグが人に害を与えるため）、知識共有の役割も同時に立ち上がる
  • チームがソロ時代の習慣を数か月引きずったままポストモーテムを迎えれば、Farosの数値がそのまま自分たちのダッシュボードになる

• 大規模組織・古いコードベース・多数のユーザー

  • あらゆる警告的な数値が最大強度で当てはまり、誰も理解していない変更は**comprehension debt（理解負債）**となって、やがて誰かのオンコールインシデントに変わる
  • 重要なのは「企業は慎重、ソロは気楽」ということではなく、立場によってレビューの目的が変わるので、ルールも変わるべきだということ
  • 2人チームのプロトタイプにエンタープライズ式の多エージェント・証拠要求パイプラインを付ければ無意味な摩擦になり、決済システムに「テストが通ったからデプロイ」を適用すれば、緑のチェック付きインシデント生成機になる

いまレビューが実際にやっていること

• 人間がコードを書くと、意図はただで付いてくる。比較検討して捨てた代替案も作者の頭の中にあり、レビューはその推論を点検する作業だった
• 現代のエージェントも推論し、ときには思考過程（thinking trace）を可視化するが、その推論はdiffが生成された瞬間に捨てられ、PRには添付されない
• しかもそれは「どう実装するか」に関するエージェントの推論であって、「そもそも正しい仕事なのか」に関する人間の判断ではない
• その結果、レビューは目の前にある推論の点検から、記録されていない意図の再構成へと変わり、より難しく、より遅くなっている（441%長くかかる理由）

• AI Slop and the Software Commons（2026年論文）

  • Reddit・Hacker Newsの15スレッドにある1,154件の投稿を分析
  • ある開発者の表現では、エージェントPRのレビューは自分を「このコードを最初に見た人間」にしてしまう
  • 論文の表現では、レビューは「失われた意図を回復するようには作られていない」

• 解決策はツールの問題

  • 失われた意図は回復できる — 推論は存在していて、ただ捨てられているだけだからだ
  • エージェントに何をしようとしたのか、何を除外したのかを説明させ、それを**PRのdecision log（決定ログ）**として記録すれば、再構成コストのかなりの部分は消える
• 「AIがAIをレビューする」だけでは完全な答えではない。異なる事前知識を持つ第二のモデルは実際のバグを多く見つけられるが、「この変更は作る価値があるのか」という人間の判断は提供できない

ツールは良いが、宣伝文句どおりの理由ではない

• 専用のAIレビュー用ツールはもう十分に良くなっており、サイドプロジェクトを含むあらゆるものに、少なくともメインのコーディングエージェント（可能なら専用のレビューエージェントも）を回すことを勧めたい

• 主なツールごとの特性

  • CodeRabbit: 最も広く導入されており、独立したMartianベンチマーク（2026年1〜2月）でF1首位、精度は約49%で業界最高のrecall
  • Greptile: 精度を少し犠牲にしてrecallを確保。あるベンチマークではバグ検出率約82%（CodeRabbitの44%に対して）だが、偽陽性は多い
  • Anthropic Code Review: 自社エンジニアが誤りと判定した結果は1%未満で、実際にレビューを受けるPRの比率を16%から54%へ引き上げた

• 4レビューア並列実験（ベンダー外部の結果）

  • あるエンジニアがCodeRabbit・Sentry Seer・Greptile・Cursor BugBotを3週間半にわたり、実際のPR 146件・発見679件に並列適用
  • 617個のユニークなフラグ位置のうち、93.4%はちょうど1つのツールだけが検出し、2つが検出したのは6%、3つはほぼなく、4つすべてはゼロ
  • 4つのツールが同じ行を一度も一緒にフラグしなかった
  • 各ツールの強みは異なる。Greptileは正確性・アーキテクチャで偽陽性がほぼゼロ、CodeRabbitは最も広い網とワンクリック修正、Seerは運用障害の重大度に強い
  • 異質性（heterogeneity）が鍵であり、同じモデル4体は請求額が大きいだけの単一レビュアーだが、本当に異なる4人のレビュアーは、誰か1人では見つけられないバグをあぶり出す

• 実務上の指針

  • たった1つの最高のツールを探さないこと（そんなものはない）
  • 高リスク領域では、性格の異なる2つを意図的に併用すること（上の実験では日常的な正確性向けのGreptile + 運用障害の重大度向けのSeer）
  • ソロなら、良いレビュアー1つと本物のテストがあれば十分
  • マーケティングに関係なく、必ず自分のコードで測定すること。すべての結果は特定のコードベースに限定される

AIにもっと多くのレビューを任せるべきか

• 1年前なら異端だったこの問いが、経験豊富なエンジニアたちから出てきている — 機械がレビューのより多くの部分、あるいは大部分を担うべきなのか

• AIレビューが機能するという不都合な事実

  • Anthropicの発見では誤り判定は1%未満で、人間が見逃したバグを拾い、1日の30件目のPRでも疲れない（人間の信頼性が最も低い局面）
  • 一方で人間は追いつけない — レビューなしマージは31%増え、レビュー時間は3桁増加している
  • 正直なフレーミングは「AIにもっと任せるべきか」ではなく、「AIはすでにやっているので、これを意図的にやるのか、それとも人間が全部読んでいるふりをしながら放置するのか」である

• Loop engineeringの視点

  • ループの前提は、エージェントにプロンプトを入れる人間から離れ、エージェントにプロンプトを入れるシステムを作ることにあり、その中心には作業完了を判定するjudge（判定者）エージェントがいる
  • レビュアーは意図的に内部ループから設計上取り除かれる次の役割になる。作成の自動化から1年後には検証も自動化され、人間はさらに上位へ押し上げられる

• 閉じたループの危険

  • エージェントが書き、別のエージェントがレビューし、3つ目が判定するなら、それは**相関した盲点（correlated blind spots）**を持つモデルたちの閉じたループになる（特に同系統なら同じ地点で自信満々に一致しやすい）
  • 人間がまったくいない自信ありげな「looks good」は、**借り物の確信（borrowed confidence）**にすぎない — システムの確信がそのまま自分の確信になり、誰も本当に理解していない

• 人間は消えず、1段上へ移動する

  • すべてのdiffを読むことから、モデルに移譲できない部分を所有することへ移る。責任（accountability）が重要である
  • 人間が守るべき領域: これが作るべき正しい変更かどうかの判断、間違えると高コストな高blast radiusゲート、そして誰も仕様化していない挙動（モデルは存在するコードしかレビューせず、誰も書いていない要件はほとんどフラグできない）
  • human in the loopからhuman on the loopへ — すべてのPRを読む代わりに、システムをサンプリング・スポットチェック・監査し、間違えたときに本当に痛い箇所へ限られた注意を集中する

• Kun Chenの事例（元Meta L8エンジニア、ソロビルダー）

  • 1日に約40件のPRを出荷し、コードレビューは事実上停止、20〜30のエージェントを並列実行
  • 労力を計画（plan）へ移す — 事前に詳細な計画を書き、エージェントを数時間走らせ、計画の質が無人実行時間を左右する
  • 検証をやめたのではなく、意図を自分で先に書くことで「このコードを最初に見た人間」問題を半分解決している（人間が事後ではなく事前に理由を理解する）
  • セーフティネットなしでは働かない — No Mistakesと呼ぶ自動レビューゲートがマージ前にコードを検査し、エージェントが詰まればエスカレーション待ちになる
  • ただし、彼は大規模チームも10年物の地雷原システムも持たないソロビルダーであり、その条件は大半の読者には当てはまらない — 多数ユーザー向けチームにそのままコピーすれば、Farosの数値を自分のダッシュボードで再現することになる
• スペクトラムとしての結論: ソロ・ユーザーなしなら、AIにほぼすべてを任せるのは2026年時点で防御可能な立場であり、大規模・多数ユーザーでは、最初と2回目のパスや退屈な90%は機械に任せつつ、負荷を支える経路（load-bearing paths）には実際の人間を残す。人間をどれだけ置くかは罪悪感ではなくblast radiusで調整すべきダイヤルである

実際に何をすべきか

• 組織の原則: レビューの努力を間違えたときのコストに合わせ、安価で決定論的な作業をできるだけ前倒しし、人間の注意は人間にしかできない仕事のために予約する

• 作者ではなくリスクで層別する（Tier by risk, not by author）

  • 設定変更なら、リンターと一度の見直しで十分
  • 中核ビジネスロジックの経路修正ならフルスタック: 型、テスト、性質の異なる2つのAIレビュアー、そのシステムの所有者である人間、セキュリティパス
  • ボイラープレートに重いレビューを使わず、テストが緑だからといって大きな変更を通さないこと

• 高コストな尻尾を早く切る（Fast-fail the expensive tail）

  • Early-Stage Prediction of Review Effort（2026年1月）では、エージェント作成PR 33,707件を研究
  • エージェントは小さくよく定義された変更に強く、約28%はほぼ即時にマージされるが、主観的フィードバックを受けた瞬間に「ゴースト化」して、レビューの核心であるやり取りを放棄する傾向がある
  • 併発する2026年論文では、**レビュアー離脱が却下されたエージェントPRの38%**を占める
  • 研究者たちは、ファイル種類やパッチサイズのような安価なシグナルで、高維持コストPRを人間が見る前に予測する「サーキットブレーカー」を構築し、うまく機能した

• レビューに値する基準そのものを引き上げる

  • 解決策はリポジトリをロックすることではなく、証拠なしに到着した変更のレビューを拒否することである
  • レビュー前の要求事項: 変更の目的の記述、注釈なしの3,500行ではないdiff、テスト出力、実際に実行した証拠
  • 意図再構成という高コスト作業を自分で抱え込む代わりに、安く処理できる提出者へ差し戻す

• PRを意図的に小さく保つ

  • エージェントPRは大きくなりがちである（Farosデータでは平均51%大きい）。そしてレビュアー参加はPRがマージされるかどうかの最強予測変数の1つである
  • 大きくてレビュー不能なPRは、即座に拒否されるか、もっと悪くすると形式的に承認されるだけになる
  • エージェントに小さなコミットを作るよう指示すること。人間が実際に読めるdiffは、もはや礼儀ではなく設計上の制約である

• コードよりテスト変更を注意深く読む

  • 注視すべきエージェントの失敗モード: 挙動を変えたあと、新しく壊れた挙動に合わせてassertionを書き換え、テストを「修正」してしまうこと
  • 200件の編集済みテストの上にある緑チェックは、その編集が正しいと確認するまでは無意味である。大量のテストを書き換えるdiffはフラグとして扱い、先に読むべきだ
  • mutation testingの価値: カバレッジは行が実行されたかを示すが、ミューテーションテストはその行が間違っていたときにテストが気づけるかを教えてくれる

• CIを動かない壁として扱う

  • GitHubがレビュアーに警告するパターンを監視すること: 削除されたテスト、スキップされたlint、引き下げられたカバレッジ閾値、すでに存在するのに重複したヘルパー、プロンプトへ流れ込む信頼できない入力
  • 最後の項目は特に重要 — エージェントが作った機能はprompt injectionの新しい発生源であり、ユーザー制御テキストをLLM呼び出しにそのまま渡すと、脆弱性はdiffには見えず、後から到着するデータに潜伏する
  • エージェントは合格のために悪意なくCIを弱める（勾配降下は緑へ行く最も安い道を探すため）。決定論的ゲートは、自信満々の段落で判定を覆せない唯一の部分なので、厳格に保つべきである

• マージは人間が所有する

  • モデルは呼び出し（page）されることも責任を取ることもできないため、マージボタンを押す人が所有する
  • AIレビューが落ち着いた自信ある声で「looks good」と言うとき、それは必ずしも獲得された確信ではない
  • すべてのAIレビューを判決ではなくセンサーとして扱うこと — 決定ではなくデータである

チームを運営しているなら何を意味するか

• 出荷の制約条件は、もはやコードをどれだけ速く書けるかではなく、信頼される人が変更の正しさをどれだけ速く確信できるかである
• 生成をボトルネックと見てレビューを無料扱いする計画は、速度ダッシュボードを緑に保ったまま静かに停滞する
• Farosの報告は、アウトプットが増えてもQA・レビュー作業は増えると明言しており、レビューギャップを埋める前に「AIで速くなった」としてエンジニアリング人員を減らすのは危険である
• 3桁増に膨らんだレビュー時間というシニアエンジニア税は、最もボトルネックにしてはいけない人たちに最も重くのしかかるが、マージ済みPRだけを数える指標には現れない
• オープンソースメンテナーはこの壁に最も早く、最も強くぶつかっている — もっともらしいが中身の薄い貢献の継続的な流入は、善意であっても実際のトリアージ時間を消費し、これが炭鉱のカナリアであり、企業が次に来る
• うまく対処している組織は、レビュー能力をAIが生み出した余裕ではなく、測定し、守り、意図的に消費すべき実在資源として扱っている

書くことは安くなったが、理解はそうではなかった

• 両極端の画一的な答えを受け入れないこと — ソロ・ユーザーなしにとって、エンタープライズのchurnや重複への恐怖談は今日の火事ではなく将来リスクであり、テストに依存して重要なものだけレビューしつつ、先送りした仕事が依然として負債として残ることを正直に認めるべきだ
• 大規模・多数ユーザーなら、ここにあるすべての警告数値は自分の話であり、有効なのは層別化・証拠要求・意図的に異質なレビュー工程、そしてマージを所有する人間だけである
• スペクトラム全体で変わらないのは根本的な経済学だ — 書くことは安くなったが、理解することは昔からそうであったように高コストなまま残っている
• これからうまくやるチームは、最も多くのコードを生成するチームではなく、実際に信頼できるレビューシステムを築くチームであり、「テストが通った」と「人間がそれが何で、なぜそうするのかを理解している」を決して混同しないチームである
• Simon Willisonの表現を借りれば、仕事の本質は動作することを証明したコードを届けることにある — エージェントはこれを変えず、証明を副次的作業ではなく仕事の中心にした
• その背後に立てるほどシステムを十分に理解する能力こそ、ソフトウェアにおいて最も持続的で興味深い技能であり、いまはそれを極めて上手くなるにはこの上なく良い時期である